Determine the Root Cause: 5 Whys

Asking “Why?” may be a favorite technique of your three year old child in driving you crazy, but it could teach you a valuable Six Sigma quality lesson. The 5 Whys is a technique used in the Analyze phase of the Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) methodology. It is a great Six Sigma tool that does not involve data segmentation, hypothesis testing, regression or other advanced statistical tools, and in many cases can be completed without a data collection plan.

By repeatedly asking the question “Why” (five is a good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of a problem. Very often the ostensible reason for a problem will lead you to another question. Although this technique is called “5 Whys,” you may find that you will need to ask the question fewer or more times than five before you find the issue related to a problem.

Benefits of the 5 Whys

Help identify the root cause of a problem.

Determine the relationship between different root causes of a problem.

One of the simplest tools; easy to complete without statistical analysis.

When Is 5 Whys Most Useful?

When problems involve human factors or interactions.

In day-to-day business life; can be used within or without a Six Sigma project.

How to Complete the 5 Whys

Write down the specific problem. Writing the issue helps you formalize the problem and describe it completely. It also helps a team focus on the same problem.

Ask Why the problem happens and write the answer down below the problem.

If the answer you just provided doesn’t identify the root cause of the problem that you wrote down in Step 1, ask Why again and write that answer down.

Loop back to step 3 until the team is in agreement that the problem’s root cause is identified. Again, this may take fewer or more times than five Whys.

5 Whys Examples

Problem Statement: Customers are unhappy because they are being shipped products that don’t meet their specifications.

1. Why are customers being shipped bad products? – Because manufacturing built the products to a specification that is different from what the customer and the sales person agreed to.

2. Why did manufacturing build the products to a different specification than that of sales? – Because the sales person expedites work on the shop floor by calling the head of manufacturing directly to begin work. An error happened when the specifications were being communicated or written down.

3. Why does the sales person call the head of manufacturing directly to start work instead of following the procedure established in the company? – Because the “start work” form requires the sales director’s approval before work can begin and slows the manufacturing process (or stops it when the director is out of the office).

4. Why does the form contain an approval for the sales director? – Because the sales director needs to be continually updated on sales for discussions with the CEO.

In this case only four Whys were required to find out that a non-value added signature authority is helping to cause a process breakdown.

Let’s take a look at a slightly more humorous example modified from Marc R.’s posting of 5 Whys in the iSixSigma Dictionary.

Problem Statement: You are on your way home from work and your car stops in the middle of the road.

1. Why did your car stop? – Because it ran out of gas.

2. Why did it run out of gas? – Because I didn’t buy any gas on my way to work.

3. Why didn’t you buy any gas this morning? – Because I didn’t have any money.

4. Why didn’t you have any money? – Because I lost it all last night in a poker game.

5. Why did you lose your money in last night’s poker game? – Because I’m not very good at “bluffing” when I don’t have a good hand.

As you can see, in both examples the final Why leads the team to a statement (root cause) that the team can take action upon. It is much quicker to come up with a system that keeps the sales director updated on recent sales or teach a person to “bluff” a hand than it is to try to directly solve the stated problems above without further investigation.

5 Whys and the Fishbone Diagram

The 5 Whys can be used individually or as a part of the fishbone (also known as the cause and effect or Ishikawa) diagram. The fishbone diagram helps you explore all potential or real causes that result in a single defect or failure. Once all inputs are established on the fishbone, you can use the 5 Whys technique to drill down to the root causes.

Take-away Quotation

“If you don’t ask the right questions, you don’t get the right answers. A question asked in the right way often points to its own answer. Asking questions is the ABC of diagnosis. Only the inquiring mind solves problems.” – Edward Hodnett

The 5-Why tool is a very useful tool but I find that if you are not experienced with facilitating a 5-Why session for Root Cause Analysis then it can lead you down the wrong path. Most problems do not have one cause but many interdependent causes. I like to use the “Fault Tree Analysis” for RCA. This tool looks at the many dependent and independent causes of an effect.

Ron, The 5 Why method is to dig down to you recognize something you can fix, the digging can go to different levels depending on the process you are looking at, the more complex the more roots you might have to dig down using the 5 Why method, which might mean you ask the Why question many, many more times than 5 as you dig down each root cause. Thus the analogy of using the tree and its roots and digging is so pertinent. Just my Common Sense thoughts that aren’t so common, Glenn

Nice article. I have been practicing this and it definitely helps to understand the whys of the problem. Also as part of it you first need to understand what is the problem and where the problem occurs. Is it at a particular time or during an acitvity , then when? This way you can better understand the problem and get to the root cause of the problem. There may or may not be a fix to the problem, then a solution needs to be applied/devised.

The example of the car running out of gas is actually a good example of how NOT to use the 5-Why method. Consider applying the logic used in this example to problems at your business. The easiest such demonstration of this is if we make the driver in this example an employee whose job it is to drive a company vehicle. The company vehicle runs out of gas because the employee didn’t buy gas before driving, because he didn’t have money, because he lost it gambling the night before, because he can’t bluff. So what’s the solution? Teach your employee how to bluff? No, obviously not. The 5-Why was done incorrectly. The 5-Why should be used to reveal a failure of your process, not faults in employees. The 5-Why *SHOULD* have gone something like this: Problem – The employee doesn’t make it to the scheduled task on time because the car stopped in the middle of the road. 1. Why did the car stop? – It ran out of gas. 2. Why did it run out of gas? – There is no process in place requiring verification that the amount of gas in the tank is sufficient to reach the destination.

If the employee had done this and realized there wasn’t enough gas to reach his destination, he wouldn’t have started to drive *KNOWING* he couldn’t arrive on time. The driver’s ability to successfully gamble has absolutely nothing to do with this problem occurring. The process should be set up in a way to prevent it.

I run into this kind of problem all the time while managing corrective action teams. The 5-Why is a great technique – fast, efficient, easy to understand – but it takes some thorough thought to keep it from going on weird tangents, and teaching this type of thinking is the challenging part of problem solving.

Jorgy, I believe the two gas examples (yours and the one in the article) fundamentally differ here. One has the fundamental source of cash/trigger being the individual whilst yours has the company as the trigger, practically there would not emanate from the same root cause.

However, both problems applied the same principle of root cause analysis. With that being said, I don’t think the analysis was incorrectly applied.

Also, there are ten many reasons, or unclear reasons. Eg why am I poor? Could be because I don’t market enough. Or because I chose the wrong market. Or because of BOTH of those. How does 5-questions handle this?

For complicated engineering problems, for example, every step should be based on hypotehsis, and backed up by investigation testing and evidence. It is a tool to summarize the logic to reach the root cause across different processes.

Trucker hooked to empty trailer traveled 170 ft turned right then traveled 170 more ft and trailer came in latched. Driver checked latch with flashlight and says it was Latched. Why did trailer come unlatched?

maybe I’m missing something but I didn’t find either of these examples were particularly helpful nor do I think they got to the root cause. The man did not run out of gas bc he is bad at bluffing – I think the proper conclusion would be he makes bad financial decisions and shouldn’t gamble money he needs to pay his bills what should be be doing abt that?! Nor do I think we got to the root cause of the issue with the first example – the root problem is not that the Dir needs to be in the loop – many problems were identified and need to be addressed even if the Dir did not need to be informed. Changing just the last whys do not fix all the issues in either example.

Interesting article. I have not been able to find a bright line rule on when you reach the root cause. Instead, I have developed some guidelines to help team decide when to stop asking why. l would appreciate any thoughts people might have. – Cannot get information needed to answer the why – people have left the company, no records kept, problem cannot be reproduced. – Further analysis or corrective action is outside the company’s control and the source is not willing to assist. – The responsible person, with adequate information, made a business decision. – The cost of deeper analysis is not justified by the potential gains – this one is an easy way out for teams, so we ask the team to adjust its composition to ensure it contains people who could answer the question.