Root Cause Analysis: How to Find the Real Problem

Root cause analysis is the process of working past the visible symptom of a problem to the underlying cause that, if removed, stops the problem recurring. Done well, it means you fix a thing once rather than repeatedly patching the same failure. The essential move is to resist the obvious explanation, gather evidence about what actually happened, and keep asking why until you reach a cause you can genuinely control. Everything else is technique in service of that discipline.

I have spent more than twenty-five years in manufacturing operations, from the foundry industry through to aerospace at Goodrich and Moog, and if there is one lesson I would carry into every investigation, it is this: memory is not evidence. This guide explains what root cause analysis is, how to run it step by step, the tools worth knowing, and the mistakes that lead teams to fix the wrong thing.

Why symptoms are so seductive

A symptom is what you notice: a rejected batch, a late delivery, a machine that stopped. It is concrete, urgent and demands action. The trouble is that acting on the symptom feels like progress while often changing nothing. You scrap the batch, chase the delivery, restart the machine — and next week the same thing happens because the cause was never touched.

Root cause analysis deliberately slows this reflex. It treats the symptom as a clue rather than the problem itself, and it insists on evidence before conclusions. The reward is fewer repeat failures and a quieter operation.

A lesson I learned in a quality meeting

I once sat in on a quality meeting at a prime aircraft manufacturer. A gearbox had failed, and the team had already concluded the root cause and drafted an improvement plan — without even taking the gearbox apart. They were working entirely from past experience, from what a similar failure had looked like before.

So I asked what had happened the last time this gearbox failed. "We applied corrective and preventative actions," came the reply, said with some confidence. So I asked the obvious question: then how could this be the same fault? If the previous corrective and preventative actions had genuinely removed the cause, the same cause could not be back. Either the earlier fix had not addressed the real cause, or this was a different cause wearing the same symptom — and there was no way to know which without opening the gearbox and looking.

The room went quiet, because the point lands hard. Experience is valuable for forming a hypothesis, but it is a terrible substitute for evidence. Real root cause needs the thing on the bench and the data in front of you, not a recollection of the last time something looked similar.

How to run a root cause analysis, step by step

1. Describe the problem in specifics

Start by pinning down exactly what happened. When did it start, where does it appear, how often, and how do you know? A precise description — "solder joints failing inspection on the night shift line since the reel change" — narrows the search dramatically. A vague one — "quality problems" — sends everyone off in different directions.

2. Gather the evidence while it is fresh

Go and look. Talk to the people who were there. Collect the data, the failed parts, the settings, the timings. Take the gearbox apart. Evidence decays quickly as memories fade and conditions change, so capture it early. Resist forming a theory until you have looked, because a premature theory makes you notice only the facts that confirm it.

3. Ask why, and keep asking

Take the confirmed symptom and ask why it happened. Then ask why that happened, and continue until you reach a cause within your control. Crucially, separate two questions: why did the defect occur, and why did it escape detection? These usually have different answers, and both matter.

4. Test the candidate cause

A candidate cause is only a hypothesis until you test it. Can you switch it on and off? If removing the suspected cause makes the problem disappear, and reintroducing it brings the problem back, you have strong evidence. If you cannot explain the mechanism, keep digging.

5. Correct, verify and standardise

Put in a corrective action that removes the cause, then confirm with data that the problem has actually stopped over a meaningful period. Finally, update the standard, the check and the training so the lesson is captured as information the whole team can use rather than a story one person remembers. This is what turning data into information really means.

Tools that support the analysis

No tool finds a root cause on its own; they organise thinking. The most useful for operations teams are:

• The 5 Whys — a fast, conversational route to a cause for simpler problems.
• The fishbone (Ishikawa) diagram — a way to brainstorm causes across categories such as people, method, machine and material.
• Is/Is-not analysis — comparing where the problem appears with where it does not, to isolate what is different.
• Pareto analysis — ranking problem types by frequency or cost so you attack the biggest first.

Use the simplest tool that fits. A complex problem affecting a customer may justify a full structured investigation; a recurring niggle may need only a few well-aimed whys.

Mistakes that lead you to the wrong cause

• Concluding from memory. As that gearbox showed, past experience is a hypothesis, not proof; open it up and look.
• Stopping at "human error". People operate within a process; ask why the process allowed the error.
• Confirmation bias. Deciding the cause first, then collecting only the evidence that agrees.
• Single-cause thinking. Serious problems often have several contributing causes acting together.
• Skipping verification. A cause you have not tested is a guess wearing a lab coat.
• Solving in the meeting room. The evidence is usually on the shop floor, not the whiteboard.

Imagine a firm that keeps rejecting a machined component and repeatedly re-cuts it. A quick fix re-cuts the part; root cause analysis might reveal, hypothetically, that a worn fixture is letting the part shift, so every batch will fail until the fixture is replaced. Same symptom, entirely different action.

Frequently asked questions

What is the difference between a symptom and a root cause?

A symptom is the visible effect you notice, such as a defect or a delay; a root cause is the underlying reason it happened. Acting on the symptom brings temporary relief but the problem returns, whereas removing the root cause stops recurrence. Good analysis always traces the chain from one to the other.

How many times should I ask "why"?

There is no magic number; five is a memory aid, not a rule. Keep asking until you reach a cause you can actually act on and can no longer sensibly go deeper. Sometimes that takes three whys, sometimes seven, and complex problems may branch into several chains.

Can a problem have more than one root cause?

Yes, and serious problems often do. Several conditions can combine to produce a failure that none of them would cause alone. This is why brainstorming tools like the fishbone diagram are useful — they stop you settling on the first cause and missing the others.

Where to go next

Finding the real problem is a skill that compounds across an organisation once teams practise it. If you would like a structured way to score your operation and generate a tailored plan for where your biggest recurring problems sit, ProgressXL is coming soon. To talk through a stubborn, repeating issue in your own business, get in touch.