Writing a Scope of Work

What goes in one

A workable scope of work covers six things. Longer documents are usually padding; shorter ones are usually missing one of these.

1. The objective. One paragraph on what this project is for. Not the deliverables, the point. It is what both sides fall back on when a question comes up that the document did not anticipate.

2. The deliverables. A specific list of what will exist at the end. "A reporting dashboard" is not a deliverable. "A dashboard showing the six metrics listed in appendix A, filterable by date range and team" is.

3. Acceptance criteria. How each deliverable will be judged complete, in terms a third party could check. This is the section that decides whether the final invoice is a formality or an argument.

4. Exclusions. What is explicitly not included. See below, because this is the section people skip.

5. Timeline and milestones. Dates, and what is delivered at each one. Larger projects should tie payment to these.

6. Assumptions and dependencies. What the contractor is relying on you for: access, data, decisions, review turnaround. A dependency nobody wrote down becomes a delay somebody gets blamed for.

Why the exclusions section matters most

Scope disputes are almost never about whether something was excluded. They are about whether it was included, and the two parties reading the same optimistic list reach different answers in good faith.

Writing exclusions forces the conversation while both sides are still cheerful. If you write "does not include data migration from the legacy system" and the contractor says "I assumed that was in", you have found the disagreement in week zero, when it costs a conversation, rather than in week nine, when it costs the relationship.

Useful exclusions to consider naming: content or data you will supply rather than they will produce; third-party integrations; hosting and infrastructure; training; ongoing support after handover; anything that is a phase two.

Writing acceptance criteria that hold

The test for an acceptance criterion is whether someone uninvolved could apply it and reach the same answer as you. "Looks professional" fails that test. "Renders correctly at 375px, 768px and 1440px widths" passes it.

Where the work is genuinely subjective, do not pretend otherwise with a fake-objective criterion. Name the person who decides, and bound the process instead: how many rounds of revision are included, how long you have to respond, and what happens after the last included round. Bounded subjectivity is manageable. Unbounded subjectivity is where fixed-price projects die.

The change process

Scope changes. Assume it in the document. A change process only needs to answer three questions: who can request a change, how its cost and time impact get agreed, and who signs it off.

Written down, a change is a small administrative event. Undocumented, the same change becomes an argument about what was originally promised, held at the worst possible moment.