Statement of Work (SOW)
A statement of work is the contractual document that defines what a supplier will deliver, by when, to what standard, and for how much. It sits under a master agreement and covers scope, deliverables, acceptance criteria, milestones, rates or fixed price, assumptions and dependencies. Anything not written in it is out of scope by default.
What it contains
A workable SOW has eight parts. Scope, describing the work in enough detail that both sides recognise it. Deliverables, listed individually with a format and a date. Acceptance criteria, stating how each deliverable will be judged and who signs it off. Commercial terms — fixed price, time and materials, or capped — with a rate card if applicable. A payment schedule tied to milestones or elapsed time. Assumptions, which are the supplier's estimating basis. Client dependencies, which are what the buyer must provide for the estimate to hold. And change control, defining how variations are agreed and priced.
The assumptions and dependencies sections do most of the commercial work, because they are what a supplier will point to when raising a change. An SOW without them is not cheaper; it just moves the argument later.
How it is used
The SOW is written during vendor selection and signed before mobilisation. Once signed it becomes the reference for three recurring activities: confirming whether a deliverable has been met, approving invoices, and pricing changes. Most delivery organisations keep an SOW register listing each active SOW, its value, its milestones and how much has been invoiced against it — which is the register the budget and vendor workbook is built around.
It also feeds the selection process that precedes it. Requirements and weighted scoring produce a preferred supplier; the SOW is where those requirements become contractual. The selection tracker carries the scoring through to the SOW register for that reason.
During delivery, the SOW milestone list should match the project plan. Where a payment milestone is not a plan milestone, invoices arrive for work the plan does not show as complete.
Where it goes wrong
The most common defect is deliverables described as activities. "Support the data migration" is an activity with no completion point; "deliver migration mapping specification for the twelve in-scope objects, reviewed and signed off" is a deliverable. Activity-based SOWs cannot be judged complete, which makes both acceptance and dispute impossible to resolve cleanly.
The second is acceptance criteria left to be agreed later. They never get easier to agree once the work is done and the invoice is pending.
The third is client dependencies that nobody on the buying side has read. Environment availability, data extracts, business availability for workshops and timely decisions are all in the SOW, all owned by the buyer, and all routinely missed — which converts into a legitimate change request and a revised price.
The fourth is an SOW that outlives its plan. Scope changes are agreed verbally in weekly meetings, the plan moves, and the SOW is never varied. Six months later the contractual position and the delivered position have little to do with each other. Keeping the change log aligned to the SOW variations is the mechanical fix.
Related terms
Master services agreement is the umbrella contract covering legal terms; the SOW covers the specific engagement. Deliverable is the unit an SOW is judged against. Acceptance criteria define what "done" means for each deliverable. Time and materials and fixed price are the two common commercial models, with capped T&M a hybrid. Change request is the mechanism for varying an SOW after signature.
Questions
What is the difference between an SOW and a contract?
The master agreement is the contract covering liability, IP and legal terms. The SOW sits beneath it and defines the specific scope, deliverables and price for one engagement.
Should an SOW be fixed price or time and materials?
Both are used. Fixed price transfers estimating risk to the supplier and prices it accordingly; time and materials keeps flexibility and leaves the buyer holding the overrun risk.
Why do client dependencies matter so much?
They are the conditions the supplier's estimate assumes. When they are missed, the supplier has a contractual basis for a change request, and the price moves.
How specific should deliverables be?
Specific enough that both parties can agree, without discussion, whether one has been delivered. Named documents, named environments and named sign-off roles achieve that.