5 Whys Technique: Basics, Examples, and Tips (updated 2023)

When faced with a lingering or reoccurring problem, what do you do?

There are 2 solutions – Try to resolve the problem and move on Or investigate and analyze it to see the real source of the problem so that it does not resurface. 5 Whys is a proven and widely used technique for ‘Root Cause Analysis’, which helps identify the cause(s) contributing to the occurrence of the problem.

Now, let’s go through the article which will help you understand:

• History of 5 Whys
• 5 Whys basics and examples
• The correct procedure to conduct the 5 Whys analysis
• 5 Whys tips & best practices

 

History of 5 Whys

The 5 Whys technique was initially invented by Sakichi Toyoda, the founder of Toyota Industries Co. and father of the Japanese industrial revolution.

However, the credit for bringing the 5 Whys to mainstream implementation goes to Taiichi Ohno, the pioneer of the Toyota Production System.

According to the Toyota company website:

Whenever a problem cropped up, Taiichi Ohno encouraged his staff to explore problems first-hand until the root causes were found. “Observe the production floor without preconceptions,” he would advise. “Ask ‘why’ five times about every matter.”

Toyota believes in the ‘go see and clarify’ approach. When an issue occurs with a manufacturing machine, the solution is not found by looking at some historical data or manual. A deduction is made by understanding the problem, questioning employees working there, inspecting them, and then making a decision.

Continuous implementation of practices like 5 Whys has made Toyota the world’s largest automaker.

Basics of 5 Whys

One of the main reasons 5 Whys is so famous as a root cause analysis technique is its simplicity.

Whenever an issue or a problem occurs, ask, “Why did the problem occur?” (at least) 5 times to the people working on it. That’s it. There are no fancy steps or acronyms and no need for memorization.

5 Whys works on the premise that “Every problem has a cause behind it,  but a superficial analysis will only depict symptoms. A persistent inquiry is required to find the real cause (the root cause) behind the issue so that lasting solutions can be taken and the problem doesn’t resurface.”

For example, Jack is sick with nausea and goes to the doctor, expecting to get medication to treat it. However, nausea is just a ‘symptom’ of the problem, and treating it does not mean we treat the real cause of nausea. The doctor’s investigations reveal that he also has a stomach ache, and further diagnosis confirms that Jack is ‘actually’ suffering from a stomach infection.

Thus, what appeared to be a problem was just a ‘symptom’ of an actual issue,  and had Jack treated only his nausea without going to the doctor, it would have resurfaced again. (Another lesson here – don’t try to be a doctor when you are not 😉 )

Understanding 5 Whys with Examples

To effectively use the 5 Whys, one should have a ‘questioning outlook’ towards problems and not take them at face value.

Example 1: Let’s take an example from the manufacturing domain.

Problem statement: The conveyor belt on the main production line has stopped

1. Why has the conveyor belt stopped?
The main pulley responsible for rotating the belt is not functioning.

2. Why is the main pulley not rotating?
Because it’s not getting enough power from the motor.

3. Why is it not getting enough power from the motor?
Because the motor has stopped working.

4. Why has the motor stopped working?
The windings of the motor had burned out.

5. Why have the windings burned out?
The motor was loaded beyond its power capacity.

6. Why was the motor overloaded?
Although there were specifications about the permitted load frequency every hour, there were no instructions about the maximum load weight.

Root Cause: So you see, we needed 6 Whys to finally decipher that the weight of the load on the motor was more than its capacity, and now we either need to replace the motor with a more powerful one or restrict the maximum load weight permitted on the conveyor belt at a time.

Example 2: Here’s another example of our Information Technology (IT) Industry.

Problem statement: During the time of User Acceptance Testing (UAT), the client observes an issue

1. Why has the client encountered the issue?
According to the Technical Lead, the testing team has not reported any such issue to the development team

2. Why the testing team was not able to catch the issue
The testing team performed only sanity testing and not complete regression testing

3. Why did the testing team perform only sanity testing?
Because they didn’t have enough time to perform thorough functional testing of the complete application

4. Why was there not enough time for thorough functional testing?
The build came only one day before the UAT timelines, and thorough functional testing takes at least three days.

5. Why was the build given only a day before the UAT?
Because the development team took more than the estimated time to resolve some bugs.

In this example, we see that there are two root causes rather than one:

First root cause: The team members couldn’t give correct estimations around their functionalities, and there is a need for training on estimation techniques and their implementation.

Second root cause: There is an issue with project management. Ideally, a code freeze should happen at least 4 days before the UAT, but here, the team was working on fixing bugs until the very last day.

Procedure to conduct 5 Whys analysis

Following are the critical steps in the overall process of conducting a thorough 5 Whys analysis:

Step 1 – Gather the relevant team members

When faced with a problem, the first logical step is to gather relevant team members. These people are working on the equipment, process, or project that is facing the situation and have encountered the problem firsthand.

In our manufacturing example above, the conveyor belt operator, the support engineer, the shift in charge, and the electrician should be relevant members.

Similarly, in the IT example above, the relevant members should be the business analyst, the technical lead, the testing lead, and the developers working on the fixes.

The rationale behind gathering every relevant member is to get a different viewpoint of the problem at hand. Every member has their way of looking at the problem, and listening to the accounts of all the people associated with it gives a 360-degree view – something vital when looking for the root cause.

In the case of a large team, a meeting ‘moderator’ or ‘facilitator’ may even be appointed to collect and analyze all the results.

Step 2 – Define the problem statement

Once the team is available, it’s time to define the problem. The scope of the issue should not be too big, or you may end up with many root causes, and it shouldn’t be too narrow, as you may end up treating another symptom.

The problem statement should be balanced and brief while clearly explaining the issue.

Taking the above example of the Conveyor belt, you should not take ‘delay in processing goods’ as the problem statement as it will be too broad of the scope, and also you shouldn’t take ‘motor failure’ as the scope shall be too narrow.

While defining the problem, you may want the individual members to explain what they feel is the issue and make a list of their responses. The team can then discuss these responses to reach a consensus on the problem statement.

Step 3 – Ask Why?

This step requires you to ask your team members why the problem statement occurred and note their responses.

Then, they keep questioning ‘Why‘ their responses have occurred.

Repeatedly. AT LEAST 4 MORE TIMES.

At each step, the answer should be noted and form the basis of the next ‘Why’; Since the 5 why technique depends upon the ‘cause-and-effect’ relationship, it’s imperative to ensure that the response to every ‘Why’ leads to a logical answer.

If you are wondering why we have to repeat asking Why at least 5 times, here’s the answer – Asking why one or two times is equivalent to just scratching the surface of the issue and treating the initial symptoms with the problem to resurface sooner. Diligently trying to probe the reason behind the answers will get you past any guesses or speculations around the problem and direct you toward the actual issue.

The ‘moderator’ or ‘facilitator’ should be careful not to go by the participant’s emotional responses but rather concentrate on those backed by facts.

For example, in the IT example above, going only by the word of the Technical Lead, it seemed as if the Testing team was at complete fault for being unable to find the bug. However, further probing unearths the issue with the team’s project management and estimation skills.

Once the actual root cause is known, it should be discussed separately to find the corrective actions and countermeasures to ensure the problems are finally tackled and will not occur again.

Advantages of the 5 Whys technique

• Encourages collaborative problem-solving
• Inculcates the feelings of openness within the team as the outlook of every member is considered
• Simple, easy to follow without requiring any statistical analysis or additional tools
• Aids in reaching amicable consensus on areas with issues rather than fault-finding or blaming individuals

Limitations of the 5 Whys technique

• 5 Whys is a time-consuming technique and involves deep probing and thorough evaluation of all the facts
• 5 Whys cannot be done in isolation and need the availability of the associated team members
• Sometimes, it’s not possible to isolate a single root cause through this technique
• The facilitators should be experienced enough to be able to ask the ‘right’ Why question
• The success of this technique depends upon its participants, i.e., if relevant people are not available, the remaining group may not be able to find the correct answer to the Why question.

5 Whys Technique – Tips and Best Practices

1. Never tackle the root cause alone; independently, you will never be able to reach the very crux of the problem.
2. Ensure there is a consensus among the team members while drafting the problem statement.
3. Don’t stop at only 5 Whys; see if the problem can still be broken down. More complex issues might require further investigations.
4. The technique should also be used in conjunction with other methods where quantitative data can validate the findings of 5 Whys.
5. The process should be evaluated, not the people. Look past people’s mistakes to see process flaws (examine the IT example above).

FREE KIT DOWNLOAD: Get BA Documents Template Toolkit!!

Our free Template Toolkit contains the following professional, pre-formatted, and ready-to-use Business Analyst Document templates:

• Use Case Document Template
• Requirement Traceability Matrix (RTM) Template
• Requirement Management Plan Template
• Project Vision Document Template
• Test Case Template