Root Cause Analysis - The 5 Whys Technique

Over a series of previous posts, we've learned to define problems, understand customer value, map processes, identify waste, measure performance, and observe reality by observing the process where the work is done.

Now it’s time to put everything we’ve learned together and get to the heart of the matter: understanding why problems occur in the first place.

The Symptom vs. Root Cause Trap

Here's a plausible scenario: A process experiences frequent equipment breakdowns. The team's solution? Hire more maintenance technicians so breakdowns can get fixed faster.

Problem solved, right? Not quite. Fast forward six months and breakdowns are still happening at the same rate. We've just gotten faster at responding to fires and failed to address the reasons the fires start in the first place.

This is a classic mistake: treating symptoms instead of root causes. We're exceptionally good at this in organizations. Something goes wrong, and we immediately jump to a solution that addresses what we see happening, not what's causing it to happen.

Root cause analysis is the discipline of asking "why" until we get to the real problem and move beyond visible symptoms.

The 5 Whys Technique

Developed by Taiichi Ohno at Toyota, the 5 Whys is deceptively simple: when a problem occurs, ask "why" five times (or until you reach the root cause—it might be three whys, it might be seven).

Example: Late Project Deliveries

Problem: Our projects are consistently delivered late.

Why? → Because we miss key milestones during the project.

Why do we miss milestones? → Because unexpected issues arise that we didn't plan for.

Why didn't we plan for these issues? → Because our project planning sessions don't include input from all departments.

Why don't all departments participate in planning? → Because we schedule planning meetings during times when key people have conflicts.

Why do we schedule at conflicting times? → Because we don't have a shared calendar system and don't check availability before scheduling.

Root Cause: Lack of coordinated scheduling system preventing cross-functional input during planning.

Notice what happened? We started with "projects are late" and discovered the real issue was calendar management. If we'd jumped to the obvious solution ("hire a project manager to track deadlines better"), we would have missed the root cause entirely.

5 Tips on How to Conduct Effective 5 Whys Analysis

1. Start with a Specific Problem
Not: "Quality is bad"
Better: "15% of orders from the Northeast region contained shipping errors last month"

2. Assemble the Right Team
Include the people who do the work and understand the process. Don’t do the analysis in isolation or with people far removed from the problem.

3. Focus on Process, Not People
Bad: "Why was the form filled out wrong?" → "Because Sarah didn't pay attention"
Good: "Why was the form filled out wrong?" → "Because the form instructions are confusing"

4. Use Data When Possible
"Why do we have defects?" → "Because we think quality is slipping" (weak)
"Why do we have defects?" → "Because percent-complete-and-accurate (%CA) dropped from 95% to 82% over three months" (strong)

5. Verify the Root Cause
Once you think you've found it, test your logic: "If we fix THIS, will it prevent the problem from recurring?" If yes, you've likely found the root cause.

Common Pitfalls to Avoid

Stopping Too Soon
"Why are orders late?" → "Because shipping is backed up"
Many people stop here. Keep going! Why is shipping backed up?

Multiple Root Causes
Sometimes a problem has multiple contributing causes. That's fine—map them all. The 5 Whys can branch like a tree.

Jumping to Solutions
Resist the urge to solve each "why" as you go. Document the full chain first, then address the root cause(s).

Accepting Vague Answers
"Why?" → "Because of communication issues"
What specifically about communication? Which information? Between whom? When?

Beyond the 5 Whys: Other Root Cause Tools

The 5 Whys is just one tool in the root cause analysis toolkit. Lean practitioners also learn:

• Fishbone (Ishikawa) Diagrams - Visual tool for exploring categories of causes
• Pareto Analysis - Identifying the "vital few" causes among the "trivial many"
• Failure Mode and Effects Analysis (FMEA) - Proactive identification of potential failures
• A3 Problem Solving - Structured one-page approach combining multiple tools

Each has its place depending on problem complexity and context.

The Real Power: Prevention vs. Reaction

Here's why root cause analysis matters: Every minute spent finding the root cause saves hours of fighting symptoms.

When we fix root causes:

• Problems don't recur (we're not constantly firefighting the same issues)
• Solutions are more cost-effective (addressing one root cause vs. many symptoms)
• Organizational learning occurs (we understand our systems better)
• Employee frustration decreases (people aren't constantly fixing the same problems)

When we only fix symptoms:

• The same problems keep coming back in slightly different forms
• We waste time and money on temporary fixes
• We create a culture of heroic firefighting instead of prevention
• People become cynical ("nothing ever really changes here")