September 6, 2026 · 7 min read
TL;DR: A change request is for anything that would move an approved baseline: scope, schedule, cost, or quality. Anything else gets logged and actioned. When a request is real, assess its impact first, then take it to whoever owns the baseline under the change management plan. Approval authorises the change; it does not fund it.
Most candidates lose change-control questions before they reach the process at all. They spot that something is changing and go hunting for the option that submits a change request. The exam is usually asking something one step earlier: is this actually a change to a baseline, and if it is, whose call is it?
The test is the baseline, not the size of the adjustment or how surprised you were by it.
Take three things arriving in the same week on a facility extension. A supplier offers a delivery slot two days earlier on materials already on order, at no extra cost. An electrician wants to swap a specified fixture for a functionally identical one from a different manufacturer, same price. The construction team wants to reroute a power connection, which changes the approved design.
Only the third is a change request. The first two touch no approved scope, schedule, or cost baseline, so they get logged and actioned. That scenario is one of the 92 change-control questions in this bank, and its wrong answers are the two symmetrical failures: send all three to the change control board, or handle all three informally.
| Situation | Route it as | Why |
|---|---|---|
| Earlier delivery, no cost change | Log and action | No baseline moves |
| Equivalent substitution, same price | Log and action | No baseline moves |
| Design reroute | Change request | Alters the approved scope baseline |
| Stakeholder asks for a new feature late | Change request | Alters scope, and probably schedule and cost |
| Team reorders work inside the sprint | Backlog refinement | Iteration work, not a baseline |
Common trap: treating scope creep and change as the same problem. They are not. Scope creep is scope that grows without anyone deciding it should. The failure is not that the project changed, it is that the change never passed an authorisation point. Wrong answers in this cluster regularly offer "refuse the change" or "freeze the scope" as the anti-creep move, and both miss for the same reason. A formal change process does not stop change. It makes change arrive funded and scheduled instead of quietly eating the contingency you were going to need anyway.
Whoever owns the affected baseline, as named in the change management plan. That is the honest answer, and it is why the exam so rarely rewards naming a body from memory.
What the exam does test, over and over, is the sequence. A stakeholder asks for a substantial new capability late in the cycle, against a tight deadline. The tempting answers are to decline it because there is no time, or accept it because the stakeholder is senior. Both skip the step that decides the question: assess the effect on scope, schedule, cost, quality, resources, and risk, then let the authority choose with that in front of them. Lateness and a tight deadline make the assessment more important, not less, because they are exactly what determines whether the work can be absorbed at all.
Three authority patterns worth keeping separate:
The change, and only the change.
The bank puts this almost as plainly as it can be put. During execution you receive an approved change request from the client, then realise the allocated budget may not cover delivering it. The approval settled whether the change happens. It said nothing about the second fact you have just found.
The client is both the requester and the party whose money is at stake, so the cost impact goes back to them, and they decide whether to fund it, cut it down, or drop it. Absorbing it from contingency, starting work and reporting the overrun later, or resubmitting the whole change request all show up as options, and all three make a funding decision on behalf of someone nobody asked.
The same separation explains why configuration management is not change control. Configuration management identifies and documents an item's characteristics, controls changes to them, and records and audits their status. Deciding who holds change-control authority in the first place is a governance decision, not a configuration management activity. Questions that blur the two are checking whether you know that one tracks the what and the other decides the who.
One filing note if you studied from pre-2026 material. Change control now sits in Business Environment under the July 2026 Exam Content Outline, alongside risk and impediments, which is part of why that domain went from 8 percent of the exam to 26. The subject matter barely moved. The filing did, and it matters when you are budgeting study time by domain.
Does every change on a project need a formal change request? No. A change request is needed when something would alter an approved baseline: scope, schedule, cost, or quality. An operational adjustment that leaves all four untouched can be logged and actioned. Routing everything through the board buries it in trivia and hides the real baseline changes.
Who approves a change request on the PMP exam? Whoever owns the affected baseline, as defined by the change management plan. That may be a change control board, the sponsor, or the project manager within a delegated threshold. The exam rarely wants a job title guessed; it wants the impact assessed first and then taken to the authority the plan names.
Does an approved change request come with the budget to deliver it? No. Approval authorises the change; funding is a separate decision. If you find after approval that the allocated budget will not cover delivery, you raise the cost impact with whoever owns the money.
Do change control boards apply on agile projects? Not inside the iteration. Mid-sprint changes go to the product owner for backlog refinement and prioritisation against everything else waiting. The board governs baselines on predictive work; the backlog is the equivalent control point on adaptive work.
The 92 change-control questions in PMP Practice are re-certified against PMBOK 8 and the July 2026 ECO, and every wrong answer comes with the reasoning that makes it wrong, explained rather than just marked. Start the free 20-question sample with no card and no signup.
Related: Business Environment tripled in weight · Risk probability and impact · Business Environment study guide
Sources: PMI — PMP Examination Content Outline, 2026 (PDF) · PMI — PMBOK Guide standards
Does every change on a project need a formal change request?
No. A change request is needed when something would alter an approved baseline: scope, schedule, cost, or quality. An operational adjustment that leaves all four baselines untouched can be logged and actioned without formal evaluation. Routing everything through the change control board buries it in trivia and makes real baseline changes harder to see.
Who approves a change request on the PMP exam?
Whoever owns the affected baseline, as defined by the project's change management plan. That may be a change control board, the sponsor, or the project manager within a delegated threshold. The exam rarely wants you to guess a job title; it wants you to assess the impact first and then take it to the authority the plan names.
Does an approved change request come with the budget to deliver it?
No, and this is a favourite exam distinction. Approval authorises the change; funding is a separate decision. If you discover after approval that the allocated budget will not cover delivery, you raise the cost impact with whoever owns the money rather than absorbing it quietly or starting work and reporting the overrun later.
Do change control boards apply on agile projects?
Not inside the iteration. On agile or hybrid delivery, mid-sprint change requests go to the product owner for backlog refinement and prioritisation against everything else waiting, not to a change control board. The board governs baselines on predictive work; the backlog is the equivalent control point on adaptive work.