Most statements of work describe deliverables in language loose enough to fuel a dispute later about what was actually agreed. The Stratenity pattern closes that gap by defining every deliverable in terms of the decision it enables and the acceptance criteria the client will apply, so "done" is a test rather than an opinion. It pairs that with a change request protocol and clear intellectual property terms, giving the agreement teeth without inviting downstream fights. Built this way, it survives both the buyer's legal review and the mid-engagement request that would reopen scope.
The document that decides who is right later
A statement of work is the artifact everyone signs and no one rereads until there is a disagreement. When that disagreement comes, the words on the page are the only thing that matters, and most statements of work are written in a way that guarantees the argument. They list deliverables as nouns: a strategy, a model, a roadmap. A noun cannot be tested. When the client says the strategy is not what they expected and the team says it clearly is, both are pointing at the same sentence and reading it differently, and neither can prove the other wrong because the sentence never said what "complete" would look like. The document created the dispute rather than preventing it, which is the opposite of what a contract is for.
The Stratenity pattern writes the statement of work to remove the disputed territory before it exists. Every deliverable is defined by the decision it enables and by the acceptance criteria the client will apply to judge it complete, so that "done" becomes a test a neutral party could run rather than a matter of taste. It adds an explicit change request protocol so new asks route through a known process instead of eroding scope by increments, and it states intellectual property and reuse terms plainly so ownership is never the surprise discovered at the worst moment. The result holds up in two places at once: under the buyer's procurement and legal scrutiny at signing, where vague language gets bounced back, and under the pressure of the mid-engagement request that would otherwise quietly reopen everything the two sides thought they had settled.
Four components that make the agreement testable
The pattern has four parts. Together they convert a statement of work from a description of intentions into a document with acceptance built in, so that both sides know in advance what completion looks like and how change will be handled when it arrives, as it always does.
| Component | How it is written | Dispute it removes |
|---|---|---|
| Deliverables defined by decision | Each deliverable named with the specific decision it enables the client to make | Arguments about whether an output was the "right" one |
| Acceptance criteria | The testable conditions the client will apply to mark each deliverable complete | The endless "not quite what we wanted" loop with no finish line |
| Change request protocol | A defined route by which new asks are scoped, priced, and approved | Scope creep smuggled in as clarification rather than change |
| Intellectual property and reuse | Explicit terms on who owns the work and what each party may reuse | Ownership fights discovered only when the client wants to reuse an asset |
Worked example. A private equity client engages the team for a diligence workstream. Rather than listing "market analysis" as a deliverable, the statement of work defines it by decision: an analysis sufficient for the investment committee to decide go or no-go on the target by the offer deadline. The acceptance criteria are testable and specific: coverage of the three named competitors, a demand model with its assumptions stated on the page, and a one-page recommendation, all delivered five business days before the committee meets. The change request protocol specifies that any added target scopes as a new work order at a defined day rate, approved in writing by the deal lead. The IP terms state plainly that the client owns the deliverables while the team retains its underlying methods and templates. When the client later asks to add a fourth competitor midway through, the protocol turns the request into a priced change order settled in a day, rather than a week of tension over whether it was "really" already included in a scope that never said one way or the other.
Writing the statement of work this way
- Name the decision behind every deliverable. If a deliverable does not enable a specific client decision, question whether it belongs in the scope at all, because unattached outputs are where budget and time quietly disappear.
- Write acceptance criteria as tests a third party could apply, not as adjectives. "Comprehensive" is an opinion that both sides will read to their own advantage; "covers the three named competitors" is a test that either passes or fails.
- Include the change request protocol in the signed document, not as a side conversation or an assumed norm. The moment to agree how change is handled is before any change is requested, while both sides are still reasonable.
- State intellectual property and reuse terms explicitly, including what the firm may reuse across other clients. Silence on reuse becomes the client's assumption of exclusivity, discovered only when the firm reuses a template.
- Draft the whole document to survive procurement review, using precise, testable language throughout, because the buyer's legal team will read it far more literally than the sponsor who scoped it did, and they will send back anything that cannot be enforced.
Where statements of work fall apart
- Deliverables written as nouns. A noun cannot be judged complete, so completion becomes a matter of opinion. Fix: define each deliverable by the decision it enables and the criteria that mark it done.
- Acceptance criteria full of adjectives. "Robust" and "thorough" cannot be tested and will be read differently by each side. Fix: rewrite every criterion as a condition a neutral party could verify.
- No change protocol in the document. Undocumented change becomes silent creep that no one agreed to price. Fix: include the scoping, pricing, and written approval route for changes inside the signed statement of work.
- Vague or absent IP terms. Ownership assumptions surface at the worst possible moment, usually when value is on the line. Fix: state who owns the deliverables and what each side may reuse, in plain terms, up front.
- Language that only satisfies the sponsor. Procurement reads literally and sends loose language back. Fix: draft for the buyer's legal review, precise enough to survive a hostile and literal read.
Before the statement of work is signed
- Every deliverable names the specific client decision it enables.
- Each deliverable has acceptance criteria written as testable conditions.
- A change request protocol is included in the signed document.
- Intellectual property ownership and reuse rights are stated explicitly for both sides.
- The language is precise enough to survive the buyer's procurement and legal review.