Key takeaways
- Describe work as deliverables with measurable acceptance criteria and quantities.
- State exclusions as explicitly as inclusions.
- Name the standards, drawings and specifications by revision number.
- Split responsibilities into a simple who-does-what table, including client obligations.
- Include change control, access and approval turnaround times, and the completion definition.
The anatomy of a usable scope of work
| Section | Purpose | Common gap |
|---|---|---|
| Parties and project reference | Ties the SOW to the contract or purchase order | No contract reference, so the SOW floats |
| Objectives | One paragraph on the outcome required | Restates the task list instead |
| Deliverables | Numbered items with quantities and acceptance criteria | Descriptive prose with no counts |
| Standards and references | Codes, specifications, drawing numbers and revisions | "As per specification" with no revision |
| Responsibility matrix | Who supplies, does, checks and approves each item | Client obligations left implicit |
| Schedule | Start, key dates, sequencing constraints, working hours | Duration only, no access assumptions |
| Exclusions | What is explicitly not included | Missing — the single biggest dispute source |
| Change control | How variations are requested, priced and approved | Verbal instruction accepted in practice |
| Completion and handover | What must be delivered for completion to be certified | No handover list, so retention is held |
Writing acceptance criteria that hold up
An acceptance criterion answers: how will we prove this is done? If the answer needs a discussion, the criterion is not written yet.
- Attach a number wherever possible — units, square metres, test passes, documents, sessions, uptime.
- Name the evidence: test report, inspection sign-off, snag-free walkthrough, delivered file format.
- Name the approver and the review window, for example three working days from submission.
- State what happens if the approver does not respond: deemed accepted, or the schedule extends.
- Keep one criterion per deliverable; bundled criteria fail as a whole.
For subcontracted work, the SOW should mirror the wording of the main contract's scope. Divergent wording between the head contract and the subcontract SOW is how contractors end up funding the gap.
Scope of work vs proposal vs contract
| Document | Answers | When it is issued |
|---|---|---|
| Proposal | Why us, what we suggest, what it costs | Before award, to win the work |
| Scope of work | Exactly what will be delivered and to what standard | At or after award, to execute the work |
| Contract / agreement | Legal rights, liability, payment and termination | At award, with the SOW attached as a schedule |
In practice the SOW is attached to the agreement as a schedule and referenced by it. Keep commercial terms in the agreement and technical detail in the SOW so each can be updated without reopening the other.
Keeping the scope stable during delivery
Once work starts, the SOW should be quoted rather than rewritten. Log every variation request against the numbered deliverable it changes, price it in writing, and reflect approved changes in the project plan and the next progress report. When the final deliverable is accepted, issue the completion certificate against the same numbering.
How to write a scope of work
Step 1: Reference the award
State the parties, project name and the contract or purchase order the scope belongs to.
Step 2: State the objective
Describe the outcome in one paragraph before listing any task.
Step 3: List deliverables
Number each deliverable with quantities and a measurable acceptance criterion.
Step 4: Fix standards and responsibilities
Cite specifications by revision and set out who supplies, executes, checks and approves.
Step 5: Write the exclusions
List everything not included, including permits, third-party costs and out-of-hours work.
Step 6: Add change control and handover
Define how variations are approved and what completion and handover require.
Frequently asked questions
Is a scope of work the same as a statement of work?
The terms are used interchangeably in most industries. Where a distinction is drawn, the statement of work is the broader contractual document and the scope of work is the technical description of the work itself.
Should the scope of work include prices?
Usually not. Keep pricing in the proposal, purchase order or agreement and keep the SOW technical, so a commercial change does not require reissuing the technical scope.
How do I handle work that is discovered later?
Treat it as a variation: record it against the affected deliverable, price it in writing, obtain approval before proceeding, and note the schedule impact in the progress report.
Who should sign the scope of work?
Both parties, plus the technical approver where one is named. An unsigned SOW is still useful evidence, but a signed one ends the argument about which revision applies.