September 8, 2026 · 7 min read
TL;DR: These two plans sit next to each other as options across this bank, and the split between them is a split of question type. The configuration management plan answers what is under baseline control, so it is keyed when you need to know whether a request touches a baselined item at all. The change management plan answers how a change gets raised, assessed and approved, and who sits on the board, so it is keyed once the stem has already established that a change is needed. Consult them in that order and the pairs stop looking alike.
Candidates who treat these as roughly the same document get about half of these items right by luck. The bank writes them as deliberate pairs, which means the coin flip is the design.
The configuration management plan.
The bank keys this in a record where several stakeholders on a payroll-system upgrade ask to alter parts of scope, cost and schedule, and the project manager must work out which items require formal approval and which can simply be actioned. What do you check first? The options offer the change management plan for the approval process, the scope management plan, the configuration management plan for the baselined items, and the requirements traceability matrix.
Keyed is the configuration management plan, and the explanation states the sequencing rule that runs through this whole topic. The two plans answer different questions, and the order in which you consult them is what the item tests. The configuration management plan identifies which project artifacts are configuration items under baseline control, which specific elements of scope, cost and schedule are frozen, so it is what tells you whether a given request touches a baselined item at all. Only once that is known does the change management plan's process become relevant.
The word first in that stem is not decoration. It is the entire question.
When the change is already established and the question is about approval.
During user acceptance testing, a senior user identifies a major scope change needed for success. You may lack the money or resources and will need approval to increase either. What next? Keyed is reviewing the change management plan for the change control process and the approvers on the change control board.
The explanation names why the stem points here rather than at the configuration plan. The question is procedural and specific: a change is needed, it will require more money or resources, and you need to know how approval is obtained and who grants it. That is the change management plan's content, the change control process end to end, the forms and records it uses, and the composition and authority of the change control board, including what it can approve and what has to go higher.
The configuration management plan appears as a distractor in that same record, phrased as finding who can configure the project. That phrasing is a small tell: configuration control is about item versions, not about who is permitted to make settings.
The same two plans, sorted by what the stem is actually asking.
| What the stem is asking | Configuration plan role | Change plan role | Keyed |
|---|---|---|---|
| Which requests need formal approval at all | Names the baselined items | Offered as the distractor | Configuration management plan |
| How approval is obtained and by whom | Offered as the distractor | Names the process and the board | Change management plan |
| Stakeholders cannot see what gets baselined | Part of the answer | Part of the answer | Create both, plus the performance measurement baseline |
| Board approved the change, what next | Update the plan itself | Not offered | Re-version every baselined item the change touches |
| Ready to baseline scope after the scope statement | Add the scope statement to it | Not offered | Create the WBS and WBS dictionary |
The third row is the useful one for seeing what each plan is for. Stakeholders reviewing the project management plan say they cannot see what gets baselined or how performance and changes will be measured. Keyed is creating the configuration management plan, the change management plan and the performance measurement baseline with your team and adding them to the plan.
The explanation defines all three in a single line each, which is as compact a summary as this topic gets. The configuration management plan defines what gets baselined. The change management plan defines how changes are raised and decided. The performance measurement baseline defines what performance is measured against. Three distinct questions, three distinct artifacts, and the stakeholders had found all three missing.
The work is not over, and the bank has a record built entirely on that.
A change control board has approved a major scope change and it has been formally recorded. What next? One distractor updates the configuration management plan to reflect how the newly baselined items will be version-controlled. Keyed is identifying every baselined item the approved change touches and bringing each under configuration control at its new version.
The explanation makes the distinction sharp: an approved change does not update itself into the project's baselined documents and deliverables. The next step is working out exactly which baselined items the change affects and re-versioning each of them, so that the record of what the project now consists of matches what was actually authorised.
The distractor is subtle because it is not nonsense. Updating the plan changes the rules for version control. What the situation calls for is applying the existing rules to the items that just changed. Two of the other distractors are cruder and worth naming for contrast: waiting until the next status meeting, and closing the issue that triggered the change because the change is now approved. An approved change is a decision, not a completed piece of work.
Common trap: believing that adding a document to the configuration management plan is what baselines it. The bank offers exactly that in a scope record, where you have collected requirements, are finishing the scope statement, and need to baseline scope so future changes go through change control. Adding the scope statement to the configuration management plan as a baselined document is one option. Keyed is creating the WBS and WBS dictionary with your team, because the scope baseline is the approved scope statement plus the WBS plus the WBS dictionary, and two of those three do not exist yet. There is nothing to baseline. This bank flags that distractor by name and explains what is missing, rather than only marking it wrong.
What is the difference between the configuration management plan and the change management plan? The configuration management plan identifies which project artifacts are configuration items under baseline control, so it tells you whether a request touches a baselined item at all. The change management plan defines the change control process end to end, including the forms, the records, and the composition and authority of the change control board.
Which one do you consult first? The configuration management plan, when the question is whether something needs formal approval. The bank keys it for a project manager working out which of several requests require approval and which can simply be actioned, and its explanation says only once you know an item is baselined does the change management plan's process become relevant.
When is the change management plan the keyed answer instead? When the stem has already established that a change is needed and asks how approval is obtained or who grants it. In the bank's user-acceptance-testing record, a senior user identifies a major scope change requiring more money or resources, and the keyed answer is reviewing the change management plan for the change control process and the approvers on the board.
What happens to baselined items after the change control board approves a change? You bring each affected item under configuration control at its new version. The bank keys identifying every baselined item the approved change touches and re-versioning it, because an approved change does not update itself into the project's baselined documents, and the record of what the project consists of has to match what was authorised.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 Exam Content Outline, with every wrong answer explained, not just marked wrong, which is what turns a near-miss pair like these two plans into a rule you can reuse. Start the free 20-question sample — no card, no signup required to try it.
What is the difference between the configuration management plan and the change management plan?
The configuration management plan identifies which project artifacts are configuration items under baseline control, so it tells you whether a request touches a baselined item at all. The change management plan defines the change control process end to end, including the forms, the records, and the composition and authority of the change control board.
Which one do you consult first?
The configuration management plan, when the question is whether something needs formal approval. The bank keys it for a project manager working out which of several requests require approval and which can simply be actioned, and its explanation says only once you know an item is baselined does the change management plan's process become relevant.
When is the change management plan the keyed answer instead?
When the stem has already established that a change is needed and asks how approval is obtained or who grants it. In the bank's user-acceptance-testing record, a senior user identifies a major scope change requiring more money or resources, and the keyed answer is reviewing the change management plan for the change control process and the approvers on the board.
What happens to baselined items after the change control board approves a change?
You bring each affected item under configuration control at its new version. The bank keys identifying every baselined item the approved change touches and re-versioning it, because an approved change does not update itself into the project's baselined documents, and the record of what the project consists of has to match what was authorised.