Every so often, unexpected events occur in project management. Wires get crossed, systems break, and legacy processes don’t live up to current expectations. When things don’t go according to plan, there’s a simple yet powerful technique to quickly discover the root of the problem: the 5 Whys. Using the 5 Whys, Lean teams can:
- Move past blame
- Think beyond the specific context of a problem
- Identify a proper, sustainable solution to resolve the issue
Origin of the 5 Whys
One of the early pioneers of Lean thinking and the architect of the Toyota Production System in the 1950s, Taiichi Ohno, discusses the 5 Whys of Lean in his book, Toyota Production System: Beyond Large-Scale Production. Ohno introduces the idea as “the basis of Toyota’s scientific approach … by repeating why 5 times, the nature of the problem as well as the solution becomes clear.”
How the 5 Whys Help Teams
The 5 Whys are helpful for many reasons. By conducting a root cause analysis, the 5 Whys allow you to identify lasting solutions, rather than settling for temporarily “patching up” problems, which can lead to a mountain of technical debt.
If your teams are already practicing and thinking Lean, the 5 Whys provide an opportunity to naturally diagnose and eliminate sources of waste. Teams can think beyond the specific context of an issue to see even greater opportunities for improvement.
Using the 5 Whys, Lean teams can shift the focus away from blaming the person “responsible” for an issue and focus instead on improving the process itself.
Getting Started with the 5 Whys
Getting started with the 5 Whys of Lean is simple: Identify a problem facing your team and ask, “why is this problem happening?” Record the answer and repeat the process four more times or until your answers become absurd. When your answers become absurd, it’s time to find a solution, no matter how small, to improve the process and prevent the issue from recurring.
Some experts and Lean practitioners recommend appointing a 5 Whys master: Someone who will run the post-mortem discussion, ask why five times, and assign the solutions to the team members. Other teams find it helpful to take turns facilitating 5 Whys discussions. Your team may decide not to implement formalized 5 Whys of Lean discussions, rather choosing to build the 5 Whys into daily conversations about work.
Remember that this simple, easy-to-remember thinking tool is always available whenever you are facing a problem without a clear solution. Pausing to reflect on the 5 Whys could save your team time, effort, and frustration, while helping you identify sustainable solutions to your persistent problems.
The 5 Whys in Action
Here’s a real-life example of how one organization used the 5 Whys of Lean to solve a problem. A mobile development team had a problem in which all delivery tasks were manual, making delivering bug fixes to Quality Assurance incredibly time-consuming. Here’s how they proceeded to use the 5 Whys:
The Problem: Delivering bug fixes to Quality Assurance is hard.
Why? — It’s time-consuming to produce new application release candidates.
Why? — Build steps need careful attention.
Why? — If you make a mistake, you must start all over again.
Why? — There’s a specific build sequence for delivering successful release candidates.
Why? — That’s how mobile platforms work.
Why? — Because…
If the team hadn’t worked through the 5 Whys of Lean, they may have prematurely decided that the people on the team responsible for delivering bug fixes weren’t moving quickly enough.
In reality, the work they were responsible for was tedious, repeatable, and prone to human error and a perfect candidate for automation. The team decided to automate the process of delivering bug fixes to Quality Assurance, drastically reducing lead time and improving work quality and morale.
The 5 Whys of Lean should be performed by a cross-functional team, not completed by one person. The team should include members who are familiar with the process and willing to respond with facts or data rather than an emotional response. The goal is to arrive at the root cause of the problem, rather than treating symptoms. This not only creates continuous improvement opportunities but gives teams confidence that they can solve problems with better processes.