PMP · Question #930
A project manager is executing a large project with many stakeholders. One of the primary stakeholders is requesting a change to the project scope. The project manager knows that this scope change…
The correct answer is D. Submit a formal change request since the change is affecting the project baseline. Even if a scope change appears minor, it must undergo the formal change control process, as it directly impacts the project baseline and requires proper documentation and approval.
Question
A project manager is executing a large project with many stakeholders. One of the primary stakeholders is requesting a change to the project scope. The project manager knows that this scope change will not require much effort from the project team. The project manager is worried that going through the full change control process will hold up the project schedule. What should the project manager do?
Options
- AAsk the primary stakeholder for their official approval to avoid the change control process.
- BImplement the change in order to avoid changes to the schedule baseline.
- CReject the change request because the project is already being executed.
- DSubmit a formal change request since the change is affecting the project baseline.
How the community answered
(42 responses)- A5% (2)
- B5% (2)
- C14% (6)
- D76% (32)
Why each option
Even if a scope change appears minor, it must undergo the formal change control process, as it directly impacts the project baseline and requires proper documentation and approval.
Getting informal approval from a stakeholder, even a primary one, does not replace the formal change control process, which ensures all affected stakeholders and baselines are considered and documented.
Implementing the change without formal approval is a direct violation of change management principles and will lead to uncontrolled scope creep, potentially impacting schedule, cost, and quality baselines without proper oversight.
Rejecting a change request simply because the project is in execution phase is not a valid reason; all change requests should be evaluated through the formal change control process, regardless of the project phase.
Any change to the project scope, no matter how small the perceived effort, constitutes a change to a project baseline (scope, schedule, cost). The change control process is designed to evaluate, approve, or reject such changes in a structured manner, ensuring all impacts are considered, documented, and officially approved. Bypassing this process can lead to scope creep, unmanaged risks, and an unaligned project.
Concept tested: Integrated Change Control; managing scope changes
Source: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/project-integration-management#integrated-change-control
Topics
Community Discussion
8D is the answer here. Think of it like a town wanting to add a small playground to an already approved city park plan, even if the construction crew can build it in an afternoon, the city still has to file the paperwork and get the council to sign off so the budget and property records stay honest. In project management, any modification to the project scope means you are touching the baseline, and the PMI mindset demands you submit a formal change request through the change control process regardless of perceived effort. Skipping the process just because a change seems easy is a fast track to scope creep and a compromised
Saw this last month, D is correct. PMI always wants formal change control, no shortcuts.
Co-sign D, and remember PMI spells it C-H-A-N-G-E: Control Happens After No Golden Exemptions, so even tiny tweaks go through the formal pipeline.
D is the call here, and my sticky hook is B.A.S.E.L.I.N.E. = Big Adjustments Seldom Escape Large In-process Notice Ever. Even if the tweak feels tiny, scope touches the baseline, so you march it through the change control gauntlet. A and B skip the paperwork and C just pretends execution means no more changes, which is silly. Quick question: does the size of the change ever let you bypass the formal process, or is it strictly about whether a baseline is touched?
D is the right call but the wording bugs me since the stem never says the change definitely impacts the baseline, just that its scope. Still, scope changes go through change control no matter how easy they seem, and A is tempting because a primary stakeholder asking to skip the process sounds like a shortcut when you are pressed for time.
D is right and your read on A is spot on, but on exam day watch for stems where the scope change is explicitly called minor because they use that to bait you into thinking it can skip change control.
Going with C here. During execution the scope baseline is locked, and even a small change sets a bad precedent, so rejecting it outright keeps the project on track and protects the integrity of the baseline.
D is correct because the PM should check the change management plan first to see how requested changes should be handled, not just reject them outright. C sounds principled but skipping the documented process is exactly what gets you in trouble on these questions.