Define scope before delivery
A strong scope states:- business question;
- process boundary;
- teams and locations;
- stakeholder count or coverage assumptions;
- evidence sources;
- deliverables;
- revision rounds;
- exclusions;
- client responsibilities.
Use the business-question test
When a new request appears, ask:Is this necessary to answer the agreed business question, or is it a new question?If it is a new question, treat it as a scope decision.
Three responses to additional work
Absorb
Use for genuinely trivial clarification that does not change effort or risk.Trade
Replace something already in scope.We can add the second workshop if we remove the optional detailed appendix and keep the same timeline.
Change request
Use when the new work materially changes effort, duration, stakeholders or risk.Change-request structure
Include:- requested change;
- reason;
- impact on scope;
- impact on fee;
- impact on timeline;
- dependencies;
- approval required.
Common scope traps
Watch for:- “while you are here, can you also look at…”;
- unlimited stakeholder interviews;
- undefined data cleaning;
- detailed production architecture inside a diagnostic;
- additional business units;
- repeated executive revisions;
- implementation support added to an advisory scope.
Useful talk track
That is a sensible extension, but it is outside the process we originally scoped. I can either price it as an additional workstream or we can trade it against something already included. Which would you prefer?Scope control is not unhelpful. It makes the commercial agreement explicit and protects delivery quality for both sides.