Most Statements of Work fail before anyone starts delivering. Not dramatically, and not necessarily in a way that shows up in the first month. They fail because the document described activity rather than outcomes, and everything downstream inherited that ambiguity.
The pattern is well documented. In the Institute of Project Management’s 2026 survey, 45% of practitioners named unclear objectives as the most frequent trigger of scope creep. A SoW is the artefact where those objectives are supposed to be settled.
The three ways SoWs usually go wrong
Too vague.
The deliverable is described in language everyone can agree with and nobody can measure. “Improve data quality.” “Support the migration.” If two reasonable people read the clause and picture different end states, it will be disputed later.
Too rigid.
The opposite failure. Every task specified in advance, on the assumption that nothing will be learned during delivery. When reality intervenes, the change control process becomes the project.
Too contractor-shaped.
The document names people, day rates and hours rather than outputs and acceptance criteria. That is contingent staffing with a SoW cover page. It carries none of the accountability benefits and attracts all of the IR35 scrutiny.
What a deliverable SoW contains
An outcome, expressed as an end state.
Not “conduct discovery” but “a documented and signed-off target architecture covering X, Y and Z, delivered by [date]”. The test is whether an independent third party could look at the result and say yes or no.
Acceptance criteria written before work starts.
Every deliverable needs a definition of done, agreed while nobody is under pressure. Criteria negotiated mid-delivery are negotiated from the weaker position.
Explicit exclusions.
What is out of scope matters as much as what is in it. Most disputes are about assumed inclusions, not stated ones.
Named dependencies and client obligations.
Environment access, availability of subject matter experts, sign-off turnaround times. A supplier cannot hold a date if the things it depends on are undefined.
A proportionate change mechanism.
Small adjustments should not require a governance board. Material changes to scope, cost or date should. Say which is which, and who decides.
Milestones tied to something verifiable.
Payment against elapsed time reintroduces the problem the SoW was meant to solve. Payment against accepted deliverables keeps incentives aligned.
Handover as a deliverable in its own right.
If knowledge transfer is a closing courtesy rather than a line item, it gets compressed the moment the schedule tightens.
How to stress test a draft
Read the document as though the relationship has already gone wrong. If delivery slips by six weeks, does the SoW tell you who is accountable and what happens next? If two people in the room would describe “finished” differently, the gap is in the specification, not in the goodwill of the parties.
Then check the verbs. Activity verbs, support, assist, contribute, advise, describe effort. Outcome verbs, deliver, migrate, hand over, certify, describe a result. A SoW built mostly on the first set is a timesheet in disguise.
None of this is a pessimistic exercise. Well-specified SoWs make good relationships easier to maintain, because there is less left to argue about.
Where suppliers should be pushing back
A supplier who accepts a vague SoW without challenge is telling you something. Credible partners ask uncomfortable questions at the scoping stage: what does success look like in measurable terms, what happens if a dependency slips, and who has authority to accept a deliverable. A bidder comfortable signing something unmeasurable is managing commercial risk rather than delivery risk.
This is closely tied to whether the work should be a SoW at all. If the requirement is genuinely open-ended, contract resource may be the more honest structure.
Send us the draft
We scope, price and deliver Statement of Work engagements for enterprise technology and transformation programmes, and we read a lot of other people’s SoWs in the process.
If you have a draft, or a requirement you are trying to shape into one, send it over. We will tell you plainly where the risk sits, which clauses tend to get disputed later, and whether a SoW is the right structure at all.
