PMP · Question #461
A project team is experiencing delays in completing a task that turned out to be more complex than initially estimated. This is a critical task that could impact current iteration goals. What two opti
The correct answer is B. Review and update dependencies D. Conduct a root cause analysis. A critical task is delayed due to unexpected complexity, threatening iteration goals. The team needs to immediately understand why it's complex and how it impacts other work. The team should conduct a root cause analysis and review task dependencies.
Question
A project team is experiencing delays in completing a task that turned out to be more complex than initially estimated. This is a critical task that could impact current iteration goals. What two options will help the team initially address this obstacle? (Choose two.)
Options
- AEscalate the issue to the project sponsor
- BReview and update dependencies
- CSchedule a retrospective
- DConduct a root cause analysis
- ECreate a risk management plan
How the community answered
(50 responses)- A4% (2)
- B72% (36)
- C8% (4)
- E16% (8)
Why each option
A critical task is delayed due to unexpected complexity, threatening iteration goals. The team needs to immediately understand why it's complex and how it impacts other work. The team should conduct a root cause analysis and review task dependencies.
Escalating to the sponsor is premature before the team has analyzed the issue and attempted to find solutions; it's typically a last resort for unresolvable impediments.
When a critical task is delayed, reviewing and updating its dependencies is crucial. This helps the team understand the downstream impact on other tasks and the overall iteration goal, allowing for proactive adjustments to the schedule or resource allocation.
A retrospective is for *after* an iteration or a significant event to reflect and learn; it's not the initial action to resolve an *ongoing* critical task delay impacting the current iteration.
Conducting a root cause analysis immediately helps the team understand *why* the task is more complex than estimated. This understanding is essential for devising an effective solution, preventing similar issues in the future, and accurately re-estimating the remaining work.
Creating a full risk management plan is a proactive, upfront planning activity for the entire project, not an immediate action to address an emergent issue with a single task.
Concept tested: Agile impediment resolution and task analysis
Source: https://agilemanifesto.org/principles.html
Topics
Community Discussion
7B and D. The stem asks what helps the team address the obstacle initially, so you want immediate problem-solving moves: update dependencies to see the ripple effect on the iteration, and run a root cause analysis to understand the complexity before deciding next steps. A and C are tempting but wrong here because escalating jumps past the team's ability to self-solve, and a retrospective is a later event, not an initial response.
My mentor showed me this exact pattern last month, and the one thing he stressed was that the root cause analysis here is lightweight, not a full blameless postmortem, otherwise you risk stalling the iteration while you investigate.
B and D are your dynamic duo here, and I remember it with the phrase Big Decisions Require Review, where dependencies come first and root cause follows. When the team hits a complex wall mid-iteration, you map what it blocks and dig into why it stalled. Anyone else find it odd that people jump straight to scheduling a retrospective, or is that just a trap that gets me every time?
The retrospective trap is real because it sounds collaborative, but the exam wants you to resolve the blocker now, not reflect on it later, so dependencies first and root cause second is exactly the sequence to lock in.
First leaned toward A and C because escalating and scheduling a retro sound like safe agile moves, but the question asks for an INITIAL response to a blocked critical task, not a later reflection. B and D are your quick wins here because updating dependencies and running a root cause analysis directly attack the obstacle right now, flag E as a time sink for later.
My senior always says the word INITIAL in the stem is the trap, people scan right past it and pick the agile-sounding options, so B and D make sense, though I would add that between the two, D is the one that actually unblocks the task while B is more about keeping others informed.
B and D, my senior called these the "fix it now" pair. Does root cause analysis happen during the iteration or after?