Root cause analysis: which tool, in what order

Which tool to start with

Pick the first tool from what the problem looks like and the data you already have. Most problems then pass through several of these tools in the order in the next section; this table only tells you where to enter.

This table picks a tool inside one investigation. To choose between a quick fix, a kaizen event, an A3 and a DMAIC project, use the process improvement method selector.

One problem worked through every tool

This example is illustrative: the plant, the dates and the numbers are made up, but they add up. A plant welds steel hydraulic oil tanks in two robot cells, cell 1 and cell 2, each making about 600 tanks a week, and every tank gets a leak test at the end of the line. In the eight weeks before 15 July, 77 of 9,600 tanks failed the test (0.8%). In the four weeks from 15 July, 221 of 4,800 failed (4.6%).

1. Contain, then focus with a Pareto chart

Every tank is already leak tested, so containment starts with whether the test can be trusted. The team runs a reference leak through the tester at the start of every shift, and it is caught every time, so leaking tanks are not getting out. Rejects are repaired and retested. With the customer protected, the team sorts the 221 rejects by where the leak was found.

One bar holds 85.1% of the rejects. The other locations add up to 33 rejects in 4,800 tanks (0.69%), the same rate as before (63 in 9,600, 0.66%), so they are the normal background and not part of this problem. From here on the investigation is about the drain-boss weld alone: 188 leaks in four weeks (3.9% of tanks) against 14 in the eight weeks before (0.15%).

2. Describe it: 5W1H, then is / is not

5W1H turns the reject reports into one statement with a number and no cause in it: "Since 15 July, 3.9% of hydraulic tanks leak at the drain-boss weld at the final leak test (188 of 4,800 in four weeks), against 0.15% in the eight weeks before." The why stays empty on purpose. The is / is not table then splits the same data by cell, shift and week, and writes down where the problem could be but is not.

3. Find what changed: records, then a walk of the cell

The team lists every change in the month before 15 July from purchasing, receiving, the maintenance log and the change log, then walks cell 2 with the people who run it, using the 5G sheet. The walk finds a change that no record shows.

Change analysis keeps a change only if it is on the is side alone and came before the start. Three are left: the torch neck, the failed roof fan and the pedestal fan. The wire and the boss lot went into both cells, and the new leak test operator started six days after the leaks did.

4. Widen with a fishbone, then test every candidate against the facts

So that the list is not limited to recent changes, the team runs a 6M fishbone. It gives 16 causes. Two came up in the first five minutes and took most of the votes: the supervisor's view that new operators on cell 2 were not wiping the bosses before loading, and the quality engineer's view that the new wire was to blame. The votes only set the order of the checks; the is / is not table does the checking.

Only the fan explains every row without an extra assumption. The three marked Check each fail at least one fact but are cheap to rule out, so the team checks them before acting: no leak at the new torch neck, gas flow at the nozzle matches the welding procedure in both cells, and heat alone does not explain why only one weld leaks.

5. Dig: a fault tree for the mechanism, 5 whys for the system

Ten rejected tanks are cut through the drain-boss weld, and all ten show gas porosity: pinholes running through the weld. Porosity has several known mechanisms, so the team draws a small fault tree with porosity as the top event and closes every branch with evidence before trusting the fan.

Every gate in this tree is an OR gate: any one branch can cause porosity on its own, so every branch has to be closed. In a safety event you will usually meet AND gates too, such as a hazard present and a guard bypassed, and the fix can then target whichever input is easiest to remove for good. The fault tree template has the symbols and the arithmetic.

With the physical cause found, the 5 whys ask why the system let it happen. Each answer rests on a fact the team checked.

A team that stops at the fourth why blames the shift for the fan. The shift solved a real heat problem with what it had, and nothing in the system would have caught the side effect. The two root causes are system conditions the plant can change: changes to the surroundings of a weld cell go unreviewed, and a failed extraction fan can wait indefinitely.

6. Verify before fixing

7. Fix, hold and report

The pedestal fan went and a draft screen was fitted at the cell 2 door on day 1; the roof extraction fan was repaired on day 3. Changes to the surroundings of the weld cells, such as fans, open doors and heaters, now go on the change log the cells already use (see the 4M change sheet), with the welding engineer as reviewer, and extraction and cooling repairs get a due date. In the first week after the fan went, cell 2 had 2 drain-boss leaks in 600 tanks (0.33%). Over the next four weeks both cells had 6 in 4,800 (0.13%), and all leak test rejects were 39 in 4,800 (0.81%), back at the old 0.8%.

The leaks were caught inside the plant, so the team wrote the work up on an A3: the Pareto and the problem statement as the current condition, the is / is not, timeline, fault tree and 5 whys as the cause analysis, and the three tests and the hold as the check (three worked A3s show the format). Had a leaking tank reached a customer, the same work would go into an 8D report, with containment in D3 and a second cause in D4: why the leak test let it out.

Where teams usually go wrong

• Stopping at a person. "Operators not wiping the boss" sounded like an answer, but the rate followed the cell, not the people. When the answer is a person, ask what made the error possible or likely, as the 5 Whys template does.
• Taking the first plausible cause. The new wire was a real change close to the start date, and it took the most votes. One row of the is / is not table, cell 1 running the same wire at 0.29%, struck it out before anyone changed supplier.
• A thin is not column. Without the cell 1 and night shift facts, the wire, the boss lot and the operators all stay possible. Fill in the is not side from data or a visit, not from memory.
• A timeline built from records alone. The fan was in no log. Walk the area with the people who run it before you call the change list complete.
• Treating fishbone votes as proof. Votes set the order of the checks. Several of the fishbone examples show the most-voted cause ruled out.
• One chain, one cause. A single line of whys tends to find a single cause, a limit Alan Card describes in his 2017 critique of the 5 whys. Go wide first with a fishbone or fault tree, then deep, and expect more than one root cause: the example has two.
• Closing the problem on the day of the fix. Without a number and a hold period, a fix that only coincided with a good week looks the same as one that worked.

Sources

• ASQ, "What is root cause analysis?" (quality resources): the definition of a root cause and the main approaches, including events and causal factors, change analysis, barrier analysis and Kepner-Tregoe.
• US Department of Energy, DOE-NE-STD-1004-92, Root Cause Analysis Guidance Document (February 1992): the five phases from data collection to follow-up, change analysis (Appendix E), the definition of a root cause and effort matched to significance.
• W. E. Vesely and others, Fault Tree Handbook, NUREG-0492, US Nuclear Regulatory Commission (1981): fault tree analysis as a deductive method, the top event, OR and AND gates, and minimal cut sets.
• Kepner-Tregoe problem analysis (is and is not, distinctions, changes, testing causes against every fact), as described by Kepner-Tregoe (B. Prigge, "8D: IS or IS NOT", 2022) and in AHRQ's Kepner-Tregoe matrix tool.
• Taiichi Ohno, Toyota Production System (Productivity Press, 1988), the origin of the five whys, as summarised in the Lean Enterprise Institute's Lean Lexicon.
• A. J. Card, "The problem with '5 whys'", BMJ Quality and Safety 26(8), 2017, pages 671 to 677.
• Miller Electric, "Tips for troubleshooting common MIG weld defects" (2024): drafts, low gas flow, leaks and spatter as causes of porosity, used for the example's mechanism.