When conducting a Five Whys accident analysis, you start with a clear statement of what happened and then ask “why” repeatedly until you move past the obvious symptoms and reach the underlying cause that, if corrected, would prevent the accident from happening again. The process typically takes three to five rounds of questioning, though it can take more. It works best for straightforward incidents with a relatively linear chain of causes, and it requires a team that’s willing to push past surface-level explanations.
How the Process Works Step by Step
The Five Whys was created by Sakichi Toyoda, co-founder of Toyota Motor Company, originally to troubleshoot manufacturing problems. His reasoning was simple: “by repeating why five times, the nature of the problem as well as its solution becomes clear.” The same logic applies to accident investigation. Rather than stopping at the immediate trigger (someone slipped, a machine failed), you keep digging until you find the systemic issue underneath.
The process follows a specific sequence. First, your team develops a problem statement that is clear and specific. “An employee was injured” is too vague. “A worker fractured their wrist after falling from a ladder on the loading dock on March 12” gives everyone a concrete starting point. Second, a facilitator asks why that event happened and records the team’s answer. Third, and this is the critical part, the facilitator applies a simple test to each answer: if this specific cause were corrected, would the accident likely still happen again? If the answer is yes, you’ve found a contributing factor, not the root cause. You keep asking “why” until the team agrees you’ve reached a cause where fixing it would genuinely prevent recurrence.
What a Five Whys Analysis Looks Like in Practice
A construction safety study documented a near-miss incident where a tower crane lifted a balcony slab from a truck and an additional slab unexpectedly came with it, falling and nearly striking workers below. Here’s how a Five Whys chain might unfold for that type of incident:
- Why did the extra slab fall? Two slabs got lifted because they were frozen together.
- Why were they frozen together? Water had collected between the slabs and froze overnight.
- Why was water between the slabs? The slabs were stored outdoors without separation material between them.
- Why were they stored without separation material? The precast factory stacked warm slabs directly on top of each other before shipping.
- Why did the factory stack them that way? There was no specification in the purchase order requiring slabs to be separated for winter deliveries.
Notice how the first answer (frozen slabs) sounds like a root cause but isn’t one you can meaningfully fix. You can’t control the weather. By the fifth question, you’ve reached something actionable: updating procurement specifications to require separation material during cold months. That’s the kind of systemic fix that prevents recurrence, not just for this site but for every future delivery.
Telling Root Causes Apart From Symptoms
The biggest mistake teams make during a Five Whys analysis is stopping too early. As the Institute for Healthcare Improvement puts it, “what we think is the cause is sometimes just another symptom.” A machine malfunctioned. Why? Because a part wore out. Many teams stop here and replace the part. But asking why the part wore out (no preventive maintenance schedule), and why there was no schedule (the maintenance role was eliminated during budget cuts), reveals a very different kind of problem requiring a very different kind of solution.
The test at each step is always the same: if you fixed this one thing and changed nothing else, would the accident still be possible? If yes, keep going. You’ve identified something that contributed to the accident, which is worth noting, but you haven’t found what caused it at a fundamental level. Root causes almost always live in systems, processes, training, or organizational decisions rather than in a single physical failure or human error.
When Five Whys Works and When It Doesn’t
The Five Whys is best suited for incidents with a fairly direct chain of cause and effect. OSHA’s guidance on incident investigation notes that for simpler incidents, brainstorming-based tools are often sufficient to identify root causes, while more complicated incidents may require logic trees or event trees. The Five Whys falls squarely in that first category: a powerful tool for straightforward problems, but one that has real limits.
Its main weakness is its linear structure. Each “why” produces one answer, which funnels the investigation down a single path. Real accidents often involve multiple interrelated causes happening simultaneously. A worker fell because the ladder was damaged, and because it was raining, and because there was pressure to finish before a deadline, and because the safety harness policy wasn’t enforced. A single chain of “whys” can only follow one of those threads at a time.
For incidents involving multiple concurrent causes, a fishbone diagram (also called a cause-and-effect diagram) provides a more structured approach. It lets you map out causes across several categories, such as equipment, environment, procedures, and training, all at once. Many safety professionals use both tools together: the fishbone diagram to identify all the possible contributing categories, then a Five Whys chain within each category to drill down to root causes. This hybrid approach captures the breadth of a complex incident without losing the depth that makes root cause analysis useful.
Common Pitfalls to Avoid
Beyond stopping too early, several other mistakes can derail a Five Whys analysis. One is letting the chain end at “human error.” Saying a worker made a mistake is rarely a root cause. The next question, why the mistake was possible in the first place, is where the real insight lives. Was the procedure confusing? Was the worker fatigued from overtime? Was there no checklist for that task? Blaming individuals produces disciplinary action. Identifying system gaps produces prevention.
Another pitfall is conducting the analysis with too few perspectives in the room. The team should include people who understand the work being done, the equipment involved, and the environment where the accident occurred. A facilitator who wasn’t present at the incident may not know which follow-up questions to ask. Front-line workers often identify contributing factors that supervisors and managers would never think of, because they experience the daily friction between written procedures and actual working conditions.
A third issue is failing to document the full chain. Each “why” and its corresponding answer should be written down, along with the evidence supporting each link. This creates a record that others can review, challenge, and learn from. It also prevents the analysis from drifting into speculation. Every answer in the chain should be grounded in what actually happened, not what might have happened.
Turning Root Causes Into Corrective Actions
The analysis is only valuable if it leads to changes. Once you’ve identified a root cause, the corrective action should directly address it. If the root cause is a missing inspection protocol, the fix is creating and implementing that protocol, not just reminding workers to be more careful. Strong corrective actions change systems: they revise procedures, add physical safeguards, update training programs, or restructure responsibilities so that the gap that allowed the accident no longer exists.
Each corrective action should also have an owner and a timeline. Without accountability, Five Whys analyses become paperwork exercises that sit in filing cabinets. The most effective safety teams revisit their corrective actions after implementation to verify that they actually reduced risk, closing the loop between investigation and prevention.