5 Whys

The 5 Whys is a method for finding the root cause of a problem by repeatedly asking "Why?" until the underlying issue is revealed. The best starting question about the late project was "Why was the project late?" because it's a specific, blame-free inquiry into the process, which is the heart of this technique. For example, if your phone keeps dying (the problem), you might ask "Why?" until you discover the root cause isn't just a bad battery (a symptom), but a faulty charging port that's damaging new batteries.

Try this: The next time a small problem occurs, ask "Why?" at least three times to look past the initial symptom.

The 5 Whys technique is a simple, structured process for moving past symptoms to uncover a root cause. To ensure a thorough and unbiased analysis, it is best to follow an explicit procedure.

Here is a step-by-step guide to running a 5 Whys session:

1. Assemble a Team and Define the Problem. Gather people who are familiar with the specific problem. Agree on a clear, factual problem statement (e.g., "The latest software release was delayed by one week.").
2. Ask the First "Why?" Ask the team, "Why did this happen?" The answer should be a direct, factual cause, not a guess. Validate it with data if possible.
3. Continue Asking "Why?" Use the answer from the previous step to frame the next question. This creates a direct causal link at each step, preventing you from jumping to unfounded conclusions.
4. Identify a Process-Level Root Cause. The goal is to continue until you identify a foundational process or system that failed, not to stop at a person or a superficial technical issue. The number '5' is a guideline; the key is to go deep enough to find a cause you can truly fix.
5. Define and Assign Countermeasures. Once the root cause is identified, the team should agree on specific actions to prevent the problem from recurring. Assign an owner and a deadline to each action for accountability.

For example, let's revisit the late project:

• Why was the project late? Because the final testing phase took an extra week. (Step 2)
• Why did testing take an extra week? Because major bugs were discovered late in the process. (Step 3)
• Why were they discovered so late? Because a new software module wasn't properly integrated. (Step 3)
• Why wasn't it integrated properly? Because no specific integration testing was included in the project plan. (Step 4: A process root cause)

The solution (Step 5) would be to update the project planning template to include mandatory integration testing.

The 5 Whys technique originated as a critical component of the Toyota Production System (TPS), designed to promote a scientific, evidence-based approach to problem-solving on the factory floor. It forces a team to trace a problem back to a flaw in a process or system, rather than stopping at superficial technical glitches or human error. Its modern application in agile and lean startup methodologies has broadened its use to product development, management, and organizational learning.

• Taiichi Ohno (1988), a key architect of the TPS, described the 5 Whys as a fundamental practice for making problems visible and ensuring that countermeasures addressed true causes, not just symptoms. [1]
• Eric Ries (2011) popularized the 5 Whys for modern tech startups, framing it as a tool to conduct 'blameless postmortems' that turn failures into learning opportunities and prevent recurring issues. [2]
• Olivier Serrat (2017) notes that while effective for simple to moderately difficult problems, the 5 Whys can be limiting for complex issues where multiple factors interact, as it tends to guide investigators down a single, linear path of inquiry. [3]

While powerful in its simplicity, the 5 Whys has several limitations:

• It tends to identify a single causal path, which can be misleading for complex problems where multiple factors contribute to the outcome.
• The results are highly dependent on the knowledge and persistence of the people involved. Different teams may arrive at different root causes for the same problem.
• There's a risk of stopping too soon, identifying a symptom or a person as the cause (e.g., "Dave made a mistake") instead of pushing further to find the process failure that allowed the mistake to happen (e.g., "Why was the training on the new system inadequate?").