How to write a statement of work
Almost every project dispute is a disagreement about whether the work was finished. This walks through writing a SOW that answers that question in advance, using one engagement throughout.
The short version
- Write the acceptance criteria first. Everything else follows from what "done" means.
- Deliverables are artefacts with formats and dates, not activities.
- Every dependency needs an owner by name, not a department.
- Add a deemed-acceptance window so silence has a consequence.
- Change control decides what happens when scope moves. Without it, it moves for free.
- Say which master agreement governs, so liability is not re-litigated here.
One deal runs through this guide: A customer portal for Northwind. Three phases, fixed price, and a question on the call about whether the portal work is inside this SOW or a separate phase.
-
01Start at the end: what does done mean?
Write acceptance criteria before anything else. If you cannot say how each deliverable will be judged, you do not yet know what you are agreeing to build, and no amount of scope prose will cover for it.
On this deal"Processes 10,000 order records in under 60 seconds with zero validation errors, verified by Priya in a shared session." Not "the client is satisfied". -
02Name the governing agreement
The SOW describes the work. The master agreement carries liability, IP, confidentiality and payment terms. Saying which one governs stops you re-negotiating them in every SOW, and stops the SOW quietly contradicting them.
On this deal"This SOW is issued under the Master Services Agreement dated 4 January 2026." -
03Turn activities into artefacts
A deliverable arrives, in a format, on a date. If a third party could not tell whether it turned up, it belongs in the scope section as an activity, not in the deliverables list.
On this dealNot "integration work". Instead: "a deployed integration against the staging order API, plus a written runbook in PDF, by 14 March". -
04Write the out-of-scope list
Explicitly what is not included. This is the cheapest section in the document and the one that prevents the most expensive arguments, because it converts an assumption into a written agreement.
On this deal"Out of scope: migration from the legacy CRM, changes to the ordering system, and any work on the mobile app." -
05Give every dependency an owner
By name, not by department. "The client will provide API access" has no owner and therefore no deadline. A named person with a date is a commitment.
On this deal"Sam provides staging API credentials by 3 March. Each week of delay moves phase two by one week." -
06Add a deemed-acceptance window
The clause that stops a project hanging open forever. A named reviewer, a number of business days, and what happens if they say nothing. Without it, a client who goes quiet suspends the project indefinitely.
On this deal"Priya reviews within 10 business days. Absent written rejection with reasons, the deliverable is deemed accepted." -
07Price it against the phases
Tie payments to accepted deliverables rather than to dates where you can. A payment triggered by a date arrives whether or not anything was delivered, which sounds good until you are the one delivering.
On this deal"$18,000 on acceptance of phase one, $62,000 on acceptance of phase two, $16,000 on completion." -
08Write the change control clause
How a change is requested, how it is priced, who may approve it and that work does not start before approval. One paragraph, and it is the difference between scope moving and scope moving for free.
On this deal"Changes are priced in writing and approved by Sam before work begins. No change proceeds on a verbal instruction."
Four sentences, before and after.
Each of these is a line that appears in real documents, and the reason it fails.
Deliverable: project documentation.
Deliverable: a written runbook in PDF covering deployment, rollback and on-call escalation, delivered by 14 March.
The first cannot be judged, so it cannot be finished, so the final payment has no trigger.
The client will provide access to relevant systems in a timely manner.
Sam provides staging API credentials by 3 March. Each week of delay moves phase two by one week.
"Timely" is whatever each side needs it to mean at the time. A name, a date and a stated consequence are enforceable.
Acceptance: the client will review and confirm the deliverable is acceptable.
Priya reviews within 10 business days. Absent written rejection with reasons, the deliverable is deemed accepted.
The first has no deadline and no consequence for silence, which is the most common way a project stays 90% finished for a quarter.
The four common ways this goes wrong.
- Acceptance criteria written as feelings
- "To the client's satisfaction" is not a criterion, it is a veto. Something a third party could apply is the standard to aim for.
- No deemed acceptance
- The client goes quiet, the deliverable is neither accepted nor rejected, and the payment triggered by acceptance never triggers.
- Dependencies without owners
- A dependency on "the client" is a dependency on nobody, and its slippage becomes your delay.
- No change control
- Every small request is free because there is no mechanism to price it, and the twelfth small request is the one that makes the project unprofitable.
How much detail?
Enough that someone with no context could read it and tell whether the work was delivered. That is the whole test, and it is a more useful guide than a page count. If a section could not be used to settle an argument, it is decoration.
| Simple, one deliverable | 2–3 pages |
|---|---|
| Multi-phase project | 6–10 pages |
| Regulated or safety-critical | Longer, with testable criteria per deliverable |
| No master agreement in place | Add liability, IP and confidentiality, roughly doubling it |
Straight answers.
What is the difference between a scope of work and a statement of work?
The scope of work is one section, describing the activities. The statement of work is the whole document: scope plus deliverables, acceptance criteria, schedule, price, assumptions and change control. The terms get used interchangeably, which matters when one side means the section and the other means the document.
What makes good acceptance criteria?
That a third party with no context could apply them. Measurable, with a named reviewer and a time limit. Pair them with a deemed-acceptance window so that silence has a defined consequence rather than suspending the project.
Does a SOW replace a contract?
No. It normally sits under a master agreement that carries liability, IP, confidentiality and payment terms. If no master agreement exists, the SOW has to carry them itself and becomes a much longer document.
Who should write it?
Whoever scoped the work, because the detail that matters is in the conversation rather than in a template. The practical route is to write it from the call that scoped it, which is what DocuDeal does from a transcript.