Scoping and the statement of work
Scoping turns a well-framed problem into a commitment both sides understand the same way. A good scope protects the customer from surprises and protects you from endless expansion. A vague one guarantees conflict later, usually right before a deadline.
What a scope document contains
- Objective — the problem statement and success metric from framing.
- In scope — concrete deliverables, users, data sources and environments.
- Out of scope — the tempting adjacent things you are explicitly not doing.
- Assumptions and dependencies — what must be true, and what the customer must provide, by when.
- Acceptance criteria — how each deliverable will be judged complete.
- Plan and milestones — phases, dates and stage-gate reviews.
- Risks — what could derail the work, and the mitigation.
- Change process — how new requests are handled.
Out of scope is the most important section
Every engagement has gravity pulling it outwards: "while you're in there, could it also…". Listing exclusions up front turns future scope creep into a calm conversation ("that's listed as out of scope — shall we add it as a change?") instead of an argument.
Assumptions and dependencies
Most delays come from the customer side, through no one's fault: access takes longer than expected, an SME goes on leave, a system migration lands mid-project. Write these down with owners and dates.
| Dependency | Owner | Needed by | Impact if late |
|---|---|---|---|
| Read access to the claims database (staging) | Customer IT | Week 1 | POC start slips day for day |
| 200 labelled example documents | Claims team lead | Week 2 | Cannot measure accuracy |
| Security review of the data flow | Customer security | Week 4 | Pilot cannot start |
Acceptance criteria for AI work
Traditional acceptance criteria are binary ("the API returns X"). AI deliverables are probabilistic, so define criteria against an agreed evaluation set:
| Deliverable | Acceptance criterion |
|---|---|
| Document field extraction | ≥ 95% field-level accuracy on the 200-document test set reviewed by the claims team |
| Answer assistant | ≥ 85% of answers rated "correct and complete" by two SMEs on a 100-question set; zero answers citing non-existent policies |
| Latency | p95 response under 5 seconds at expected pilot load |
Agree the evaluation set and who labels it during scoping. If you wait until the end, "good enough" becomes a matter of opinion.
Prioritising inside the scope
Use MoSCoW — Must, Should, Could, Won't (this time) — so that if time runs short, everyone already knows what gets cut. Keep "Must" small enough to finish with margin.
Timeboxing
Fix the time and flex the scope, not the other way round. A four-week POC with a prioritised list delivers something useful in four weeks; a POC defined by a feature list delivers when it delivers.
Handling change
Changes are normal and often good — they mean the customer is learning. Keep a simple change log: what was requested, why, the impact on time and cost, and who approved it. The point isn't bureaucracy; it's that nobody is surprised at the end.
Never absorb significant scope changes silently to keep a customer happy. It feels generous in the moment and turns into a missed deadline and a damaged relationship later.
"The customer keeps adding requirements. What do you do?" Show the mechanics: refer back to the agreed scope, quantify the trade-off, offer options (swap something out, extend the timeline, phase it), and let the sponsor decide.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.