Root cause analysis explained: how 5 Whys and fishbone diagrams differ, when to use each, and the "Five Blames" trap that turns a real investigation into a blame exercise.
The 5 Whys is one of the most misused tools in manufacturing. Not because
it’s a bad technique — it’s simple and genuinely useful — but because
teams stop at whatever answer sounds like an explanation, and the answer
that sounds most like an explanation is almost always “operator error.”
That’s not root cause analysis. That’s stopping early.
This guide covers what root cause analysis actually is, how the 5 Whys
and the fishbone diagram differ, when to reach for which one, and the
specific trap that turns a real investigation into a blame exercise.
Root cause analysis (RCA) is the umbrella term for structured methods
that trace a problem back to its actual origin, rather than the symptom
that got noticed first. The 5 Whys and the fishbone (Ishikawa) diagram are
two specific tools within RCA — not competing definitions of it.
A defect, a downtime event, a customer complaint — RCA is the discipline of
asking “why did this actually happen” until you reach something you can fix
and verify, not just something you can blame.
| Tool | Best for | Common failure mode |
|---|---|---|
| 5 Whys | A single, fairly linear problem with one clear symptom and a small team | Stops at “operator error” instead of the system that let the error happen |
| Fishbone (Ishikawa) | A complex problem with multiple plausible cause categories and a cross-functional team | Generates a long list of possible causes but never narrows down to the real one |
| Pareto chart | Deciding which of several known problems to investigate first, using real frequency data | Used without reliable data behind it, turning a data tool into a guess dressed up as one |
They’re not mutually exclusive. A common real-world sequence: run a
Pareto chart on your downtime log to find the biggest recurring problem,
build a fishbone diagram with the team to map out plausible cause
categories (Machine, Method, Material, Man, Measurement, Environment), then
use 5 Whys to drill into the most likely branch until you hit something
fixable.
Here’s the honest part most vendor content skips: the fifth “why” isn’t
special. There’s nothing about asking “why” exactly five times that
guarantees you’ve reached a true root cause — it’s a rule of thumb, not a
law. In practice, teams under time pressure tend to stop as soon as they
hit an answer that resolves the discomfort of not knowing, and “the
operator missed a step” resolves that discomfort a lot faster than “our
training process doesn’t verify the skill it’s supposed to teach.” Critics
call this degeneration the “Five Blames” — a 5 Why session that produces a
name instead of a cause.
The fix isn’t a stricter rule about counting to five. It’s a standing
question at each step: “if we fix only this, will the problem definitely
not come back?” If the honest answer is no, there’s another why underneath
it.
5 Whys assumes a mostly linear chain — each cause leads to one next
cause, in a single line back to the root. Real manufacturing problems
aren’t always that shape. If a defect can plausibly come from any of
several unrelated sources at once — a material lot change, a tooling
wear-out, and an operator swap that all happened the same week — forcing
a single why-chain will produce a plausible-sounding story that’s wrong,
because it picked one branch and ignored the others.
That’s the signal to switch to a fishbone diagram instead: get the
cross-functional team in a room, map every plausible cause into its
category without judging them yet, and only then start investigating which
branches actually hold up against the data. Trying to force a multi-causal
problem through a single 5 Whys chain is one of the most common ways a
root cause investigation quietly turns into a guess.
A pump keeps overheating and shutting down a line. Why? The bearing is
running dry. Why? The lubrication schedule was skipped. Why? The technician
responsible was out and no one covered the task. Why? There’s no backup
assignment for lubrication routes when someone’s absent. Why? The PM
schedule assumes one dedicated person per route with no documented
coverage plan.
Stopping at “the technician was out” fixes nothing — someone will be out
again. The real fix is a coverage plan for lubrication routes, which is a
system problem, not a person problem. That’s the difference between a real
root cause and a name.
Write the finding down where it’s useful, not just where it’s filed.
A root cause that lives only in one investigator’s head, or in a closed
ticket nobody revisits, tends to resurface in six months as a “new”
problem. This is exactly why RCA tools work best inside a structured
format like an A3 — the analysis and the countermeasure live on the same
page, and someone owns following up on whether it actually stuck.
Root cause analysis isn’t a standalone course in SCMEP’s current
catalog — the tools covered here (5 Whys, fishbone diagrams) are the
building blocks underneath our
A3 problem solving workshops, where the
“why” analysis happens inside a structured, one-page investigation rather
than a standalone exercise. As a
NIST Manufacturing Extension Partnership affiliate
serving South Carolina manufacturers since 1989, our focus is building
the habit of asking “why” past the comfortable answer, not just teaching
the diagram.
If you want to build this discipline in your team, you can
browse the Lean and continuous
improvement training catalog or email the training team.
For the full structured method these tools feed into, see our related
article on A3 problem solving, including
the 7-step process and how it compares to 8D and DMAIC.
The 5 Whys and Fishbone methods covered here are the same root cause tools that populate a formal customer-facing corrective action report. See our related guide on 8D problem solving for the eight-discipline format used in automotive and aerospace supply chains.
Root cause analysis (RCA) is the umbrella discipline of tracing a problem back to its true origin. 5 Whys is one specific technique within RCA — a simple, repeated-questioning method, not a synonym for the whole discipline.
5 Whys works well for a fairly linear problem with one clear symptom and a small team. A fishbone diagram works better for a complex problem with several plausible cause categories and a cross-functional team — it’s common to use both together, fishbone first to map categories, then 5 Whys to drill into the most likely one.
There’s no rule that guarantees five questions reaches a true root cause — it’s a rule of thumb. Teams under time pressure tend to stop at the first answer that feels like an explanation, which is often “operator error,” a person instead of a system. Critics call this pattern the “Five Blames.”
Ask, at each step: if we fix only this, will the problem definitely not recur? If the honest answer is no, there’s another “why” underneath it. A true root cause is a system condition you can fix and verify, not a name.
The traditional manufacturing set is Machine, Method, Material, Man (people), Measurement, and Environment — sometimes called the 6M model. Teams map possible causes into each category before narrowing down to the most likely one.
