Statement of Work

In work done for a client, disputes rarely start with quality. They start with scope. Cases where the vendor failed to do the agreed thing are far outnumbered by cases where the two sides disagreed about whether it was agreed.

The typical scene runs like this. A team signs a $30,000 deal to roll its product out at an enterprise customer. Two weeks in, the customer asks when the 80,000 documents sitting in their old system will be migrated. Nobody on the engineering side ever counted that work. The customer read "rollout" as obviously including it; the vendor read it as making the product ready for new documents. Neither side lied, and two weeks of work has nowhere to go.

Reaching for the proposal to settle it does not help. A proposal is written to sell, so phrases like "rollout support" or "data integration" stretch to whatever size the reader wants them to be.

A statement of work goes in between. Underneath the agreement that governs the relationship overall, it records this engagement's scope and its finishing line in nouns and numbers. The point of the document is separating the language used to sell from the language that binds. It is also the cheapest document in the stack to write: a page and a half, drafted in an afternoon, against a disagreement that costs weeks.

Eight sections: scope, deliverables, schedule, acceptance criteria, payment, assumptions and exclusions, change procedure, and named contacts.

1. Scope — the work stated as verbs. "Review" and "support" have no measurable size, so write something countable instead: build five screens, migrate two data sources.
2. Deliverables — what actually gets handed over, in format and quantity. A feature running in production, five administrator accounts, one operations guide.
3. Schedule and stages — start date, end date, and the checkpoints in between, each with a statement of what has to be complete by then.
4. Acceptance criteria — what state counts as done. An empty version of this section means the work never ends: the customer can keep raising items and the vendor has no basis for saying it is finished. Something like "behaves per the feature list with no severity-one defects open" works, because both sides can check it the same way on the same day. Whatever is written here has to line up with what the warranty clause promises.
5. Payment and timing — amounts attached to stages. Thirty percent at kickoff, forty at the midpoint checkpoint, thirty on acceptance is a common split.
6. Assumptions and exclusions — the section most often omitted and the most expensive one to omit. Migration of existing data is not included; network configuration inside the customer's environment is the customer's responsibility. Writing three exclusions is usually enough; the useful ones are whatever the delivery team assumed without saying.
7. Change procedure — how scope gets added. One sentence saying changes are agreed in writing with revised cost and schedule lets a team say yes to a request without absorbing it for free.
8. Contacts and customer obligations — both sides named, and deadlines attached to what the customer has to supply. "Acceptance feedback returned within five business days" belongs here.

The selling side drafts it. What it must not do is copy the proposal across: the people who will actually do the work confirm the effort before anything is final. Skip that review and the scope that was sold and the scope that is achievable get signed in the same document.

Four audiences read it, and each one reads a different section.

1. The customer's project owner — scope and schedule, checking that what they pictured appears on the list.
2. The customer's procurement and legal reviewers — payment terms and the change procedure, plus anything that contradicts the master agreement.
3. The delivery team — acceptance criteria and exclusions. Mid-project requests get judged in or out against this document, which is what lets an engineer answer a scope question without escalating it.
4. Finance — stage amounts and acceptance dates, because this document is the basis for each invoice.

It gets written after the proposal and before the contract. The usual arrangement is one master agreement signed once, with a statement of work attached per engagement. Unlike terms of service, which puts identical conditions in front of everyone, this document differs per customer, so teams settle on a template and change only the fields.

"That's in the exclusions. If we're doing it, we need a change order first."

Not a refusal; a request to run the procedure.

"Acceptance criteria are blank, so this engagement has no way to close."

Without a finishing condition the project stays open indefinitely.

"Don't paste proposal wording into the statement of work. That's sales language."

The two documents do different jobs.

Pagedeck started its first large rollout without one. Sofia sent a proposal and a quote, the contract was signed on that basis, and once Theo began work the customer asked about migrating 80,000 existing documents. The proposal said only "rollout support."

The migration got done for free and cost two extra weeks. Grace then added a statement of work to the pre-contract steps, with the exclusions section mandatory rather than optional. When the same request came up on the next engagement it was already listed as excluded, and the migration was contracted separately for $6,000.

Many teams treat this as the same document as the proposal, which is a fair confusion since both describe what will be delivered. But a proposal persuades and a statement of work binds. Phrasing written to sound generous in a proposal becomes an obligation at the same width once it lands here. Copy those sentences over and an unsized promise crosses into the contract, where the party that gets to size it later is the one making the request. The safer habit is drafting the statement of work first and letting the proposal describe it, rather than the reverse.

The second misreading is that spelling things out makes a vendor look difficult, especially the exclusions. It works the other way around. A customer who can see what is not included knows what to arrange separately and plans around it. A project that starts without that list still has the conversation eventually, only by then the schedule is at stake, which turns a negotiation into a dispute. Customers who have run projects before tend to read the exclusions first, and a document that has them reads as competence rather than caution.