Five whys (or5 whys) is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem.[1] The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question "why?" five times, each time directing the current "why" to the answer of the previous "why". The method asserts that the answer to the fifth "why" asked in this manner should reveal the root cause of the problem.[2]
The technique was described by Taiichi OhnoatToyota Motor Corporation. Others at Toyota and elsewhere have criticized the five whys technique for being too basic and having an artificially shallow depth as a root cause analysis tool (see § Criticism).
Why? – The alternator belt was well beyond its useful service life and not replaced.
Why? – The vehicle was not maintained according to the recommended service schedule (a root cause).
The questioning for this example could be taken further to a sixth, seventh, or higher level, but five iterations of asking why is generally sufficient to get to a root cause.[3] The key idea of the method is to encourage the troubleshooter to avoid assumptions and logic traps and instead trace the chain of causality in direct increments from the effect through any layers of abstraction to a root cause that still has some connection to the original problem. In this example, the fifth "why" suggests a broken process or an alterable behavior, which is indicative of reaching the root-cause level.
This nature of the answer to the fifth why in the example is an important aspect of the five why approach. The real root cause should point toward a process that is not working well or does not exist.[4] Untrained facilitators without this understanding of the method often observe that answers obtained seem to point towards classical answers such as not enough time, not enough investments or not enough resources.[citation needed] These answers regardless of merit are often out of the troubleshooter's control to fix. Therefore practitioners of the method recommend instead of asking why? to ask why did the process fail?[citation needed]
The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. It is a major component of problem-solving training, delivered as part of the induction into the Toyota Production System. The architect of the Toyota Production System, Taiichi Ohno, described the five whys method as "the basis of Toyota's scientific approach by repeating why five times[5] the nature of the problem as well as its solution becomes clear."[2] The tool has seen use beyond Toyota, and is now used within Kaizen, lean manufacturing, lean construction and Six Sigma. The five whys were initially developed to understand why new product features or manufacturing techniques were needed, and was not developed for root cause analysis.
The five whys technique has been criticized as a poor tool for root cause analysis. Teruyuki Minoura, former managing director of global purchasing for Toyota, criticized it as being too basic a tool to analyze root causes at the depth necessary to ensure an issue is fixed.[9] Reasons for this criticism include:
Tendency for investigators to stop at symptoms rather than going on to lower-level root causes.
Inability to go beyond the investigator's current knowledge – the investigator cannot find causes that they do not already know.
Lack of support to help the investigator provide the right answer to "why" questions.
Results are not repeatable – different people using five whys come up with different causes for the same problem.
Tendency to isolate a single root cause, whereas each question could elicit many different root causes.
Medical professor Alan J. Card also criticized the five whys as a poor root cause analysis tool and suggested that it be abandoned because of the following reasons:[10]
The artificial depth of the fifth why is unlikely to correlate with the root cause.
The five whys is based on a misguided reuse of a strategy to understand why new features should be added to products, not a root cause analysis.
To avoid these issues, Card suggested instead using other root cause analysis tools such as fishboneorlovebug diagrams.[10]
