Professional Documents
Culture Documents
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.
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 😉 )
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:
In our manufacturing example above, the conveyor belt operator, the support engineer,
the shift in charge, and the electrician should be relevant members.
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.
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.