Root Cause Analysis Methods: When 5 Whys Works, and When It Doesn’t
Root cause analysis (RCA) is a structured way to find the underlying cause of a problem so it stops recurring, and the 5 Whys, the fishbone diagram and FMEA are the methods most teams start with. Your next step is simple: assemble a small cross-functional team, including someone who can authorise change, and pick a method scaled to the size of the problem, not the other way round.
TL;DR:
- Reserve 5 Whys for simple repeat issues, use FMEA or fault tree analysis for high risk cases, and apply Pareto charts when frequency data exists.
- For services, pair an 8P fishbone with a current state process map; software outages benefit from timelines and event and causal factor analysis.
- Treat five Whys as a prompt, not a limit: systemic issues may need more than five rounds, and blame can suppress useful evidence.
- Close analysis only after corrective actions have owners and deadlines, then verify with data that the problem stopped or shrank and controls can catch recurrence.
Table of Contents
- What are the core phases of root cause analysis?
- Which root cause analysis techniques exist, and when does each fit?
- How do you choose the right method for your problem?
- How do you run a root cause analysis step by step?
- What pitfalls and biases weaken a root cause analysis?
- What do root cause analysis examples look like in practice?
- Which tools and resources support root cause analysis?
- Why we treat RCA as the start of capability work
- How can we help you embed root cause analysis capability?
- FAQ
- Sources
What are the core phases of root cause analysis?
Whatever method you choose, the workflow underneath it stays the same. ASQ describes a five-phase RCA process that applies across engineering, software and business administration, and its focus is systemic prevention, not treating symptoms. Applying it consistently is what separates a genuine analysis from a meeting that ends with a guess.
- Define the problem. State the impact and the outcome you want in a sentence or two. A vague problem produces vague causes.
- Gather and analyse evidence. Collect logs, timelines, process maps and incident records before anyone proposes an explanation.
- Identify all potential causes. Use a structured method to list every plausible contributor, not just the first one someone suggests.
- Evaluate and prioritise. Rank likely root causes using data, applying Pareto thinking to find the few causes behind most of the effect.
- Develop and implement corrective actions. Choose actions backed by evidence, then verify that they worked and put controls in place so the fix holds.
Phases rarely run in a perfectly straight line. Experienced practitioners often collect data and brainstorm at the same time to keep momentum, and they return to earlier phases when new evidence contradicts a working theory. Treat the phases as a checklist of what must be true by the end, not a rigid timetable.
Which root cause analysis techniques exist, and when does each fit?
No single technique suits every problem. The right choice depends on what you are investigating and how much rigour the situation justifies. These are the main options and where each earns its place.
- 5 Whys. A fast, linear chain of “why?” questions, best for simple or repeat issues where one causal thread is likely. ASQ lists it among the popular RCA tools for linear causal chains.
- Fishbone (Ishikawa) diagram. A visual branching diagram for brainstorming contributors to an effect. Branches are often sorted into categories such as the 6M set (typically manpower, machine, method, material, measurement, mother nature) or the 8P set. The 8P variation (Procedure, Policy, Place, Product, People, Process, Price, Promotion) is particularly adapted to service-based industries.
- FMEA (failure mode and effects analysis). A rigorous method that works through every potential failure point in a process. It suits high-risk or regulated processes where you want to find weaknesses before they cause harm.
- Pareto chart. A frequency-based chart that quantifies the “vital few” contributors. StatPearls notes that Pareto charts reveal those vital few, which makes them a natural partner to any method that produces a long list of candidate causes.
- Fault tree analysis and event and causal factor analysis. Structured techniques for single, high-consequence incidents. They map how a chain of events and conditions combined to produce the outcome.
- DMAIC and change analysis. DMAIC and change analysis are options for structured process improvement and investigating what shifted between a working state and a failing one.
Sector context changes how you use each one:
- In services, the fishbone with 8P categories and a current-state process map usually do the most work.
- In software, teams can use timelines and event and causal factor analysis to investigate outages and failed releases.
- In manufacturing, teams can consider FMEA, Pareto charts and DMAIC when investigating process problems.
Process maps deserve a note of their own. StatPearls describes them as exposing delays and decision points that show where to act. For service work, our piece on value stream mapping for services explains why standard maps often miss hidden waits.
How do you choose the right method for your problem?
Match the method to the stakes and the data you have. ASQ advises scaling RCA to problem complexity: simple issues may need only brainstorming or a fishbone, while high-impact single events usually call for structured techniques such as fault tree analysis. Organisations are advised to choose the most cost-effective and relevant tool, not to apply a complex method to a simple problem.
Work through these questions in order:
- How large is the impact? Safety, regulatory or major financial consequences justify heavier methods. A minor annoyance does not.
- How likely is recurrence? A problem that keeps returning deserves a more thorough look than a genuine one-off.
- What data do you have? Rich frequency data supports a Pareto chart. Sparse data points towards structured questioning.
- How quickly do you need an answer? A live issue may call for a quicker method, while FMEA requires a more structured investigation.
- What resources can you commit? Count people, time and access to the relevant systems.
- How many stakeholders does the problem touch? Wide reach favours a visual method that a mixed group can contribute to.
A workable rule of thumb follows from this:
- Quick repeat issues: 5 Whys or a fishbone.
- Complex problems or regulatory risk: FMEA or fault tree analysis.
- Process improvement with measurable targets: DMAIC.
Pro Tip: Start with the simplest method that could plausibly work, and escalate only if the first pass leaves causes unexplained.
The most common mistake is over-engineering. A team that builds a full FMEA for a recurring scheduling slip burns weeks and loses the appetite for follow-through. The reverse also happens, so let the evidence decide when to move up a level.
How do you run a root cause analysis step by step?
This sequence works as a workshop template for most teams, from kickoff to verification.
- Assemble a multidisciplinary team. Include someone close to the work, someone from an adjacent function, and someone with authority to approve changes. Without that last person, good recommendations stall.
- Write a concise problem statement. Name what happened, where, when and how much it cost, and agree measurable criteria for success before anything else.
- Collect data and build a timeline or current-state process map. Gather records first and opinions second. A shared timeline settles disagreements about sequence quickly.
- Apply the chosen method. Run the 5 Whys on one causal thread, build a fishbone with the whole group, or construct an FMEA row by row, as the problem demands.
- Prioritise causes and commit to actions. Rank by frequency and impact, set corrective actions, assign each an owner and a deadline, and agree how and when you will check that the fix worked.
Keep the workshop focused. A single well-prepared session of a few hours, backed by evidence gathered in advance, usually beats a series of loosely structured meetings. Record every assumption you test and every piece of evidence behind a conclusion, because the verification step depends on knowing what you expected to change.
Close the loop. An RCA that ends with a report is incomplete. It finishes when someone confirms, with data, that the problem has stopped or shrunk and that a control exists to catch it if it returns.
What pitfalls and biases weaken a root cause analysis?
The most damaging trap is blame. IEEE guidance stresses a non-blame mindset: the aim is to understand systemic process gaps, not to identify which individual made an error. Asking “who?” instead of “why?” silences the people who hold the best evidence and prevents lasting improvement.
The second trap is stopping too early. AWS guidance warns against settling on the first plausible cause, and notes that iterative techniques like the 5 Whys may need more than five rounds for systemic issues. Five is a prompt, not a limit.
Individual bias is the third. A single investigator tends to find the cause they already suspected. Practical countermeasures include:
- Using a mixed team so that no single viewpoint dominates.
- Appointing a facilitator who keeps discussion on evidence.
- Keeping an evidence log that ties every proposed cause to a record.
- Collecting data in parallel, so findings are not shaped by the first theory.
- Reviewing evidence anonymously where hierarchy might suppress honest input.
What do root cause analysis examples look like in practice?
Two short sketches show how the methods play out. The details are illustrative, not drawn from a real case.
- Recurring delivery delays. The team draws a fishbone and finds contributors under process, people and materials. A 5 Whys on the most frequent late order might run: the order shipped late because picking started late, because stock was not confirmed, because the inventory count was updated weekly, because nobody owned the update. The root cause is a missing owner and cadence, and the action is to assign one and move to daily updates.
- A single major outage. The team builds a timeline of events, marks each change and alert, and maps causal factors. They find a configuration change, an alert threshold set too high, and a handover gap, none of which would have caused the outage alone.
Use this one-page checklist to capture any RCA:
- Problem: one-sentence statement and measurable impact.
- Evidence: logs, timeline, maps and their sources.
- Method: the chosen technique and why.
- Owners: named people for each action.
- Actions: the corrective steps agreed.
- Verification date: when you will check that the fix held.
Which tools and resources support root cause analysis?
You rarely need specialist software to start. Match the tool category to the method.
- Spreadsheets and charting tools handle Pareto analysis and action tracking.
- Diagramming and collaborative whiteboard tools suit fishbone diagrams, process maps and fault trees.
- Specialist FMEA and reliability templates become worthwhile when risk is high.
- Evidence capture tools help when the raw records are scattered. A digital inspection record such as the timestamped damage evidence in TransportMate’s vehicle inspection software shows how transport operators keep reliable evidence for later review.
- Organisational memory matters for repeat problems. This analysis of how AI agent memory fails in production is a useful read on why decisions and context get lost.
For authoritative guidance, consult ASQ’s RCA resources, the explanations in the IEEE Technology Navigator, and StatPearls on quality improvement tools for healthcare settings.
Why we treat RCA as the start of capability work
Most organisations treat an RCA as the end of an incident. I think that is a mistake. The analysis can be an opportunity to learn what your organisation cannot yet do, and the findings are more useful when they feed a deliberate programme of change. A fishbone that ends in a filing cabinet has produced a document and nothing else. Done well, the same session sets priorities, names owners and exposes the missing standard that a targeted intervention can then fix and embed. In my experience, workshops that bring several functions into one room also speed decisions and make ownership clearer, because people hear the constraint from the person who lives with it. The goal is a team that needs the workshop less each time, and our approach to capability mapping is built on that idea.
— Chris
How can we help you embed root cause analysis capability?
Finding a root cause is only half the job. We help teams convert RCA findings into repeatable processes and lasting capability, moving through our Build to Embed stages so the fix becomes the way you work. The intended outcomes are fewer repeat incidents, accountable owners and verification mechanisms to check whether each change held. You can see how our staged approach works, compare programme tiers on our pricing page, or book a discovery call to talk through a problem you are facing now.
FAQ
How do you identify the root cause of a problem?
Start with a clear problem statement, gather evidence, then apply a structured method such as the 5 Whys or a fishbone diagram to list possible causes. Prioritise those causes with data, and confirm each against the evidence before acting. ASQ outlines this sequence as five phases from defining the problem to implementing corrective actions.
How long does a root cause analysis take?
It depends on the method and the problem. A simple repeat issue can be analysed in a single workshop, while a high-impact incident or an FMEA needs more preparation and evidence gathering. Scale the effort to the stakes, and expect verification to extend beyond the workshop itself.
What is root cause analysis in Lean Six Sigma?
In Lean Six Sigma, RCA sits mainly in the analyse stage of DMAIC, where teams use tools such as fishbone diagrams, Pareto charts and the 5 Whys to find causes of process variation. The result feeds the improve and control stages, which implement and sustain the fix.
Which technique is most effective for root cause analysis?
No technique wins in every case. ASQ advises choosing the most cost-effective tool for the situation, so a 5 Whys or fishbone often suits simple issues, while FMEA or fault tree analysis suits high-risk ones. Pair any of them with a Pareto chart when you have frequency data.
Sources
- What is Root Cause Analysis (RCA)? | ASQ
- What is Root Cause Analysis? - RCA Explained - AWS
- Root cause analysis | IEEE Technology Navigator