What is the five whys method?
The technique involves asking a question about the cause of a problem and using the answer as a starting point for further investigation. It aims to move from an immediate description to conditions that explain why the problem arose or persists. In prevention, it can be used within the root cause analysis, provided the connection to the investigated facts is maintained.
The title doesn’t require you to ask exactly five questions. One line of inquiry might need further development, while another might be discontinued due to a lack of information. Nor does it demand finding a single, definitive cause. The answers may lead to different paths, and it’s preferable to keep them separate rather than force a linear explanation that doesn’t reflect what actually happened at work.
Clearly define the initial problem
Before asking questions, it’s important to describe the incident specifically: what happened, where, when, and during what task. “The equipment is unsafe” is too broad to begin a useful line of questioning. A more precise formulation might be “an unexpected movement occurred during the removal of a blockage,” provided that this description is confirmed by an investigation.
The initial formulation should not already include the conclusion. If it is written as “accident due to inattention,” the questions will tend to justify a pre-selected blame. Separating the event from its explanation allows for consideration of design, maintenance, organization, available information, and operating conditions. It also helps to recognize when several problems requiring separate analysis are being conflated.
Asking questions without leading the answers
The questions should encourage explanations of conditions and decisions, not confirmation of an accusation. You can alternate between “why did it happen?” and “what allowed it to happen?” or “what condition should have been controlled?” The important thing is to maintain a plausible and verifiable causal link between the answer and the previous event, without introducing judgments about the intentions or character of the people involved.
Every answer needs to be verified. An explanation offered in a meeting might be a useful hypothesis, but it doesn’t gain factual validity simply by being repeated or by someone in authority. It’s important to note which document, observation, or testimony supports it and what data could refute it. This discipline prevents the construction of seemingly convincing chains of events that are weak as a basis for a preventive measure.
Open multiple branches when necessary
A single event can have several relevant antecedents. For example, a disabled safety device and a restart occurring without checking the area are different issues. Investigating only one can leave important controls out of the analysis. The five whys can be developed in branches and then organized using a cause tree when it is useful to represent their relationships.
The team should avoid always selecting the easiest response to modify. The fact that training can be organized quickly does not prove that a lack of training explains the incident. The conditions that made it difficult to implement the procedure, the available resources, and how previous warnings were handled should also be analyzed, when data exists to support these considerations.
Practical example
In a hypothetical example, a loaded cart rolls while being parked and hits a shelf without causing any injuries. The first question identifies that the brake wasn’t holding. The technical inspection confirms wear. The next line checks why it wasn’t detected earlier: the inspection used verified the visual condition but didn’t include a functional test of the brake.
The analysis continues, examining how that inspection was defined and discovering that it was copied from a different cart model without reviewing the safety features. Another branch examines the parking space and confirms an overlooked slope. The measures focus on the brakes, the parking, and the definition of the inspections. The case demonstrates several contributions without requiring five answers in each branch.
From responses to actions
A useful conclusion describes a modifiable condition with sufficient precision. “Improving safety” doesn’t allow you to decide what to do; “include and verify the brake’s functional test according to the equipment’s characteristics” does guide action. Proposals must be technically evaluated and not simply a positive repetition of the last sentence in the chain of questions.
Implementation requires assigning responsibilities, setting deadlines, and verifying compliance. In this example, it’s advisable to confirm that the affected equipment has been inspected and that the procedure distinguishes between different models. It’s also important to assess whether the measure introduces additional operational challenges. While technology can be helpful in planning, risk management depends on the quality of the solution and its sustained application.
Common mistakes
Common mistakes include dwelling on “human error,” repeatedly asking why without providing new data, or accepting a generic phrase like “lack of education” as the cause. Another problem is closing the investigation simply because the fifth question has been answered. The criteria for closing the investigation should be based on the available evidence and a sufficient explanation of the mechanisms that allowed the event to occur.
It is also important to avoid confusing coincidence with causation. The fact that someone had little seniority does not prove that their experience explains the incident. The investigation should examine what knowledge was required, what information was provided, and how the job was designed. If data is missing, the uncertainty should be documented, and other techniques or specialized support may be necessary.
When to use it and when to complement it
The five whys can be useful for exploring a nonconformity, a warning, or a specific line of inquiry. Their simplicity facilitates participation from those familiar with the process. However, they do not replace information gathering or a technical evaluation when complex mechanisms, multiple systems, or potentially serious consequences are involved.
An Ishikawa diagram can help organize hypotheses before delving deeper, and a tree diagram can then show verified relationships. The combination should address the problem, without accumulating tools out of habit. A good application clearly states what is known, what has been deduced, what remains open, and what measures will be checked to avoid repetition.
