5 Whys Technique: Basics, Examples and Tips

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

There are 2 solutions – Just try to resolve the problem and move on Or investigate and analyze to see what is 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.

This article takes you through the history of 5 Whys, its basics and examples, the correct procedure to conduct 5 Whys analysis and some tips & best practices on 5 Whys.

 

History of 5 Whys

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

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

According to 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 ‘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, asking questions to people working there, inspecting 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 reason why 5 Whys is so popular as a root cause analysis technique is its simplicity.

Whenever an issue or a problem occurs, just ask “Why the problem occurred?” (at least) 5 times to the people working on it. That’s it. There are no fancy steps no acronyms and there is no need for any 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 – Let’s consider Jack is sick with nausea and goes to the doctor while expecting to get medication to treat nausea. However, nausea is just a ‘symptom’ of the problem and treating it does not mean we treat the real cause of nausea. Investigations by the doctor reveal that he has a stomach ache as well 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

Implementation of 5 Whys depends upon a questioning outlook towards problems and not taking them at their face value.

 

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

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

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

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) an issue is observed by the client

1. Why has the issue been encountered by the client?
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 testing team performed only sanity testing?
Because they didn’t have enough time to perform a thorough functional testing of the complete application

4. Why there was not enough time for thorough functional testing?
Because the build came only one day before the UAT timelines and thorough functional testing take at least 3 days.

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

In this example, we see that there are 2 root cause rather than one:

First root cause: The team members are not able to give correct estimations around their functionalities and there is a need for training on estimations techniques and their implementation.

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

 

Procedure to conduct 5 Whys analysis

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

 

Step 1 – Gather the relevant team members

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

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

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

The rationale behind gathering every relevant member is to get a different viewpoint of the problem at hand. Every member has his or her own way of looking at the problem and listening to the accounts of all the people associated to the problem gives a 360-degree view – something very important when looking for the root cause.

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

 

Step 2 – Define the problem statement

Once the team is available, it’s time for the actual problem to be defined. The scope of the problem should not be too big or you may end up having a lot of root causes and it shouldn’t be too narrow as well as you may end up treating another symptom.

The problem statement should be balanced and brief while giving a clear explanation of the issue being faced.

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 as it shall be too narrow.

While defining the problem you may want the individual members to define what they feel is the issue and make a list of their responses. These responses can then be discussed to reach a consensus on the problem statement.

 

Step 3 – Ask Why?

This step calls on for you to ask your team members why the problem statement has occurred and note down their responses.

Then, question ‘Why’ their responses have occurred.

Repeatedly. AT LEAST 4 MORE TIMES.

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

If you are wondering why we have to repeat the process of asking Why at least 5 times, here’s the answer – Asking a 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 each of the answers will get you past any guesses or speculations around the problem and direct you towards the actual issue.

The ‘moderator’ or ‘facilitator’ should be careful not to go by the emotional responses of the participants but concentrate on responses which are 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 is at complete fault of not being able to find the bug. However, further probing unearths the actuals issue with the project management and estimation skills of the team.

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

 

Advantages of 5 Whys technique

  • Encourages collaborative problem solving
  • Inculcates the feelings of openness within the team as the outlook of each and every member is considered
  • Simple, easy to follow process 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 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 is dependent 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 do root cause alone as independently you will never be able to reach the very crux of the problem
  2. Ensure there is a consensus of the team members while drafting the problem statement
  3. Don’t stop at only 5 Whys and try to see if the problem can still be broken down. More complex problems might require further investigations.
  4. The technique should also be used in conjunction with other techniques where the findings of 5 Whys can be validated by quantitative data
  5. It’s the process that should be evaluated and not the people. Go past people mistakes and you will see process flaws (examine the IT example above)

Wind-Up

5 Whys is a straightforward technique for root cause analysis that is elementary yet immensely effective. If done with the right set of participants it will lead to the discovery of faulty process and procedures and will help tackle the actual causes rather than just symptoms.

Remember – “People do not fail, processes do”