The 5 Whys (5 Why) and root-cause analysis (RCA, Ishikawa, 4M)

Water is dripping from the kitchen ceiling. You put out a bucket, and by the next day it is full again. The bucket does not solve the trouble, because the problem is not the dripping but the pipe leaking above it. Until you fix the pipe, you can empty the bucket forever. This is exactly the trap the 5 Whys (in Hungarian 5 Miért) avoids: instead of treating the visible symptom, you keep asking “why?” until you reach the real triggering cause, whose elimination means the problem does not come back. The method is so simple that even a curious child uses it (“but why?… and why is that?”), yet it is the basic tool of Lean root-cause analysis. Let’s look at what it is, why it works, and how to use it.

The 5 Whys (5 Why) is simple root-cause analysis: starting from the symptom, we repeatedly ask “why?” until we reach the problem’s real triggering cause. Typically five questions lead from the surface symptom to the actionable root cause, but “five” is only a guide number. The logic is that, instead of treating the symptom, eliminating the root cause ensures the problem does not recur. It is the basic tool of the cause-analysis phase of A3 problem-solving; to categorize the causes it often calls on the Ishikawa (fishbone) diagram and the 4M framework (Man, Machine, Material, Method). The countermeasure always targets the root cause, not the symptom.

Figure 1 — the 5 Whys on the classic oil-pump example: the root cause is not the blown fuse but the missing preventive maintenance; the countermeasure targets that.

Who is this for?

This article is for those who meet recurring faults and their investigation in practice too: operator · shift and plant manager · process engineer · maintenance technician · reliability engineer · quality engineer · HSE · Lean/CI specialist.

Learning objectives

After reading this article you will be able to:

• carry a 5-Why chain through from a symptom to the actionable root cause, and justify why the number is not the point;
• distinguish the symptom from the root cause, and the intervention aimed at each (symptomatic treatment vs. countermeasure);
• categorize causes on an Ishikawa diagram and in the 4M/6M framework, and recognize when a linear chain must give way to parallel branch analysis;
• apply the “5 Whys, not 1 Who” principle, i.e. ask about the process, not about the culprit;
• draw the boundary: when the 5 Whys is not enough, and what stronger method complements it.

The essence

• From the symptom to the root cause we get by chained “why?” questions, typically in five steps.
• The “5” is a guide, not a dogma: keep asking until you reach an actionable root cause.
• Countermeasure on the root cause, not on the symptom, otherwise the problem returns.
• Precondition: a validated current-state observation (gemba), otherwise the “whys” rest on assumption.
• Complements: Ishikawa (fishbone) + 4M for the cause categories; tree-based analysis for complex, parallel causes.
• “5 Whys, not 1 Who”: examine the process, not the culprit; this is the basis of a learning, blame-free culture.

Why does it matter? (the stakes)

A quick “fix” of a symptom looks cheap, but if you do not eliminate the real cause, the fault returns, and at every recurrence you pay for it again: with downtime, scrap, risk. This is where the traditional and the Lean mindset part sharply.

Mindset	What it does with the fault	Consequence
Traditional	treats the symptom (replaces the fuse, puts out the bucket)	the problem returns
Lean	eliminates the root cause	the problem does not recur

Lean advice

Eliminating the root cause may in the short term take more time than the symptomatic fix, but the investment pays off quickly, because the problem never recurs again. A root-cause-based problem-solving culture leads to higher OEE, higher productivity and a more motivated team.

That is why the discipline is worth it: the goal is not to make the fault disappear from sight quickly, but to eliminate it once and for all. To the Lean eye a problem is not an annoyance but an opportunity for continuous improvement.

What is the 5 Whys, and where does it come from?

The 5 Whys is Lean’s oldest and most easily teachable problem-solving tool: we keep asking “why?” until we get to the bottom of the problem. It leads to the root cause by challenging every answer with another “why?”: the chained questions move layer by layer from the surface symptom to the actionable triggering cause, whose elimination means the fault does not recur. The method was made famous within the Toyota production system by Taiichi Ohno, who placed the discipline of root-cause analysis at the center of the TPS’s problem-solving culture. The basic idea is that the answers link into one another: every “why?” targets the previous answer, so step by step we peel the problem’s layers from the surface symptom to the system-level cause.

The method’s power lies in its simplicity. It requires no software, statistics or long training, only the discipline not to stop at the first obvious cause. In practice the 5 Whys is the basic tool of the cause-analysis phase of A3 problem-solving and of the Root Cause Problem Solving (RCPS) method; it is the common backbone of the analysis phase of PDCA and DMAIC.

How does it work step by step?

The recipe is simple: state the symptom precisely, then repeatedly ask “why?”, and finally plan a countermeasure on the root cause. The steps:

1. State the problem/symptom precisely based on a validated current-state observation (see gemba-walk).
2. Ask: “Why does this happen?” and record the answer.
3. Ask “Why?” again about the previous answer.
4. Repeat, typically five times, until you reach an actionable root cause.
5. Check the chain’s logic backward (“because of this, therefore…”).
6. Plan a countermeasure on the root cause, not on the symptom.

The method’s classic textbook example (see Figure 1) is a stopped machine:

1. Why did the machine stop? The overload fuse tripped.
2. Why did the fuse trip? There was not enough oil on the shaft.
3. Why was there not enough oil? The pump delivered too little, because the shaft had worn.
4. Why did the pump not work well? The oil filter was clogged with metal shavings.
5. Why did the filter clog? There was no preventive maintenance, no weekly filter cleaning.

The fifth answer is the root cause: the missing preventive maintenance. If you only replace the fuse, the machine will stop again in a few days. The countermeasure is therefore the introduction of the weekly filter cleaning, not the part replacement.

How do we categorize the causes? Ishikawa and the 4M

If the problem does not have a single linear cause-chain but several parallel causes, one “why”-chain does not cover them all. In that case the Ishikawa (fishbone) diagram helps: the spine points to the problem (the “effect”), and the diagonal “bones” are the cause categories along which you systematically go through the possible causes. The fishbone ensures that you think through every possible cause, and it is especially useful for uncovering the cause of recurring failures.

Figure 2 — the Ishikawa diagram with the 4M cause categories; the problem is examined on several parallel branches, and each branch can run its own 5 Whys.

The most common category framework is the 4M, which is at the same time the diagnostic framework of the gemba walk:

M	Category	What it looks at
Man	present, trained, multi-skilled?	competence, presence
Machine	proactively maintained (TPM)?	reliability
Material	just in time and in quality (JIT)?	feed, auxiliary material
Method	standard work within the takt time?	SOP, parameter window

The 4M was originally 3M (man, machine, material), which “method” complemented. Its extended version is the 6M, where two further categories appear: Measurement and Mother Nature / Environment. On every “bone” it is worth running its own 5 Whys, to reach the real root cause of that branch.

Concept vs. tool

The 5 Whys and the fishbone are not rivals but a division of labor: the fishbone maps in width all possible cause categories, the 5 Whys drills in depth down one branch to the root cause. On a complex problem the two together are the strongest.

“5 Whys”, not “1 Who” — examine the process

Good root-cause analysis asks about the process, not about the person. The managerial anti-pattern is the “1 Who?” (who erred): this looks for a scapegoat, silences reporting, and the real, system-level cause stays hidden. The “5 Whys?”, by contrast, uncovers the system, for example the missing preventive maintenance or the standard that was not followed.

This principle was put sharply by James Womack: the leader’s role is to ask questions (“5 Whys?, not 1 Who?”), not to hand out answers or hunt for someone to blame. The biggest obstacle is gemba-phobia: leaders were trained to know all the answers, whereas the root cause is revealed not in the office but on site.

A deterrent counterexample

A typical bad reaction: “There are 22 A2 fault codes in last week’s data, but the person is not here now, what can we do about it? Nothing. Let’s jump to the next item.” The fault codes are administered, but nobody goes out to the scene, and the problem is never solved. Root-cause analysis is precisely the opposite of this.

The process-focused, blame-free approach is the basis of a learning culture, and a precondition of the willingness to report near-misses.

What is the countermeasure?

The output of the 5 Whys is the countermeasure: a verifiable intervention that eliminates the root cause. It is not a “solution” in the sense of closing the topic forever, but the currently best, re-measurable answer to the uncovered root cause. Its features:

• it targets the root cause, not the symptom;
• it is concrete: who, what, by when;
• it is re-measurable (PDCA Check phase);
• it is built into the standard (standard work), so it does not slip back.

The countermeasure is done when the measurement confirms that the problem really does not return, and the proven solution has been built into the daily standard.

Process-industry context and safety

In incident and near-miss investigation the 5 Whys is the established, fast and structured entry tool of process-safety root-cause analysis: by uncovering the organizational and maintenance causes behind the observed deviation, a similar event can be prevented, and the lesson is built into the preventive maintenance and the standards.

For complex, multi-cause events, however, a single “why”-chain is not enough, so structured investigation uses a whole toolkit, scaled by severity:

Tool	What it is good for
Fishbone / Ishikawa	collects all possible root-cause candidates (by cause category)
Fact Tree	identifies the event’s objective facts and the underlying causes
5 Whys	summarizes the analysis, and goes deeper to the base causes and the missing controls
Events & Causal Factor	timeline-based cause-effect analysis, where applicable
Reality Charting	for the most complex cases

Safety boundary

For major-accident-hazard (Seveso) events the 5 Whys on its own is not enough: in such cases it is complemented by more formal, tree-based methods (fault tree, bow-tie), because a single linear chain does not cover the parallel causes and the missing protective layers (see lopa-sil). Root-cause analysis serves learning, but it does not replace certified risk analysis.

Introduction in practice (roadmap)

The 5 Whys as a culture can be introduced as part of Root Cause Problem Solving (RCPS), whose goal is to prevent the recurrence of problems and to drive continuous improvement. Suggested steps:

1. Choose a painful, recurring problem that is measurable (downtime, scrap, near-miss). State precisely what the deviation from the standard is.
2. Go to the gemba, and validate the symptom with a real observation, not with an assumption.
3. Map the causes with a fishbone (4M/6M) if the problem is complex, then run the 5 Whys on the most probable branch.
4. Identify the root cause, and plan a countermeasure for it (owner, deadline).
5. Introduce it and re-measure with the PDCA cycle; if the problem does not return, build it into the standard and extend it to similar cases.

Hands-on / worked example

Task. Shift “B” does not have the required 100 parts available. Run the chain; it is a good example of a case where not five but six “whys?” lead down to the root cause (the “5” really is only a guide):

1. Why were the 100 parts not available? Because they were out of tolerance.
2. Why were they out of tolerance? Because the diameter of the holes was not right.
3. Why was the hole diameter not right? Because the drill bit wore out prematurely.
4. Why did the drill bit wear out prematurely? Because the machine was running at the wrong speed.
5. Why was the machine running at the wrong speed? Because the operator changed the speed setting.
6. Why did they change the speed? Because that was the correct parameter for making the previous product.

The source closes the chain here. To the Lean eye, however, the root cause is not the operator’s mistake, but the missing changeover standard: there is no forced step that resets and checks the parameter at product change. From this follows the countermeasure too: introducing the changeover standard and a parameter check (with a poka-yoke-type forced sequence), not reprimanding the operator.

Homework. Choose a recurring problem in your own area, and run the 5 Whys on it. Write down the chain, mark the root cause, and formulate one concrete countermeasure (who, what, by when). Check: does your chain ask about the process, or about a person?

Measurement / audit

• The trend of recurring faults and stoppages (does it decrease after the root cause is eliminated).
• The share and lead time of closed countermeasures.
• The share of recurring causes: if the same root cause resurfaces, the analysis or the countermeasure was weak.
• OEE connection: a root-cause-solving culture reduces recurring stoppages, thereby raising the OEE and the motivation.

Common mistakes

The pitfalls almost all stem from the same thing: the analysis stops too early, or turns in the wrong direction. In anti-pattern ↔ correction pairs:

• Stopping at the symptomatic cause. We replace the fuse and we are “done”. The problem returns in a few days. Instead: keep asking down to the actionable root cause, and plan the countermeasure for that.
• “Whys” resting on assumption. We give the answer from the office, from experiential guessing. Instead: back every “why” answer with a validated gemba observation (San Gen Shugi: real place, real data, real part).
• “1 Who?” scapegoat-hunting. Who erred? Reporting falls silent, the system cause stays hidden. Instead: “5 Whys?”, ask about the process, not about the person.
• A linear chain for a multiple cause. A single “why”-row does not cover the parallel causes. Instead: first a fishbone (4M/6M) for the cause categories, then a branch-split 5 Whys.
• Countermeasure without re-measurement. “We solved it”, but nobody checks. Instead: PDCA Check, and building it into the standard, so it does not slip back.

When NOT to use it? (the limits of the method)

The 5 Whys is fast and cheap, but not for every situation. Knowing where its boundary is, is just as important as the method itself:

Situation	Why (primarily) not the 5 Whys	The right answer
A multiple, parallel-cause event	a single linear chain does not cover all the causes	first Ishikawa/Fact Tree, then a branch-split 5 Whys
A major-accident-hazard (Seveso) incident	the chain does not show the missing protective layers	tree-based method (fault tree, bow-tie), [[lopa-sil.en	LOPA/SIL]]
The facts are uncertain	the “whys” would rest on speculation	first fact-finding (Fact Tree, gemba), then the 5 Whys
A statistical problem arising from variability	the “why” does not handle the variance	data-based analysis ([[dmaic.en	DMAIC]], SPC)

Rule of thumb: the 5 Whys is strongest for recurring problems reducible to one main cause-chain. For a complex, many-cause or safety-critical event it does not replace the formal methods, but is best as part of them, as a summarizing tool.

Take it home (keys)

• The symptom is not the root cause. Emptying the bucket or replacing the fuse does not solve the trouble; you have to eliminate the leaking pipe, respectively the missing maintenance.
• Ask until you can act. The “5” is a guide: go on until the answer gives an actionable countermeasure.
• Countermeasure on the root cause, concretely (who/what/by when), re-measured, built into the standard.
• “5 Whys, not 1 Who”: ask about the process, not about the culprit; this is the precondition of reporting and of learning.
• For a complex cause, fishbone + 5 Whys, for a safety-critical event a tree-based method.
• Go to the gemba: you find the root cause not in the Excel sheet but on site.

Self-test

1. A pump stops weekly. Run a 5-Why chain on it, and say at which point you would reach an “actionable” root cause, and where the symptomatic fix would stop.
2. When would you swap the linear 5-Why chain for an Ishikawa diagram, and which 4M categories would you go through?
3. What is the difference between the “5 Whys?” and the “1 Who?” question, and why does the latter suppress fault reporting?

How does it appear in digital practice?

The 5-Why principle does not stop at the workshop flipchart: the same logic is realized in software too, in a well-designed deviation-management system. Instead of the paper sheet, here structured fields, mandatory actions and recurrence monitoring carry the “from symptom to root cause, then to the countermeasure” chain — the mechanism differs, the principle is the same.

5-Why principle	Digital implementation	What it delivers
Structured root-cause chain	a deviation-recording form with chained “why?” fields	the chain is documented, not kept in the head
Countermeasure on the root cause	an action with owner and deadline, mandatory to fill in	every root cause has a closable, accountable action
Re-measurement (Check)	recording the status + result of the closed action	it surfaces if the intervention did not work
“5 Whys, not 1 Who”	the log records the process and the cause, not the person	a blame-free, learning trail
Recurrence monitoring	automatic reporting of the recurring causes	by the Pareto principle it focuses on the big causes

The essence

Modern digital deviation-management systems do the same thing as a good 5-Why workshop: they do not let a symptom be closed without a root cause and a countermeasure. If a system requires a cause and a re-measured action for every closed deviation, chances are the logic of the 5 Whys is at work in the background.

Connection to OPEREX (shift diary)

The 5-Why analysis of a near-miss or process upset and the preventive action that follows from it can be logged in the shift diary (OPEREX), giving a documented root-cause trail. This way the trend of recurring faults and the actions taken are traceable and auditable (ISO 45001 §10.2, incident investigation and corrective action). At the handover between shifts the pending root-cause action is not lost, and the recurring causes can be filtered out.

Terminology (HU / EN / JP)

Hungarian	English	Japanese / note
5 Miért	5 Why	なぜなぜ分析 — iterative root-cause questioning
Gyökérok-elemzés	Root Cause Analysis (RCA)	uncovering the triggering cause
Gyökérok-alapú problémamegoldás	Root Cause Problem Solving (RCPS)	preventing recurrence
Halszálka-diagram	Ishikawa / Fishbone / Cause-Effect	特性要因図 — cause categories
Négy M	4M (Man, Machine, Material, Method)	the “bones” of the fishbone
Hat M	6M (+ Measurement, Environment)	extended cause categories
Ellenintézkedés	Countermeasure	対策 — the intervention acting on the root cause

FAQ

Why exactly do we ask "Why?" five times?

Five is only an experiential guide: on average, after this many questions we reach from the symptomatic cause (e.g. a blown fuse) to the actionable root cause. The point is not the number, but that we should not stop at the surface cause, nor go on pointlessly once we have reached an actionable countermeasure.

What is the problem if the countermeasure only treats the symptom?

Then the problem will return, and at every recurrence you pay for it again. The goal of cause analysis is precisely to eliminate the triggering root cause, so that the intervention achieves a durable, non-recurring effect.

What is the difference between the "5 Whys" and the "1 Who"?

The “5 Whys?” uncovers the root cause of the process and the system; the “1 Who?” looks for the person at fault. The latter creates a scapegoat and silences reporting; Lean examines the process, not the culprit.

What is the difference between the 5 Whys and the fishbone diagram?

The fishbone (Ishikawa) maps in width all possible cause categories (4M/6M), the 5 Whys drills in depth down a given branch to the root cause. On a complex problem we use the two together: first the fishbone, then the 5 Whys on the most probable branch.

When is the 5 Whys not enough?

For complex, multiple-cause events (e.g. a Seveso incident), where parallel causes act, or where the facts are uncertain. In such cases an Ishikawa diagram, a Fact Tree or a tree-based analysis (fault tree, bow-tie) complements or precedes it.

Related concepts

A3 report · pdca · jidoka · poka-yoke · kaizen · gemba-walk · standard work · near-miss · oee · lopa-sil

Next step

If you have understood this, from here it is worth going on, in this order:

1. A3 report — the frame in which the 5 Whys lives: the cause-analysis phase of the one-page problem-solving is precisely the root-cause analysis.
2. pdca — the improvement cycle that re-measures whether the countermeasure really eliminated the root cause.
3. poka-yoke — how to make the countermeasure fail-safe, so that the fault arising from the root cause physically cannot return.

References / further reading

• Taiichi Ohno: Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. — the canonical source of root-cause analysis and the discipline of “why five times” (with the pump example).
• James P. Womack, Daniel T. Jones: Lean Thinking. Free Press, 1996 (expanded edition 2003). — the root-cause-centered, process-focused managerial thinking.
• James P. Womack: Gemba Walks. Lean Enterprise Institute, 2011. — the “5 Whys, not 1 Who” principle and gemba-based leadership.
• Kaoru Ishikawa: Guide to Quality Control. Asian Productivity Organization, 1976. — the canonical foundational work on the cause-effect (fishbone) diagram.