What is a Statement of Work?
A Statement of Work, or “SOW” as they are sometimes called, is a common document executed by service providers and customers. There is no one form of Statement of Work, and they vary widely in practice. Typically, a Statement of Work contains the details of work to be done for a service provider for a customer and other pertinent terms such as the type and nature of services to be performed. In some Statements of Work where a service provider is creating items for a customer, the Statement of Work will also detail these items which are often called “deliverables”.
Is a SOW an Agreement?
A Statement of Work can certainly be deemed to be a stand-alone agreement between a service provider and a customer, but that is usually not the intent of the parties. A Statement of Work is most often tied to a master services agreement that addresses important legal terms such as warranties, limitations on liability, indemnification and other terms and conditions affecting the rights and obligations of the parties. In most cases, the parties negotiate a master services agreement at the outset of their relationship, and provide that each Statement of Work is governed by its terms. This enables the parties to execute Statements of Work that are subject to the master services agreement without having to renegotiate the master services agreement each time. This saves the parties time and expense, and lets them focus on the actual services and deliverables to be performed and described in the Statement of Work.
Should I Execute a SOW Without a Master Agreement?
Typically, no. The only exception would be if the Statement of Work also contained the appropriate provisions that a master agreement is intended to cover. If a service provider or a customer executes a Statement of Work that does not address key legal terms and conditions, they will expose themselves to risks that should have been properly addressed and negotiated in a master agreement at the outset. This raises the risk profile of the transaction significantly, and can often result in unwanted statutory terms being imputed into a transaction that could otherwise have been avoided. Parties that intend to do business together over time typically negotiate a master services agreement and an initial SOW at the same time. Then, subsequent SOWs can be added. In some cases, the form of the SOW to be used is attached to the master services agreement itself. In other cases, especially where services and deliverables (or delivery modalities) may change significantly, the parties don’t include a form of SOW with the master services agreement, or may execute separate master agreements to cover different issues.
A master services agreement often contains many defined terms and other hooks that tie to the SOW. These allow a Statement of Work to be streamlined and avoid unnecessary duplicative content. When preparing a SOW, the master services agreement should be reviewed to make sure that the appropriate items from it are properly addressed in the SOW.
Is There a Form of SOW that Fits All Master Agreements?
No, the SOW should be customized to match the framework set out by the master agreement to which it relates. In some cases, a master agreement covers a wide variety of potential services, deliverables and governing terms. For example, in some cases in the technology sector, a master agreement could cover services, software licensing, creation of custom deliverables and a variety of related terms. Other master services agreements may be purely services based, such as master services agreements where the service provider is acting to augment existing customer resources with respect to one or more particular projects. Do not assume that a form of SOW matches a master agreement. Review both together to ensure that they adequately address the subject matter of the relationship. If they do not, a new agreement or form of SOW may be needed, or both.
What are Common Terms Found in a SOW?
A Statement of Work can contain a variety of terms and conditions, many of which will tie back to the master agreement under which the Statement of Work is governed. Here are some examples of concepts that are often found in a SOW (the list is by no means exhaustive):
- Objectives. A SOW often contains a statement of the objective of the services and deliverables. This is often a summary statement that tries to define what will be done at a high-level, and serves as a reference point for other elements of the SOW. In some SOWs, where the services and deliverables are simpler and easy to define, the objective can be simple or omitted altogether.
- Economic Terms. How much due the services and deliverables cost? When will payments be due? Up-front, on a milestone basis or pursuant to another mechanism? Will the services and deliverables be provided on a time and materials basis and billed monthly or bi-weekly, is there a fixed cost or perhaps a hybrid approach? Are there any third party costs that are to be billed by the service provider?
- Specifications. When provided and delivered, what do the services and deliverables have to conform to? What standards and criteria apply? Are there any third party standards, guidelines or other principles that should be utilized in addition to what the parties have agreed? Being objective and specifying in as much detail as possible can best set the expectations of the parties and decrease the likelihood of disputes. Think features, functionality, interfaces, user experience and other areas that can be described in concrete terms.
- Timing. Are there deadlines for the delivery of services and deliverables? What factors could affect the deadlines? Think about factors affecting the service provider and the customer, as well as possible third-party issues. For example, if a project involves multiple vendors and one delays, it could result in delays by the service provider who is waiting for inputs needed to progress their work.
- Acceptance Testing. If not covered directly in the master services agreement, what is the process for accepting the performance of the services and/or deliverables? In some cases, the methodology used in the performance of the services (e.g., Agile development) will be utilized rather than a more legacy waterfall approach to acceptance testing.
- The Story. While a master services agreement may contain more “legalese”, a SOW should tell a story. Ideally, you want the SOW to be as clear to a third party as it is to the service provider and customer. If there is a dispute and the the SOW doesn’t lay out what is happening in terms that are easy to understand (or whose meaning is not readily ascertainable) it will be hard for a party to prove what its rights and obligations are without involving third parties who are experts in their field.
- Place of Performance. Services are often performed at a client’s location, at a service provider’s location, remotely, or in certain cases at a third party location. In some cases, it is a combination of all of these locations. The parties should specify where services are to be performed, and ensure that the costs and expenses involved are
- Assumptions & Conditions. Don’t assume something is included or addressed, spell it out if it is important. This helps align the expectations of the parties. If a party is relying on the other for certain items, provide the appropriate details. If one party is supposed to be granting access to the other to certain third party systems or products, make it clear and identify all third party products involved. If cost, timing or other factors may change if an assumption is not fulfilled, make the consequences clear. The same logic applies to conditions. If a party needs something as a condition to being able to perform, the condition should be spelled out an allocated to the party who is tasked with satisfying it.
- Expansion and Contraction. Is it possible that the quantity of services and deliverables could expand or contract? If so, the SOW should address how this can occur. Often, a form of change order is used for organic changes, while other changes are identified as requiring an amendment to the SOW. In other cases, the expansion or contraction is set forth directly in the SOW (e.g., a pricing table may be utilized to add more users to a deliverable, add a new customer location being serviced, etc.)
- Term and Termination. A Statement of Work often has its own term and sometimes its own distinct termination provisions. In some cases, either party is able to terminate for convenience, while in others a SOW is a fixed agreement under the terms of the master services agreement until a “for cause” termination event occurs.
- In-Scope and Out-of-Scope. During the discussions of a potential project, a service provider and customer often discuss areas that are considered in-scope or out-of-scope. Sometimes they forget to do so. As part of preparing a SOW, the parties should think through these issues and address them. Sometimes these items are small, such as excluding a remote customer site from the scope of on-site services. In other situations, these items are larger. For example, a service provider might agree to provide deliverables meeting certain compatibility specifications with third party products, but not others. Or, a service provider may want to make clear that the services will not include integrating the deliverables with certain customer legacy systems. These terms can also be used to help address “scope creep”, which can occur in projects as the services and deliverables are being performed. By identifying issues that are not covered by the SOW (and potentially covered by future follow-on SOWs), the parties can focus their energies on the tasks at hand and decrease the likelihood of disagreements over what the SOW is intended to cover.
- Reporting and Project Management. When a longer-term engagement is envisioned, or a particular project is complex and will have inputs from multiple individuals from the service provider and/or customer, a SOW often provides for a mechanism for reporting on the status of the project and may contain provisions identifying those individuals working for each party (and sometimes third parties) who will be involved in managing the project. These provisions can be helpful in keeping a project on track, identifying issues or problems early, and providing for points of contact who have the authority to approve decisions that may be needed to prevent issues from blocking the progress of a project.
SOW Review Process
A Statement of Work should be reviewed by those members of the service provider and customer teams who have been directly involved in discussing the potential project the SOW covers, as well as other stakeholders who will utilize the services and deliverables themselves. In addition, those responsible for handling the contracting function at an organization (whether in-house counsel or contract specialists or outside counsel) should review the SOW for content, coverage and conformity with the master services agreement under which the Statement of Work will be governed. It is often helpful to also have others not involved in the project review a draft Statement of Work, as they can often spot issues and gaps that those who are more involved may have missed.
Copyright 2019, Geoffrey G. Gussis. Learn more about me, the legal services I provide, and other articles I have written. All rights reserved. Contact: firstname.lastname@example.org or (732) 898-0549. Licensed to practice in New Jersey and New York.