Disc Statement Of Work

---
name: disc-statement-of-work
description: Writes a results-based Statement of Work with objectives as results, deliverables with acceptance criteria, a dated timeline, client responsibilities, assumptions and exclusions including your won't list, and change control for new requests, with contract terms left for a qualified adviser. Use for "run disc-statement-of-work", "write the SOW", "statement of work", "scope of work document", "acceptance criteria for deliverables", "stop scope creep", "change control clause", part of the Claude for Winning Proposals Pack by Polar Bear.
---

# Statement of Work

## When To Use
The client said yes, and the scope must hold when their own AI suggests more next month. The proposal persuaded; now both sides need one document that says what is delivered, how anyone will know it is done, who does what by when, and what happens when a new idea arrives. It answers: what exactly are we agreeing to?

## When Not To Use
If the client has not chosen an option yet, stay with the Consulting Proposal. If the scope itself is still being argued, settle it in MoSCoW Scope first; the SOW records scope, it does not decide it.

## Inputs
- The accepted option, your approach phases and your MoSCoW scope with its won't list
- Dates you can commit to, and what you need from the client (access, people, decisions, data)
- Your AI use statement, and any contract template you or the client already use
If you have none of this, I start from the accepted option, leave every date and standard as a [placeholder], and mark the output as a first draft.

## Approach
The writing rule comes from FAR 37.602 (acquisition.gov/far/37.602): describe the work by required results and measurable standards, not by hours or method. It is a public procurement convention used here as a writing principle only, with practitioner SOW sections around it. The failure it prevents: "support the client's transformation programme" as a deliverable, which can never be finished and can always be expanded.

## Workflow
1. Ask at most three questions: which option was accepted, which dates are fixed on both sides, and who on the client side accepts deliverables.
2. Objectives as results: what will be true when the work is done, in the client's measures. Activities are not objectives; "run workshops" becomes the result the workshops serve.
3. Deliverables, each with an acceptance criterion the client can check: format, content, review rounds, who accepts and within how many days. You set every standard; a deliverable without one is flagged.
4. Timeline with your dates, and client responsibilities with theirs: access, people, decisions, data. A late client input moves the dependent dates, and the SOW says so.
5. Assumptions and exclusions. The won't list goes in verbatim from your MoSCoW scope, so nothing dropped earlier creeps back. Reference your AI use statement for how AI is used.
6. Change control: how any new request is raised, sized, priced and approved in writing before work starts, including requests generated by the client's own AI tools. Treat them like any other request, no more and no less.
7. Contract terms, liability, IP, confidentiality and payment stay as [placeholders] marked "check with a qualified adviser". Draft in Claude Docs (beta) or as a docx; you send it.

## Output Format
```markdown
# Statement of Work
**Client:** [organisation] | **Provider:** [you] | **Version:** [n], [date]
## Objectives (results)
- [What will be true, in the client's measure]
## Deliverables and acceptance
| Deliverable | Acceptance criterion | Review rounds | Accepted by (role) | Within |
|---|---|---|---|---|
| [deliverable] | [standard you set] | [n] | [role] | [days] |
## Timeline and responsibilities
| Date | Provider delivers | Client provides | Owner (role) |
|---|---|---|---|
| [date] | [item] | [access, data, decision] | [role] |
## Assumptions and exclusions
- Assumption: [ ]
- Not included (won't list, verbatim): [ ]
## Change control
[How a request is raised, sized, priced and approved in writing before work starts]
## Terms
[Liability, IP, confidentiality, payment: placeholders; check with a qualified adviser]
## Decision
[Client signer] and [you] approve version [n] by [date]; contract terms are reviewed by a qualified adviser before signature.
```

## Done When
- Every deliverable has an acceptance criterion and a named accepting role
- The won't list appears verbatim and the change control route is written out
- Every date is one you or the client supplied, or a [placeholder]

## Quality Bar
- Results and standards, not hours; no deliverable that can never be finished
- Client responsibilities are as specific as yours, with dates
- No legal wording presented as advice; terms stay placeholders for an adviser
- Results you can check, dates you set; contract terms go to a qualified adviser

## Next
Run disc-proposal-red-team (Proposal Red Team Review) to read the full draft as the buyer will.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).