What belongs in a statement of work

A statement of work gets read twice. Once at signing, quickly, by people who are optimistic about the project, and once months later — slowly, line by line, by people trying to establish whether a particular piece of work was ever promised.

The second reading is what the document is actually for. Everything below is about writing for that reader rather than the first one.

What the document has to settle

That is the whole surface, and most of it is uncontroversial. There is a free statement of work template with these fields already laid out if you would rather start from a structure than a blank page.

Four of those rows decide whether the document does its job. The rest of this post is about them.

Deliverables, not activities

An activity is something you do. A deliverable is something you hand over that can be looked at and either accepted or rejected.

Scope written as activities cannot be closed out. There is no moment at which "discovery workshops with the operations team" is finished, because there is always one more workshop somebody would find useful, and no way to point at a page and say that part is done.

Each deliverable needs three things: a name, a date, and a test.

The test is the part that gets skipped. Compare:

• Migrated customer data in the new system.
• A migration run against a production copy in which all 1.2 lakh customer records load without error, the target row count matches the source, and a sample of 200 records reconciles field by field. Delivered as a migration report and the loaded environment.

The second one can be failed. That reads like a disadvantage and it is the entire point — a deliverable nobody can fail is a deliverable nobody can pass either, and your invoice is attached to it.

Two smaller things in the same section. Number the weeks from the effective date rather than fixing calendar dates: a project that starts a fortnight late drags every calendar date with it, and nobody wants to reissue a signed SOW to correct arithmetic. And name the format, because "a report" means a PDF to you and a working model to them.

Then write down what you need from the client — production access by week two, a named decision-maker, sign-off on the data mapping — and say what happens when it does not arrive. Dates shift day for day is the usual answer. Leave it out and you have quietly accepted a delay you did not cause.

The section people leave out

Out of scope is the single most expensive omission in this document, and it is omitted almost every time.

The reason is not carelessness. At signing, listing what you will not do feels like negotiating against yourself in a room where everyone is being cooperative, and the scope was written before either side knew what the work would actually feel like.

Here is what happens next. Scope paragraphs are read generously by whoever is paying. "Model three automation options" quietly acquires a fourth. "A final presentation" acquires a board pack the week before it. Neither party is behaving badly; they are reading the same sentence from different sides of an invoice.

The asymmetry is what makes this expensive. You can decline out of a written exclusion. You cannot decline out of a silence — in a silence the only available arguments are about what was implied, and those are arguments the party holding your payment is better placed to win.

Exclude the things adjacent to your work that a reasonable person might assume are included: software licensing and hardware procurement, cleansing of the source data, training beyond a named number of sessions, work at any site other than the two listed, support after go-live, integrations with third-party systems not named here. Add anything you did for free on the last project for this client, because precedent is the quietest form of scope creep.

Wording matters as much as the list. Give every exclusion a route through it — "cleansing of the source data is not included; it can be added by change order at the rates in Schedule B." An exclusion with a price attached is a commercial conversation. An exclusion without one is a refusal, and refusals get escalated.

Money moves on acceptance

A single fixed fee with nothing attaching it to specific deliverables means the whole amount is available to argue about at the end. Break it up so a dispute about the fourth deliverable does not hold the money for the first three:

State the tax treatment on the same page. "₹12,00,000 plus GST" and "₹12,00,000 inclusive of all taxes" differ by eighteen per cent, and vague middle grounds like "plus applicable taxes as per actuals" get read the cheaper way by the side writing the cheque.

Notice what those triggers now depend on. If invoices are raised on acceptance, acceptance is a cash-flow event, and an undefined cash-flow event is a forecast you cannot make. Three sentences fix it:

• How long the client has to review — ten business days is a normal figure.
• What happens if they say nothing.
• What a rejection has to contain.

The middle one is left out most often and matters most. Without a deemed-acceptance clause a deliverable can sit unreviewed indefinitely, usually not through bad faith but because the reviewer got pulled onto something else, and your invoice never becomes raiseable. One sentence: if the client does not respond within ten business days, the deliverable is deemed accepted.

Rejection needs a floor too, or you get an unbounded loop. A rejection should be in writing and should name the acceptance criterion that failed; you get a stated period to fix it; and resubmission starts a shorter window, five business days rather than ten. Without the shorter window, every round of minor corrections costs you two weeks of calendar.

Finally, count payment terms from something checkable. "Thirty days from receipt of a valid invoice" needs valid defined — PO number quoted, correct GSTIN, correct legal entity — or you will have an invoice bounced on day twenty-nine and the clock restarted. If their accounts payable process needs a purchase order at all, put a deadline on issuing it, because otherwise your first invoice waits behind their procurement queue and nothing in the document says it should not.

Which agreement wins, and how it gets amended

An SOW is rarely alone. There is usually a master services agreement above it, often an NDA and a data processing agreement beside it, and eventually a stack of change orders on top — all written at different times, by different people, in different moods.

The division is straightforward in principle. The MSA carries what does not change per project: liability caps, IP ownership, confidentiality, insurance, termination, governing law and the seat of arbitration. The SOW carries what is specific to this piece of work.

Two mistakes are common enough to name.

The first is restating MSA terms inside the SOW. It feels helpful, because the reader gets everything in one document. What it does is create two copies of the same clause that drift apart the moment the MSA is amended, and now you have a conflict where you previously had none.

The second is having no precedence clause at all. The SOW says forty-five day payment terms, the MSA says thirty, both are signed, and the order between them is discovered by argument at the worst possible moment. Pick an order and write it down. The usual construction is that the MSA governs, and an SOW varies it only where it expressly says so and names the clause it is varying. That makes every deliberate variation visible, and makes an accidental one lose.

Change orders sit above the SOW on the same principle. Number them in a series, reference the SOW number, name the sections being amended, state that everything else continues unchanged, and have them signed by people with authority — which is generally not the project manager who agreed the change on a call. Name those people in the SOW so nobody has to guess later.

The failure mode here always has the same shape: work agreed verbally, delivered in good faith, invoiced, and then queried by somebody in finance who was not on the call and can only see signed documents. From where they are sitting, refusing it is the correct behaviour.

Before you send it for signature

Five passes, each of which takes a few minutes:

1. Read the scope as though you were the one paying for it. Every phrase that could reasonably cover more work than you intend gets a number or an exclusion.
2. Check that every deliverable can be failed. If you cannot describe the test it would fail, you have written an activity.
3. Check that every rupee is attached to an event, and that every one of those events is defined somewhere in the document.
4. Check for deemed acceptance, and that the window is a stated number of business days rather than "promptly".
5. Read the SOW against the master agreement and delete anything the SOW repeats.

None of this makes the project go well. It makes the disagreement short — which on a project that is going badly is the more valuable property of the two.