Quality & InspectionFree referencePDF, Excel, Word export

Root Cause Analysis Method Selector

Choosing the wrong root cause method wastes days. This table helps you match the method to the problem, so a sudden defect gets change analysis and a safety event gets a fault tree.

Download:

Method	Best used when	Effort	Evidence needed	Main limitation
5 Whys	Single-thread problems with a likely linear cause chain	Low	Process knowledge and checks at each why	Can follow one path and miss parallel causes
Fishbone (Ishikawa) diagram	Brainstorming many possible causes across man, machine, method, material, measurement, environment	Low to medium	Team input, then data to test each candidate	Lists possible causes, does not prove which one is real
Is / Is Not analysis	Narrowing a problem by what, where, when and how big	Medium	Defect location, lot, time, shift and quantity data	Needs good data on the good units too
Pareto analysis	Choosing which defect type or supplier to attack first	Low	Counted defects by category over a period	Shows where, not why
Fault tree analysis	Safety-critical or complex failures with several contributing events	High	Design and failure data, event probabilities where available	Needs skilled facilitation and a clear top event
FMEA review	Checking whether a failure mode was anticipated and why detection failed	Medium	Current PFMEA or DFMEA, control plan	Only as good as the existing FMEA
Change analysis	Problems that appeared suddenly after something changed	Medium	Change records, ECNs, tooling and supplier change history	Fails if changes were not recorded
Design of experiments	Confirming which of several process factors drives the defect	High	Planned trial runs and measurement capability	Needs production time and capable measurement
Process flow and walk-through (gemba)	Finding where reality differs from the written process	Low to medium	Direct observation, interviews, standard work	Observation can change behaviour
Barrier analysis	Explaining why a defect escaped to the customer	Medium	Inspection points, control plan, escape history	Does not explain how the defect was created
Comparative analysis (good versus bad)	Intermittent defects where good and bad units can be compared	Medium	Measurements of paired good and bad units	Needs enough bad units to compare
A3 problem solving	Structured one-page reporting of problem, cause, countermeasure and follow-up	Medium	Data supporting each section	A reporting format, not a cause-finding technique on its own

No single method is right for every problem. Many investigations combine a Pareto to choose, an Is/Is Not to narrow, a fishbone to list candidates and a 5 Whys or test to prove the cause.

Root cause investigation plan template

Optional: a one-page plan that lists method, evidence and owner for each candidate cause.

Optional. The tool and every export work without this. No spam.

How to use the selector

Start with the situation, not the tool. Is the problem new after a change, intermittent, one of many defect types, or a failure with possible serious consequences? Search the Best used when column for words that describe your case, compare effort and evidence needed with the time you have, and note the limitation. Export the shortlist to Excel and paste it into your investigation plan so the team agrees on method before the first meeting.

Combining methods

Good investigations use methods in sequence. A Pareto picks the biggest defect. An Is/Is Not analysis shows where and when it occurs. A fishbone collects candidate causes, and testing or a 5 Whys confirms the true cause. A barrier analysis then explains why detection missed it. Treat brainstorming tools as hypothesis generators only, and insist on data before a cause is accepted into a CAPA record.

Pareto to choose the problem
Is/Is Not to narrow it
Fishbone to list candidates
Test or 5 Whys to confirm
Barrier analysis for escape point

Common mistakes

The most common mistake is stopping at human error. Operator error is a symptom of a process that allowed the mistake, so ask what made the error possible and why the system did not catch it. Another is using a fishbone and picking the cause the loudest person prefers. Require each candidate cause to be checked with a measurement, a trial or records before it is accepted, and record that evidence in the report.

Frequently Asked Questions

Is 5 Whys enough for a customer complaint?

Sometimes, for simple problems with a clear chain. For recurring or complex complaints, customers usually expect more evidence, such as a verified cause, an escape point and a link to the FMEA. Combine 5 Whys with data checks.

What is the difference between a fishbone and a fault tree?

A fishbone groups possible causes by category for brainstorming. A fault tree is a logic diagram that shows how combinations of events lead to a defined top failure, and can be quantified. Fault trees take more skill and data.

When should I use design of experiments?

Use it when several process factors might interact and you need to know which ones matter, and when you can afford planned trial runs with a capable measurement system. It is rarely the first step of an investigation.

How do I know a root cause is real?

A real cause can be demonstrated: when you introduce it the defect appears, and when you remove it the defect goes away. If you cannot test directly, show the data pattern that matches the cause and rules out the alternatives.

If your root cause data lives across ERP lots, inspection results and maintenance logs, we can help build a read-only view that supports the investigation.

Talk to an Expert Explore More Free Tools

Related Tools

Quality & Inspection

More Quality & Inspection tools

See all

Back to All Tools