Funny Ideas for Root Cause Analysis

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 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 helps you understand:

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

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 reasons 5 Whys is so popular 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, acronyms, and there is 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 – 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

In order to effectively use 5 Whys, one should have a 'questioning outlook' towards problems and not take them at their 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), 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 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 take 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 resolving some bugs.

In this example, we see that there are 2 root cause 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 as 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 key 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 are the people who 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 to the problem gives a 360-degree view – something vital when looking for the root cause.

In Case of a lasrge 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 actual problem. 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 you may end up treating another symptom.

The problem statement should be balanced and brief while clearly explaining 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 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, question 'Why' their responses have occurred.

Repeatedly. AT LEAST 4 MORE TIMES.

At each step, the answer should be noted 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 backed by proof.

If you are wondering why we have to repeat 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  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 participants emotional responses, rather concentrate on those that 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 was at complete fault for 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 known, then it should be discussed separately to find the corrective actions and countermeasure to ensure the problems are 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 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 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 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 methods 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)

hobbsorwastincer.blogspot.com

Source: https://thebusinessanalystjobdescription.com/5-whys-technique-basics-examples-and-tips/

Share this post