How to write a statement of work that holds up

A statement of work that describes the engagement in broad themes, "ongoing marketing support," "website redesign," reads fine at signing and becomes a liability the moment anyone disagrees about what's actually included. The specificity that felt unnecessary during a friendly negotiation is exactly what prevents a dispute later.

A SOW that holds up isn't a longer document. It's one specific enough that "was this included" has an actual answer.

A vague SOW is where later scope disputes actually begin

Ambiguity in a statement of work doesn't cause a problem immediately, it causes one later, when both sides remember the vague language differently. Specificity at signing costs a little more effort and saves a much more expensive disagreement.

List concrete deliverables, not general themes

"Website redesign" could mean five pages or fifty, one round of revisions or unlimited. List the actual deliverables, specific pages, specific formats, specific counts, so there's no ambiguity about what's being produced.

Define what's explicitly excluded, not just what's included

A list of inclusions alone leaves the boundary implicit; explicitly stating what's out of scope removes the most common source of later disagreement, the thing the client assumed was included and you didn't. State it plainly, even if it feels unnecessary at the time.

Specify how a deliverable gets accepted as done

Define what "done" and "approved" actually mean for each deliverable, who signs off, what the review window is, rather than leaving completion as an assumed, unstated moment. This prevents disputes about whether something was ever actually finished.

Build in a defined process for changes, not silence about them

Scope will change on most real engagements; a SOW that says nothing about how changes get handled leaves that negotiation to happen informally and inconsistently later. Define the change process explicitly, even briefly, so it's a known procedure rather than an improvised one.

A simple checklist

If you do nothing else, do these five things:

• List concrete, countable deliverables, not general themes.
• State explicitly what's excluded, not just what's included.
• Define acceptance criteria for each deliverable.
• Build in a defined process for handling scope changes.
• Favor specificity over brevity, even when it feels unnecessary.

Do that, and a statement of work becomes a document that actually prevents disputes, not just one that documents intent.