Statement of Work (SOW)

Overview

A statement of work (SOW) is a project-specific document that defines the scope, deliverables, timeline and pricing for a particular piece of work, executed under the umbrella of a broader master services agreement (MSA) that has already been agreed between the parties. This two-tier structure — a stable MSA setting out general legal terms (liability, IP, confidentiality, termination), with individual SOWs for each project or phase — is standard commercial practice in England and Wales for IT, consultancy, marketing and similar services engagements, because it avoids renegotiating the whole legal framework every time a new piece of work is commissioned. Relationship to the master services agreement: an SOW should always state expressly that it is issued under, and governed by, the terms of the parties' existing MSA (identified by date and parties), and that in the event of any conflict between the SOW and the MSA, the MSA terms prevail unless the SOW expressly states otherwise for that specific project. An SOW used without an underlying MSA is really a stand-alone services contract and should be drafted with full contract terms (liability, IP, termination etc.), not just project mechanics — this template assumes an MSA is in place. Scope and deliverables: the single most important part of an SOW is a precise, unambiguous description of what will be delivered — specifications, quantities, format, and quality criteria. Vague scope ('marketing support', 'ongoing consultancy') is the leading cause of scope-creep disputes and non-payment disputes under SOW-based engagements. Milestones and acceptance: the SOW should set out a milestone schedule (dates and associated deliverables), and an ACCEPTANCE PROCESS — how the client will review and either accept or reject each deliverable, and what happens if a deliverable is rejected (a right to remedy within a defined period is standard). Payment is commonly tied to milestone acceptance, not simply to time elapsed, which protects the client against paying for undelivered or defective work. Change control: because scope inevitably evolves, the SOW should include a change control mechanism — a defined process (usually a change request form, agreed in writing by both parties) for varying scope, timeline or price, rather than allowing scope to drift informally through email exchanges, which is very difficult to enforce or dispute later. Resourcing and dependencies: for services-heavy SOWs, it is good practice to name the key personnel assigned (particularly if the client is relying on specific expertise) and to record any dependencies on the client (information, access, sign-off) that could affect the timeline if not met. When to use: for any discrete project or phase of work commissioned under an existing master services agreement, where the parties want to fix scope, deliverables, milestones and price for that specific piece of work without renegotiating the underlying legal terms. Common pitfalls: issuing an SOW with no reference to a governing MSA (leaving basic legal protections undefined); vague deliverable descriptions; no defined acceptance process; and no change control mechanism, leading to unmanaged scope creep. This template is a drafting aid only and should be reviewed alongside the parties' MSA.