5.3. Manage and Control Changes
💡 First Principle: Change control exists to prevent silent scope drift — every enabler in this task is about making change visible, deliberate, and documented, because an undocumented "small" change is how uncontrolled scope creep actually happens.
Enablers: execute the change-control process, communicate the status of proposed changes, implement approved changes, and update project documentation to reflect changes.
"Communicate the status of proposed changes" is easy to under-value: stakeholders who submitted a change request and hear nothing back lose trust in the process and start routing around it informally — which is exactly the uncontrolled-change pathway this task exists to prevent.
The sequence the exam expects
A change request is a formal proposal to modify a document, deliverable or baseline. Change control is the process by which those modifications are identified, documented, and approved or rejected. Most change questions are really asking which step comes next.
When a stakeholder raises a change after finding defects and a missed requirement, and a formal process exists, your next move is to take it to the change control board (CCB) and then communicate the decision. When the CCB has already approved a change, the next step is to note the outcome in the change log and tell stakeholders — not to start re-analyzing it.
Impact analysis looks at everything at once
The CCB exists so that changes are evaluated for their effect on scope, schedule, cost and quality before anyone implements them. A change that shortens duration but adds 15% to cost and introduces a high-impact risk demands a documented impact analysis across scope, schedule, cost, quality, resources and risk. A board that approves a scope addition after looking only at cost has a broken process. Value and risk are weighed together: a valuable change that depends on a vendor's unreleased feature gets one decision that accounts for both. Under PMBOK 8's principle Integrate Sustainability Within All Project Areas, long-term and environmental impact is also a standing input to that evaluation.
Approval authority should mirror governance thresholds: higher-impact changes route to more senior approvers, while small ones may be decided at a lower level under the same rules.
| CCB outcome | Next action |
|---|---|
| Approved | Implement, then update baselines and documentation |
| Rejected | Communicate the rationale to the requester and close the request |
| Deferred | Re-evaluate at a later milestone |
| Needs more information | Request clarification from the requester |
⚠️ Exam Trap: A rejection still has to be communicated. A stakeholder who is never told the outcome, or the reason, learns that the process is a black hole and is more likely to bypass it next time.
Urgency is not an exemption
A "small, obviously beneficial" change requested under time pressure still goes through change control — most processes offer an expedited review for exactly this case. If following the process pushes an urgent scope addition from this sprint into the next, accept the one-sprint delay: bypassing it under pressure normalizes the behavior that produces scope creep. A plant manager demanding a new custom report mid-rollout gets the same treatment — evaluate its impact on scope, schedule and an already-strained budget before any decision.
After approval: documentation, baselines and configuration
Implementing an approved change is only half the step. Documentation must be updated promptly; if it lags three sprints behind, reconstructing which change caused which effect becomes guesswork, and a new team member reading stale documents gets a false picture. Baselines matter even more: if approved changes never reach the cost and schedule baselines, CPI and SPI are measured against an outdated plan and every variance figure misleads.
| Change control | Configuration management | |
|---|---|---|
| Controls | Decisions to modify documents, deliverables and baselines | The product's functional and physical attributes and their versions |
| Question it answers | Should this change happen? | Which version is current, and does it match its requirements and design? |
Watch the pattern, not just the request
Many small undocumented changes made directly by developers add up to scope that has drifted from the baseline in ways no one can account for, which makes true status, cost and risk impossible to assess. Even when every request is reviewed, a high volume of individually minor changes can quietly shift the project's direction, so review the cumulative pattern periodically, not only each request in isolation.
Change in adaptive delivery
Adaptive teams expect change: new or revised backlog items are prioritized by the product owner rather than sent to a board, and work already committed to an iteration is normally protected until the next one. Formal change control still governs what is baselined or contracted — the budget, a fixed-scope agreement, a regulatory commitment — which is why hybrid projects usually run both mechanisms side by side.
⚠️ Exam Trap: Implementing a change once it's "clearly a good idea" without running it through the formal change-control process, even under time pressure. Bypassing the process — even for a beneficial change — is the trap PMI tests for.
