When faced with a persistent or recurring problem, what do you do?
There are 2 solutions – Try to fix the problem and move on OR investigate and analyze to see the true source of the problem so that it does not appear again.5 Why is a proven and widely used technique for 'Root Cause Analysis' which helps to identify the causes that contribute to the occurrence of the problem.
Now, let's see the article that helps you understand:
- Story of the 5 whys
- 5 basic whys and examples
- The correct procedure to carry out the analysis of the 5 whys
- 5 Why tips and best practices
Story of the 5 whys
The 5 Whys technique was originally invented by Sakichi Toyoda, the founder ofToyota IndustriesCo. and father of the Japanese industrial revolution.
However, credit for bringing the 5 Whys to mainstream implementation goes to Taiichi Ohno, pioneer of the Toyota Production System.
According to the Toyota company website:
Whenever a problem arose, Taiichi Ohno encouraged his team to explore the problems firsthand until they found the root causes. "Observe the factory floor without prejudice," he advised. "Ask 'why' five times on each topic."
Toyota believes in'go see and clarify'getting closer. When a problem occurs with a manufacturing machine, the solution is not found in some historical or manual data. An inference is made by understanding the problem, asking questions of the people who work there, inspecting it, and then making a decision.
Continuous implementation of practices like the 5 Whys has made Toyota the world's largest automaker.
Principles of the 5 whys
One of the main reasons why the 5 Whys are so popular as a root causeanalysis techniqueit's yourssimplicity.
Whenever a problem or problem occurs, simply ask "Why did the problem occur?" (at least) 5 times for the people who work on it. Is that. There are no complicated steps, no acronyms, and no memorization required.
5 Why work with the premise that“Every problem has a cause behind it, but a superficial analysis will only show symptoms. Persistent investigation is needed to find the real cause (root cause) behind the problem so that lasting solutions can be taken and the problem does not re-emerge.”
For example, suppose Jack is sick with nausea and goes to the doctor while waiting to receive medication to treat his nausea. However, nausea is only a "symptom" of the problem and treating it does not mean treating the actual cause of nausea. The doctor's investigations reveal that he, too, has a stomach ache, and a later diagnosis confirms that Jack "really" is suffering from a stomach infection.
So what seemed to be a problem was just a "symptom" of a real problem, and if Jack had treated his nausea without going to the doctor, it would have flared up again. (Another lesson here: don't try to be a doctor when you're not 😉)
Understanding the 5 whys with examples
To use the 5 Whys effectively, one must take a “questioning perspective” on issues and not take them at face value.
Example 1: Let's take an example from the manufacturing domain.
Problem Statement: The conveyor belt of the main production line has stopped.
1. Why did the conveyor belt stop?
The main pulley in charge of rotating the belt does not work
2. Why doesn't the main pulley turn?
Because it's not getting enough power from the engine.
3. Why doesn't it get enough power from the engine?
Why did the motor stop working?
4. Why did the motor stop working?
The motor windings had burned out.
5. Why did the windings burn out?
The engine has been loaded beyond its power capacity
6. Why was the motor overloaded?
While there were specifications on the frequency of charging allowed per hour, there were no instructions on the maximum charging weight.
Primary cause:You see, we needed the 6 Whys to finally figure out that the load weight on the motor was greater than its capacity, and now we need to either replace the motor with a more powerful one or restrict the maximum load weight allowed on the belt at one time.
Example 2: This is another example from our information technology (IT) industry.
Problem Statement: During the User Acceptance Test (UAT) time, the client notices a problem
1. Why did the customer find the problem?
According to the technical lead, the test team did not report such issues to the development team.
2. Why the test team could not identify the problem
The test team only performed sanity testing and not full regression testing.
3. Why does the test team only perform sanity tests?
Because they didn't have enough time to perform full functional tests of the entire application.
4. Why was there not enough time to perform full functional tests?
Because the build arrived just one day before the UAT deadlines and the full functional test takes at least 3 days.
5. Why was the build only given one day before UAT?
Because the development team took more time than estimated to fix some bugs.
In this example, we see that there are 2 main causes instead of one:
First root cause:Team members were unable to give correct estimates of its functionality, which required training in estimation techniques and their implementation.
Second root cause:There is a problem with project management, as ideally a code freeze should happen at least 4 days before UAT, but here the team was working on bug fixes until the last day.
Procedure to carry out the analysis of the 5 whys
The following are key steps in the overall process of conducting a comprehensive 5 Whys analysis:
Step 1: Gather relevant team members
When faced with a problem, the first logical step is to bring together the relevant team members. These are the people who are working on the team, process, or project that is experiencing the problem and have encountered it firsthand.
In our manufacturing example above, the conveyor operator, support engineer, shift manager, and electrician must all be relevant members.
Similarly, in the IT example above, the relevant members should be thebusiness analyst, the technical lead, the test lead, and the developers working on fixes.
The logic behind bringing all the relevant members together is to get a different point of view on the issue at hand.Each member has their own way of looking at the problem and listening to reports from everyone associated with the problem gives a 360 degree view, which is critical when looking for the root cause.
In the case of a large team, you can even appoint a 'moderator' or 'facilitator' of the meeting to collect and analyze all the results.
Step 2 – Define the problem statement
Once the equipment is available, it is time to define the real problem. The scope of the problem shouldn't be too large, or you might end up having too many root causes, and it shouldn't be too narrow, or you might end up treating another symptom.
The problem statement should be balanced and brief, clearly explaining the problem being addressed.
Taking the conveyor belt example above, you should not consider 'goods processing delay' as the problem statement as that will be too broad in scope, and you should not consider 'motor failure' as the scope either, as which should be too wide. narrow.
When defining the problem, you may want each member to explain what they think the problem is and list 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 write down their responses.
Then ask 'Why' your responses occurred.
Repeatedly. AT LEAST 4 TIMES MORE.
At each step, the answer should be noted and should form the basis of the following 'Why'; Since the 5 Whys technique is based on the "cause and effect" relationship, it is imperative to ensure that the answer to each "why" is a logical answer supported by evidence.
If you are wondering why we have to repeat the Why question at least 5 times, here is the answer:Asking why once or twice is tantamount to scratching the surface of the problem and treating the initial symptoms so that the problem returns sooner. Diligently trying to investigate the reason behind the answers will help you get past any assumptions or speculation about the problem and direct you towards the real problem.
The 'moderator' or 'facilitator' should be careful not to get carried away with the emotional responses of the participants, focusing instead on those that are supported by facts.
For example, in the TI example above, just taking the technical lead at his word, it seemed like the test team was dead wrong in not being able to find the bug. However, further investigation reveals the real problem with project management and team estimation skills.
Once the actual root cause is known, it should be discussed separately to find the corrective actions and countermeasures to ensure that the problems are finally resolved and do not occur again.
Advantages of the 5 whys technique
- Encourages collaborative problem solving
- Instills feelings of openness within the team as each member's perspective is considered.
- Simple, easy to follow, no statistical analysis or additional tools required
- It helps to come to an amicable consensus on problem areas instead of finding fault or blaming people.
Limitations of the 5 Whys Technique
- 5 Whys is a time-consuming technique that involves in-depth research and thorough evaluation of all the facts.
- The 5 Whys cannot be done in isolation and need the availability of associated team members.
- Sometimes it is not possible to isolate a single root cause through this technique.
- Facilitators must be experienced enough to be able to ask the "right" question. Why?
- The success of this technique depends on its participants, that is, if the relevant people are not available, the rest of the group may not be able to find the correct answer to the Why question.
5 Whys Technique: Tips and Best Practices
- Never tackle the root cause alone, because you can never get to the core of the problem independently.
- Make sure there is consensus among team members when writing the problem statement
- Don't stop at just 5 whys and try to see if the problem can still be solved. More complex issues may require additional investigation.
- The technique should also be used in conjunction with other methods where the 5 Whys findings can be validated using quantitative data.
- It is the process that should be evaluated and not the people. Ignore people's mistakes and you'll see process failures (look at the IT example above)