PMI-ACP Facilitate Problem Resolution: Root Cause Analysis, Five Whys, Fishbone and Timely Resolution

Facilitating problem resolution means helping an agile team find out why a problem is happening, choose the fix that adds the most value, and drive that fix to closure quickly, while the team (not the leader) owns the thinking and the decision. The leader's job is to run the process well: frame the problem, bring the right people and data together, keep the analysis honest, and make sure nothing stalls.

The PMI-ACP Examination Content Outline lists this as the second task under the Leadership domain, with three enablers that this lesson follows:

1. Investigate the root cause of problems (for example, root cause analysis and Ishikawa diagrams).
2. Determine the resolution strategies with the team that will add the most value.
3. Ensure the problems are resolved in a timely manner.

The outline's tools and techniques list supports the first enabler with the Five Whys, fishbone diagram analysis, value stream mapping and control limits, all covered here.

Three neighbouring tasks share vocabulary but test different things. Disagreements between people, and the levels of conflict, belong to Facilitate conflict management in this domain. Spotting impediments and risks early, and ordering which ones to remove, belong to the Delivery domain's impediment and risk task. Running retrospectives and acting on their findings belong to the Mindset domain. This lesson is about a problem that has already appeared: a broken build, a slow process, rising defects, an outage.

A symptom is what the team observes; a root cause is the condition in the process or system that produces it, such that removing it stops the problem coming back. A workaround treats the symptom: it makes today's pain go away but leaves the cause in place, so the problem returns or keeps costing time.

Symptom fixes look sensible on their own, which is why they are tempting:

• Clearing disk space on a test server every Friday because it fills up, without asking why log files are never rotated.
• Adding a manual check after every deployment because configuration errors slip through, when nothing validates the configuration before it ships.
• Hiring a contractor to answer "where is my order?" emails, when the order page never shows a delivery date.
• Padding estimates to absorb a slow review step instead of finding out why reviews queue.

Each of these can move a number for a while. The test is the goal: if the goal is for the problem to stop, the strongest resolution changes the condition the evidence identifies as the cause. Adding capacity to absorb a problem, or shrinking commitments around it, accepts the problem as permanent. A workaround can still be a reasonable interim step, but the team should choose it knowingly and keep the underlying problem open.

A related trap is closing a problem because it disappeared after a reset of some kind. A problem that comes back and is cleared the same way each time is telling the team that the cause is still there. Recurrence is evidence, so the problem stays open until the cause is understood.

The Five Whys is a root cause technique in which the team takes a problem and asks "why did that happen?" repeatedly, each answer becoming the subject of the next question, until it reaches a cause in the process that it can change. Five is a rule of thumb, not a quota: stop when the answer is a process or system condition the team can act on, and keep going while it is not.

It suits a problem with a fairly clear first explanation that the team wants to look beyond, quickly and without drawing anything. Good practice:

• Aim for a process cause, not a person. An answer that names someone's slip ("the reviewer missed it") is never the end of the chain, because people will always slip sometimes. The next question is why the process depended on nobody slipping. Process answers lead to fixes the system enforces (an automated check, a safer default); person answers lead to reminders and blame, which rely on the same attention that already failed.
• Follow the evidence, not the vote. When a step produces two answers and data supports both, the problem has two contributing paths, so each chain is followed until it reaches its own process cause. Popularity does not decide between causes, and an intermediate answer is not yet a root cause just because the discussion has run long.
• Do it with the people who know the work, and check each answer against facts where possible.

The limitation is that a single chain finds a single cause. When the same symptom keeps showing up under different conditions, or a fix based on one chain does not stop it, the problem probably has several contributing causes. A fishbone diagram is then a better fit, because it lays the causes out side by side instead of following one chain at a time.

An Ishikawa diagram, also called a fishbone or cause-and-effect diagram, lays out the possible causes of one problem in categories that branch from a statement of the problem at the "head" of the fish. Common categories are people, process, tools, environment, materials or data, and measurement, but the team can choose categories that fit its work.

It is the right tool when a problem probably has several contributing causes and the team needs to see them together rather than follow one chain. What makes it work, and why:

• A specific, measurable problem statement at the head. "Average time to answer a support ticket rose from 4 to 11 hours after the help-desk migration" focuses the group; "support is slow" lets everyone attach a different problem. A vague head produces a vague diagram.
• Everyone whose work the problem touches. The branches can only hold what the people in the room know. A problem that crosses several steps or roles needs someone from each of them, or whole categories of cause stay invisible.
• Open brainstorming before anyone's favourite theory is on the board. Whatever is written first anchors the group. Starting from a ready-made list, or from one person's suspicion, narrows the branches to what someone already believed, which defeats the purpose of mapping all the causes.
• Output treated as candidates. A fishbone generates possible causes; it does not prove any of them. Data comes next, to check which candidates are real (see "Evidence before cause").

The right tool depends on what the team already knows and what question it needs answered: drill one chain, map many causes, rank logged data, find where time goes, or judge whether a change is a real signal.

A Pareto chart sorts categories by frequency, usually with a cumulative line, reflecting the observation that a few categories often account for most occurrences (the "80/20" pattern). It ranks causes the team has already recorded; it does not generate new ones.

A value stream map follows one item from request to delivery and shows each step's working time and waiting time. Its usual finding is that most elapsed time is spent waiting in queues and hand-offs, often between groups, rather than being worked on. That is why it is the tool for long lead times across group boundaries: a team analysing only its own steps would guess at delays it cannot see, while mapping the whole flow with each group involved shows where the time actually goes.

Other charts sound related but answer different questions: a cumulative flow diagram shows work accumulating by state over time, and burndown and burnup charts track work remaining or completed. They can reveal that a problem exists, but they do not diagnose its cause.

Control limits are boundaries on a control chart, usually set three standard deviations above and below the process mean and calculated from the process's own history, that separate normal (common cause) variation from unusual (special cause) variation. They tell a team when a result is worth investigating and when it is not.

• Common cause variation is the ordinary spread a stable process produces. Suppose a team's pipeline build usually takes 10 to 13 minutes and the upper control limit is 17. A 16-minute build looks slow, but it is inside the limit, so it is consistent with normal variation. Analysing a single in-limit point tends to "find" causes that are not real, and changing the process in response (what Deming called tampering) can make it less stable. The right response is to explain this and keep watching.
• Special cause variation is a signal that something specific happened. A 35-minute build against that same limit justifies asking what was different about that run. The response is aimed at the occurrence: it is neither absorbed into the limits (which would hide the signal) nor treated as a reason to change how the whole system works.
• Non-random patterns inside the limits are signals too. PMI's rule of seven (other rule sets use eight or nine points) says that seven or more consecutive points on the same side of the mean are very unlikely to be chance, so the process has probably shifted even though no point has crossed a limit. Waiting for a limit breach would miss it. As with any signal, the next step is to find out what changed before deciding what to do about it.

Every candidate cause is a hypothesis until data supports it, so the team should check its likeliest candidates against evidence before spending effort on a fix. Agreement, seniority and conviction are not evidence.

Three principles keep the analysis honest:

• Narrow with data, not with enthusiasm. A brainstorm produces many candidates and usually a favourite. The team picks the few that look likeliest and checks them against records it already has (when the problem started, which work items or steps it involves, what changed around then). Only the candidates that survive deserve a fix. Effort spread evenly across every candidate, or aimed at whichever got the most votes, is effort spent before anyone knows what the cause is.
• Give every theory a fair test, including a senior person's. A stakeholder's explanation is one hypothesis among several. The analysis should be able to prove it wrong: use data the team already holds about the whole flow of work, examine it together, and compare the theory with the alternatives. A method that starts from the suspected cause, or that only looks at the group under suspicion, can only confirm what it assumed.
• Do not let the fix come first. When a measure gets suddenly worse, proposals for controls and targets arrive quickly. A fix chosen before the cause is known may address the wrong thing and still cost everyone time. Generating causes together and checking the records comes before choosing any of them.

Inputs that capture how people feel about a problem, such as satisfaction scores, help decide how much it matters but rarely explain why it happens.

Once the cause is known, the people who experience the problem generate and choose the resolution, and the leader facilitates; the strategy chosen should be the one that adds the most value, not the one that is most popular, fastest or most familiar to the leader.

Who decides

• A problem inside the team's own process, affecting nobody outside it, is the team's to resolve. The scrum master or agile practitioner facilitates, the product owner owns what gets built, and a functional manager deciding would override a self-organizing team.
• The leader's experience is input, not a decision. Something that worked for the leader before is worth offering as one option among others. Imposing it takes ownership away from the team, and people commit far less to a fix they did not shape.
• Everyone whose behaviour the fix must change takes part. If the cause sits partly in another role's work, that role helps diagnose it and agree the fix with the team. A fix needs the commitment of the people who must carry it out, so it cannot be decided by one side and handed to the other, and an outside body deciding it leaves out the people who live with the problem.

Choosing the most valuable strategy

• Weigh impact against effort. Analysis often yields more possible actions than the team has capacity for. Ranking them by expected impact relative to effort, then doing the best one or two properly, beats any ranking that looks at only one side of that ratio. Spreading capacity across everything at once tends to leave everything half-done.
• Respect the real constraints. When a full fix takes longer than the time available, the most valuable strategy often combines immediate relief with steady removal of the cause, for example automating the riskiest part of a manual regression pass now and the rest over the next few iterations. A strategy that only hides the symptom keeps the cause and can mask new problems; one that stops all delivery until the fix is done trades a problem for a bigger one.
• Fix at the source when the problem is shared. When several teams suffer from one cause owned by someone else, each team's local workaround keeps paying the cost and leaves the cause in place, and separate complaints hide how big the problem is. Pooling the evidence and fixing the cause once, with its owner, removes the loss for everyone.

Treat the fix as an experiment

A resolution is a hypothesis that a particular change will remove the problem. So before the change starts, the team agrees what result would show it worked (a measurable outcome, not just "we did it") and when it will look at that result together.

Without those two, a fix turns into a permanent habit nobody evaluates. Decisions about keeping a practice, spreading it or formalising it belong after the evidence, not before it.

When the review date arrives, read the result in two parts:

1. Was the fix actually carried out? If adoption was patchy, the experiment did not test the hypothesis.
2. Did the outcome move?

If the fix was applied fully and the outcome is unchanged over the agreed period, the hypothesis has failed: the team most likely targeted the wrong cause. The response is to go back to the diagnosis with the team. Anything that keeps the original diagnosis, whether more time, more enforcement or extra fixes layered on top, ignores what the experiment just showed.

Timely resolution means problems are surfaced as soon as they appear, harm is contained at once, the team concentrates effort on whatever is blocking flow, and someone owns each open problem until it is verifiably gone. Waiting for the next scheduled meeting is rarely timely.

Contain first, then resolve

When a problem is harming customers or the business right now, the first priority is to stop the harm with the fastest reliable step available, such as switching off a faulty feature flag or reverting to a known-good version. Analysis takes time, and every hour spent analysing while the harm continues is an hour of avoidable damage. A change made to production without a known cause is not containment; it is a guess that may add a second fault. Containment is not resolution, though: the team still needs the root cause, or the fault returns.

Swarm on blockers

Swarming means several team members work together on one blocking item until it is cleared. When one item is holding up others, finishing it fast matters more than keeping everyone busy, because starting new work just adds to the pile of things that cannot finish. In Kanban, a full column behind a blocked item is the board doing its job: the WIP limit is signalling that the team should clear the blockage. Loosening the limit or starting more work silences that signal. If the cause is something the team owns, the team fixes it rather than handing it off.

Surface fast, solve in a focused follow-up

The daily stand-up is where blockers should surface, as soon as they appear rather than days later at a retrospective. But the stand-up is not where they are solved. When a problem needs discussion, the practitioner arranges a follow-up straight after the stand-up with just the people needed. The problem gets worked on that day, the rest of the team keeps its time, and nobody is left to solve it alone. Teams with little shared working time need a channel that does not wait for a meeting at all: a blocker posted to a shared board or channel, tagging the people who can help, gets seen the same day wherever they are.

A problem the team cannot fix itself should be taken promptly, with evidence and its impact, to whoever owns the cause; a problem the team can fix should stay with the team. Either way, each open problem needs an owner, a target date and a check that it is really gone before it is closed.

When to escalate, and when not to

When an external dependency threatens a goal, two things are needed at once. The impediment needs action from someone with the authority to unblock it, so escalation states the impact on the goal, not just the delay. And the people who make scope and stakeholder decisions, chiefly the product owner, need to know the goal is at risk, because those decisions are theirs and not the scrum master's. Workarounds that bypass the owning group create new risks, and repeating an approach that has already failed only uses up time.

Follow up until closed

When problems are raised but stay open for weeks and nobody knows who is handling what, the gap is ownership, not visibility. An impediment board (or a tracked list) gives every open problem an owner, a status and a target date until it is resolved. Talking about a problem more often does not make anyone accountable for it; a named owner and a date do.

Closure belongs to the team that experienced the problem. When another group reports an escalated item as done, the team checks that the effect it was suffering has actually stopped before taking the item off the board. "Done" on someone else's list is a claim, and the team's own experience is the evidence.