I’ve had so many people ask me, “How can I find the root causes of the problem?” that I’ve decided to put my experience (or at least some of it) and links to others’ suggestions (even though some of the suggestions are bad) in one location – THIS ARTICLE – about how to find root causes.

I’m going to start with a “simple” root cause analysis technique. A technique that I do NOT recommend but that I will share because it is frequently recommended by others. If you choose to use this simple technique, don’t blame me when the “root cause” you find and fix doesn’t seem to improve performance and you keep having the same accidents happen over and over again.

Next, I’ll cover more complex techniques. Some of these are souped-up versions of the simple technique. However, the complex techniques – while being more complex – still have the same inherent problems as the simple technique. Therefore, I can’t recommend these more complex techniques for serious root cause analysis of important safety, quality, maintenance, service, or production issues.

Finally, I’ll talk about the technique you should be using. A technique that was developed to avoid the problems presented by the previously mentioned simple and complex techniques. A technique that was intelligently designed to take you beyond your current knowledge. A technique that users praise for it’s repeatability, thoroughness, and effectiveness.


I’ve probably heard more “experts” talk about 5-Whys than any other root cause tool. Why? Because it is simple. Simple to teach and simple to use. All you have to do to find root causes is ask “Why?” five times.

Here’s an example of the technique from the technique’s creator, Tailchi Ohno:

1. “Why did the robot stop?”

The circuit has overloaded, causing a fuse to blow.

2. “Why is the circuit overloaded?”

There was insufficient lubrication on the bearings, so they locked up.

3. “Why was there insufficient lubrication on the bearings?”

The oil pump on the robot is not circulating sufficient oil.

4. “Why is the pump not circulating sufficient oil?”

The pump intake is clogged with metal shavings.

5. “Why is the intake clogged with metal shavings?”

Because there is no filter on the pump.

What do you think? Is “NO FILTER ON THE PUMP” a root cause? I think this example is a perfect example of what is WRONG with 5-Whys (and most unguided cause-and-effect  analysis).

First, they missed a whole line of questioning. Why didn’t the loss of lube oil pressure trigger an alarm or an automatic shutdown?

Another line of questioning that was missed was “Where did the metal shavings come from?” After all, metal shavings are not normally found in a well-maintained machine.

And finally,”Why was there no filter on the pump?” Did maintenance forget to install it? Did the designer fail to include it? Was it removed because it kept getting clogged?

All of these questions need to be answered but the ultimate expert, Tailchi Ohno, didn’t ask them because he thought he already had the answer.

Watch this 5-Why training video and see if you can poke more holes in their example …

OK, so according to the video, you might need to ask why more or less than five times. And in other 5-Why training they try to teach techniques to determine when you have asked enough “whys” to call the result a “root cause.” So simple might not be so simple after all.

Just watch this 5-Why example and see if you can tell when a root cause has been reached …

Five, six, ten, twenty “Whys”? Or was a root cause ever mentioned in all those why question answers?


Many root cause analysis tools start with the idea of cause and effect. Every effect is caused. If you follow the cause and effect chain back far enough, you will reach the root cause.

Most of the techniques realize that the unguided 5-Why process fails to produce adequate results. Therefore, they modify the process by putting rules or structure around the asking of why (developing the cause and effect chain). They think rules or more extensive training can solve the basic defects inherent in cause and effect.

Here’s an article I wrote for Quality Progress (a quality oriented professional society journal) that outlines most of the problems with cause and effect:



Here’s the root cause analysis example that I criticize in the Quality Progress article “Under Scrutiny” … the bug example.

Here is a You-Tube training video about a common cause-and-effect technique – a Fishbone Diagram …

Here’s what Dilbert has to say about Fishbone Diagrams …


Another technique commonly included as a cause-and-effect analysis tool is Fault Tree Analysis. Here is a presentation oriented toward engineers about Fault Tree Analysis …

Still another version of cause-and-effect mainly used as a design evaluation tool (rather than a root cause analysis tool) is Failure Modes and Effects Analysis (or FMEA). Here is a video about FMEA …

Once again, each example presented in the above references provides proof of why the technique should NOT be used for root cause analysis. All the examples show that the techniques display the analysis teams current knowledge. The technique does NOT get beyond what the team knows. If the team doesn’t know about human factors, they won’t solve human factors problems. And worse yet, the investigators don’t even know that they don’t know. And that’s a real problem when analyzing accidents by finding the accidents’ root causes.


Back in 1985, I started looking for a way that people in the field could be taught to find the root causes of human error and equipment failure related incidents. Because of my human factors training, I often saw causes that others couldn’t see. I knew the answer wasn’t for me to do every investigation (the ultimate root cause guru) or to put everyone through the same training and experience that I had. Instead, the answer was to develop a system that would help people be able to troubleshoot, understand, and fix problems by leading them to root causes that they previously would have overlooked.

The work over the next six years eventually lead to the development of the TapRooT® Root Cause Analysis System. And that initial development work was just the start. We, with the help of tens of thousands of users, have continuously improved TapRooT® for over 20 years.

How does TapRooT® work? Here are two links that explain the workings of the TapRooT® Root Cause Analysis System:



The first link includes a TV interview I did about root cause analysis. The second link is a white paper that describes how the TapRooT® Root Cause Analysis System works.

What’s the best way to learn to use TapRooT®? One of our courses – a 2-Day, 3-Day, or 5-Day.

For those that lead difficult investigations, I would recommend the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training.

I hope this article helped you understand some of the techniques that are available and the limitations of the common or “simple” techniques.

Please be careful when you decide “How to find root causes.” Picking the wrong technique can lead to poor analysis and corrective actions that don’t solve the real root causes. That’s why we developed TapRooT® and recommend it … because we know you really need to find and fix the root causes of serious safety, quality, production, service, or maintenance issues.