Key Points

• Using the 5 Whys helps identify a root cause readily.
• You don’t need software to utilize the process.
• It is one of the simplest tools in your problem-solving toolbox.
• You don’t have to utilize all 5 Whys to get to the bottom of a problem.

Asking “Why?” may be a favorite technique of your 3-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. In many cases, it can be completed without a data collection plan.

Why Should You Ask Why?

By repeatedly asking the question “Why” (five is a good rule of thumb), you can peel away the layers of symptoms that 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; is 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

1. 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.
2. Ask Why the problem happens and write the answer down below the problem.
3. 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.
4. 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: How to Best Implement the Practice

Issues with Deliverables

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

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

Why did manufacturing build the products to a different specification than that of sales?
Because the salesperson 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.

Why does the salesperson 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).

Why does the form contain 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 the issue causing a process breakdown.

Gambling and Gas

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.

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

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

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

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

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 address. It is much quicker to come up with a system that keeps the sales director updated on recent sales or teaches a person to “bluff” a hand than it is to try to directly solve the stated problems above without further investigation.

Why Should You Use the 5 Whys?

While the question is riddled with redundancy, you might genuinely wonder about the efficacy of the 5 Whys. Simply put, there isn’t a good reason to ignore such a useful tool. Understanding when and where to use these questions allows you to hone in on a problem with relative ease.

Further, there is very little cost associated with the process. After all, you only need a sheet of paper and a little bit of free time to hammer down the problem at hand. So, why aren’t you using it?

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.

Additional Problem-Solving Tools

If you need something more involved in your problem-solving processes, why not consider the Ishikawa Diagram? This is a proven and tested tool, and our comprehensive guide covers the reasons why it is such an effective means of solving issues.

Further, if you need more convincing at least, you might want to look at how effective these methodologies are in use. This intriguing read covers how Six Sigma problem-solving tools helped reduce downtime and increase productivity at a nature conservancy’s central headquarters.

Some Parting Thoughts on the 5 Whys

If you’re in a crunch, implementing the 5 Whys can help you nail down the root cause of an issue. The fact that it doesn’t require outside data to identify the problem makes it flexible, even for smaller teams. Six Sigma practitioners owe it to themselves to learn and implement the 5 Whys for the simple sake of productivity. This methodology is the difference between getting bogged down in the details and getting your project back on track.