The 5 Whys method is based on a simple principle: successively asking the question “why?” to trace back from a visible symptom to its root cause. Used for decades in the automotive industry and then extended to project management, quality, and management, this problem-solving technique is appealing due to its quick implementation. However, its simplicity masks significant variations in results depending on how the analysis is conducted.
Reliability of the analysis: 5 Whys method compared to other tools
Before launching into the iterative questioning, it is useful to position this tool among other cause analysis techniques. The table below compares the 5 Whys method to three alternatives commonly used in businesses.
| Criterion | 5 Whys | Ishikawa Diagram | Cause Tree | Fault-tree analysis |
|---|---|---|---|---|
| Type of problem suited | Simple incident, linear causal chain | Multifactorial problem, categorization of causes | Serious event, parallel causes | Complex system failure |
| Number of causes explored | One single branch | Multiple branches (5M or 6M) | Network of simultaneous factors | Logical combinations (AND/OR) |
| Risk of subjectivity | High (choice of “why” at each step) | Medium (structured framework by categories) | Low (factual reconstruction) | Low (formal modeling) |
| Implementation time | Minutes to an hour | One to several hours | Several hours to several days | Several days |
The 5 Whys method is suitable for common incidents where the causal chain remains linear. For serious or multifactorial events, a single chain of “whys” may overlook parallel causes related to equipment, organization, or time constraints. It is therefore beneficial to complement it with an Ishikawa diagram or a cause tree.
To deepen the practical application of this iterative questioning, Nefa Blog’s advice details each step with concrete examples.
Subjectivity of questioning: why two teams find different root causes
The main blind spot of the method lies in the choice of “why” asked at each level. Faced with the same problem, two teams may follow distinct causal branches and arrive at different diagnoses, each defensible.
Let’s take a common case in project management: a deliverable submitted late. One team directs its questions towards the internal validation process and identifies a bottleneck at the quality manager level. A second team instead questions the initial workload and concludes that the project team was undersized.
Both analyses are logically coherent. The problem does not stem from the technique itself, but from three factors that amplify subjectivity:
- The data available at the time of analysis mechanically directs the answers. If the team only has validation deadlines, it will explore this avenue without considering the overall workload.
- The composition of the team influences the hypotheses retained. A production manager and an HR manager will not formulate the same first “why.”
- The absence of factual verification between each iteration allows for a shift from observation to interpretation without realizing it.
Reducing the gap between two analyses
To limit this drift, an effective practice is to document each answer with an observable proof: a time log, a report, a process indicator. If the answer to a “why” relies solely on a collective impression, it should be put on hold and verified.
Another approach is to run the exercise with two distinct groups on the same problem, then compare the causal branches. The divergences reveal areas where data is lacking, guiding the next steps of the investigation.
Corrective actions after the 5 Whys: what quality standards require
Identifying a root cause is not enough. Management standards require verifying the effectiveness of corrective actions, not just naming a triggering factor. Under ISO 45001, clause 10.2 provides for responding to the incident, investigating its causes, implementing actions, and then evaluating their effectiveness and keeping documented information.
The 5 Whys method only covers the second step of this process. It produces a hypothesis of root cause but prescribes neither the action plan nor the follow-up. In practice, many teams stop at identifying the cause and consider the problem resolved, which explains the recurrence of certain dysfunctions.
Completing the analysis with measurable follow-up
For problem resolution to be complete, each identified root cause should lead to three elements:
- A specific corrective action, assigned to a responsible person and accompanied by a deadline.
- A verification indicator to measure whether the action has produced the expected effect on the concerned process.
- A scheduled review (in one or several weeks) to confirm the disappearance of the initial symptom or to restart the analysis if the problem persists.
Without this verification loop, the 5 Whys method remains an intellectual exercise that does not permanently alter the functioning of the company.
Conditions for effectiveness: when to use the 5 Whys and when to change tools
The technique works well when the problem presents a relatively linear causal chain and the team has factual data at each level of questioning. Recurring tasks with a measurable gap from a standard (delivery delays, isolated quality defects, data entry errors) are particularly suited to this type of analysis.
On the other hand, as soon as multiple factors must be combined simultaneously to trigger the event, the linear chain of “whys” becomes insufficient. An incident involving a material failure, a lack of training, and time pressure cannot be reduced to a single causal branch. In this case, switching to a cause tree or an Ishikawa diagram avoids oversimplifying the diagnosis.
The 5 Whys method retains its value as a first reflex of investigation, provided it is not the only problem-solving tool used. Its strength lies in the speed of questioning. Its limit becomes apparent as soon as the reality of the problem exceeds a single line of causality.
