The 5-Why Method: A Guide with Practical Quality Management Examples

Ask “why?” five times - few methods in quality management sound this simple, and few are applied this poorly in practice. The problem is rarely the principle itself; it’s that the chain stops at the first convenient answer, usually a person. Understanding why that happens - and how to do better - starts with where the method actually comes from and what it was built for.

Origin: from Sakichi Toyoda to Taiichi Ohno

The method traces back to Sakichi Toyoda, the founder of Toyota Industries, and was established as a core element of the Toyota Production System by Taiichi Ohno. Ohno called the Five Whys “the basis of Toyota’s scientific approach” to problem solving - not a side tool, but the methodical foundation Kaizen, continuous improvement, was built on. Ohno was known for consistently rejecting surface-level answers and sending engineers back to the shop floor until the analysis landed on a systemic cause rather than a convenient one.

That discipline - not the number five - is the actual core of the method. Five is a rule of thumb that historically emerged because most causal chains at Toyota reached a cause within the team’s own control at roughly that depth.

The method in practice: a chain, not a form

The most common mistake is treating 5-Why as a rigid five-line form. It’s actually a chain: each answer becomes the next question, until the analysis reaches a cause whose removal genuinely prevents recurrence. Sometimes that’s three levels, sometimes eight. The three examples below, from different domains, show what a chain looks like when it actually reaches a systemic cause.

Example 1 - manufacturing: a dimensional deviation on a milled bore

1. Why was the bore machined out of tolerance? Because the tool was already worn.
2. Why was a worn tool used? Because the tool-change trigger never fired.
3. Why didn’t it fire? Because the change is tied to a piece count, not a measured wear value.
4. Why is it tied to piece count? Because the original tool data sheet was never updated with real wear data from series production.
5. Why was it never updated? Because no process exists to periodically reconcile tool data with actual wear after launch.

Systemic cause: a missing feedback loop between series production and tool data maintenance - not carelessness at the machine.

Example 2 - services: a customer invoice sent two weeks late

1. Why was the invoice two weeks late? Because project completion wasn’t recorded in the system.
2. Why wasn’t it recorded? Because the project lead doesn’t report completion; billing has to look it up themselves.
3. Why does billing look it up instead of being notified? Because there’s no defined handover point between project closure and invoicing.
4. Why is there no handover point? Because the invoicing process was originally designed for single projects, where billing was informed informally anyway.
5. Why was the process never adapted as project volume grew? Because nobody is explicitly responsible for maintaining the invoicing process.

Systemic cause: a process with no owner that never grew with the organization - not “the project lead forgot.”

Example 3 - supply chain: the wrong part variant delivered

1. Why was the wrong variant delivered? Because the supplier used the wrong drawing revision.
2. Why did the supplier have the wrong revision? Because the current revision isn’t automatically passed on to them.
3. Why not automatically? Because drawing changes are currently communicated as email attachments.
4. Why by email instead of a system? Because there’s no structured interface between the PLM system and the supplier portal.
5. Why doesn’t that interface exist? Because it was classified as “can be added later” during supplier onboarding and never got prioritized since.

Systemic cause: a missing technical interface, not a lapse of attention on the supplier’s side.

The most common mistake: the chain ends at a person

A reliable warning sign that an analysis stopped too early is a cause that points at a person - “the operator wasn’t paying attention,” “the supplier was careless.” Human error is almost never the systemic cause; it’s the point where the analysis stopped being uncomfortable. The next, decisive question is always: why did the process allow this mistake to happen at all, without catching it?

Where the method has documented limits

An honest account of 5-Why also has to cover where it fails - and this isn’t a matter of interpretation, it’s well documented in the literature. Teruyuki Minoura, Toyota’s former global purchasing chief, criticized the method itself as too basic to analyze causes at the depth required. Physician Alan J. Card points to three structural weaknesses in his analysis: the method tends to isolate a single cause even though real problems often have several parallel causes; different people arrive at different chains for the same issue because the method prescribes no way to verify individual answers; and the arbitrary fifth question doesn’t reliably correlate with the actual root cause. Olivier Serrat, in his widely cited brief for the Asian Development Bank, recommends switching to complementary tools - the Ishikawa diagram, barrier analysis, or change analysis - as soon as 5-Why stops intuitively pointing at a cause.

In practice, that means 5-Why suits manageable deviations with a recognizable, linear chain. For customer complaints, safety-relevant defects, several parallel causes, or recurring problems, the tool is overmatched - a more structured process with a team, containment actions, and verification, such as the 8D process, is the better fit there.

The link to corrective action

Root cause analysis isn’t an end in itself. ISO 9001:2015 clause 10.2 explicitly requires distinguishing between correction - immediately fixing the specific problem - and corrective action, which removes the cause so the problem doesn’t recur. Without a causal chain carried through to its end, that distinction is hard to draw cleanly in practice; more on this in our article on the CAPA process.

How qportal keeps the chain traceable

In qportal, the causal chain is maintained as a structured sequence rather than a free-text field: each level is its own record and stays linked to the previous one. That makes it visible at which level an analysis actually ends - and whether that final level is a statement about a process or about a person. Actions attach to the specific level they address rather than to the case as a whole, and corrections to the chain stay logged instead of producing a new, disconnected file version. Details are on the 5-Why page in qportal.

Conclusion

5-Why is the most accessible root cause method - and for exactly that reason, the one most often applied superficially. Carrying the chain through to a systemic cause within your own control instead of stopping at a person, and knowing the method’s documented limits instead of applying it to problems it wasn’t built for, is what actually produces a defensible corrective action instead of another guess in the file.

Sources

• Wikipedia contributors: Five whys - en.wikipedia.org
• Serrat, O. (2009): The Five Whys Technique, Asian Development Bank - Knowledge Solutions - adb.org
• ISO 9001:2015, clause 10.2 (Nonconformity and corrective action)