Ten clauses in a statement of work that decide whether the project survives

A statement of work is not an annex to the contract. It is the written form of five things: scope, dependencies, acceptance, change, and exit. Ten clauses carry those five, and each clause earns its place by preventing one specific argument. If a clause is missing, the argument still happens; it just happens later, with less goodwill and less money.

Scope, in two clauses

1. What is delivered, at the granularity of an operation path. Not "a reporting module" but the path a clerk walks: open the page, import this export, see this total, correct this row. The test is whether the customer can point at the sentence and say yes, that is the thing. When this clause is vague, the argument is about whether a module was "finished", and the verdict goes to whoever is angrier.

2. What is explicitly not delivered. Every product has a gravitational field of adjacent features, and the customer assumes all of them are included. One sentence — features, pages, integrations and reports not listed here are not delivery obligations — converts a silent expectation into a priced change request. Missing this clause is how a demo becomes an unpriced obligation.

Dependencies, in three clauses

3. What the customer must provide. Data, accounts, permissions, a process owner, and the decision-maker's time, each with a name against it. Without this clause, waiting is unbilled, and the FDE absorbs the delay as a personal cost.

4. Which preconditions stop the project. Not every missing input should pause work; the SOW has to say which ones do. A missing export, no access to the system of record, or no one able to confirm a business rule are stop conditions. Without the clause, every missing precondition becomes a delay you carry while the project stays nominally on track.

5. Dates for reviews, not a duration. "Two weeks" is not a date; it becomes two weeks from whenever the data arrives. Name the review dates and the artefact each review will look at. This is also the clause that makes the stage boundaries visible to a customer who has never run a delivery.

Acceptance, in two clauses

6. How it is tested. Which test set, who runs it, in which environment, with which data. A test set written after the build tends to contain the cases the build already handles.

7. What counts as acceptance. Each row ends in pass, fail, unverified, or not applicable, with a date and an evidence location, signed by the person who will operate the system. "Not applicable, not implemented in the original" is a legitimate outcome; silence is not. When this clause is missing, acceptance becomes a feeling, and feelings are renegotiated at the end of every month.

Change and risk, in two clauses

8. What happens on a change, by type. Three kinds exist: the customer adds something, the vendor underestimated, or a precondition turned out to be false. The first is a price change, the second is the vendor's cost, the third is a schedule change with a new precondition. Mapping all three to overtime is how a margin disappears in the same week as trust. The clause must name the decision-maker and the response time for each type.

9. Who carries which risk. Model behaviour, upstream interface changes, customer data quality, and events outside either party. The clause does not need to be long; it needs to say who pays and who decides when each of those happens. Without it, the first incident is argued as fault rather than handled as a case, and the technical response waits behind the commercial one.

Exit, in one clause

10. Training and after-sales boundary. What is included, for how long, through which channel, with what response time, and what is billed separately. Missing this clause is why projects never end: the FDE becomes the helpdesk, every small question reopens the relationship, and no one ever designs the exit. Training is not a courtesy at the end; it is the clause that makes handover possible.

What it protects	Clauses	The argument when absent
Scope	1, 2	"The module was finished" versus "this was obviously part of it"
Dependency	3, 4, 5	The delay is real, the invoice is not, and nobody agreed who owns it
Acceptance	6, 7	Whether it "works" is decided by mood and seniority
Change	8, 9	Every new request becomes unpaid overtime, then resentment
Exit	10	The project has no end date and the FDE has no exit

The test of a clause

A clause is real if someone who was not in the meetings can act on it. Hand clause 2 and clause 10 to a new project manager and ask them to name three things that will not happen. If they cannot, the clauses are prose, not commitments.

A second test comes from the definition stage: every claim of "done" must point at a clause. If it cannot, it is not done; it is a demo with a date on it. The same rule applies to payment — tie each instalment to a verifiable artefact, never to a person-day, because a person-day prices your calendar and turns every scope conversation into an argument about your availability.

Then run both tests across the whole document before signing. List the ten clause titles, and next to each write the sentence that would be spoken in the argument if the clause were missing. The ones you can write in one sentence are the ones to add this week. The ones you cannot write are the ones this customer will not argue about — and that is a useful thing to know too, as long as you know it before the first invoice rather than after. The quote is where the numbers live; the SOW is where the boundaries live; and the sunset clause is where the exit lives. A project with all three can end cleanly, which is the only reliable way to start the next one.