The 5 Whys
The 5 Whys is the simplest and most widely used root cause analysis technique. Ask why five times and you will reach the root cause of almost any problem. But most analyses stop at Why 2 or Why 3 — at the process level — when the real answer lies in the system. Knowing when to stop is as important as knowing how to start.
☰ Contents — click to expand
Origin and method
The 5 Whys was developed by Sakichi Toyoda, the founder of Toyota Industries, in the early twentieth century and became a central element of the Toyota Production System in the 1950s. It was adopted by Toyota as a standard problem-solving technique and popularised in the West through Taiichi Ohno’s Toyota Production System (1978) and later through the lean manufacturing movement.
The method is deliberately simple: when a problem occurs, ask why it happened. Take the answer and ask why again. Repeat five times. The principle is that surface symptoms have proximate causes, proximate causes have underlying causes, and underlying causes have root causes — and that five iterations is typically sufficient to reach a cause that is actionable and preventive rather than merely corrective.
Problem: The robot stopped.
Why 1: The circuit overloaded, causing a fuse to blow. Why 2: There was insufficient lubrication on the bearings. Why 3: The oil pump on the robot was not circulating sufficient oil. Why 4: The pump intake was clogged with metal shavings. Why 5: There was no strainer fitted to the pump.
Fix: Attach a strainer to the pump. Replacing the fuse (Why 1) would have allowed the robot to restart but the problem would have recurred. Only the Why 5 answer prevents recurrence.
How to run a 5 Whys
The technique requires a clearly defined problem statement, a multidisciplinary team with direct knowledge of the process, and the discipline to keep asking why rather than accepting the first plausible answer. Five practical rules:
- Start with a specific event, not a general problem. “The patient received the wrong medication” is specific. “Medication errors are too high” is not. A vague problem statement produces vague answers.
- Each answer must be based on evidence, not assumption. “Because staff are careless” is an assumption. “Because the check step was skipped” requires evidence that the check step was actually skipped in this specific case.
- Each why must follow logically from the previous answer. Read the chain backwards: “Because of Why 5, Why 4 occurred. Because of Why 4, Why 3 occurred...” If the chain does not read logically, an answer is missing or wrong.
- Keep asking until you reach something actionable that prevents recurrence. If the answer to Why 5 is still something you cannot change, keep going to Why 6 or Why 7. The number five is a guide, not a rule.
- Apply the Joiner test at the end. Is the fix at the output level, the process level, or the system level? If it is at the output or process level, ask whether a system-level cause exists that the analysis has not yet reached.
Worked example — NHS Never Events
Wrong-route medication administration has been classified as a Never Event — wholly preventable — since 2010. Bootstrap CUSUM on 15 years of NHS data finds a flat process at 17.5 events per year with no structural change. The 5 Whys analysis of a single wrong-route event illustrates exactly why the flat line persists.
The NHS response to each wrong-route event has overwhelmingly operated at Why 1 and Why 2: retraining, revised checklists, new alert notices, updated frameworks. The Why 5 answer — the missing feedback loop between cost-bearer and decision-maker — has never been addressed. Bootstrap CUSUM shows the result: 17.5 events per year, flat, for 15 years.
The Joiner test — which level did you reach?
The most important question at the end of any 5 Whys analysis is: at which level is the proposed fix operating? Joiner’s Levels of Fix provides the test.
Fix the output
The fix addresses the specific event that occurred. Retrain the individual, replace the fuse, reprimand the team. Prevents recurrence of this exact event in this exact way — but the system that allowed the event remains unchanged. A different person, a different day, a different event of the same type will recur.
Fix the process
The fix changes the process that allowed the problem. New procedure, new checklist, new training programme, new labelling. Reduces recurrence of this type of event — but the system that produced the faulty process remains unchanged. The process improvement may be absorbed, forgotten, or bypassed under pressure.
Fix the system
The fix changes the system that produced the faulty process. Physical redesign, structural accountability change, economic mechanism change. Prevents the entire class of problems, not just this instance. Does not rely on individual behaviour or memory. This is where the 5 Whys should aim to reach.
A Level 3 fix works because it changes the system, not because people remember to apply it. ENFit connectors prevent wrong-route administration whether or not staff remember the training. A carbon price floor changes generator economics whether or not operators remember the policy intent. A Level 1 or Level 2 fix requires sustained human attention to maintain. Under pressure, in understaffed shifts, at 3am, the check gets skipped. The system was not redesigned. The event recurs.
Why most 5 Whys stop too early
In practice, most 5 Whys analyses in healthcare, industry, and policy stop at Why 2 or Why 3. There are three structural reasons for this.
The person answer is satisfying. Why 1 almost always produces a person answer: someone did something wrong, skipped a step, misread a label. This answer feels complete and actionable. It names a cause and implies a fix (retrain, remind, reprimand). The discomfort of asking Why 2 — which often implicates the system or management — is avoided.
The system answer is threatening. Why 4 and Why 5 answers frequently implicate management decisions, resource allocation, procurement policies, or organisational structures. These are uncomfortable findings for the people conducting the analysis, especially when those people are part of the management hierarchy. A 5 Whys that stops at Why 2 protects the institution. One that reaches Why 5 challenges it.
The fix is outside the team’s authority. A ward team can retrain a nurse. They cannot redesign the national procurement system. When the Why 5 answer requires an action that is beyond the team’s authority, the analysis often retreats to a Why 2 or Why 3 answer that produces a fix the team can implement — even though that fix will not prevent recurrence.
Deming estimated 94% of problems are caused by the system, not the people. A 5 Whys that terminates at “human error” as the root cause has almost certainly stopped too early. Human error is not a root cause — it is a symptom. The root cause is the system condition that made the error easy to commit and difficult to catch. “The nurse made an error” answers nothing about why the system was designed so that the error was possible, likely, or uncaught. Asking why the error was possible, likely, and uncaught is where the 5 Whys should go.
Limitations of the 5 Whys
The 5 Whys is powerful for linear causal chains — where A caused B caused C caused D. It is less effective for complex systems where multiple interacting causes produce an outcome, and where the same outcome can arise from different causal paths. For those situations, a fishbone (Ishikawa) diagram or a causal loop diagram is more appropriate.
Three specific limitations worth noting:
- Different teams reach different root causes. The 5 Whys is not deterministic. Two teams analysing the same event will often produce different Why chains depending on their knowledge, experience, and willingness to pursue uncomfortable answers. This is not a flaw in the technique — it reflects the fact that complex events typically have multiple contributing causes — but it means the result should be treated as a hypothesis to be tested, not a definitive finding.
- It analyses individual events, not patterns. The 5 Whys answers the question “why did this event occur?” It does not answer “why does this type of event occur at this rate?” For the second question, SPC analysis and Bootstrap CUSUM are the appropriate tools.
- It does not verify that the fix worked. The 5 Whys identifies a root cause and implies a fix. It does not tell you whether the fix produced a genuine structural change in the outcome. That requires a pre-specified PDSA Study phase with Bootstrap CUSUM as the objective test.
The 5 Whys and Bootstrap CUSUM
The 5 Whys and Bootstrap CUSUM address different questions and operate on different timescales. Together they form a complete improvement cycle.
📊 How the two tools work together
Bootstrap CUSUM identifies that a problem exists and dates it precisely. A structural change point in a safety event series — an upward change point in a wrong-route medication series, a downward change point in a sepsis mortality series — tells you that something structurally changed at a specific time. It does not tell you what caused the change.
The 5 Whys identifies what caused the change. Once Bootstrap CUSUM has dated a change point, the 5 Whys investigation can be focused: what changed in this system in the 6–12 months before the change point? The date narrows the investigation window from the entire history of the system to a specific period. The causal chain revealed by the 5 Whys in that window is the hypothesis about what produced the change point.
Bootstrap CUSUM then verifies whether the fix worked. Once a Level 3 fix has been implemented (identified by the 5 Whys), pre-specify a Bootstrap CUSUM change point as the test: we expect an improvement in outcome measure Y within Z periods. When the change point appears, the fix is confirmed. When it does not appear, the Why 5 answer was incomplete and the analysis must continue.
This is the PDSA cycle made rigorous: the 5 Whys is the Plan phase theory of change, the fix is the Do phase, and Bootstrap CUSUM is the Study phase objective test. Without Bootstrap CUSUM, the Study phase is replaced by narrative — and any result can be declared success.