November 2, 2005 | Mark Paradies

More on 5-Whys

Bill Wilson had some questions about the analysis of 5-Whys that I performed so I thought I would reply so that everyone could read the questions and responses.

Here is the link to the complete prior article that Bill is referring to.

Bill wrote:


You’ve identified a number of potential issues involved in the use of the 5 whys technique. However, your main arguments against the method itself (not including support features like database and trending) seem to be:

a) it is based on cause-effect logic, and

b) it doesn’t protect against “tunnel vision”.

Furthermore, you state that these two factors combined cause investigators to:

1) miss subtle causes,

2) ignore other causes, and

3) focus exclusively on causes they know.

The remedy I would ordinarily suggest to address these 3 problems is rigorous use of the necessary and sufficient test, and to require that every causal claim be backed up by some piece of corroborating evidence. (My view on this is described more fully at

The remedy you suggest is to use an expert system that guides the investigator through a hierarchy of causes, the details of which I’m sure have been researched extensively.

I have a few questions.

1) Does the TapRooT root cause tree include subtle causes?

2) How does TapRooT keep an investigator from ignoring other causes that are on the tree?

3) How does TapRooT handle causes that may not be on the tree?

One final question and a comment… where does the use of evidence fit in? I didn’t see “evidence” mentioned anywhere in your 10 musts, or the 4 installments of this article.


Bill Wilson

– – –

My Reply:

I don’t completely agree with your summary of my critique of the problems with 5-Whys. But let me try to answer your questions about some of the troubling aspects of 5-Whys without quibbling over the finer points of why it doesn’t – as you put it – “protect against tunnel vision” (or, as I would suggest, that 5-Whys CAUSES “tunnel vision”).

Here are my answers to your questions:

1) As for your idea about “necessary and sufficient test” … here is what I said in the article:

Therefore, the investigator must know all possible causes and must do some sort of “validation” (is the cause necessary and sufficient) of the root cause analysis to PROVE that the cause they selected produced the effect they observed. But even a “necessary and sufficient” test could be wrong if an unknown cause could also be necessary and sufficient.

One might say that if you have a very expert investigator with a very complete lists of potential causes in their mind, they could use cause-and-effect to produce a good investigation and root cause analysis.

So good use of the 5-Why technique depends on someone who knows all the potential causes and is very good at asking the right QUESTIONS (not just “Why”) to determine all the cause and effect relationships.

This seems to validate Kevin McManus’ claim about 5-Whys NOT being easy to use. Thus cause-and-effect analysis requires a root cause guru – not the average person performing an investigation. And technique praised for it’s “easiness” actually requires decades of training and experience if it is to produce adequate results.

Thus I think that the “necessary and sufficiency test” usually does not work if an investigator has fallen for the “I’ve seen this before!” trap.

2) Your first question: “Does the TapRooT(R) Root Cause Tree(R) include subtle causes?”

Yes – many!

And when I started developing it in 1985, I would say that MOST were subtle and didn’t appear on most investigators’ radar screens.

Today, the root cause world has progressed much. And I think that TapRooT(R), and the categories we created, have a lot to do with that advancement. But many of the causes we help investigators find are still subtle to many investigators.

3) Your next two questions:

“How does TapRooT(R) keep an investigator from ignoring other causes that are on the tree?”

“How does TapRooT(R) handle causes that may not be on the tree?”

Good questions.

First, we have had extensive reviews of the system and causes listed on the Root Cause Tree(R) by human performance (human factors) and equipment reliability experts. This helped us make sure that we have a good, very complete list of potential causes. But this is just a start.

TapRooT(R) guides the investigator from the general (for example, Human Performance Difficulty) to more specific, “subtle” causes. It does this through a process of selection and elimination of potential causes.

We believe that the causes listed represent about 95% or more of the potential causes that an investigator is likely to find in an investigation. We believe this subset is at least twice as many causes as most investigators look for without guidance.

Therefore, we approach this question from the opposite side of the coin than the way you pose the question.

We see TapRooT(R) as HELPING people find causes that they previously would have overlooked BECAUSE their subset of causes that they recognize (either from their system or from their brain) is smaller than the number of causes suggested by TapRooT(R).

But we don’t stop there.

In class we emphasize the potential for other causes. We show students that as they get more specific, they may be able to eliminate all the lower level causes that are listed why still selecting a higher level cause. We give them reasons behind why this may happen AND how to use the system to develop corrective actions even if they can’t identify a cause that is not listed on the Root Cause Tree(R). (They can do this by using a module in the patented TapRooT(R) Software called the Corrective Action Helper(R) Module.)

We also encourage students to contact us if they discover causes not listed on the Root Cause Tree(R) when they are using the technique at their facility. With over 100,000 users, that gives us a pretty good testing base and source of ideas.

When we get the suggestions from the users, we first compare them to the already existing root causes on the Root Cause Tree(R). Sometimes we find that the user just needed to read the Root Cause Dictionary more closely (and we let them know that the cause was already there). Sometime we decide that we need to modify the Root Cause Tree(R) Dictionary to include that “flavor” of variance of a cause in an already existing category on the tree (and we make a note for our next dictionary revision). Sometimes we find that we need to add a category to the Root Cause Tree(R). And very infrequently, we find a category of causation that is so seldom present that we have decided to specifically NOT include it on the tree.

We occasionally get suggestions for root causes that we specifically exclude from the Root Cause Tree(R) because they are not root causes. These include “Where does ‘Joe was just stupid” go on the tree?” and other causes that violate our definition of “root cause.”

Finally, we also believe that there are causes that currently can’t be found in an investigation OR can’t be proven by an investigation. We don’t believe any system can find/prove these. What are they? Who knows. Some future scientific revelation will help us see them. Then we’ll add them to the tree!

So I think we do a pretty great job of covering all the bases (and we get lots of feedback from our users that helps us reach this conclusion).

Also, as the years have gone by and our revisions to the TapRooT(R) System have improved both the Root Cause Tree(R) and the Root Cause Tree(R) Dictionary, we get fewer suggestions of all kinds. I believe this is because the TapRooT(R) System does such a good job of helping people find fixable causes and analyzing their problems that there are less and less practical causes that need to be added to the tree.

Thus, I think my evaluation of the 5-Whys is based on a solid foundation.

4) As for your questions about “evidence” (“Where does the use of evidence fit in?”) – good question!

What I was talking about in the 10 Root Cause Musts was 10 musts for a root cause analysis tool or system. I wasn’t talking about the “evidence” or “facts” that the system uses or how you collect those facts (which a system can also help you to do).

Here’s an analogy:

If you are talking about the best way to grind corn into corn meal (use a tool to find root causes), you talk about different varieties of grist mills (root cause tools). EVERYONE would probably agree that a better quality of corn (facts/evidence) would also help produce better corn meal (root cause analysis). But the quality of the corn (facts/evidence) wasn’t what was being evaluated.

By the way, one of the big advantages of TapRooT(R) that is often not talked about is that it helps investigators do a better job of collecting and organizing the facts that lead to the incident/accident. But this has little to do with the 5-Why evaluation, so I won’t go into details about this advantage over 5-Whys and cause-and-effect analysis.

For more of an idea about my beliefs on “facts” click here.

Hope this discussion helps answer your questions and helps everyone else understand some of the advantages that TapRooT(R) will bring to their organization.

Root Cause Analysis
Show Comments

Leave a Reply

Your email address will not be published. Required fields are marked *