Root Cause Analysis Methods: How to Choose and Use Them

Root cause analysis (RCA) is a structured way of finding why a problem happened, so that the fix removes the cause and not just the symptom. The main methods are 5 Whys, the fishbone (Ishikawa) diagram, fault tree analysis, failure mode and effects analysis (FMEA), causal timelines and incident models such as Tripod Beta. The right one depends on how complex the problem is, how much harm is at stake and how much evidence you have. This guide explains what each method is good for, where it breaks down, and how to turn a finding into corrective action that holds.

TL;DR

• Use 5 Whys for simple, single-chain failures. Use fault tree analysis or a causal timeline when several conditions combined to cause the problem.
• A fishbone diagram is a brainstorming aid for grouping possible causes. It does not prove any of them.
• Good investigations are open, objective and focused on learning, not blame. Question everything and beware of preconceived ideas.
• A root cause is only confirmed when you can reason backwards from it to the original problem and the chain holds.
• Corrective actions need owners, target dates and a check that they worked. Training helps most when it teaches people to run the method, not just name it.

Table of Contents

• What root cause analysis actually involves
• The main root cause analysis methods compared
• How to choose the right method
• Making the analysis honest
• Verifying the root cause
• Choosing and checking corrective actions
• How long does a root cause analysis take?
• Tools that support the work
• Root cause analysis and incident investigation training
• Our perspective
• Train your team with Oxford Centre
• FAQ
• Sources

What root cause analysis actually involves

Most organisations already fix problems. RCA is different because it refuses to stop at the first plausible explanation. “The operator made a mistake” is rarely a root cause. It usually points to a question: why was a mistake possible, and why was it not caught?

That second question matters. The International Rail Quality Board’s problem-solving guideline says problems have two categories of root cause: the cause of occurrence and the cause of non-detection. A supplier ships a faulty batch because a setting drifted (occurrence), and the fault reaches the customer because the inspection did not test for it (non-detection). Fix only one and the problem can return.

Whatever method you pick, the process follows the same shape:

1. Define the problem precisely. What happened, where, when, how often, and what was the impact? Vague problem statements produce vague causes.
2. Contain the immediate risk. Make the situation safe before analysing it.
3. Collect evidence. Records, data, physical evidence, photographs and interviews, gathered before memories fade and equipment is moved.
4. Map what happened. A timeline of events and conditions comes first, before any theory about why.
5. Analyse causes. Apply one or more of the methods below.
6. Verify the root cause. Test your logic, ideally in reverse.
7. Act and check. Fix each cause, then confirm the fix worked.

The UK Health and Safety Executive’s workbook on investigating accidents and incidents sets the tone for steps three to five: investigations should be open, honest and objective, investigators should question everything, and they should beware of preconceived ideas. That last point is the one most teams break. If you walk in with a favourite suspect, every method will find it guilty.

The main root cause analysis methods compared

No single method is best. The table shows what each does well and where it struggles.

5 Whys

You state the problem and ask “why?” repeatedly, usually around five times, until you reach a cause that you can act on. A pump stopped. Why? A fuse blew. Why? The bearing seized. Why? It was not lubricated. Why? The task fell off the maintenance schedule when the schedule was updated. The last answer is something you can fix.

It is quick and anyone can use it. The weakness is that it follows one path. Engineering firm ClickHouse notes that 5 Whys suits simple, single-chain failures but biases towards a single causal chain, so more complex incidents often need several methods combined, such as a causal timeline. If two people running 5 Whys on the same incident reach different roots, that is a sign the problem has more than one cause, not that one person is wrong.

Fishbone diagram

The problem sits at the head of a “fish” and the bones are categories of possible cause. Common headings are people, process, equipment, materials, environment and management. A team fills each bone with ideas, which stops the discussion collapsing onto the first category anyone mentions.

Use it early, as a way to widen the search. Then test each candidate against evidence. A fishbone diagram full of untested ideas is a list of hypotheses, not a finding.

5 Whys versus fishbone

They answer different questions. 5 Whys goes deep along one line of reasoning. Fishbone goes wide across many lines. A practical pairing is to use the fishbone to generate candidate causes, pick the ones the evidence supports, then run 5 Whys down each of those branches. This also guards against the single-chain bias described above.

Fault tree analysis

Fault tree analysis starts from the unwanted outcome at the top and works downwards, using logic gates to show which combinations of events must occur together (AND) or alternatively (OR) to produce it. It suits situations where redundancy and safeguards mean that one failure alone would not cause harm. ClickHouse’s guidance again points to fault trees as better suited to safety-critical and multi-condition failures than 5 Whys.

FMEA

Failure mode and effects analysis looks forward. For each step in a process or each component in a product, the team asks how it could fail, what the effect would be and how likely it is to be caught. Scores for severity, occurrence and detection help rank the risks. It sits neatly with the two-sided view of causes above, because detection is built into the scoring.

There is a wider point here. The North American Electric Reliability Corporation’s cause analysis methods document says root cause work should combine proactive methods, which seek to understand how mistakes occur, with reactive ones that draw lessons from past events. FMEA is proactive. 5 Whys, fault trees and timelines are usually reactive. A mature programme uses both.

Causal timelines and event mapping

For complex incidents, build a timeline of what happened, then add conditions and decisions at each point. Gaps in the timeline show you where evidence is missing. Transport safety investigators use richer versions of this idea. Taiwan’s Transportation Safety Board, for example, uses a Safety Factors Map adapted from several established accident models. It displays the logical relationships between sequential events and causal factors at different levels of the system. You do not need that sophistication for a late delivery, but the principle scales down: show events in order and link each causal factor to the level at which it sits.

Pareto charts

A Pareto chart ranks problem categories by frequency or cost. It does not find causes, but it tells you which problem deserves a full investigation. If three defect types account for most of your rework, start there.

Accident models and Tripod Beta

In safety work, methods rest on models of how accidents happen. The European Agency for Safety and Health at Work’s OSHwiki groups them into sequential models (the domino effect), epidemiological models (such as the Swiss-cheese model) and systemic models (such as FRAM and STAMP). The model you hold in your head shapes what you look for. A sequential model looks for the one domino that fell first. A systemic model looks at how normal variation in a whole system interacts.

Tripod Beta is an incident investigation methodology first developed in the 1990s, with its official user guide published by the Energy Institute. It links immediate human actions to the underlying organisational factors that made them likely. It is used in high-hazard sectors such as energy, and it requires trained investigators.

How to choose the right method

Ask four questions before picking a tool.

How many causes could there be? One obvious chain points to 5 Whys. Several interacting conditions point to a fault tree or timeline.

What is the cost of being wrong? A cosmetic defect and a serious injury do not deserve the same rigour. The higher the stakes, the more you should combine methods and document the logic.

What evidence do you have? A fishbone session needs people. A fault tree needs reliable failure data. A timeline needs records and witness accounts.

Is this reactive or proactive? Investigating a past event calls for the reactive tools. Reviewing a process before launch calls for FMEA.

A useful rule of thumb: start with a timeline, widen with a fishbone, go deep with 5 Whys on the supported branches, and use a fault tree where safeguards failed in combination. When problems have several contributing causes outside engineering too, such as skills, culture and coordination across teams, the thinking in this white paper on coordinating individual and system-level change can help you frame how separate factors reinforce each other.

Making the analysis honest

Methods do not protect you from bias. A few habits do.

• Separate facts from inference. Mark each statement on your timeline as observed or assumed.
• Keep blame out of the room. The International Civil Aviation Organization’s 2023 workshop material says accident and incident investigations must take a just culture approach, working out what happened, how and why in order to improve safety rather than to find someone to blame. People who fear punishment stop telling you what really happened.
• Stop at a cause you can control. “Human error” is a starting point. Keep asking until you reach a condition the organisation can change, such as unclear procedures, workload or a missing check.
• Invite someone who was not involved. An outside view challenges the assumptions insiders no longer notice.

Verifying the root cause

Before you act, test the finding. The International Rail Quality Board suggests verifying by reasoning in reverse: start from the identified cause and walk back to the original problem, checking that each link holds. If you can say “because X, therefore Y, therefore Z” all the way to the symptom, and nothing in the evidence contradicts a step, you have a credible root cause. If a step needs “and also, somehow”, keep digging.

A second test: if this cause had been absent, would the problem still have occurred? If yes, you have found a contributing factor, not the root.

Choosing and checking corrective actions

This is where many analyses fail. The report is excellent and nothing changes. The same IRIS guideline says organisations should make sure corrective actions address both the occurrence and the non-detection root causes, set an action plan with responsibilities and target dates, and then monitor implementation and effectiveness through checks, tests or KPIs.

Spain’s State Aviation Safety Agency makes a related point in its root cause analysis guide: corrective actions should be clear and complete, because unclear actions can leave incomplete or unclear evidence, and each action should correct an identified root cause. For significant organisational changes, it recommends internal audits to verify them.

A simple action table keeps this honest:

Two habits make the difference: one named person per action, and a review date written into the plan on the day you agree it.

How long does a root cause analysis take?

It depends on the problem, and no universal figure exists. A quick 5 Whys on a minor process slip can take under an hour. A serious incident with witnesses, physical evidence and several teams takes weeks. Regulated sectors sometimes set deadlines. In the United States, for example, the Centers for Medicare & Medicaid Services guidance notes that for Joint Commission-accredited facilities steps two to six of an RCA must be completed within 45 days of the event. That is a rule for that setting, not a general benchmark. In the UK, check your own sector regulator and your internal policy.

What stretches the timeline is almost always evidence: records that are hard to find, people on shift rotations, or equipment that is needed back in service. Plan to secure evidence first.

Tools that support the work

You do not need software to begin. A whiteboard, sticky notes and a shared document will carry a fishbone session, a timeline and a 5 Whys. Software helps when you need to keep a register of investigations, draw fault trees that stay editable, assign and track actions, or spot repeat causes across sites. Choose a tool for what you do after the analysis (tracking, trending, reporting) rather than for its diagrams alone.

Root cause analysis and incident investigation training

Methods are easy to read about and harder to do well. The common failures are leading questions in interviews, stopping at the first human error, and treating a fishbone as a conclusion. Good training addresses those directly.

When you compare courses for root cause, incident or accident investigation, look for:

• Practice on realistic cases. You should leave having built a timeline, a fishbone and a fault tree yourself.
• Evidence and interview skills. Preserving the scene, taking witness statements and keeping bias out.
• A just culture approach. Investigations aimed at learning, in line with the ICAO principle above.
• Legal context for your sector. Reporting duties and the regulator’s expectations.
• Action follow-through. Writing actions that are specific, owned and checked.
• Fit with your hazards. A construction site, a hospital ward and a software team need different examples.

For organisations, customised delivery usually beats an open course, because the team can work on its own incident types and procedures. Look at who will lead investigations, who will sit on panels and who simply needs awareness, and train each group to a different depth.

Our perspective

We see the same pattern in organisations that ask us for investigation and problem-solving training. They rarely lack a method. They lack a shared habit of using one the same way, and a way to prove that fixes worked.

Our view is that the method matters less than three things. First, a precise problem statement, because every later step inherits its vagueness. Second, a team that is allowed to say what really happened without fear of blame. Third, an action plan with a named owner and a date for checking whether it worked. A mediocre method with those three beats a sophisticated one without them.

We also think training should be built around the learner’s own work. That is why we focus on customisable programmes that can be delivered on-site, online or blended, led by industry practitioners who have dealt with real incidents, so that a team practises on problems it will actually meet.

— Sam

Train your team with Oxford Centre

If you want your managers, engineers or safety leads to apply these methods with confidence, we run professional training that can be tailored to your sector and delivered on-site, online or blended. Our project management courses are a good starting point where root cause work sits inside delivery and quality control, and you can find sessions near you through our London training centre page. For security-related incidents, our Security Performance Measurement and Reporting course covers how to measure and report what is going wrong.

FAQ

Which root cause analysis technique is most effective?

None is best in every case. 5 Whys is effective for simple, single-chain problems, while fault trees and causal timelines suit complex or safety-critical failures. For serious incidents, combining two or three methods gives a more reliable result than relying on one.

What is the difference between 5 Whys and a fishbone diagram?

5 Whys drills down one chain of reasoning to a cause you can act on. A fishbone diagram spreads out many possible causes across categories. Teams often use the fishbone to generate candidates and 5 Whys to test the most likely ones.

How do I know I have found the real root cause?

Reason backwards from the proposed cause to the original problem and check that every link is supported by evidence. Then ask whether the problem would still have happened without that cause. If it would, you have found a contributing factor and need to keep looking.

Who should attend incident investigation training?

Anyone who will lead or sit on an investigation, such as supervisors, safety advisers, engineers and quality managers. Senior managers benefit from a shorter session on just culture and on reviewing action plans, so that they support learning rather than blame.

Sources

• HSE: Investigating accidents and incidents, a workbook
• NERC: Cause Analysis Methods
• OSHwiki: Accident investigation and analysis
• IRIS Guideline 7: Problem solving
• Energy Institute: Tripod Beta
• ClickHouse: What is root cause analysis?
• TTSB: Tools for transportation occurrence investigation
• CMS: Guidance for performing root cause analysis
• ICAO: Models and principles, 2023 AIG workshop
• AESA: Guía de Análisis de Causas Raíz