Root Cause Analysis Methods: Proven Approaches to Use

Root cause analysis (RCA) is how you get past the symptom of a problem to the underlying cause, so you fix it once instead of firefighting it forever. There is no single RCA method; there is a small toolkit, and the skill is choosing the right one for the problem in front of you. This guide covers the main root cause analysis methods, when to use each, a worked example of the 5 Whys, the steps of a solid RCA, the mistakes to avoid, and a real case where finding the true root cause changed the outcome.

What is root cause analysis?

Root cause analysis is a structured way of finding the real reason a problem happens, rather than the first explanation that sounds plausible. “The machine failed” is a symptom, not a root cause; you need to understand why it failed. Get to the true cause and you can fix the process that created the problem, so it does not come back. Stop at the symptom and you are left applying the same band-aid again and again.

Which root cause analysis method to use

Different problems call for different methods. A good rule of thumb is to match the method to the shape of the problem:

• 5 Whys for a simple problem with one likely cause.
• Fishbone (Ishikawa) when there are many possible, interacting causes to organize.
• Pareto when you have a lot of data and need to focus on the vital few causes.
• Process map for a process problem full of delays and handoffs.
• FMEA when you want to prevent risk before it happens, not just react to it.

Is there a single best method? Not really, but for most everyday Lean Six Sigma projects a reliable go-to combination is Fishbone plus 5 Whys, with (if needed) data validation to confirm the cause. Fishbone opens up the possible causes, 5 Whys drills into the most likely one, and the data proves it. You will find most of these in the wider Lean Six Sigma tools toolkit.

The 5 Whys, with a worked example

The 5 Whys is the simplest RCA method: start with the problem and keep asking “why did this happen?” until you reach a cause you can meaningfully act on. Here is how it plays out on a real problem, late deliveries.

Problem: 20% of customer orders are shipped late. Why? The warehouse often does not receive the finished product on time. Why? Production frequently finishes orders later than scheduled. Why? Machines experience frequent unplanned downtime. Why? Preventive maintenance is not being completed as scheduled. Why? Maintenance is prioritized around urgent breakdowns, with no protected capacity for preventive work.

That last answer, no protected capacity for preventive maintenance, is far more actionable than “the machines keep breaking.” The fix might be a preventive-maintenance schedule with protected windows, clear ownership, and a KPI for completion. One important point: you do not have to ask exactly five times. Sometimes three whys is enough, sometimes you need six or seven. “Five” is shorthand for keep drilling until you reach a cause that explains the problem and can be acted on.

How to run a root cause analysis, step by step

A good RCA is more than picking a tool. The basic process runs start to finish like this:

1. Define the problem clearly. State what happened, where, when, how often and how significant it is, using facts rather than assumptions. For example: 12% of orders shipped more than two days late in July.
2. Gather data and evidence. Understand what actually happened from process data, observations, records, timelines and defects.
3. Identify possible causes. Generate potential explanations with tools such as fishbone or a process map.
4. Drill down to the root cause. Use 5 Whys or similar questioning to get beyond symptoms.
5. Verify the root cause with evidence. This is critical: do not accept the team’s favorite explanation simply because it sounds plausible. Look for data (if needed) showing the suspected cause actually drives the problem, or examine the process yourself first-hand (going to the Gemba).
6. Develop and implement corrective actions. Address the verified root cause, not the symptom, with owners and deadlines.
7. Confirm effectiveness and sustain. Measure whether the problem actually decreased, standardize the change, and put controls in place to prevent recurrence.

A useful shorthand for the whole flow is: define, investigate, identify, verify, fix, confirm.

The most common RCA mistakes

The biggest mistake is stopping at the symptom. “The machine failed” is not a root cause until you understand why it failed. The others come up again and again:

• Jumping straight to solutions before the cause is understood.
• Relying on opinions instead of data.
• Assuming there must be only one root cause.
• Blaming an individual rather than examining the process that allowed the error.
• Selecting a cause without verifying it with evidence.

A real example: getting to the true cause

A hospital was seeing repeated medication administration errors. The initial assumption was that nurses needed more training, so the obvious solution was retraining. Root cause analysis showed something different: the wrong medication was being selected because similar packages were stored next to each other, and storage locations were not standardized. The real root cause was a storage system that made selection errors easy. Instead of retraining people, the hospital redesigned and standardized medication storage. Errors fell, because the process that created the risk was changed rather than blaming the people working within it. That is the value of RCA: fix the cause, not the symptom.

Putting root cause analysis to work

The methods matter less than the discipline behind them: define the problem with facts, find the real cause, verify it with data, fix the process, and confirm it worked. Root cause analysis sits in the Analyze phase of a DMAIC project, and pairs naturally with FMEA when you want to prevent problems as well as solve them.

The Lean Six Sigma Company runs in-company group training and full deployment support across the United States. If you want your team to run root cause analysis that actually sticks, those are the right starting points.

Frequently Asked Questions