In the world of professional services, technology outsourcing, and complex vendor relationships, the Statement of Work ("SOW") is not just a formality, it is a critical backbone of any successful project. A vague or poorly drafted SOW can introduce issues that will jeopardise a project, such as service quality degradation, scope creep, missed deadlines, disputes, and cost overruns. In this article, we set forth some key lessons learned from real-life engagements that highlight importance of precisely and accurately drafting SOWs.
Scope clarity: Understand the services
It is important to clearly understand the scope of services, technical requirements, assumptions, and retained responsibilities. If these are not clearly articulated in the SOW, it can result in scope creep. An example is where a vague description of the software to be deployed or implemented is included with no specific functionality or software features listed. This could result in the deployment of the software in a manner which does not meet the customer's business requirements. This could ultimately result in contractual disputes.
It is recommended to use exact and precise language to define the scope of the services and to avoid broad phrases such as "implementation" or "support" without further including further specific details of what is required technically and operationally. Further, clearly document deliverables, modules, tools, features, and specifications. It is also important to clarify assumptions, such as which third party tools will be used, licencing requirements, etc.
Link deliverables to milestones and payments
Once the deliverables have been clearly documented, these should be linked to acceptance testing procedures, milestone dates, and payments. In large and critical IT outsourcing contracts, it is a good practice to link deliverables to retained amounts which will only be paid to the service provider upon the deliverable successfully passing acceptance testing. An example of how this could become an issue is where payment obligations are tied to specific dates with no retained amounts and acceptance testing, where the customer will be liable to pay even in the case of a non-functional deliverable or service. By linking deliverables to retained amounts, this protects the customer and incentives the service provider to meet deadlines.
Clearly define and document roles and responsibilities
Both customer and service provider roles and responsibilities should be clearly delineated and documented in the SOW. Any customer retained responsibilities should be specified in the SOW and linked to specific deliverables. This will prevent the situation where a service provider claims that it cannot deliver a specific deliverable as the customer was required to perform a specific action, such as procure a specific third party licence or to provide access to client systems. In complex IT projects, it is recommended to include a RACI Matrix (Responsible, Accountable, Consulted, Informed) to document each party's roles and responsibilities.
Change control procedure
IT projects often evolve. There could be regulatory changes or other changes which necessitate a change to specific functionality of software, software modules, or pricing, or there could be an increase or reduction in the scope of services. A change management process is key to governing any contractual changes and any changes to pricing, contractual terms, and the scope of services should follow a formal change control procedure. Therefore, a robust change control procedure must be included which address, inter alia, how changes are proposed, reviewed, approved, and billed.
Change control is critical to avoid 'unforeseen costs' where a service provider performs additional work and invoices the customer claiming that the additional work formed part of the scope of the services. This will ultimately prevent payment disputes down the line.
Acceptance testing
Every deliverable and service component must have clearly defined and documented acceptance testing criteria and procedures. Customers should avoid 'deemed acceptance' provisions where a deliverable will automatically be deemed to be accepted by the customer after a certain period of time. The risk for the customer is that deficient deliverables could be deemed to be accepted, and once accepted, there may be little to no contractual recourse available for remediation or reperformance of the deficient deliverable.
Legal terms
In reality, most contractual disputes do not occur under a Master Services Agreement (which contains key legal clauses) but rather under an SOW (which contains commercial and service-specific clauses). Customers should ensure that SOWs do not contain overarching legal provisions which overwrite key Master Services Agreement clauses, such as warranties, indemnities and liability provisions.
SOW template refreshes
SOW templates are helpful starting points, especially for consistency across projects, however every SOW must be tailored to the specific project in question. This entails removing irrelevant clauses, updating terminology, and including project timelines and deadlines. Ultimately, the SOW should be treated as a bespoke document and not a fill-in-the-blank template.
Therefore, a precisely drafted SOW is more than a mere project document, it is a service and commercial document which is key to any successful project. It is important to ensure that SOW contain key clauses including but not limited to acceptance testing, deliverables, service-specific terms, project and delivery plan, etc. For more information on drafting precise SOWs, please contact our experts as follows:
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
