Sometimes people will share with you some worldview (e.g. that they like something or not, or that they think of something as good/useful/helpful or not, or that they need something to work in such and such way). You might wonder what is the reason behind it. They might give you a reason but very ofter that "justification" won't reflect the true source of the problem (the true source of one's pain).
If you want to dig and try to find the true nature of the underlying problem the five whys technique might help you.
Also, very often a given problem will not have a single root cause but instead, a whole catalogue of root causes. The five whys technique can also be helpful in such situations.
A simple example of how one can use the five whys: Customers cannot use the service.
- Why? - Server repeatedly returns a timeout error.
- Why? - Because the database server is constantly overloaded.
- Why? - Because the routing is badly configured and all traffic is redirected to a single machine.
- Why? - Because person who was responsible for creating the configuration was not aware of how to create the configuration in a correct way.
- Why? - Because the system designer team did not communicate it clearly enough to the developing team.
Boom! Now we can wonder how to improve communication between these two teams so that such situation will not occur in the future.
Remember that the "five" in five whys is not a strict rule. You may have to add the sixth or seventh why. Sometimes four whys will suffice.
When using this technique in a group you might want to pick a facilitator - a person which will be asking "Why?".
With this technique we want to follow the chain of casualty. We want to finally end up with a process - some activity which we will rule as faulty. In the example above the process which failed was a human communication within a company. When asking "Why?" you want to be careful that people do not give blunt (typical) answers such as: there was not enough time, there were not enough resources, etc. We want to stay focused on things that we can control.
Never blame people. Do not call worker's inattention or human mistake the root cause. Try to understand what could have led to it. Again - we want to find a faulty process.
When organizing a meeting make sure that key persons (which might be responsible for or participate in a process that fails) are present. You want to give a clear problem statement. What is that you would like to fix?
Like with other brainstorms or retrospectives you want to keep an atmosphere of sincereness and inclusiveness (openness). Your analysis ought to be based on identifiable facts and team's knowledge.
💡 When asking "Why?" you are given more that one reason, try voting on the most likely cause. 💡 At the end of the meeting, when the root cause has been identified you want to define countermeasures that you are going to take and also, who is going to be responsible for the realization of a given countermeasure and how will the success be measured. Also, ask yourselves how will you monitor the progress. This is where the measurability of the success comes in handy 😁.
👉 The five whys techniques is quite simple and easy to use. It should provide you with the causes of a problem, not only the observable symptoms.
👉 Also it gives the opportunity to plan actions with the identified causes taken into consideration.
🚨 This technique is only as useful as good is the experience and knowledge of people involved in the analysis. In other words, we will not be able to identify causes that we do not already know.
🚨There is always a risk that we won't ask "Why?" enough times and subsequently will not find the true root cause.
🚨With different groups of people you may end up finding a different root cause. This is linked with the limited knowledge issue.