Scope of Work (SOW)

Why it matters

Most client disputes and lost margin trace back to a vague scope. A precise SOW sets expectations, protects the fee, and gives you grounds to raise a change order when the client asks for more.

What to include

Deliverables, milestones and timeline, number of revisions, assumptions, and an explicit out-of-scope list.

Scope of work example, section by section

The structure most professional services scopes follow traces to a public US Department of Defense handbook, MIL-HDBK-245D, which prescribes three sections. Scope states the breadth and the limits of the work and deliberately contains no task instructions. Applicable documents lists anything the work has to comply with. Requirements is where the actual tasks and deliverables live.

For agency work that translates into: what this covers and what it does not, what it has to comply with such as brand guidelines or an accessibility standard, then the deliverables with counts and dates, then assumptions, dependencies, revision rounds, acceptance and what happens when something changes.

The single most useful line in that handbook is its instruction to avoid directing how the work is done and to state only what result is required, written specifically enough that there is no question about whether the supplier is obliged to deliver it.

A good deliverable line against a vague one

The same handbook publishes a list of phrases with multiple meanings that should never appear in a scope. Its examples include "to the satisfaction of the contracting officer", "in accordance with best commercial practice" and "workmanship shall be of the highest quality". Every one of those describes a standard that only becomes definite during an argument.

It also warns specifically that "support" is ambiguous, and gives a real case: an engineer wanting a damaged roof edge repaired and repainted wrote "match existing" without writing "repaint". The contractor repaired the edge and left it unpainted, and was entitled to.

So: vague is "ongoing social media support". Specific is "12 static posts and 4 short-form videos a month across Instagram and LinkedIn, captions written by us, two revision rounds per asset, published to a calendar agreed by the 25th of the previous month". The second one can be delivered, checked and argued about without anybody guessing.

Scope of work, statement of work and SOW

SOW is just the abbreviation of statement of work, so those two are the same document under two names. The real distinction is between the statement of work and the scope of work. In the framing used by the PMBOK Guide, the statement of work carries the high-level description of what is being bought, and the project scope statement carries the detailed deliverables, acceptance criteria and exclusions.

In practice most agencies write one document containing both and call it whichever their client called it first. That is fine. What matters is that the detail exists somewhere signed, not which of the two names sits at the top of it.