Root cause analysis
Root cause analysis is the discipline of asking
why something went wrong until the answer stops moving. Fix the root and the symptoms above it go with it; fix a symptom
and it comes back. Quality management, IT incident response, patient safety and aviation all require one after a
failure. The methods differ mainly in who does the reasoning.
The methods
Five whysAsk "why" of the failure, then of the
answer, five times. One person or a small team. Fast and cheap, and it finds one chain of causes — the one the person asking
already suspects. Good for a single incident with a single mechanism; weak where causes interact.
Fishbone (Ishikawa) diagramCauses sorted into
categories — people, process, equipment, materials, environment — drawn as bones off a spine. A facilitator fills it in
from a group's suggestions. Broad rather than deep: it lists candidates but says nothing about which causes drive which.
Fault tree analysisTop-down logic tree from the
failure through AND/OR gates to basic events. Rigorous for engineered systems where the components and their failure
modes are known. Built by an analyst; needs data the social world rarely has.
Pareto analysisCount the incidents by category and
fix the categories that account for most of them. Says where the pain is, not what causes it — a triage tool, not a cause
finder.
Structured Democratic DialogueThe people who
live with the problem write the candidate causes, clarify them, and then judge — one pair at a time, at an 80% bar — whether
each cause significantly influences each other. The answers are assembled into an influence map by an algorithm
(interpretive structural modelling), and the causes at the bottom of the map are the roots. Fifty years of practice,
several hundred documented dialogues. It is what this site runs.
When the group beats the analyst
One question decides. Is the cause known to anyone in the
room? If a machine failed, an engineer with the logs will find why faster than fifteen people voting. If deliveries
are late, patients wait, a school is losing teachers or a town is losing trust, the causes are spread across the people
involved — the night shift knows one, the dispatcher another, the customer a third — and no analyst holds them all. Then
the method has to collect the causes from everyone and let everyone judge the links, or it finds only what the analyst
already believed.
Two findings from the research explain why a plain group
discussion does not do this either. People asked to rank causes by importance before the links between them are
examined rank them wrongly — the erroneous priorities effect — and a group asked for its views spreads them so
widely that nothing has a majority — spreadthink. Structured dialogue is built around both: no ranking until the
links are judged, and links judged one at a time by supermajority.
What a good root cause analysis produces
- A map, not a list: which causes drive which, with the roots at the bottom.
- Each link with the agreement behind it, so a reader can see what was settled and what was not.
- The disputes on the record rather than averaged away.
- Actions judged against the roots, not against the loudest symptom.
The seven-stage template ·
A worked example with real numbers ·
How this site runs it for any number of groups