What’s Wrong with 5-Whys??? – Complete Article

The Complete What’s Wrong With 5-Whys Article

I wrote this as a series of articles, but I thought I would publish it as one blog posting. So, here is complete reasoning on why you should not use the 5-Why technique.

A Question from a Former TapRooT® Root Cause Analysis User…

A former TapRooT® User who now works for a company that uses the “5-Why” technique sent the following questions:

Hi Mark,

As a “former” licensed user of TapRooT while with **********, I was left wanting more information after reading the e-Newsletter.

Perhaps you do not have time to respond in detail, but if you could point me in the direction……

What exactly about the “why” five fails to produce true root causes analysis?

My interest is based on the fact that ********** uses the Five Why method.

As a side note….my present employer, ******* ****** *******, also uses the five why method.

Thank you in advance for any information you are able to provide.

Bruce

My Answer to Bruce’s Question

Bruce:

Here is your answer.

As one who has spent most of the last twenty years understanding how root cause tools work (and which ones don’t) and analyzing root cause tools from a viewpoint of a human factors professionals, I have very definite ideas about root cause analysis based on psychological principals and personal observation and experience. But I don’t usually share these views because many see my ideas as self-serving (“He is just promoting his own product by tearing down others.”).

However, because so much is at stake when people perform poor root cause analysis (lives, injuries, environmental damage, jobs, corporate profits, customer satisfaction, …), I just can’t let poor root cause analysis go unchallenged.

So let me lay out my reasoning for including the 5-Why technique on my list of root cause techniques that should be banned from any reputable organization’s list of analysis tools.

Yes “banned” is a serious statement. Some might even say that I am inciting a root cause revolt. Perhaps I am. But I hope that everyone who reads this will agree that techniques that when used properly produce substandard results, should be banned. And that this writing clearly shows why 5-Whys is substandard and all of the industry can make progress getting beyond the sad state of affairs that many companies claim is “root cause analysis.”

So let me start out by saying that my goal here is NOT to compare the miss-use of techniques with proper use of other techniques. Rather, my purpose is to compare real use and results of 5-Whys and the human psychology or human factors that underpin 5-Whys.

You could analyze any technique this way. This study and development of the real use of tools and techniques is how we developed TapRooT®.

In writing this critique of 5-Why’s, I will to cover:

1. What is good root cause analysis?

2. WHY (the basic human factors or human performance reasons) 5-Whys works – or fails to work – the way it does.

3. How 5-Whys meets (or does not meet) the goals of a good root cause analysis technique.

WHAT IS GOOD ROOT CAUSE ANALYSIS

To understand root cause analysis and judge a root cause analysis tool, you have to develop criteria for a root cause analysis system. To do this I developed a list of ten root cause analysis “musts.”

Where 10 “musts” come from? My experience and the experience of others. They came from:

* seeing thousands of incidents,

* performing hundreds of investigations,

* reviewing the results of thousands of investigations,

* surveying over 300 people at four TapRooT(R) Summits

* formally evaluating dozens of root cause tools and their effectiveness (including 5-Whys)

* developing dozens of performance improvement programs in a variety of industries

* evaluating the effectiveness of a variety of performance improvement programs

* collaborating with internationally recognized human performance and equipment reliability experts

Certainly 10 “musts” are not an exhaustive list. But they are a good list to use when evaluating a root cause analysis tools/systems.

BLAME

One thing that isn’t explicitly mentioned in the list, but probably should be considered is BLAME.

Why?

Because blame stands in the way of effective root cause analysis no matter what kind of tool you use.

So if you could develop at root cause tool that reduces or eliminates blame, it would help the investigator find root causes and develop more effective corrective actions.

TEN ROOT CAUSE ANALYSIS MUSTS

1. Must be easy-to-use but not “too easy”.

2. Must lead investigator to fixable causes of human performance and equipment problems.

3. Must have embedded expert knowledge.

4. Must be usable by regular people (not just PhDs/gurus).

5. Must be robust.

6. Must be tested – proven success in improving performance.

7. Must be well documented.

8. Must have excellent training.

9. Must have a database for organizing/sharing/saving/trending info.

10. Must have unique categories for trending.

That’s Not All…

Let me briefly explain why each of these MUSTS on the list. (The theory behind why it is a “must”.)

1. Must be easy-to-use but not “too easy”.

No matter how “good” you think your root cause analysis system is, users must be able to understand it, they must be able to use it, and management must be able to understand the results.

HOWEVER, being easy-to-use is not all that is required. That is why I added the term “but not too easy.”

Some people who believe in the 5-Why concept see the “easiness” of asking why five times as the great virtue of the technique. They seem to have fallen for the STAR TREK philosophy put forward by Mr. Spock that:

“An easily understood falsehood is better than an incomprehensible truth.”

If easiness is the ONLY criteria, then Spin-A-Cause would be the best root cause analysis system (much better than asking why 5 times).

In root cause analysis, there are more choices than just an easily understood falsehood or an incomprehensible truth. So one must find the middle ground – a system that is easy enough to use without being too easy.

This is much more along the lines of the Einstein quote:

“Make solutions as simple as possible, but not too simple.”

Without a doubt, any systematic evaluation of the cause of a complex accident requires work. So how do we know what is easy enough when we evaluate a root cause analysis tool or system?

First, the system’s results must be acceptable. If the system is easy but yields unacceptable results, then the system is too easy. To judge the results we use the second “must” below.

Also, any tool should be evaluated by potential users to see if THEY think it is easy enough.

For example, in developing TapRooT(R), user testing was conducted with safety engineers and evaluators, a group of union members who were refinery operators and maintenance technicians, hospital employees (nurses, risk managers, and doctors), and government regulatory personnel. They evaluated TapRooT(R) as being easy enough to use and suggested ways to make it even easier.

One caution: One must be careful not to allow unreasonable constraints when evaluating “easiness.”

For example, if a company assigns complex accidents to be investigated to supervisors in their spare time, NO system will yield acceptable results and be easy to use.

YOU CAN’T GET SOMETHING GOOD FOR NOTHING!

So when evaluating “easiness”, one must allow the user reasonable amounts of time and effort in performing an investigation and using the tool.

A second caution: The person evaluating the use of the tool must have been adequately trained.

Once again, it is preposterous to give an untrained supervisor a piece of software to perform root cause analysis and expect that the supervisor will perform a good investigation and find the software easy-to-use. No matter how good the software is, most supervisors do not have the investigatory experience needed to perform a good investigation without training in investigation practices and root cause techniques.

2. Must lead investigator to fixable causes of human performance and equipment problems.

This may be the most important, and most hotly debated, “must” on the list.

Almost every word in item 2 above is important.

For example, “lead” is important. This word help us discover the third “must” in the list.

FIXABLE is also very important.

The fixable criteria came from our definition of root cause.

Some who claim to be root cause analysis experts say that fixable has no place in the definition of a root cause or in evaluating the goodness of a root cause analysis tool.

But Larry Minnick, a senior utility executive and safety expert, convinced me that if a technique didn’t lead to things that management could “fix”, then the investigators were wasting thier time.

Most of those who object to the “fixable by management” part of the definition of root cause, do so because they misinterpret the goal of management being able to fix something. They think that it means that management is willing to fix the problem. They say that if management says they aren’t willing to fix something then it is still a root cause.

But the definition and the word fixable in item 2 above says nothing about management’s willingness to fix a problem. The definition simply states that “management has control to fix.”

Perhaps a couple of examples would clear things up.

First, if someone falls from a scaffold, someone might say that “gravity” is the root cause. I would say that “gravity” is not in management’s control to fix. Therefore it is not a root cause. Gravity is simply a fact.

Someone else might say that if the person who fell from the scaffold was not wearing fall protection that was available, then management has no control to fix the problem. The person who fell is solely accountable. He/she was violating a rule.

I would say, “Not so fast!” Management has ways to encourage or discourage the use of procedures, the following of rules and administrative controls, and the safety culture of the company.

BEFORE we say that changing behavior is outside of management’s control, we need to carefully examine what management is doing to manage behavior. I have seen management cause great changes (both for the good and for the worse) in behavior so that I know that this is something that management often does have control to fix.

So perhaps the BEST measure of effective root cause analysis is the change that good root cause analysis creates. As a result of good root cause analysis people should develop and implement effective fixes that improve performance. These results come from finding, understanding, and FIXING the root causes of problems.

Thus IF a root cause analysis tool can lead a person or a team to the fixable causes of a problem and IF the person or team develops effective corrective actions and IF the company implements the effective corrective actions, THEN performance should improve. This should be measurable by effective trending. (Ahhh, but most companies don’t understand trending and don’t have an effective trending program – the topic of a different article.)

One more item to notice in the second “must” is that it includes BOTH human performance and equipment problems.

Many people miss the root causes of equipment problems because they don’t explore the human performance causes. These problems could involve installation, design, maintenance, or operation of the equipment.

3. Must have embedded expert knowledge.

Why must the system have imbedded expert knowledge? Because you can’t expect every investigator to be in expert in every cause of equipment and human performance. Also, you can’t expect every site to hire experts on every topic that an investigator can reasonably be expected to confront.

So if the investigator does not have the knowledge, the investigative tool MUST have the knowledge or guild the person to the knowledge or at least help them know that they don’t know.

The root cause tool needs to be an EXPERT SYSTEM with expert knowledge.

The more transparent (yes – invisible) this expert knowledge is, the better the system will work for most people.

The user of a root cause analysis system should not feel like they are required to have a PhD in engineering, human factors, and management to conduct an investigation. The system should make the knowledge needed available in as close to layman’s terms as possible.

So when they use this expert system knowledge, they should amaze their boss and peers with the insights they gain over and above what they discovered when investigating incidents before they had an expert system.

4. Must be usable by regular people (not just PhDs/gurus).

This “must” comes from the KISS philosophy (Keep It Simple Stupid).

KISS is a reminder for the designer – the person tempted to be stupid and make a design complex.

The reason that anyone developing a root cause tool should keep it simple is NOT that the users are going to be stupid.

Rather, if the system is simple, people will use it.

Many root cause tools are developed by experts and all you need is the expert’s knowledge to use the tool well.

People performing root cause analysis are always under pressure. They have deadlines. They deal with conflicting or missing information. They must investigate complex accidents. They don’t need their root cause analysis tool to be needlessly complex.

The key is to remember Einstein’s advice:

“Make solutions as simple as possible, but not too simple.”

And part of making a system simple is embedding expert knowledge in the system to help lead the investigator (the third “must”). This makes the system simple because the user doesn’t need to learn all the expert knowledge before they start investigating their first incident.

5. Must be robust.

What is a robust root cause analysis tool?

A tool that helps the investigator keep on track and even helps steer them back to the track when they start to go astray.

A tool with checks and balances to help the investigator assure that a wide variety of potential causes have been checked and that the root causes they uncover are accurate.

A robust tool does not require perfect use or perfect knowledge to get a good answer. (A good answer can be defined as corrective actions that improve performance.)

6. Must be tested – proven successful in improving performance.

A good root cause analysis tool should have passed the test.

It should have been tried by a variety of users in a variety of industries.

It should be able to analyze equipment and human performance problems.

Different people using the system on the same incident should get similar results.

A good root cause analysis system should have a pedigree of success stories that prove its effectiveness.

Experimental root cause systems are OK for experiments.

But if you are going to solve real problems in the real world that could:

* save people’s lives,

* save people’s jobs,

* prevent environmental damage, or

* improve your reputation with customers and regulators,

Then you want to be confident in the root cause analysis technology that you are using.

Thorough testing and proof of effectiveness is where “homegrown” root cause systems usually fail to pass muster. They seldom have thorough testing by a variety of users in a variety of industries.

7. Must be well documented.

This documentation should include how to use the system and definitions for any terminology used in the system.

Why is documentation important? Because it helps people be consistent in using the system.

Consistency is often one of the main faults with root cause analysis tools.

If you give a root cause analysis tool to two different investigators (or two different investigative teams) and they arrive at completely different answers — you have a problem.

The problem is that you need a better root cause system!

Documentation helps consistency which helps a system pass the test (must 6) and be usable by average investigators (not just experts).

8. Must have excellent training.

A system is only as good as the training for the users.

Almost any system can be misused. Excellent training will get people started the right way (and excellent management will keep them using the system the right way).

What is excellent training?

You can judge the training by the results.

How much improvement there is after the training?

Do those trained dig deeper and find root causes that they previously would have overlooked?

Do the corrective actions seem like they will work?

After the corrective actions are implemented, do they cause performance to improve? Is the improvement statistically significant?

The proof of good training is not JUST how the trainees feel about the training. The proof of good training is in the results that the trainees get after the training.

9. Must have a database for organizing/sharing/saving/trending info.

Why should you have a database for root cause analysis, incident investigation, and performance improvement?

Here are five basic reasons to have an incident database:

1. To keep track of information during the investigation. (Helps you find root causes.)

2. To provide computerized tools to make investigators more productive (including expert systems). (Helps make investigations more effective and efficient.)

3. To facilitate the searching of old incidents and sharing of lessons learned across a site or corporation. (Helps find old corrective actions that didn’t work and share information about your investigation.)

4. To track corrective actions to completion and track verification and validation of selected (especially important) corrective actions. (Root cause analysis is useless if the corrective actions aren’t implemented – and what gets measured gets done.)

5. To provide the data for trending and management of the facility or company. (Making root cause data available makes the root cause information usable.)

Thus if you have a database that meets the five items above, you will more productive, efficient, effective investigators who are more likely to get their corrective actions implemented.

10. Must have unique categories for trending.

Why trend? Why should one think about trends when developing a root cause system?

Trends should be a key part of any improvement program.

Each investigation should become a part of the “Big Picture” that helps management effectively manage a company or facility.

To make this happen and make it available to those who come along after the investigation, one must organize and categorize the data.

Once you have a good categorization system you can:

* spot areas begging for improvement (the biggest problems)

* find significant trends

* prove that improvement has occurred

* prove that random failure is NOT a trend

* estimate the expected minimum and maximum time between incidents or accidents

– – –

Now that we have looked at what makes a good root cause analysis system, let’s look at how 5-Whys meets the 10 “musts”.

EVALUATING THE 5-WHYS VS. THE 10 MUSTS

1. Must be easy-to-use but not “too easy”.

Asking “why” 5 times is certainly an easy concept. But in “How Do You Find Root Causes?”, Kevin McManus, claims that the hardest part of 5-Whys is asking the right Why questions. He cliams that just asking why is not enough. He maintains that experts can develop probing why questions that can find root causes, but that most people can’t seem to master the technique.

If this is true, then 5-Whys don’t meet the insight that W. Edwards Deming shared when he said:

“If you do not know how to ask the right questions, you discover nothing.“

Thus by this evaluation, 5-Whys don’t even pass the first test of being easy.

But others, including me, see 5-Whys as being TOO EASY. And I will try to show you why by evaluating the next three “musts”.

2. Must lead investigator to fixable causes of human performance and equipment problems.

AND

3. Must have embedded expert knowledge.

AND

4. Must be usable by regular people (not just PhDs/gurus).

I’ve combined the evaluation of these three “musts” because they are related.

These three “musts” are where 5-Whys, and all cause-and-effect based tools like fishbone diagrams and fault trees, fail the “must” test.

The cause-and-effect technique was invented by Socrates. It was used by philosophers for over a thousand years before other philosophers in the middle ages pointed out a serious cause-and-effect weakness. To understand the weakness, you must understand the basis for cause-and-effect analysis (which is the basis for the 5-Why technique).

The basis for any cause-and-effect type of evaluation (including performing cause-and-effect analysis by asking why 5 times) is that there is a cause and effect relationship that can be observed and remembered.

IF a person observes a cause produce an effect, THEN if the same person sees the same effect again, they can assume that the same cause produced the effect without seeing the cause.

Even more profound, one expert can teach another expert about cause-and-effect relationships so that understanding of events can be passed along without having to personally experience every cause-and-effect relationship.

Now for the basic problem with cause-and-effect analysis.

IF there is only one cause for each effect, THEN cause-and-effect theory would always work. (As long as you knew all the cause and effect relationships.)

However, in the middle ages several famous philosophers pointed out a weakness with cause-and-effect analysis:

SOME EFFECTS HAVE MORE THAN ONE POSSIBLE CAUSE.

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 list 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.

But even “root cause gurus” have problems using 5-Whys effectively.

Why?

First, even the smartest gurus have limited knowledge. They may claim that they will consider ALL possible causes, but they can’t consider causes that are unknown to them.

Second, every root cause guru that I have met has at least one, and sometimes several, “favorite causes”.

Modern human factors research has shown that when people solve problems they tend to develop a hypothesis fairly early in their investigation and then focus on information that proves their hypothesis and ignore information at is contradictory to their hypothesis.

I call this the “I’ve seen this before!” trap. The scientific name for the trap is “confirmation bias.”

This is true for experts (gurus) and novices. But it is truer for experts because they have more experience and tend to fall into the “I’ve seen this before!” trap more easily.

So how does the 5-Why technique meet up to the goals of “musts” 2, 3, and 4 and why should a company avoid the 5-Why technique?

Because:

* 5-Why does not lead an investigator beyond their current knowledge.

* 5-Why doesn’t have any embedded expert knowledge.

* 5-Whys isn’t usable by non-experts because of the assumptions of cause-and-effect analysis (must know all the causes).

* 5-Whys shouldn’t be used by experts because of the “I’ve seen this before” trap.

This should be enough to convince you of the unsuitability of the 5-Why technique. But I will continue to evaluate the rest of the “musts”.

5. Must be robust.

Beyond the problems listed above, 5-Whys tends to allow people to miss multiple causal factors. Therefore 5-Whys is NOT ROBUST.

Often, people using the 5-Why technique tend to ask “Why” about the incident or the most obvious causal factor that they see.

They don’t develop a timeline and observe the multiple causal factors that combined to cause the accident or incident.

For example, if there was a fire they concentrate on the fire.

They miss the lessor contributors that may have cause the fire to be worse or caused response to the fire to be slow.

6. Must be tested – proven successful in improving performance.

My testing has always shown 5-Whys to be insufficient to base improvements on.

Why do I say this? Because the results obtained using 5 Whys were the same as if the user didn’t use any technique at all.

What I have observed is that people using the 5-Why technique seem to like it BECAUSE they don’t have to think too hard – beyond their current knowledge. They really don’t ask probing “why” questions.

Thus the lack of inquisitiveness means that they try to make 5-Whys TOO EASY – and they don’t find in-depth root causes that can be used to fix problems.

7. Must be well documented.

AND

8. Must have excellent training.

At most facilities using 5-Whys, there is very little IF ANY documentation about the technique.

Also, I’ve seen people implement 5-Whys without any real training for their people. They just tell them to ask why 5 times.

These problems aren’t really failures of the technique. They are implementation problems.

However, because asking why 5 times seems so simple, people often don’t see why they need good training and documentation.

Thus to evaluate the implementation of 5-Whys at a particular facility, one would need to know about the training and documentation used (which is certainly not standardized across different applications of 5-Whys) before they could evaluate this “must” criteria.

9. Must have a database for organizing/sharing/saving/trending info.

AND

10. Must have unique categories for trending.

Information from the 5 Why technique could be put into a database.

However, the free form “brainstorming” analysis of everyone asking why 5 times is not designed to consistently lead investigators into a well thought out, documented set of categories.

Therefore, 5-Whys does not lend itself well to categories for trending and fails to meet this “must.”

CONCLUSION – BAN 5-WHYS FROM YOUR ORGANIZATION!

5-Whys FAILS every evaluation of the 10 musts.

It isn’t even the easiest root cause analysis tool (for that, you should be using Spin-A-Cause™).

But these five reasons alone should be enough you to ban 5-Whys:

1. The 5-Why technique doesn’t reliably lead investigators to fixable causes of either human performance or equipment problems.

Why? Becase it does not have embedded expert knowledge and is usually used just to record the investigator’s beliefs about why a failure occurred. (It does not lead and investigator beyond their current knowledge.)

2. 5-Whys is NOT reliable for use by novices OR experts.

Why? Because of the problems described above that are inherent to the cause-and-effect philosophy.

3. The 5-Why technique is not robust.

Why? Because it causes people to focus on a single problem and miss more subtle problems.

4. The 5-Why technique usually isn’t tested or documented and usually has poor training.

Why? Because the claim that 5-Why is so easy that people assume they don’t need documentation or training. And why should anyone test a system that is so easy to use?

5. The 5-Why technique is not designed to be compatible with a consistent, well thought out categorization system for trending.

NEED MORE?

Want to go beyond these 5 reasons? You could also bring up the issue of BLAME.

In many implementations of the 5-Whys, people are taught to simply ask “Why?”

When they do this during an interview, the interviewee naturally becomes defensive.

Why?

Because they interpret the question as blaming them for something.

Therefore, instead of providing information, they start providing justification. They want to avoid the blame inherent in the “why” question.

Thus the 5-Why technique may lead to an atmosphere of blame and suspicion.

ONE MORE REASON TO BAN 5-WHYS

Most people would agree that you shouldn’t argue with a really smart person.

Einstein was a really smart person.

Einstein said:

“We can’t solve complex problems using the same knowledge that created them.”

Using the 5-Why technique IS trying to solve problems using the same knowledge that created them. Just asking “Why” does not get you beyond your current knowledge.

Don’t argue with Einstein.

Instead, use TapRooT® and experience the TapRooT® Advantage.

TapRooT® was designed to meet the 10 “musts” PLUS help reduce (or prevent) blame.

How can you find out about (and evaluate) the TapRooT® System for root cause analysis?

Attend one of our excellent, guaranteed training classes.

And if you still aren’t convinced that you need more than 5-Whys to find root causes, at least order a Spin-A-Cause™ and save some time.