PMP Change Control: Study Guide & Exam Tips

Change control protects the project's baselines (scope, schedule, cost) by routing every proposed change through a documented flow: submit a change request, assess the impact, decide through the defined authority (usually the change control board or sponsor), update the baselines and plans, and communicate the decision. On the exam, change control questions test whether you process changes before implementing them. The correct answer almost never jumps straight to implementation, no matter how small or urgent the change looks. The discipline applies to product scope, project scope, schedule, cost, and even some document updates.

• Change control governs baseline changes; configuration management tracks versions of products and components (which version is current).
• Preventive actions fix processes before problems occur; corrective actions fix them after. Both are typically processed as change requests when they touch baselines.
• Defect repair restores a component to requirements, and it is also routed through change control on the exam.
• Emergency changes ("fix forward") still get documented and reviewed after the fact; urgent does not mean exempt.
• Scope creep is change without control; gold plating is delivering unrequested extras. Both are failures of the same discipline, and questions ask you to recognize them in scenarios.

A client engineer asks a developer to add "one small export format." The classic exam pattern:

• Wrong answers: the developer adds it (no request), the PM rejects it outright (no analysis), the PM escalates immediately (premature).
• Correct answer: document the request and assess the impact on scope, schedule, cost, quality, and risk before any decision.
• Why: the exam rewards process integrity over speed. A change that looks small often shifts testing, documentation, and dependencies.

Memorize the sequence: request → impact analysis → decision by the defined authority → baseline update → communication → implementation.

Some situations cannot wait for the next board meeting: a production outage, a safety hazard, a security flaw that is being exploited. A well-written change management plan anticipates this with an emergency path, and the exam expects you to follow that path rather than improvise.

• The plan defines what qualifies as an emergency and who may authorize an emergency change (often the PM or an on-call delegate, within set limits).
• The fix is applied to contain the harm, and the decision and its rationale are recorded at the time, not reconstructed later.
• A change request is still raised, and the CCB reviews it after the fact, confirming the fix and approving any permanent baseline update.
• Configuration records, the issue log, and affected plans are updated, and stakeholders are told what changed and why.

The exam distinction: an emergency changes the order of the steps, not whether they happen. A scenario that calls a request "urgent" but describes no real harm from waiting for the normal review is not an emergency, and the standard flow applies.

Adaptive delivery expects change, so it routes most of it through the backlog instead of a board. That is a different mechanism, not a looser one.

In a hybrid project both mechanisms run side by side. A stakeholder who asks a developer directly for a new feature should be redirected to the product owner, not handed a CCB form. A request that would move the fixed go-live date or exceed the funded budget goes through formal change control, even though the team plans its work from a backlog.

The change management plan names the CCB's members and its decision rights. Typical members are the sponsor or a sponsor delegate, business or customer representatives, and the functional or technical leads whose areas a change affects; quality, security, or procurement specialists join when a change touches their area. The PM usually prepares the change request and its impact analysis, presents it, and may facilitate the meeting, but does not decide changes beyond the PM's own authority.

Decision rights are often tiered: the PM approves small changes within agreed tolerances, the CCB decides baseline changes, and changes that alter the business case go to the sponsor or a steering committee. When a question names a CCB, it is testing whether you respect those thresholds.

Change control sits in the Process domain (41% of the exam), but scenarios borrow from the other two. People-domain versions involve a stakeholder pressuring a team member to slip in an unapproved change; the credited answer pairs process discipline with a direct, respectful conversation. Business Environment versions involve regulatory or compliance changes, where the change is effectively mandatory but its impact still has to be analyzed, approved, and recorded.

PMI says approximately 40% of items represent predictive approaches and the remaining 60% is divided between adaptive/agile and hybrid. In practice that means many change questions first ask you to recognize which mechanism applies: the product backlog for product changes, formal change control for contractual and baseline commitments.

• Skipping change control for "small" changes; size does not exempt a change from the process.
• The PM approving baseline changes alone when the CCB or sponsor holds that authority.
• Confusing change control (baselines) with configuration management (product versions).
• Implementing first and documenting later in non-emergency scenarios.
• Forgetting to update the traceability matrix, plans, and baselines after approval.

Drill the flow until ordering questions are automatic:

• Any question describing a requested change: the next step is documentation or impact analysis.
• Questions naming an approver: check who owns which baseline per the change management plan.
• Agile flavor: changes to the product backlog go through the product owner and backlog refinement, not a CCB. The exam blends both worlds.

Practice change-control questions mixed with scope and schedule items, since real scenarios combine them.