What needs change control
- Scope changes that exceed an agreed threshold (often 5–10% of effort).
- Schedule changes that affect milestones in the charter.
- Budget changes beyond a delegated approval limit.
- Quality / acceptance criteria changes.
The change request flow
- Submit — anyone can raise a change request (CR). Document the change, the reason, the impact estimate.
- Analyze — PM + tech lead assess scope/schedule/cost/quality impact.
- Decide — CCB approves, rejects, or defers. Decision is recorded.
- Update baseline — if approved, the schedule/budget/scope baseline updates.
- Communicate — affected stakeholders are notified.
↳ the agile equivalent
Agile teams don't convene CCBs for every story change. The Product Owner has authority to reorder and reshape the backlog continuously — that's the system. Larger changes that affect committed milestones still escalate. Same principle: explicit decision authority for changes above a threshold.
Why this matters
Change control isn't bureaucracy for its own sake — it's the mechanism that keeps the schedule, budget, and scope-baseline numbers honest. Without it, you can't answer "what's the actual baseline anymore?" mid-project, and you can't defend variance to a sponsor.