FDE Foundations · Module 3: Problem Framing & Scope
Handling Scope Change
Scope change is normal; absorbing it silently is the failure mode. Every change gets a log entry and a re-estimate, and the agreed core stays protected.
8 min reading
Objectives
- Log changes with date, reason, and impact
- Re-estimate affected phases instead of absorbing the cost
- Protect the agreed core when pressure rises
The change log
Keep a dated list: what changed, who requested it, why, and the impact in days or scope. The log does two jobs: it keeps the current plan honest, and it makes the engagement history legible when someone asks in month three why the date moved.
Re-estimate out loud
A change does not get absorbed into goodwill. Say the number: "Adding multi-currency support is three days of work and moves the pilot date to Thursday." Customers can then decide with the real price in front of them. Most conflicts come from prices being hidden, not from the change itself.
Protect the core
The core is the set of capabilities the primary metric depends on. When pressure rises late in an engagement, the temptation is to shave tests, docs, and error handling from the core to fit new requests. Do the reverse: new requests wait, the core ships whole.
A signed brief plus a change log ends most scope arguments in one sentence: point at the line.
Quick check
An optional 2-3 question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Exercise
Write a change log entry for this request on a fictional engagement: 'While you are in there, add an approval email to the CFO.' Include impact estimate and the reply sentence you would send.
Pass criteria
Entry has date, requester, reason, day impact, and a reply that states the new date or asks a ranking question rather than absorbing the work silently.