Statement of Work: Where Projects Go Wrong Early

Integration with your existing systems. Six words, signed by both sides, each of them certain they knew what it meant. One party was thinking of two systems and the other of nine, and the difference became somebody unpaid overtime in month three.

Ambiguity is not neutral

A vague line feels like flexibility when you are signing. It reads as room to be reasonable, and both parties sign assuming their own interpretation will hold.

It is not neutral, and it does not stay unresolved. It gets resolved later by whoever can afford to push, which in a client relationship is rarely the supplier halfway through delivery with an invoice outstanding.

This is why pinning down specifics is a kindness to both sides rather than a sign of distrust. A client who knows exactly what they are getting and a supplier who knows exactly what they owe have no reason to argue in month three.

The sections that carry the risk

Most statements of work are long in the places that are easy to write and short in the places that decide the outcome.

Suppliers leave client obligations out because it feels presumptuous, and that omission is what sinks timelines. If your work depends on a system login, a data export and one decision from a named person, and any of those arrives three weeks late, the timeline moves. Writing that down in advance converts an awkward conversation into a clause.

An out-of-scope list feels similarly impolite and does the same job. Naming the five things a reasonable person might assume are included is far cheaper than discovering the assumption later, which is the same logic as the specificity in a service level agreement that means something.

Deliverables, not activities

There is a real difference between we will run discovery workshops and you will receive a written requirements document of roughly twenty pages covering these four areas. The first is an activity you can perform fully and still disappoint. The second can be handed over and judged.

Activities are easier to write because they describe what you intend to do, and they are what most statements of work contain. Deliverables are harder because they commit you to an artefact, which is exactly why they protect both sides.

Then attach acceptance to each one. A named person, a stated test, and a review window after which it is deemed accepted. Without that last clause a deliverable can sit unreviewed for two months while the project cannot close.

What AI should and should not draft

The useful job is making the implicit explicit. Give it the meeting notes and the email thread and ask for the scope, the deliverables and, most valuably, a list of assumptions nobody wrote down. The things both sides took for granted are where the risk is, and a model reading the correspondence will surface several you had stopped noticing.

It is also good at the out-of-scope section, which is tedious to write and easy to leave thin, and at checking a draft against your own previous statements of work for sections you have simply forgotten this time.

Where it should stop is anywhere describing what happens when things go wrong. Payment terms, liability, indemnity, intellectual property ownership and termination are commercial and legal positions, not descriptions of work. A model will write all of them fluently, reflecting no particular jurisdiction and no particular appetite for risk, which is the same failure mode as generating contract templates and the reason AI contract review misses what it misses.

One practical check before sending: read the draft looking only for sentences that could be read two ways. Numbers, counts and names are where to look, because every unquantified plural is a future argument.

Change is not the enemy

Projects change. A statement of work written to prevent that gets quietly ignored by both sides, which leaves you with no document at all.

What works is making change visible and priced. A named approver, a written request, and a stated basis for cost means a change is a decision rather than something absorbed in silence until somebody notices the margin has gone.

Where you are the one subcontracting, the same clauses need to flow down, because an obligation you accepted upstream and did not pass on is a gap you now own, which is the point of keeping control of work you do not do yourself. And if a scope keeps arriving vague from the client side, the fix is usually earlier, in how the request was written.

Frequently Asked Questions