How to Write a Statement of Work
A statement of work is not a proposal and it is usually not the contract. It is the document both sides reach for when they disagree, which means it is written for a reader who is annoyed, in six months, and was not in the room when any of it was agreed.
Write it for that person and it will also do its everyday job, which is to stop the disagreement happening at all.
The eleven sections, in order
- Parties and dates. Who is doing the work, who is paying, when it starts, when it ends. Boring and load-bearing.
- Background, in two sentences. Why this work exists. The reader in six months needs it and everybody else will skip it.
- Objectives. The business outcome, not the task list. “Reduce the time it takes to onboard a new customer” is an objective. “Build an onboarding form” is a deliverable, and it belongs three sections down.
- Deliverables. Each one a noun with a format attached. Not “training” but “a two-hour session, recorded, plus a written handbook as a PDF”.
- Out of scope. Named, specific, and drawn from arguments you have already had on other projects.
- Acceptance criteria. Per deliverable. This is the section that matters.
- Assumptions and client dependencies. What you are relying on them to do, with dates and a named person.
- Schedule and milestones. Dates tied to deliverables, not to weeks of effort.
- Price and payment schedule. Tied to milestones wherever you can manage it. A payment triggered by a date is a payment argued about; a payment triggered by an accepted deliverable is a payment.
- Change control. One paragraph. The most commercially useful paragraph in the document.
- Sign-off. Names, roles, dates.
Acceptance criteria: turning “done” from an opinion into a test
The single most common defect in a scope document is a deliverable with no definition of finished. “Deliver a redesigned website” — delivered when? When it is live? When they like it? When the fourth round of changes runs out?
An acceptance criterion answers one question: what would have to be true for this to be signed off?
Weak: “A redesigned homepage, delivered to the client’s satisfaction.”
Usable: “A homepage design covering desktop and mobile, in Figma, using the agreed brand palette, reviewed in one consolidated round of feedback and accepted in writing within five working days of delivery. If no response is received within ten working days, the deliverable is treated as accepted.”
That second version is not longer because it is legalistic. It is longer because it contains four things the first one left to chance: the format, the standard, the review process and what happens when the client goes quiet. The last of those is the one that saves the project, because a deliverable that can never be accepted can never be invoiced.
Creative deliverables are the hard case, because “accepted” there is partly a judgement. The criterion cannot remove the judgement, but it can fix the process around it — how many rounds, in what form feedback arrives, who consolidates it — and the argument that the work meets the brief belongs in a separate document sent with the work. How to write a design rationale covers that one.
Client dependencies are where the overrun actually comes from
Most projects that run late do not run late because the work was harder. They run late waiting on somebody else’s access credentials, somebody else’s legal review, somebody else’s decision about which of two logos to use.
So name them, and name what happens when they slip:
- What you need, specifically — “admin access to the analytics account”, not “access as required”.
- Who on their side owns it. A named human, not a department.
- By when.
- What happens if it is late. The usual and fair answer is that the schedule moves by the same amount, and it costs you nothing to say so in advance and everything to say it for the first time in week six.
Change control is not paperwork, it is how you say yes
Freelancers and small teams often leave change control out because it feels bureaucratic for a project between five people. The result is that every new request becomes a personal negotiation, and after three of them you are either resentful or working for free.
One paragraph fixes it. It needs four things:
- How a change is requested — in writing, to whom.
- Who prices it, and how quickly.
- Who has to approve it before work starts.
- What it does to the schedule, stated as its own consequence rather than folded into the price.
With that paragraph in place, “can we also add …” becomes a form of good news instead of a threat. Without it, saying yes is the only polite option available to you.
What to cut
- Adjectives. “Robust”, “seamless”, “best-in-class” are unenforceable in both directions — you cannot be held to them and you cannot hold anyone to them.
- Your methodology, unless a deliverable depends on it.
- Anything you would be embarrassed to have read aloud in a dispute. That is the honest test for a sentence in a scope document.
- Duplicated commercial terms. If your master agreement covers liability and IP, do not restate them here in slightly different words. Two versions of a clause is worse than one.
The read you should worry about
Scope documents produce one signal that genuinely matters, and it is a negative one: signed quickly, having barely been read.
If a document like this was opened for well under a minute and then approved, you do not have an agreement — you have a signature on an assumption. That is not a reason to chase anybody. It is a reason to spend ten minutes on your next call walking through the exclusions and the dependency list out loud, because those are the two sections that will be disputed and neither of them has been read.
Be clear about the limit of the signal, though. A tracked link tells you the document was opened, by whom where that can be established, for how long, and how many times. It does not tell you which clause somebody stopped at — there is no per-section heatmap, and any tool implying otherwise is guessing. What is and is not measured is set out on the features page, limits included.
Related: what to put in the quote that precedes this document, and the handover document that closes the same project — the two documents that between them decide whether the scope you wrote survived contact with delivery.