September 7, 2026 · 6 min read
TL;DR: Root cause analysis is keyed 13 times and wrong 14 times, the closest split measured across the bank's 2,141 questions. The dividing line is whether the cause is genuinely unknown. When the stem says nobody can explain it, diagnose. When the stem has already named the cause, or a planned response exists, diagnosing is stalling.
Most exam patterns lean one way and you can play the odds. This one does not. Root cause analysis is almost exactly a coin flip on frequency, which means the option itself carries no signal and the stem carries all of it.
An explicit statement that nobody knows why. The bank is unusually consistent about signalling this.
An agile team building a hospital rostering tool makes strong progress through four iterations, and in the fifth the pace drops sharply. The stem says: nobody can point to a reason for it. Keyed is working with the team to find the root cause. Every distractor rests on a guess the situation does not support. Removing the team member who is holding the others up assumes an underperformer nobody has identified. Doing nothing because the team slipped from norming back to storming invents a Tuckman diagnosis. Doing nothing because the first four iterations happened to hold easier stories assumes a prioritised backlog is worked easiest-first, which it is not.
A water treatment control system fails acceptance testing at 82% recovery against a 95% criterion. Keyed is a root cause analysis to establish what is limiting the recovery rate. The explanation names the stakes precisely: a thirteen-point gap could be a commissioning setting, a design limitation, or a defective component, and which one decides whether the fix costs a day or reopens the design. Proposing a workaround offers a solution to an undiagnosed problem. Seeking agreement to lower the criterion redefines success to match the shortfall. Requesting an extension commits to a schedule impact before anyone knows there is one.
Both stems share the shape: something measurable went wrong, and no cause has been established.
Three situations, and they are worth learning separately.
A planned response already exists. An organisational change programme meets internal resistance, and the stem says this was a risk the project manager identified and planned for during planning. A logistics manager's supervisor formally asks for a delay. Carrying out a root cause analysis of what lies behind the manager's resistance is offered, and loses to carrying out the risk response that was already planned. The explanation states the rule outright: root cause analysis would be the right first move only for a risk nobody had anticipated.
The cause is already named. A team is described as new, inexperienced, and short on capability, and the steering committee is pressing for better performance. Brainstorming and root cause analysis to get to the heart of the problem is offered. The heart of the problem is in the stem. Keyed is co-location, a shared knowledge portal, training, and team assessments, which close a capability gap and then measure whether it is closing.
The venue is wrong. One week into a two-week sprint, no sprint backlog items are complete and the goal is unreachable as planned. Raising the root cause of the poor performance at the daily standup is offered. Keyed is bringing the product owner and team together to renegotiate the sprint backlog and work through the obstacles. The standup is a coordination meeting, and merely diagnosing there still leaves the sprint unrenegotiated.
Common trap: assuming diagnosis is always the safe answer because the exam rewards understanding before acting. It usually does, and that makes this the most expensive habit in the set. In the risk item above, the analysis has already been done, months earlier, and repeating it wastes the planning the project paid for. The bank offers root cause analysis as the wrong answer 14 times, which is more often than it offers it as the right one. Read the stem for whether someone has already established the cause before you reach for the option that establishes it.
The retrospective for how the team works, a formal analysis for a measured shortfall, and neither when a planned response already exists.
| Situation | Where the bank keys the diagnosis |
|---|---|
| Team performance is worse than peers, next couple of sprints | The sprint retrospective |
| Unexplained drop in delivery pace | With the team, cause unspecified venue |
| Deliverable misses a measured criterion | Formal root cause analysis before any remedy |
| Sprint goal unreachable mid-sprint | Renegotiate with the product owner, not diagnose at standup |
| Risk that was identified and planned for | Execute the planned response, do not re-diagnose |
The retrospective row deserves a note. A year after a move to hybrid delivery, one project is performing worse than others in the portfolio, and the question asks what that project's manager can do over the next couple of sprints. Keyed is finding the root cause at the sprint retrospective, because the retrospective is the event at which the team inspects how it is working. Raising it with the product owner at the sprint review inspects the increment instead. Opening it at the daily standup uses a coordination meeting for problem solving. Running team-building activities presumes a motivation problem before anyone has diagnosed one, which is the same error in the opposite direction.
When is root cause analysis the keyed answer on the PMP exam? When the scenario says nobody can explain what happened. Phrases like 'nobody can point to a reason' or an unexplained shortfall against a criterion are the entry condition, and the bank keys diagnosis before any remedy.
When is root cause analysis a distractor? When a planned risk response already exists, when the stem has already named the cause, or when the analysis is proposed in the wrong venue such as a daily standup rather than a retrospective.
Where should a team diagnose a performance problem in agile? The retrospective. It is the event at which the team inspects how it is working. The sprint review inspects the increment with the product owner, and the daily standup is a short coordination meeting, not a problem-solving session.
Is a fishbone diagram the same as root cause analysis? A fishbone diagram is one technique for organising possible causes. The bank offers it in a scenario where the problem is a misunderstanding between people and it loses, because the technique is not the issue; whether diagnosis is needed at all is.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: Diagnose Before You Act: The Answer Shape the PMP Exam Rewards Most and Continuous Improvement: Retrospectives, Lessons Learned, and What the Exam Actually Rewards. Process tasks are mapped on the Process domain study page.
When is root cause analysis the keyed answer on the PMP exam?
When the scenario says nobody can explain what happened. Phrases like 'nobody can point to a reason' or an unexplained shortfall against a criterion are the entry condition, and the bank keys diagnosis before any remedy.
When is root cause analysis a distractor?
When a planned risk response already exists, when the stem has already named the cause, or when the analysis is proposed in the wrong venue such as a daily standup rather than a retrospective.
Where should a team diagnose a performance problem in agile?
The retrospective. It is the event at which the team inspects how it is working. The sprint review inspects the increment with the product owner, and the daily standup is a short coordination meeting, not a problem-solving session.