PMP · Question #1132
A project is in the final stages, and a key stakeholder demands a change to a product feature that will add 2 weeks to the critical path. What should the project manager do?
The correct answer is B. Perform a detailed assessment to analyze the impact. When a key stakeholder requests a change that impacts the critical path, the project manager must first assess the full implications before making any decisions.
Question
A project is in the final stages, and a key stakeholder demands a change to a product feature that will add 2 weeks to the critical path. What should the project manager do?
Options
- AInitiate a risk response strategy from the risk register.
- BPerform a detailed assessment to analyze the impact.
- CReject the changes as the project is in the final stages.
- DUse schedule compression methods to alter the critical path.
How the community answered
(30 responses)- A17% (5)
- B73% (22)
- C7% (2)
- D3% (1)
Why each option
When a key stakeholder requests a change that impacts the critical path, the project manager must first assess the full implications before making any decisions.
Initiating a risk response strategy is premature as a change request is not inherently a project risk until its impact is analyzed and determined to be a threat.
Performing a detailed assessment to analyze the impact is a critical step in the integrated change control process, where the project manager evaluates how the proposed change will affect scope, schedule, cost, quality, resources, and risks. This assessment provides the necessary information to make an informed decision on whether to approve, reject, or modify the change request.
Rejecting changes outright, even in final stages, without proper analysis can damage stakeholder relations and overlook potentially valuable enhancements.
Using schedule compression methods without first understanding the full impact of the change might lead to further quality issues, increased costs, or new risks.
Concept tested: Integrated change control process
Source: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/integrated-change-control
Topics
Community Discussion
7The answer is B. A senior PM at my company told me the PMI mindset is always assess first, act second, no matter how late in the project you are. Even though the stakeholder is demanding the change right at the end, you still need to perform a detailed impact assessment before deciding what to do about it. D sounds tempting because schedule compression is a real tool, but you cannot jump straight to crashing or fast-tracking until you understand the full impact of the requested change on scope, cost, and quality. C is wrong because outright rejecting a stakeholder request without analysis goes against how
Agree on B, and Ill add that the real exam trap here is C, not D, because some candidates hear late-stage change and immediately think reject, which violates the PMBOK principle that every change request gets processed through Perform Integrated Change Control regardless of timing.
B is the right call here because you never act on a change request in the final stages or any stage without first understanding what it actually does to scope, schedule, cost, and quality. C is the trap people grab when they panic about the deadline, but rejecting outright skips the whole change control process. D is premature because you might end up using crashing or fast-tracking later, but only after you know the real impact and have an approved change. Does anyone know if PMI treats a stakeholder demand this late as an automatic trigger for the formal change control process, or does the assessment happen before
Passed last month and can confirm B is the pattern they want, and to answer your question the assessment is literally the first step of the formal change control process so there is no separate pre-trigger.
First leaned toward C because the project is in final stages and rejecting felt like the safe call. But the exam always wants you to assess impact before making any decision on a change request, so B is the move.
B is correct. You always assess impact before touching the schedule or rejecting anything, and since this change hits the critical path the PM needs concrete data on cost and scope before bringing it to the change control board.
Agree with B but the stem usually wants you to flag that the schedule baseline itself does not get touched until after the CCB approves, so assess first, baseline later.