3.3Change & scope management
The essentials in 30 seconds
- The danger is not change but uncontrolled change: cumulated "small additions" drift schedule and budget.
- Every change is formalized in writing, assessed (cost, schedule, quality, risks) then decided (accept, refuse, postpone).
- Reflex: "yes, and here is what it implies" — a process that protects the cost / schedule / quality triangle.
Running case — Bilal says "yes, and here is the price"
Mid-execution, Bilal's client asks for "just a small extra module" orally, then a second one. Before, Bilal would have accepted to please — and blown the schedule. This time, each request is written down, costed (3 days, + test budget) and decided at the steering committee: one accepted with an adjusted deadline, one postponed to phase 2. The client understands: the process protects HIS project.
Sequel to cases 3.1-3.2 — Bilal channels changes instead of suffering them.
1. The danger of uncontrolled change
A project lives: change requests inevitably arise. The danger is not change itself, but uncontrolled change — those "small additions" accepted on the fly which, cumulated, blow up schedule and budget. It is the return of scope creep: the slow drift of scope. Bilal paid for it before disciplining himself.
Informal micro-requests are the most dangerous because they look harmless: their sum is a major cause of overruns.
2. A process, not a refusal
The answer is a change management process: every change request is formalized (who, what, why), its impact assessed (cost, schedule, quality, risks), then approved or refused by the competent body (often the steering committee or sponsor).
You do not say "no" to everything — you say "yes, and here is what it implies". The decision is traced and the baseline scope updated. Controlling changes means protecting the golden triangle.
🔎 Concrete example — Informal micro-requests
The most dangerous ones.
"Just a small addition" orally → looks harmless, but accumulates.
Reflex: even a small request goes through the process (trace + quick assessment).
→ this is what protects the client's project from overruns.Outcome: the cost of each change made visible.
Reflex: update the baseline scope.
Section vocabulary
- Change request
- Any request altering the agreed scope, schedule or budget; to be handled formally.
Simple example: Bilal's client's "small extra module", written and costed.
What it is not: an internal adjustment with no agreed effect between parties.
Reflex: no addition accepted orally, even small.
- Change management process
- A defined circuit: formalize the request, assess impact, decide, trace.
Simple example: Bilal applies written → costing → steering committee → trace.
What it is not: accepting on the fly to please.
Reflex: display the circuit to the whole team and the client.
- Impact analysis
- Assessing a change's consequences on cost, schedule, quality, risks and resources.
Simple example: "+3 days, + tests, delivery delay risk".
What it is not: "yes, we will see" with no costing.
Reflex: each request = 4 impact boxes filled.
- Change board
- The body ruling on requests (often the steering committee on ordinary projects).
Simple example: Bilal's steering committee rules: accept with delay or postpone.
What it is not: the team member alone accepting a client addition.
Reflex: only the competent body rules, never alone.
- Traceability
- Recording requests, decisions and justifications, for history and reference.
Simple example: Bilal files request, costing and signed decision.
What it is not: oral agreements untraceable at project end.
Reflex: every decision written and shared with all.
In practice — Setting up a change process
- Define a mini-process: every change request is written (who, what, why), never accepted orally.
- For each request, run an impact analysis: effect on cost, schedule, quality and risks.
- Get the competent body (sponsor / steering committee) to decide: accept (adjusting the triangle), refuse, or postpone.
- Trace the decision and communicate it: the baseline scope is updated, everyone is aligned.
Ready-to-say script — answering a “small addition” (30 s)
"Gladly, let us review it. Write the request in two lines, I will cost the schedule and budget impact, and we will decide together: we integrate it with an adjustment, or we put it in phase 2. That is what protects your schedule."
To say to the client calmly, with no defensiveness: the process is a service, not a refusal.
Copy-paste template — change request sheet
REQUEST (who / what / why): _______________
COST IMPACT: _______________ | SCHEDULE IMPACT: _______________
QUALITY / RISK IMPACT: _______________
DECISION (accept / refuse / postpone): _______________
TRIANGLE ADJUSTMENT: _______________ | SCOPE UPDATED ON: _______________Very small business / tight budget
A notebook is enough: 1 line per request (what, impact, decision) reviewed with the client weekly.
SME in Algeria
Bilal gets even urgent message requests validated in writing: screenshot + costing before execution.
Software project
Every addition = dev + test + acceptance costing: the client sees that “small” is never free.
External client project
Tie each acceptance to a signed amendment (schedule, budget): the trace protects both sides.
✓ Best practices
- Formalize every request in writing, even “small” ones.
- Make the cost of each change visible (costed impact).
- Trace decisions and update the baseline scope.
✗ Common pitfalls
- Accepting additions orally, on the fly.
- Refusing everything on principle (counter-productive rigidity).
- Letting micro-requests through with no trace.
Key takeaways
- The danger is not change, but uncontrolled change.
- Every change is formalized, assessed (impact) and decided.
- “Yes, and here is what it implies” rather than an on-the-fly “yes”.
- A change process protects the cost / schedule / quality triangle.
48h challenge — apply tomorrow
Write the next incoming request on the change sheet (template above), cost its impact and get it decided by the right person.
- I can cite the 4 steps of the process.
- I can say “yes, and here is what it implies”.
- I traced 1 real request (or prepared the sheet).
Frequently asked questions
Should all changes be refused to hold the schedule?
No: over-rigidifying harms as much as accepting everything. A project must absorb useful evolutions. The key is making the cost of each change visible (schedule / budget impact) to decide knowingly: you accept or decline lucidly. The process is for deciding, not blocking.
How to handle informal client micro-requests?
They are the most dangerous because seemingly harmless. Reflex: even a small request goes through the process (trace + quick assessment). Explain that this is what protects THEIR project from overruns. Once the rule is understood, it prevents countless tensions: the sum of untraced “small nothings” is a major cause of overruns.
Bilal's client slips in “just a small addition” orally. What to do?