Root Cause Analysis Beyond 5-Why: Fishbone Diagrams and Fault Tree Analysis for Engineers

In twenty years as a contract mechanical designer moving between the design floors of large Japanese manufacturers, I have sat through more root cause analysis meetings than I can count, and the vast majority of them defaulted immediately to the 5-Why method because it is simple, fast, and requires no special training to run. The trouble is that 5-Why works best on failures with a single dominant causal chain, and a surprising number of real mechanical failures I have investigated do not have one. They have two or three contributing factors that interact, and forcing them into a single linear chain of five whys either produces a shallow answer or quietly buries a real contributing cause that nobody asked about because the linear questioning never went down that branch. This article is about the two tools I reach for once 5-Why stops being enough: fishbone diagrams for exploring the full space of contributing causes, and fault tree analysis for cases where the failure is safety-critical or has genuinely multiple independent paths to the same bad outcome.

Where 5-Why Quietly Breaks Down on Real Failures

I want to start with a specific case because it explains why I moved away from 5-Why as a default. A hydraulic press was intermittently failing to reach full clamping pressure, and the initial 5-Why investigation traced it to a worn seal, replaced the seal, and closed the issue. The failure recurred within two months. A second 5-Why session traced it to a slightly undersized pump for the current duty cycle, upgraded the pump, and closed the issue again. It recurred a third time. Only when I insisted on a broader fishbone-style investigation did the team surface that there were actually three separate contributing factors happening simultaneously: the seal wear, a marginal pump, and a hydraulic fluid that was slightly out of viscosity spec due to a supplier change nobody had flagged. Each 5-Why session had correctly identified one real cause and declared victory, but the failure was multi-causal, and the linear method structurally cannot hold more than one causal chain in view at a time unless someone deliberately runs it multiple times, which rarely happens once a plausible cause is found and the pressure to close the ticket kicks in.

Building a Fishbone Diagram That Actually Surfaces Hidden Causes

The value of a fishbone diagram, also called an Ishikawa diagram, is that it forces you to check multiple categories of cause before settling on one, rather than following whichever thread the first question happens to open up. On a stamping press downtime investigation, I ran the session using the classic categories of Machine, Method, Material, Man, Measurement, and Environment, and made a point of requiring at least one candidate cause in every branch before the group was allowed to start prioritizing. The Environment branch felt like a formality until someone mentioned, almost as an aside, that the press had started failing more often after a nearby wall was removed during a facility renovation, which changed airflow and increased ambient dust loading on the machine. That single detail, which a straight 5-Why chain would almost certainly never have surfaced because nobody would have asked “why” toward a wall renovation from a jammed die failure, turned out to be a major contributor once dust ingress into a proximity sensor was confirmed as the actual failure trigger. The discipline of forcing every category to produce at least one candidate, even categories that feel irrelevant at first glance, is what makes the fishbone method catch causes that a narrower method misses.

When to Escalate From Fishbone to Fault Tree Analysis

Fishbone diagrams are good at generating a wide list of possible contributing causes, but they do not model how those causes combine logically to produce the failure, and for safety-critical systems that logical structure matters. I escalate to fault tree analysis specifically when a failure could occur through genuinely independent paths, or when I need to communicate to a safety review board exactly how a top-level hazardous event could occur. On a robotic cell safety review, we needed to demonstrate the conditions under which an operator could be exposed to a moving axis with the safety door open. A fishbone diagram would have listed contributing factors like sensor failure, interlock bypass, and software fault as a flat list, but the fault tree let us show precisely that the hazardous event required an AND condition between a specific sensor failure and a specific software state, versus an OR condition where either a door interlock defeat or a maintenance override alone was sufficient. That AND/OR logical structure is the entire value proposition of fault tree analysis over fishbone, and it directly informed which single-point failures needed redundancy and which combinations were already adequately protected by the existing design.

Quantifying Fault Trees With Failure Rate Data

A fault tree becomes far more useful once you attach actual failure rate or probability data to each base event rather than leaving it as a purely qualitative logic diagram. On the same robotic cell project, once we had the tree structure agreed upon, I pulled failure rate data for the interlock switch from the manufacturer’s reliability figures and combined it with our own maintenance log data on override frequency to get an approximate probability for the top-level hazardous event. The number that came out was higher than anyone on the safety committee expected, mainly because the maintenance log revealed the override was being used far more often in practice than the procedure allowed, a detail that a purely qualitative fault tree would never have exposed. That quantified number was what actually got budget approved for a redundant interlock rather than a procedural fix alone, because a probability estimate is a much stronger argument in a budget meeting than a qualitative diagram, even a well-constructed one.

Combining the Tools Instead of Choosing Just One

Over time I stopped treating these as competing methods and started using them in sequence on any failure serious enough to warrant more than a quick fix. My usual sequence now is a fishbone session first to generate the broad list of candidate causes across all categories without prematurely narrowing the field, followed by a fault tree for the subset of causes that appear to interact logically or that feed into a safety-relevant top event, with a quick 5-Why used only within an individual fishbone branch once that branch has been identified as worth digging into further. On a conveyor jamming investigation, the fishbone stage surfaced six candidate causes across Machine, Method, and Material categories. Rather than fault-tree all six, we used a quick 5-Why drill-down on just the two that the team’s engineering judgment flagged as most plausible, which turned out to be the right call since one of those two was confirmed as the actual dominant cause. Using each tool for what it is actually good at, rather than picking one method as a house standard for every failure regardless of complexity, has made these investigations both faster and more reliable in my experience.

Common Mistakes I See Engineers Make With Both Methods

The most common mistake I see with fishbone diagrams is treating the session as complete once causes are generated, without ever going back to verify any of them against actual data. On a bearing failure investigation, the fishbone session generated a strong consensus that lubrication interval was the root cause, and the group was ready to close the investigation and change the maintenance schedule. I pushed to actually pull the lubrication records before finalizing, and it turned out the lubrication interval had been followed correctly every time; the real cause, confirmed only after cutting open the bearing, was a manufacturing defect in the raceway that had nothing to do with lubrication at all. The team’s consensus opinion from the fishbone session was simply wrong, and only checking against physical evidence caught it. With fault trees, the most common mistake is building an impressively detailed tree and then never updating the base event probabilities as new field data comes in, leaving a stale quantitative conclusion that nobody revisits after the initial safety review closes out.

Making Root Cause Analysis a Living Document, Not a One-Time Report

The last habit that has made the biggest difference for me is treating these analyses as living documents rather than one-time reports filed away after an investigation closes. On a recurring motor failure issue that took nearly a year and three separate investigation rounds to fully resolve, keeping the same fishbone diagram alive and updating it after each new failure occurrence, rather than starting a fresh diagram each time, let the team see the pattern that no single investigation round would have revealed on its own: each occurrence pointed at a different immediate cause, but all of them traced back eventually to a marginal power supply that was borderline under-spec for the actual load. A fresh 5-Why or even a fresh fishbone each time would have kept generating plausible immediate causes without ever connecting them into that underlying pattern. Keeping the analysis document alive across recurrences, rather than treating each failure as a fully independent investigation, is what finally surfaced the real systemic cause.