Root Cause Analysis: 5 Whys vs. Fishbone vs. Pareto

Ask a room full of practitioners how to find a root cause and you'll get three different answers, delivered with equal confidence. One reaches for a fishbone diagram because that's what the training deck showed. Another starts asking "why" five times because it's fast and needs no software. A third pulls up a spreadsheet and builds a Pareto chart because that's the data they happen to have. None of them is wrong, exactly — but each tool answers a different question, and using the wrong one first is how a working session stalls without anyone noticing why.

This guide separates the three jobs these tools actually do, gives you a plain rule for picking the right one, and walks through how a real project usually needs all three, in order.

Three tools, three jobs

The confusion comes from treating "root cause analysis" as one technique instead of a small toolkit where each piece covers a different gap.

• Pareto chart — answers "which problem deserves attention first?" It ranks categories of trouble by frequency or cost so a team stops arguing about which fire to fight and starts with the one that's actually burning the most.
• Fishbone (Ishikawa) diagram — answers "what are all the plausible causes?" It forces breadth across categories of cause — method, machine, material, people, measurement, environment — so the team doesn't fixate on one favorite theory before considering the rest.
• 5 Whys — answers "how deep does this specific cause go?" It takes one suspected cause and walks it downward, link by link, until it reaches something specific enough to fix.

Each has its own mechanics worth knowing in detail: our glossary entries on the Pareto chart (/blog/what-is-a-pareto-chart), the fishbone diagram (/blog/what-is-a-fishbone-diagram), and the 5 Whys (/blog/what-are-the-5-whys) each walk through a worked example. This piece is about the order you reach for them — because picking the wrong one first is the more common mistake than doing any one of them badly.

The question decides the tool

Instead of memorizing when each tool "applies," match it to the question actually sitting in the room.

1. 01"We have a list of defect types or complaint reasons — where should we even start?" That's a prioritization question. Build the Pareto chart before anything else; it needs only counts you likely already have.
2. 02"We know which problem matters, but nobody agrees on why it happens." That's a breadth question. Run a fishbone session, and resist letting the first plausible answer end the exercise before every category has been considered.
3. 03"We've narrowed it to one or two suspects from the fishbone — now what?" That's a depth question. Take each surviving suspect through 5 Whys until it lands on something specific enough to act on.

Notice that each tool assumes the one before it has already narrowed the field. A Pareto chart doesn't explain anything — it just points. A fishbone doesn't prove anything — it nominates suspects. Only 5 Whys, applied to a suspect that's already survived the first two filters, gets you somewhere close to an actual root cause. Skip a step and you're either drilling five whys deep into a problem nobody agreed was the priority, or building a fishbone with forty branches because the problem was never narrowed first.

How they work together on a real problem

Picture a hospital lab getting complaints about turnaround time. "Turnaround time" isn't one problem — it's a bucket holding several. The team first tallies two months of delayed results by cause: sample recollection, missing paperwork, equipment downtime, staffing gaps, courier delays. Charted as a Pareto, sample recollection and missing paperwork together account for most of the delays; the other three barely register. That single chart ends a debate that could have burned the whole meeting, and the team commits to the two tallest bars instead of the loudest complaint in the room.

Next, a fishbone session on sample recollection specifically — not turnaround time in general, which is too broad to diagram usefully. Under method: draw order and container type sometimes mismatch. Under people: newer phlebotomists recollect more often than experienced ones. Under measurement: the criteria for "insufficient sample" aren't written down anywhere, so two techs apply different standards. Under machine: one analyzer flags borderline samples more aggressively than the others. Four branches, several suspects — and checking each against the lab's own data clears two of them, leaving the undocumented rejection criteria and the aggressive analyzer standing.

Finally, 5 Whys on the undocumented criteria: Why do techs apply different standards? Because the acceptance criteria were never written down. Why weren't they written down? Because they were set informally when the lab was smaller and never revisited. Why weren't they revisited? Because no one owns the recollection policy. That's a fixable root — assign an owner, write the criteria down, calibrate the two analyzers to the same threshold — a different and more durable fix than telling technicians to "be more careful," which was the fix on offer before the Pareto chart even ran.

The mistake that costs the most time

The failure mode isn't drawing any one of these tools badly. It's reaching for the wrong one, or stopping too early, without the team noticing until the fix doesn't hold.

• Running 5 Whys straight from a vague complaint, with no Pareto or fishbone first — the "why" chases whichever cause someone in the room already suspected, and confirmation bias does the rest.
• Treating a fishbone diagram as the finished analysis. It's a list of suspects, not a verdict — every branch still has to face the data before anyone spends money on it.
• Building one Pareto chart and never rebuilding it. The tallest bar changes as soon as you fix it; a chart from six months ago is a rumor, not a ranking.
• Letting a 5 Whys chain stop at a person ("the tech didn't follow the procedure") instead of pushing one more why into the process that let the mistake happen and go uncaught.

A Pareto chart tells you where to look. A fishbone tells you what to consider. 5 Whys tells you how far down to dig. Skip one and the other two are guessing.

The fix for all four is the same discipline: name which question you're actually answering before you pick up the marker or open the spreadsheet. If it's "which problem first," that's Pareto. If it's "what's plausible," that's fishbone. If it's "how deep does this go," that's 5 Whys — and only after the first two have already narrowed the target.

Where this fits in DMAIC

All three tools live in the Analyze phase of a DMAIC project, usually in the sequence above — our guide to running a first DMAIC project end to end (/blog/how-to-run-your-first-dmaic-project-end-to-end) shows how root cause work fits alongside the data collection done in Measure. And once a cause survives all three tools, it still isn't proven — our glossary entry on root cause analysis (/blog/what-is-root-cause-analysis) covers the verification step that separates a confirmed cause from a convenient story.

Root cause analysis is foundational enough that it shows up at every level of Six Sigma training, just with more rigor added each time. Our free White Belt (/courses/white-belt) introduces the 5 Whys and basic cause thinking in its foundations, with the same timed, closed-book exam format used across every Averon level. Green Belt (/courses/green-belt) is where the three tools above get used together on real data inside a simulated improvement project — so the next time a problem shows up, you'll know which tool to reach for first, not just which one you reached for last time.