Handling Scope Changes in Customer Deployments Without Burning Trust
Updated · Tech checked
Treat scope change as a priced decision, not a favor: log it, re-estimate impact on timeline and metrics, get explicit trade-off approval (add time, cut something, or accept risk), and update the brief's version - silence is how projects rot.
The short answer
Scope will change - customers learn what they want by watching you build. Healthy projects metabolize change through a visible protocol; dying projects absorb it silently until the timeline explodes. The protocol below takes 30 minutes per change and saves weeks.
The five-step protocol
- Log the request in a change register: date, requester, description, verbatim.
- Classify: is it in the spirit of the signed brief (refinement) or new territory (addition)?
- Price it: engineering hours, timeline impact, metric impact, operational cost. Be honest - padding destroys credibility; so does underpricing.
- Offer a trade-off, not a yes/no: "Adding X costs ~1 week; we can absorb it by deferring Y from this phase, or extend the milestone by a week. Which do you prefer?"
- Update the brief (v+1) with changed sections marked, and re-confirm sign-off.
What kills trust
- Quietly absorbing changes until you miss a date "for no reason."
- Weaponizing the register ("that's out of scope" as a shield) - the goal is shared decisions, not contract law.
- Re-pricing completed work.
A worked exchange
Customer: "Can the matching service also handle partial refunds?" You: "That's new logic in the matcher. Rough estimate: +4 days and a re-test of the reconciliation report. Options: (a) add now, milestone slips 4 days; (b) phase 2 right after go-live; (c) drop the exception UI polish to fit. Which?" Customer picks (b). Register updated. Trust intact - they saw the price and chose.
Prevention
The best fix is upstream: a brutally clear out-of-scope list kills half of scope creep before it starts.
Continue: Writing briefs · Defining success metrics