Posted byI found it!
I knew I had written an article about 5-Why’s in the Root Cause Network Newsletter, but I couldn’t find it.
Today I went through our archives by hand (I had already tried a computer search) and sure enough, it was there! Written seven years ago … no wonder people don’t remember it.
Click on the link below for a short article about WHY you shouldn’t ask WHY 5 times.
PS: To sign up for free e-mail delivery of our newsletters, click here.
NOVEMBER 1998 — Root Cause Network(TM) Newsletter
Why Asking “Why?” Doesn’t Work By Mark Paradies
Lately I’ve seen articles about the best way to find root causes. They tell people to ask “Why?” 5 times or to use a slightly more structured method: ask why and then draw a Cause & Effect Diagram (not to be confused with an E&CF Chart).
They say that these methods are superior to TapRooT(R). I can’t stand to see such nonsense in print! Let me explain just 3 (of many) reasons why these techniques can lead investigators astray.
Reason 1: You should never ask “Why?” in an interview.
Why? Because asking “Why?” causes people to become defensive. They justify their actions rather than communicating what they observed (the main point of an interview). If your main analysis technique is asking “Why?”, you are doomed to bad interviews. Bad interviews lead to bad investigations.
Reason 2: Cause & Effect Analysis can’t get you past what you already know.
Cause & Effect Analysis (a self made causal tree) was invented by Socrates. He used it as a basic reasoning tool. He knew its limitations. To define a cause and effect relationship one must have already observed the cause produce the effect. If one has never observed the cause produce the effect, one can’t develop a Cause and Effect Diagram.
Also, if there are many potential causes and the investigator has only experienced (or only has knowledge of) a few, then the investigator is likely to pick the cause that he/she is familiar with even if it isn’t the proper cause. I call this the “Favorite Cause Syndrome.”
Reason 3: You need structure to trend.
Asking “Why?” has no stucture. So forget about measuring your progress (i.e. no trending).
So what should you do?
Don’t be led astray! Use TapRooT(R).
It has the structure, the embedded knowledge, and the questions to go beyond other techniques.
Category: Root Causes
2 Comments »
RSS feed for comments on this post.
If you have done enough root cause analysis in your life, you will know that there is no such thing as a perfect methodology for conducting RCA using only one technique. The technique will vary depending on complexity of the problem, type of problem, your organizations readiness or willingness to accept root cause, your knowledge, the lnowledge of the team members, etc. The list is endless.
5-why technique can be a powerful technique in certain cases and if you know the right questions to ask you can get to the root causes, especially if you had to conduct an investigation in the middle of the night with very little resources.
I am an adovocate and a user of TapRooT and yet I have successfully used the 5-why technique, which I combine with logic/fault tree technique and gotten to the same root causes as TapRooT. I would rather use TapooT but I did this because the organization did not like the root causes TapRooT produced and yet they accepted the outcome of the investigation. So, there are many ways to skin a cat and if you know how to skin a cat, you will get the same result regardless of technique used, provided the technique is suitable for the given problem.
I think TapRooT can be used for all investigations but there are times when 5-why’s is better because of the reasons mentioned above.
Regards
Raj Malik
Comment by Raj Malik — November 14, 2005 @ 11:08 pm
Raj:
Thanks for the comment.
I hope everything is going well in Bahrain.
You are not the first person to resist my efforts to ban 5-Whys. But perhaps I can work on you and convert you???
First, I hate to disagree with you … you ask such insightful questions … but if can get you to see the dangers of 5-Whys and the damage that it can do, maybe I can turn your thinking around. And if I can turn around your thinking … someone who definitely has experience doing root cause analysis … maybe I can save other less experienced investigators from being tricked into thinking that asking WHY 5 times is root cause analysis. I certainly don’t want to just be disagreeable. But I think there are some very subtle reasons why some systems are truly better than others … especially better than 5-Whys.
So here goes…
First, a comment on your comment about “… no one best technique…”.
You said:
“The technique will vary depending on complexity of the problem, type of problem, your organizations readiness or willingness to accept root cause, your knowledge, the lnowledge of the team members, etc. …”
First, we developed TapRooT(R) specifically to be flexible to handle varying complexity of problems and types of problems (human performance and equipment reliability). The techniques built into TapRooT(R) allow that flexibility. That is one of the reasons that I choose NOT to use 5-Whys (it is not flexible) and is a specific reason why I believe TapRooT(R) is superior.
Second, I don’t think you should choose a second rate technique just because of “.. your orgainization readiness or willingness to accept root cause.”
Why do I think this? Because root cause analysis is so important for:
saving lives,
preventing accidents,
preventing major production losses,
preventing equipment failures, and
improving product quality.
Every industrial fatality I have ever seen could have been prevented if only the company had a good performance improvement program with good root cause analysis.
Many jobs could have been saved if only the factory had a good root cause analysis program.
That is why I fight rather than accept substandard root cause analysis results. I am fighting for people’s lives and jobs.
When I was an employee faced with an organization that resisted good root cause analysis, I didn’t give in and let them sink back to the three familiar corrective actions:
1. Disciplin employee.
2. More training!
3. Make the procedure longer.
Instead, I kept at my boss and senior management. I showed them the difference in good root cause analysis and their past results. I built support in the organization. I built a case around the return on the investment that was possible. I even built a regulatory case for improving. The work took almost two years.
The result? They eventually decided to adopt the new techniques. And I was awarded a bonus and a promotion for my efforts. Later, this work led to the founding of System Improvements (and, as they say, the rest is history!).
I’m sure you do much the same when someone asks you to do something that is less than right and you realize that the consequences could be catestrophic.
Next, about your comment about getting the same results no matter what technique you use.
This has NOT been my experience in a wide variety of applications at a wide variety of industries at companies around the world.
In fact, many people who have chosen to use TapRooT(R) told me that they did so BECAUSE the were impressed with the consistent results they achieved across investigative teams at their site or company.
One of them (Randy Bennett – who I believe you met at the 05 Summit) wrote me today to tell me about it. His comment is at the end of the other article on 5-Whys. He states that repeatability should be one of the “must” criteria for a good root cause system. Both he and I don’t see 5-Whys as being repeatable when given to different investigators, especially when some of the investigators are experienced and some aren’t.
See:
http://www.taproot.com/archives/2005/10/whats_wrong_wit_4.html#comments
Perhaps the reason you get the same results is that you are a very experienced investigator and therefore you see the answer BEFORE you start the analysis.
Be careful if this is the case. You could be falling for the “I’ve seen this before!” TRAP that I mentioned in the other article about 5-Whys. This is perhaps the most dangerous trap for experienced investigators (because they HAVE seen so many causes of problems).
Next, you state that 5-Whys can be a powerful technique “… if you know the right questions to ask …”.
But my point is that many, especially those with less investigative experince, DON’T know the right questions to ask. That is why 5-Whys can be especiually misleading to inexperienced investigators.
Finally, you imply that organizations should adopt the approach of having a large number of investigative tools to choose from.
Of course, TapRooT(R) has six techniques embedded in the TapRooT(R) Process. So it is pretty robust for giving investigators “optional” techniques to apply.
However, most organizatioins can’t afford to train their investigators in every root cause analysis technique in the world (beyond the six in TapRooT(R)). And even if they could, they would do better by standardizing on the best, most flexible methods and getting all of their investigators to continually improve their skills using those methods (rather than being rusty at using several different techniques).
Also, if a consistent approach is used, management will become accustomed to the presentations built around the consistent approach and will have a much easier time understanding the results of the investigation.
So to sum up my ideas:
– You are experinced and may get away with using 5-Whys.
– You really don’t need 5-Whys becauuse you already know the answer when you use it.
– Inexperienced investigators won’t get the same results that you do because they don’t know the questions to ask and can’t see the answer before they start.
– Organizations would be better off to pick a fexible, powerful, repeatable technique like TapRooT(R) and then apply it consistently than to have each user pick their favorite technique and have no consistency in their investigations.
Hope that helps you understand why I am so passionate about banning 5-Whys so that everyone can get superior results using TapRooT(R). I really hate the idea of anything less when so much is at risk!
Best Regards,
Mark
Comment by Mark — November 15, 2005 @ 8:26 pm