You are on page 1of 6

5 Whys Technique: Basics, Examples,

and Tips (updated 2023)


Deprecated: trim(): Passing null to parameter #1 ($string) of type string is
deprecated in /home2/thebusin/public_html/wp-includes/link-template.php on
line 3901

Deprecated: trim(): Passing null to parameter #1 ($string) of type string is


deprecated in /home2/thebusin/public_html/wp-includes/link-template.php on
line 3901

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, 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 reasons 5 Whys is so famous as a root cause analysis technique is
its simplicity.
Whenever an issue or a problem occurs, simply ask, “Why the problem occurred?” (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 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


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?
Because the build came only one day before the UAT timelines, and thorough
functional testing takes at least 3 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 2 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 estimations techniques and their
implementation.
Second root cause: There is an issue with the 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
problem 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 having a lot of 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 calls for you to ask your team members why the problem statement has
occurred and note their responses.

Then, 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
5 why technique depends upon the ‘cause-and-effect’ relationship, it’s imperative to
ensure that the response to every ‘Why’ does lead 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 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 among the team members while drafting the
problem statement.
3. Don’t stop at only 5 Whys and 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. It’s the process that should be evaluated and not the people. Go past
people’s mistakes and see process flaws (examine the IT example above).

You might also like