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.

Information to customize

• Client's name

• Supplier's name

• Reference to the governing master services agreement (parties and date)

• Project name

• Scope of work and deliverables

• Milestone schedule (dates and deliverables)

• Acceptance process for deliverables

• Key personnel assigned by the supplier

• Dependencies on the client (information, access, sign-off)

• Pricing for this SOW

• Payment schedule (tied to milestones or otherwise)

• Change control process for varying scope

• Date of this statement of work

Customize your template

Frequently asked questions

What is the difference between a master services agreement and a statement of work?

The MSA sets out the general legal terms that apply to the whole commercial relationship (liability, IP, confidentiality, termination). Each SOW is a project-specific document, issued under the MSA, that defines the scope, deliverables, timeline and price for a particular piece of work.

Can I use an SOW without a master services agreement?

You can, but it then needs to function as a stand-alone contract with its own full legal terms (liability, IP ownership, termination, governing law), not just project mechanics. This template assumes an MSA is already in place and governs those wider terms.

What happens if a deliverable is rejected at acceptance?

The SOW should define a remedy period during which the supplier can fix the identified defects and resubmit for acceptance, rather than leaving rejection undefined and open to dispute.

Why is a change control process important?

Without a defined process, scope tends to drift informally (through emails or verbal instructions), which is very difficult to enforce or price fairly later. A written change control process protects both parties.

Should payment be tied to milestones or to time elapsed?

Tying payment to milestone acceptance is generally safer for the client, since it links payment to actual delivery of agreed, accepted work rather than simply to the passage of time.

Related templates