Documents · Glossary

What is a statement of work?

A statement of work is the document that defines one specific engagement: what is being produced, by when, by whom, for how much, and how the client will decide it is finished. It sits under a broader agreement that holds the legal terms, so it can stay short and stay practical.

It is written by the people who will actually do the work, which is both its strength and the reason it so often omits the clauses that decide whether they get paid. Scope is the easy part.

Nuwan Madhusanka · Co-founder

5 min read · Published 12 September 2026

The sections a statement of work needs, and what each one prevents
Section	What it prevents
Background and objectives	Delivering something correct that nobody wanted
Scope, and an explicit out of scope list	An argument about whether a task was always included
Deliverables, each defined and named	A client expecting a document where a workshop was intended
Timeline with dependencies	Blame for a delay caused by somebody else's late input
Acceptance criteria and a review window	Deliverables sitting untested while invoices go unpaid
Client responsibilities	A team waiting for access, data or a decision
Assumptions	Repricing later with no basis for doing so
Fees, schedule and expenses	A dispute about whether the total was a cap

Deliverables have to be nouns

The single most useful discipline in writing one of these is to insist that every deliverable is a thing that can be handed over and pointed at. A migrated database, a written test report, a trained group of eleven staff with an attendance record, a signed off design file. Verbs are where the trouble lives: support the rollout, assist with testing, advise on strategy. Those describe effort, and effort has no finish line, so the work continues until somebody runs out of patience or money. Where an activity genuinely is the service, such as ongoing support, define it by boundaries instead: hours per month, response times, a start and an end date. Then it has a shape even though it has no artefact.

Acceptance is the clause that gets paid

Every deliverable needs three things attached: who reviews it, against what criteria, and within how many days. The third is the one omitted most often and the one that costs the most. Without a review window, a deliverable can sit unassessed indefinitely while the milestone payment tied to it stays unbilled, and the supplier has no lever except asking politely. A deemed acceptance clause fixes it: if no written response arrives within the stated period, the deliverable is accepted. Ten business days is a reasonable window for something substantial, five for a document. Pair it with a defined path for a rejection, requiring the client to say specifically which criterion was not met, so a vague refusal cannot restart the clock.

Assumptions and client responsibilities do different jobs

Assumptions record what the estimate rests on: the number of environments, the volume of records, the availability of a named subject matter expert, the client's existing documentation being accurate. Client responsibilities record what the client must actually do: provide extracts by a date, nominate an approver, give access within a stated time. The first protects the price, the second protects the schedule. Suppliers routinely write vague versions of both, and vague assumptions protect nobody because none of them can be shown to have failed. Write them specifically enough that a reader can tell, in a single sentence, whether each one held.

Keeping it short enough to be read

A statement of work competes for attention with the work itself, and one that runs to thirty pages is skimmed by everybody including the team delivering it. Eight to twelve pages covers most professional services engagements comfortably. The way to keep it short is to push the legal terms up into the master agreement and leave only the commercial and practical detail here. Liability caps, confidentiality, intellectual property, insurance and termination belong upstairs. What belongs here is what the team needs to know on a Tuesday morning: what they are building, who signs it off and when the next payment lands.

Changing one after signature

Scope will change; the question is whether it changes through a process or through goodwill. Name the change mechanism in the document: changes are requested in writing, priced, assessed for their effect on the timeline, and signed by the same people who signed the original before work proceeds. Small changes accumulate, so include a threshold below which a change can be approved by email rather than by a formal variation, and make sure somebody is tracking the running total. A project that has absorbed fourteen small favours has usually given away a fortnight, and nobody noticed because no single decision was large enough to notice.

Storing it where the project can find it

A statement of work is a working document, not an archive item, and it should live where the delivery team works rather than only in a contracts folder. Two habits pay off. Number the deliverables and use the same numbers in status reports, invoices and acceptance emails, so a payment query resolves in one search instead of a conversation. And keep every signed variation attached to the original in the same place, in date order, because the effective scope after four changes is not what the original document says and anybody joining the project mid way will read whichever version they find first. A short front sheet listing the original and each change, with dates and amounts, is the cheapest version of a contract register a small business can run.

Questions people ask

Can a statement of work stand alone?

It can, if the legal terms are folded into it, but the result is longer and each new project repeats the negotiation. The usual pattern is one master agreement and many short statements. Where a client refuses a master agreement, a service agreement covering the same ground is the alternative worth proposing.

Who should write it?

The delivery team, reviewed by whoever owns the commercial relationship and, for anything substantial, by a lawyer once for the template rather than every time. Written entirely by a salesperson it promises too much; written entirely by a lawyer it is unreadable by the people who have to deliver it.

Should the client sign every statement of work?

Yes, by somebody with authority to commit the budget. An emailed agreement from a project manager who cannot approve spending is the classic gap, discovered when the first invoice reaches finance. Signing also forces a proper read, which is often the first time the client's side notices an assumption they cannot meet.

How detailed should the timeline be?

Detailed enough to show dependencies and no more. Phase level dates with the client inputs marked works better than a task level plan that is wrong within a fortnight. Keep the granular schedule as a working document outside the contract, so it can be updated without a variation every time a week shifts.

What if the work is genuinely exploratory?

Split it. A short discovery engagement with its own fee and a written output, then a second statement of work for delivery priced with the knowledge discovery produced. Trying to fix a price on work whose shape is unknown produces either a padded number the client rejects or a thin one the supplier absorbs.

Does a statement of work need to mention intellectual property?

Only if the position differs from the master agreement, in which case say so explicitly and say why. Otherwise leave it upstairs. A statement of work that quietly restates intellectual property terms in slightly different words creates a conflict with the agreement above it, which is the sort of drafting error that surfaces years later.

Make one with documents

The button opens the generator with this use case already described. Change the wording to match your own.

Create a document with OneCraft

Sources

Written and checked by the OneCraft team. Last checked 12 September 2026.