ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A statement of work is the document a dispute gets settled against. Everything else
in a supplier relationship — the pitch, the kick-off enthusiasm, the working assumptions —
evaporates the moment two parties disagree about what was bought. What survives is the SOW, and it is
usually written in a hurry by whoever is free.
The SOW defines the work: what will be delivered, to what standard, by when, for how much, and how
both sides will know it is finished. It normally sits under a master services agreement, which carries
the legal terms — liability, IP, termination, confidentiality — while the statement of
work carries the substance of this particular engagement.
That split matters. Commercial teams review the MSA carefully and often wave the SOW through as
“the technical bit”, which is precisely backwards: the MSA is boilerplate that rarely
changes, while the SOW is bespoke every time and is where the money actually goes wrong.
It is also distinct from an RFP. The RFP asks suppliers what they would do; the statement of work
records what the chosen supplier has agreed to do. Copying an RFP’s aspirational language into the SOW
is a common and expensive shortcut.
| Section | What it must settle |
|---|---|
| 1. Background and objectives | Why the work exists, so ambiguity later can be read against intent |
| 2. Scope of work | The activities in scope, and an explicit list of what is out |
| 3. Deliverables | Each one named, described, and dated — not “documentation” |
| 4. Acceptance criteria | How each deliverable is judged, who judges it, in how many days |
| 5. Schedule and milestones | Dates, and what they are conditional on |
| 6. Price and payment | Fixed price or time and materials, and what triggers each payment |
| 7. Assumptions and dependencies | What the supplier is relying on you to provide, and by when |
| 8. Change control | How variations are agreed and priced, before anyone needs one |
Two things go wrong here, and both are avoidable. The first is criteria written as adjectives
— “high quality”, “industry standard”, “fit for purpose”
— which are unfalsifiable and therefore useless at the moment of dispute.
The second is the missing clock. If the statement of work does not say how long the customer has to
review a deliverable and what happens if they say nothing, a supplier can be left waiting indefinitely
with an unpaid milestone. A deemed-acceptance clause — ten working days, silence counts as
acceptance — protects the supplier, and a defined rejection process with reasons protects the
customer. Both sides want that clause; it just needs writing.
Every supplier price rests on assumptions about you: that environments will be available, that
subject matter experts will be released, that data will arrive in an agreed format, that sign-off will
take days rather than weeks. Those assumptions are the customer’s obligations in disguise.
List them explicitly, with dates and owners on your side, and state what happens if one fails
— usually a change request. That single section converts the most common source of overrun from
an argument into a process. It is the same discipline as the dependency quarter of
the RAID log, and the entries should match.
SOW, RFP and vendor selection, ready to edit.
The Project Management Toolkit ships 390+ editable MS Office templates. The procurement set covers a statement of work template and a completed project SOW sample, an RFP template, a vendor evaluation matrix and a vendor selection plan — alongside the change request and change log forms that variations to an SOW have to run through.
The pricing model belongs in the statement of work, and choosing it badly causes more friction than
any other single decision.
Fixed price works when scope is genuinely well understood. It transfers delivery
risk to the supplier, who prices that risk in, so you pay a premium for certainty. It also makes every
change a commercial negotiation, which is fine if the scope really is stable and painful if it is
not.
Time and materials works when scope will be discovered as you go. It is cheaper
when things go well and gives the customer flexibility, but it puts the burden of control on you
— without a cap and regular burn reporting, you have written a blank cheque.
A capped time-and-materials arrangement, with a not-to-exceed figure and an obligation to flag at
80%, gets much of the benefit of both. Whichever you pick, tie payment to accepted deliverables rather
than to elapsed calendar time, so acceptance criteria actually carry weight.
Most SOWs arrive already written, by the supplier, in their format. Reviewing one well is a
different skill from drafting one, and there is a short list of things worth reading twice.
The commonest and most avoidable failure is that something promised during selection never makes it
into the statement of work. Presentations, emails and demos are not contractual. If a capability
mattered enough to influence the decision, it belongs in the deliverables or acceptance criteria
— and if the supplier resists putting it there, that resistance is information worth having
before signature rather than after.
The same applies in reverse. A customer who agrees an aggressive date verbally, then signs an SOW
whose dates are conditional on dependencies they cannot meet, has bought a change request.
What is the difference between a statement of work and a contract?
The contract or master services agreement carries the legal terms; the statement of work defines the
specific work, deliverables, timescales and price. The SOW is normally incorporated into the
contract.
Who writes the statement of work?
Often the supplier, since they know their own delivery approach — which is exactly why the
customer must review it against their own understanding rather than signing what arrives.
How detailed should it be?
Detailed enough that a stranger could tell whether a deliverable had been met. If two reasonable
people could read a clause differently, rewrite it.
Can a statement of work change?
Only through the change control process it defines. Verbal agreements to do extra work are the single
most common cause of billing disputes.
Do we need one for internal projects?
For work crossing a departmental boundary with real cost attached, a lightweight version pays for
itself. The absence of a legal relationship does not remove the ambiguity.
A statement of work is worth the afternoon it takes to write properly, because it is the only
document that survives a disagreement. Name every deliverable so it can be counted, give each one
acceptance criteria a stranger could apply, write the exclusions before the inclusions, turn the
supplier’s assumptions into dated obligations on your own side, and agree change control before anyone
needs it. Then have the person who will actually run the work read it — not just procurement,
who will review the contract carefully and wave through the part where the money goes.
All of these are covered by the Project Management Toolkit, or start with the free ISO templates.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026