Much of the work I perform for high tech enterprises deals with Statements of Work or Scopes of Work (there may be other names out there as well – I will call them SOWs.)

The SOW can be a major stumbling block in a project if it is not properly written. One reason it often is not is that the people working with the customer to develop the SOW are usually stretched thin, and producing a clear, concise SOW takes time, concentrated effort, and expertise.

Here are some of the major SOW requirements that will be discussed below:

  1. Tie every SOW to a Master Services Agreement (MSA) that includes the key provisions.
  2. Have a strictly limited, but available, method of contradicting the terms set out in the MSA through specific wording in the body of the SOW.
  3. Take care in wording the pricing sections of the SOW to prevent pricing meant for a short term to be locked in for a much longer period.
  4. Include a change order process (actually contained in the MSA but referring to the SOW) that sets out strict requirements, without which a change to the scope of work is invalid.

Consider each of the requirements in more detail:

  1. To have a workable SOW, tie the document to a Master Services Agreement or some other document that sets out the terms and conditions under which one company will provide product and/or services to the other. Include in the MSAs sufficient detail so that the parties know exactly what to expect when an SOW is executed, and work begins. General requirements for a proper MSA will be covered elsewhere. Elements of a good MSA as it relates to the SOWs include:
    • The minimum requirements for SOWs to be valid under the MSA
    • Escalation procedures to handle minor disagreements about the services before they become major ones
    • A strict change order process for adjusting the SOW during the work term. This is frequently omitted, which can be a costly error. Without a clear, step-by step procedure, changes of scope are made in the field and on the fly. Margin erosion for the service provider and disagreements about the final deliverables are potential results.
    • The clear delineation of what intellectual property will be owned by whom when work is performed. If this section is not properly drafted, the parties may have a short and stormy relationship.
  2. There are always special cases where the particular SOW does not fit the terms of the MSA. Reasons for such deviations may be as simple as extended payment terms or as complex as a different allocation of intellectual property (IP).
    • Make the MSA rule in most cases if there is a contradiction between the documents. Then add language that allows for the SOW to overrule portions of the MSA if specific sections of the MSA being modified are referenced by section number. Then make it clear the exception applies only to that one SOW.
    • An exception would be an SOW that specifies unique parameters. For example, an SOW for the production of pictures or videos may include a “style guide” that sets out the quality of the pictures, time of the videos, the number of “talent” included, etc. In the unlikely event there is a conflict between the MSA and the style guide, the latter should rule. This can be specified in the SOW.
  3. Place pricing in the SOW unless, for example, the party performing the work will charge the same hourly rate regardless of what is in the SOW. These cases are rare.
    • Serious errors can occur in the pricing section. I have handled many SOWs stating that the price for a quoted service will apply for the term of the Agreement.” The SOWs for that company defined the MSA as the “Agreement” in the opening section (to tie the documents together, as required). The writers of the SOWs meant for the price to be good for the term of the SOW, but as they dealt with SOWs and not MSAs, thinking of the SOW as “the Agreement” was an easy error to make. MSAs frequently have a term of three years or more, or are evergreen, renewing automatically unless one party objects. Locking in the price for that term could be very costly to the service provider.
  4. Absolutely define what is going to be done by the performing party in a way that is so clear that there is no room for controversy. This requires a lot of work, and it is the place where most companies get into trouble. If the SOW is inexact, inaccurate, poorly written, and full of errors of omission, or all of the above (they go hand-in-hand), the room for disputes between the parties is huge, and project delays or even cancellations are likely.
    • One test is if someone with a moderate understanding of the service to be performed (especially when they are high-tech) cannot decipher what the services and/or the products to be delivered are, then the SOW is inadequate.
    • When the SOW is going to describe complex, high-tech operations, the developers or other technical people that will perform the work should review the schedule, each deliverable, any deliverable testing and other technical concerns for correctness.
      • In one memorable case, I finally got the CTO into a conference room, only to discover that the SOW described, in every instance, services the company could never perform. It took over four hours of difficult work to rewrite the entire SOW so that it accurately described the work that would be performed.
  5. Use good grammar and concise writing for clarity. Good grammar reduces the possibility of misinterpretation. Being concise makes for a shorter cleaner document. It also forces you to understand the point you wish to make well enough that extra words are not needed to express it. Even when there are bullet points rather than paragraphs, how those bullets convey the information is critical.
  6. Include an execution block. It is best that both sides agree to the terms of the SOW in writing.

It is important for the service provider to locate and utilize someone who can create an SOW that will serve both parties as an accurate guide for the term of the project. This will speed the process and avoid disagreements along the way.