Statement Of Work

---
name: statement-of-work
description: "Write a tight Statement of Work (SOW) that prevents scope creep and payment disputes. Use when asked to write a SOW, a scope of work, a project agreement, or to formalise what was agreed after a proposal. Produces an SOW — scope (and explicit exclusions), deliverables with acceptance criteria, timeline & milestones, payment schedule, assumptions, change-control, and terms. The contract layer after the proposal sells."
---

# Statement of Work Skill

The proposal wins the deal; the SOW protects it. Most consulting pain — scope creep, "that's not what I
meant," late or withheld payment — traces to a vague SOW. This skill writes a precise one: exactly what's
in (and explicitly *out*), how each deliverable is accepted, when money changes hands, and how changes are
handled — so both sides are protected.

## Required Inputs

Ask for these only if they aren't already provided:

- **The engagement** — parties, and what was agreed (often from a [`consulting-proposal`](../consulting-proposal/SKILL.md)).
- **Deliverables** — the concrete outputs and how "done" is judged.
- **Timeline & dependencies** — milestones, and what you need *from the client* and by when.
- **Commercials** — total fee, payment schedule/triggers, and rate for out-of-scope/change work.

## Output Format

### Statement of Work — [project]
**Between:** [provider] and [client] · **Effective:** [date]

**1. Scope** — what will be done, specifically. Then **explicit exclusions** ("Out of scope: …") — the most valuable section; unsaid scope is assumed-included by clients.

**2. Deliverables & acceptance criteria** — each deliverable with **how it's accepted** (the objective bar, and a review window — e.g. "approved, or feedback within 5 business days, else deemed accepted").

| Deliverable | Acceptance criteria | Due |
|---|---|---|

**3. Timeline & milestones** — phases, dates, and **client dependencies** (their inputs/approvals — and what happens to the timeline if they slip).

**4. Payment schedule** — amounts tied to milestones/dates, invoicing terms, and late-payment terms. Deposit up front where appropriate.

**5. Assumptions** — what the plan and price depend on (access, environments, responsiveness) — so a broken assumption is a change, not a fight.

**6. Change control** — how scope changes are requested, priced (the change rate), and approved in writing before work proceeds. This is the anti-scope-creep clause.

**7. Terms** — IP/ownership (on payment), confidentiality, termination, liability — flag that legal should review for material engagements.

## Quality Checks

- [ ] Scope includes an explicit "out of scope / exclusions" list
- [ ] Every deliverable has objective acceptance criteria and a review/sign-off window
- [ ] Payment is tied to milestones/dates with late terms (and a deposit where apt)
- [ ] Client dependencies are listed, with the timeline consequence if they slip
- [ ] A written change-control process with a change rate is defined
- [ ] Assumptions the price depends on are stated

## Anti-Patterns

- [ ] Do not leave scope open-ended — without exclusions, clients reasonably assume everything is included
- [ ] Do not omit acceptance criteria — "deliver a website" with no bar means endless revisions
- [ ] Do not skip change control — it's the clause that turns scope creep into billable change requests
- [ ] Do not ignore client dependencies — if their delay silently becomes your problem, you eat the cost
- [ ] Do not present this as final legal advice — recommend counsel review for significant contracts

## Based On

Statement-of-work / contracting practice — explicit scope + exclusions, acceptance criteria, milestone payments, change control.