Process Improvement

The 5 Whys: Stop Fixing Symptoms

Learn how small-business owners and managers can use the 5 Whys to move beyond employee blame, uncover root causes, improve processes, and prevent recurring problems.

Bobby Walls 12 min read

Small businesses rarely have dedicated Lean teams, quality engineers, or continuous-improvement departments. That does not mean the methods developed in sophisticated manufacturing organizations are out of reach. Some of the most useful ones require little more than time, curiosity, and a willingness to keep investigating after the obvious answer appears.

One of my favorites is the 5 Whys.

The First Answer Is Usually the Symptom

When something goes wrong in a business, there is a natural desire to resolve it quickly.

A customer received the wrong product.

An invoice went out with the wrong price.

A machine was not maintained.

Someone entered the wrong quantity into the ERP system.

The first explanation is often about a person:

  • “The operator made a mistake.”
  • “The employee forgot.”
  • “The supervisor did not catch it.”
  • “They entered the wrong information.”

Then comes the corrective action:

Problem → Find person → Retrain person → Move on

The problem is that this often explains what happened, not why the system allowed it to happen.

In manufacturing and operations, I have seen how easy it is to correct the immediate problem and move on. The shipment gets fixed. The customer is taken care of. The employee is reminded of the procedure.

Everyone gets back to work.

Then the problem happens again.

A better approach is:

Problem → Understand process → Identify contributing conditions → Correct the system → Verify the improvement

That is where the 5 Whys becomes useful.

Where the 5 Whys Came From

The 5 Whys is closely associated with Taiichi Ohno and the development of the Toyota Production System. Toyota's own history credits Ohno, a former executive vice president, with translating the concepts behind Just-in-Time and jidoka into automobile manufacturing as the Toyota Production System developed through repeated experimentation beginning in the late 1940s and early 1950s.

There is some variation in how the method's origin is described. The American Society for Quality credits Sakichi Toyoda with developing the basic questioning technique, while the Lean Enterprise Institute centers its explanation on Taiichi Ohno's use and teaching of it within Toyota. Rather than pretending the historical attribution is perfectly clean, I think the important point is that repeated “why?” questioning became firmly associated with Toyota's approach to understanding problems instead of simply patching them.

“The basis of Toyota's scientific approach is to ask why five times whenever we find a problem.”

— Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, as quoted and referenced by Alan J. Card in BMJ Quality & Safety

But there is nothing magical about the number five.

The Lean Enterprise Institute explicitly notes that the point is not to ask exactly five times. Its discussion of Ohno's method describes analyses taking three questions in some cases and eight in others. The American Society for Quality similarly says it may take fewer or more than five.

The purpose is to follow a causal chain far enough that you reach something actionable.

Consider a Wrong-Part Problem

Imagine a 50-person manufacturer discovers that a customer received a product containing the wrong component.

Problem: The wrong component was installed.

Why #1: Why was the wrong component installed?
Because the assembler selected the wrong part.

This is where a weak investigation can end.

The employee made the mistake. Retrain the employee. Problem solved.

Except it probably is not.

Why #2: Why did the assembler select the wrong part?
Because two visually similar components were stored next to each other.

Why #3: Why were similar components stored together?
Because storage locations were organized primarily around available shelf space rather than mistake prevention.

Why #4: Why was there no other control preventing the mistake?
Because the work instruction listed a part number but provided no easy visual method for verifying the component.

Why #5: Why did the process depend entirely on the assembler recognizing the correct part?
Because the process had never been designed around mistake-proofing.

Now we have a very different problem.

The symptom-focused response might have been:

  • Counsel the employee.
  • Retrain the assembler.
  • Remind everyone to check part numbers.
  • Tell supervisors to be more careful.

A system-focused response might include:

  • Physically separating confusing components.
  • Improving labels or color coding.
  • Adding photographs to work instructions.
  • Changing the kitting process.
  • Barcode-scanning parts before installation.
  • Adding a mistake-proofing, or poka-yoke, mechanism.
  • Monitoring future defects to determine whether the changes worked.

Notice the difference.

Retraining one assembler primarily protects us from that assembler making that mistake again.

Redesigning the process protects us regardless of who performs the job.

Toyota's current description of the Toyota Production System still emphasizes this idea of designing quality into the process. Under jidoka, abnormalities should be detected and production stopped so defects do not continue downstream, with improvement directed toward preventing recurrence.

That is a much more powerful management objective.

Deming Takes the Idea Further

The 5 Whys fits naturally with the management philosophy of W. Edwards Deming, even though it is not Deming's tool.

Deming urged managers to think in terms of systems. His System of Profound Knowledge specifically includes “appreciation for a system,” alongside knowledge of variation, theory of knowledge, and psychology.

His fifth Point for Management says:

“Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.”

— W. Edwards Deming, Out of the Crisis

The management implication is significant.

If the same failure routinely happens with different employees, changing employees is unlikely to fix it.

If three warehouse workers make the same picking error, perhaps we have a picking-system problem.

If multiple salespeople enter orders incorrectly, perhaps we should examine the software interface, required fields, training, workflow, or information available when the order is entered.

If operators routinely skip a procedure to keep production moving, perhaps we should understand what production pressures or process design make following the procedure difficult.

One question I think managers can use almost anywhere is:

What would I change if I knew a different employee would be doing this job tomorrow?

That question forces us to look beyond the individual.

Accountability and Systems Thinking Are Not Opposites

None of this means employees are never responsible for their actions.

That would be just as simplistic as blaming the employee for everything.

There is an important distinction between an unintentional mistake, knowingly taking an unreasonable risk, and deliberately disregarding a rule or responsibility. The Just Culture framework used by the U.S. Agency for Healthcare Research and Quality makes essentially this distinction between human error, at-risk behavior, and reckless behavior, with different management responses for each.

Good management can hold people accountable and examine the system.

Those ideas are not contradictory.

The question is not, “Was a person involved?”

Of course a person was probably involved.

The better questions are:

  • Was the correct action clear?
  • Was it practical?
  • Was the necessary information available?
  • Was the employee trained?
  • Did the process make an error unusually easy?
  • Could the system have detected that error before it reached the customer?

That is systems thinking without abandoning accountability.

Blame Can Make Problems Harder to See

There is another reason to be careful about immediately searching for someone to blame.

You may teach employees not to tell you about problems.

  1. Edwards Deming's eighth Point for Management is remarkably direct:

“Drive out fear, so that everyone may work effectively for the company.”

— W. Edwards Deming

Research on psychological safety gives that principle additional support. In Amy Edmondson's influential study of 51 work teams in a manufacturing company, psychological safety was associated with team learning behavior. Her definition focused on a shared belief that the team is safe for interpersonal risk-taking.

A blame-heavy environment creates exactly the wrong incentives.

People learn to:

  • Fix mistakes quietly.
  • Avoid reporting near misses.
  • Protect themselves.
  • Avoid experimenting.
  • Explain away problems.
  • Tell management what they think management wants to hear.

This is not just theoretical. The Institute for Healthcare Improvement notes that fear of punishment, reputational harm, or being seen negatively can discourage people from speaking up about unsafe conditions. Its recommended response is to focus improvement work on the event and the system instead of automatically singling out an individual.

For me, the management lesson is straightforward: someone who reports a problem may be giving you valuable information about your system.

Do not teach that person to keep quiet next time.

How to Run a 5 Whys Session

You do not need consultants or special software.

1. Define the Problem Precisely

Avoid:

“Shipping is terrible.”

Instead:

“Seven customer orders shipped after their promised date last month.”

Specific problems are easier to investigate.

2. Go Where the Work Happens

Toyota calls this genchi genbutsu, essentially going to the actual place and observing actual conditions. Toyota describes thorough observation as bringing hard data together with personally seeing and understanding the situation.

Talk to the people doing the job.

Look at the screen they use. Walk through the warehouse. Watch the machine run.

Do not conduct the entire investigation around a conference table.

3. Ask Why the Condition Occurred

Then write down the answer.

Do not jump immediately to solutions.

4. Test the Answer

Ask:

What evidence tells us this is true?

A 5 Whys analysis built on assumptions simply digs deeper into an assumption.

The American Society for Quality's broader root-cause-analysis guidance similarly emphasizes describing the problem, collecting and analyzing data, identifying possible causes, evaluating them, and then implementing corrective action.

5. Do Not Stop at “Human Error”

“Employee forgot.”

“Operator was not careful.”

“Supervisor missed it.”

These can describe what occurred. They do not necessarily explain why it occurred.

Treat them as reasons to keep investigating.

The Lean Enterprise Institute makes precisely this warning: when a 5 Whys exercise ends at an employee failing to follow a standard, the investigation can easily turn the worker into the scapegoat rather than discovering why the process permitted the failure.

6. Find Something Management Can Change

Eventually, you should be examining things such as:

  • Process design.
  • Equipment.
  • Layout.
  • Workload.
  • Scheduling.
  • Instructions.
  • Software.
  • Permissions.
  • Training design.
  • Supplier controls.
  • Quality checks.
  • Incentives.
  • Management decisions.

Those are things you can improve.

7. Implement a Countermeasure

A countermeasure changes the conditions that contributed to the problem.

“Remind everyone to be careful” usually does not.

8. Verify the Result

This part gets skipped surprisingly often.

Did defects actually decrease?

Did late shipments stop?

Did the problem move somewhere else?

If it continues, your supposed root cause may not have been a root cause after all.

Before You Blame the Employee, Ask These Questions

This is the checklist I would put next to every supervisor's desk:

  1. Was the correct method clearly defined?
  2. Was the employee properly trained?
  3. Was the right information available when it was needed?
  4. Could two reasonable people interpret the instruction differently?
  5. Did the process make the wrong action easier than the right one?
  6. Were workload or scheduling pressures contributing?
  7. Could the system detect the mistake before it reached the customer?
  8. Has this happened to other employees?
  9. What could we change so this error becomes harder to make next time?
  10. What part of this system is management responsible for?

Only after asking those questions would I be comfortable concluding that the problem is primarily the individual.

When the 5 Whys Is Not Enough

The simplicity that makes the 5 Whys useful is also its greatest weakness.

Alan J. Card, writing in the peer-reviewed journal BMJ Quality & Safety, cautioned that the method can oversimplify complex events by driving investigators toward a single causal path and apparent root cause.

That is an important criticism.

Real failures can have multiple interacting causes. The person asking the questions also influences which causal path gets followed. Lean practitioners themselves caution that 5 Whys analyses can remain superficial, run in circles, or produce process changes without adequately testing the underlying assumptions.

I would be especially reluctant to rely on the 5 Whys alone when:

  • Safety is involved.
  • Regulatory compliance is involved.
  • Consequences are financially significant.
  • The evidence is unclear.
  • Several causal chains interact.
  • The failure is technically complex.
  • Corrective actions have already failed.

That is when the toolbox needs to become larger.

Depending on the problem, that might mean an Ishikawa or fishbone diagram, Pareto analysis, A3 problem solving, Failure Mode and Effects Analysis, fault-tree analysis, statistical process control, or a more formal root-cause investigation.

The 5 Whys is a starting tool, not a miracle tool.

Its real value is teaching a habit:

Do not confuse the first plausible explanation with the cause.

Better Questions Are a Competitive Advantage

Large corporations can employ Lean specialists, Six Sigma professionals, quality engineers, industrial engineers, data analysts, and entire continuous-improvement departments.

A 40-person company probably cannot.

But the smaller company has another advantage.

It can often get the owner, supervisor, operator, quality person, and warehouse employee standing around the same process tomorrow morning.

And asking “Why did this happen?” costs almost nothing.

The methodology may come from world-class manufacturing, but you do not need to be Toyota to use the thinking behind it.

The strongest managers are not necessarily those who become exceptionally good at finding who made the mistake. They become good at creating processes where yesterday's mistake is less likely to happen tomorrow.

That is a much more durable form of management.

Try This Monday Morning

Pick one recurring problem in your company.

Better yet, choose one you have already “fixed” at least twice.

Do not choose your biggest problem. Do not choose the most politically sensitive one. Choose something manageable.

Then:

  1. Bring together 2–4 people who actually participate in the process.
  2. Write down exactly what happened.
  3. Ask the first Why.
  4. Write down the answer.
  5. Ask what evidence supports that answer.
  6. Ask why that condition existed.
  7. Follow additional causal branches when the evidence suggests more than one.
  8. Continue until you identify something in the process that management can realistically change.
  9. Implement one small countermeasure.
  10. Define how you will know whether it worked.
  11. Review the results after a period appropriate to that process.

If the problem stops, you have learned something useful.

If it does not, you have learned something arguably just as useful: your explanation was not complete.

Go back and ask why again.

A problem that keeps returning is often telling you something. You may have been repairing the symptom instead of changing the conditions producing it.

Sources & Further Reading