rca-classical-methods

Classical RCA Methods

Classical root cause analysis techniques are the inherited toolkit of quality and reliability engineering. They are best understood as a family with different strengths and known failure modes — not as interchangeable recipes. This skill teaches when to reach for each one, how to run it rigorously, and when to stop and escalate to a more capable method.

The six techniques at a glance

| Technique | Origin | Best for | Known weakness | |---|---|---|---| | 5 Whys | Toyota Production System (Sakichi Toyoda, Taiichi Ohno) | Simple, linear, single-cause problems on the shop floor | Forces single pathway, non-reproducible across analysts (Card 2017) | | Fishbone (Ishikawa) | Kaoru Ishikawa, 1960s | Brainstorming categorized contributing factors | Can produce unwieldy diagrams, no intrinsic prioritization | | Fault Tree Analysis (FTA) | Bell Labs, Minuteman ICBM (1960s) | Safety-critical systems with quantifiable failure probabilities | Requires known failure modes upfront, expensive to build | | FMEA | U.S. military (MIL-P-1629, 1949); automotive (AIAG) | Proactive design review, risk prioritization via RPN | RPN ordinal-math is statistically unsound (Bowles 2003) | | Cause Mapping | ThinkReliability | Multi-pathway causal narratives without imposing linearity | Tooling-dependent, visual sprawl | | Doggett's framework | A. Mark Doggett (2005) | Choosing among the above based on problem characteristics | It is a meta-method, not an analysis technique itself |

Technique 1 — The 5 Whys (with boundary conditions)

What it is

Iterative questioning that walks backward from a symptom to a causal chain. Originally formalized by Taiichi Ohno within the Toyota Production System as "the basis of Toyota's scientific approach" (Ohno, 1988). Ohno's canonical example:

Problem: A machine stopped.
Why 1: A fuse blew because of overload.
Why 2: The bearing lubrication was inadequate.
Why 3: The lubrication pump wasn't pumping enough.
Why 4: The pump shaft was worn and rattling.
Why 5: There was no strainer attached, and metal scraps got in.

Why it often fails

Alan J. Card's 2017 critique in BMJ Quality & Safety is the definitive takedown and must be understood before using this technique:

1. Gross oversimplification. Real incidents branch, converge, and interact; 5 Whys forces a single linear path.
2. Single-pathway forcing. One chain gets pursued, all others are invisible.
3. Single root-cause assumption. Complex incidents arise from the alignment of many contributing factors; insisting on one root cause is ideological, not empirical.
4. Distal-link fallacy. There is no empirical basis for the claim that the most distant link is the most effective intervention point.
5. Inter-rater reliability failure. Different analysts applying 5 Whys to the same incident reach different roots. This is a fundamental repeatability problem.

Card's recommendation for healthcare: abandon 5 Whys in favor of fishbone and multi-causal diagrams. Teruyuki Minoura, former Toyota managing director, independently called the technique "too basic" for adequate root-cause depth.

When you may still use it

• The problem is known to be linear and single-cause (shop-floor equipment, simple software bugs where one variable change reproduces the failure).
• As an entry-level probe, explicitly chained into a fishbone or cause map for downstream widening.
• Never as the sole technique for patient safety, aviation, nuclear, or complex distributed systems.

Running it rigorously

1. State the problem in observable terms. No causes, no blame.
2. Ask "why" — answer with a *factual* antecedent, not an opinion.
3. Before accepting an answer, ask: "Are there other reasons this could happen?"
   If yes, branch. You are no longer doing 5 Whys; you are building a cause map.
4. Continue until the chain reaches an actionable factor — NOT a preset depth of 5.
5. Require two independent analysts to reach the same chain. If they do not,
   the method has failed for this incident; escalate to Fishbone or STAMP.

Technique 2 — Fishbone / Ishikawa diagram

What it is

A cause-and-effect diagram that organizes contributing factors into categories attached to a spine leading to the effect (the incident). Kaoru Ishikawa developed it in the 1960s at Kawasaki Heavy Industries as part of TQM.

The category spines

Six M's (manufacturing):

• Man (people, training, fatigue, communication)
• Machine (equipment, tools, technology)
• Method (process, procedure, workflow)
• Material (raw materials, inputs, data quality)
• Measurement (metrics, instruments, calibration)
• Milieu / Mother Nature (environment, ambient conditions)

Four P's (service industries): Policies, Procedures, People, Plant.

Eight P's (marketing): Product, Price, Place, Promotion, People, Process, Physical Evidence, Performance.

For software incidents, a modern adaptation used by SRE teams: Code, Config, Data, Dependency, Infrastructure, Process, People, Environment.

Construction steps

1. Write the effect (the problem) on the right-hand side with an arrow pointing to it.
2. Draw the spine and the category ribs.
3. For each rib, brainstorm contributing factors. Keep asking "why" at each factor to drill into sub-causes.
4. Mark each factor by evidence strength: known, likely, hypothesis, ruled out.
5. Cluster factors across ribs that share a common deeper cause — these are your candidate root causes.

Evidence from Barsalou & Starzynska (2023)

Empirical survey of 43 Polish industrial organizations found Ishikawa was "by far the quality tool used most with 5 Whys, far exceeding all other quality tools combined." This validates the industry-standard pattern of 5 Whys as probe + Fishbone as map rather than treating them as alternatives.

Technique 3 — Fault Tree Analysis (FTA)

What it is

A top-down deductive technique for tracing a specified undesired event ("top event") back through combinations of lower-level events and basic causes. Invented at Bell Labs in 1962 for the Minuteman ICBM and standardized in NUREG-0492 and IEC 61025.

Notation

• Top event — the failure of interest (always a single event)
• AND gate — all inputs must occur for the output to occur
• OR gate — any input triggers the output
• Basic events — leaves that cannot be decomposed further (often with known failure-rate data)
• Undeveloped events — known but not decomposed due to scope
• External events — assumed inputs (e.g., "power supply failure")

Quantitative FTA

1. Compute the minimal cut sets — smallest combinations of basic events whose joint occurrence causes the top event. Algorithms: MOCUS, FTREX, BDD.
2. Assign failure probabilities to each basic event (from reliability data).
3. Compute the top-event probability using cut-set summation or Binary Decision Diagrams.
4. Run importance analysis — Fussell-Vesely, Birnbaum, Risk Reduction Worth — to rank contributions.

When to use

• Safety-critical, quantitative, regulator-facing (nuclear, aerospace, medical devices).
• Failure modes are reasonably well enumerated.
• You need a defensible probabilistic top-event estimate.

When not to use

• Unknown-unknowns problem: a failure mode you haven't enumerated can't be in the tree.
• Software systems with combinatorial state spaces.
• Incidents dominated by organizational and human factors (use STAMP or HFACS instead).

Technique 4 — Failure Modes and Effects Analysis (FMEA)

What it is

A proactive, forward-looking technique: list every way a component or process step can fail, and rate each failure mode on three axes. Developed by the U.S. military in 1949 (MIL-P-1629), adopted by NASA for Apollo, and institutionalized in automotive via the AIAG FMEA Handbook.

The RPN (Risk Priority Number)

RPN = Severity × Occurrence × De