The 5 Whys technique is a deceptively simple and effective brainstorming tool for root cause analysis. Here’s how to use it…
Problems often arise in teams when trying to agree and decide what the problem actually is!
As the founder of modern management, the legendary Peter Drucker, once warned,
“The most serious mistakes are not being made as a result of wrong answers. The truly dangerous thing is asking the wrong questions.”
Strategy tools can help. Using the 5 Whys, for example, will help you find the root cause of any problem by asking the same question five times.
The origins of the 5 Whys
The 5 Whys method is part of the Toyota Production System and was developed by Sakichi Toyoda, a Japanese inventor and industrialist.
“The basis of Toyota’s scientific approach is to ask why five times whenever we find a problem … By repeating why five times, the nature of the problem as well as its solution becomes clear.“ Taiichi Ohno
One of the key factors for successful implementation of the technique is to make an informed decision. This means that the decision-making process should be based on an insightful understanding of what is actually happening in your context.
There are lots of useful free templates out there to help you with the process. MIRO has this free template where you can collaborate with team members
What does a 5 Whys look like in action?
Let’s say you’re trying to ship an app that your team has been working on. You were prepared to ship on time, but you were two days late. Here’s how you might use the 5 Whys to uncover the reason that happened and how you can avoid delays in the future.
Step 1: Start with the broadest possible question, then try to answer it. Why was the app late? It was late because there was a production delay.
Step 2: Based on this answer, you can narrow the question slightly. Why was there a production delay? There was a production delay because the engineering team had to deploy a last-minute patch, which the product team did not know about until launch day.
Step 3: Narrow the question even further, and then answer it. Why didn’t the product team know about the patch? The product team didn’t know about the patch because engineering didn’t communicate it to them.
Step 4: Keep narrowing and answering the question. Why didn’t the engineering team communicate to the product team? The engineering team didn’t communicate to the product team because they did not know how to communicate that information.
Step 5: Ask the question one last time to zero in on your solution. Why didn’t the engineering team know how to communicate to the product team? The engineering team didn’t know how to communicate to the product team because the product team has no clear point of contact or processes for communication.