What is the 5 whys analysis?
The five whys (also styled 5 whys) is one of the many methods to find the root cause of a failure. It is an interrogative technique, in which you explore cause-effect by repeatedly asking “why?” until you find the root cause. Anecdotal evidence suggests that 5 times is enough to find the answer you’re looking for, hence the name “5 whys”.
The big advantage of the “5 whys” technique is recognising that there is a series of events that precede failure. More often than not, failure will arise from a chain of cause-effect reactions, or a domino effect, and not from the single event that immediately precedes it. The 5 whys analysis is a simple and quick problem-solving tool to uncover the root cause, and it applies to several contexts.
In maintenance, the goal of any root cause analysis is fixing the original error. Plus, it helps managers implement new strategies to avoid similar failures, and establish internal processes that minimise the probability of failures at any point.
Who developed the 5 whys problem-solving method?
Whenever we’re looking at root cause analysis tools, it’s always interesting to understand how they came about. The 5 whys exercise was developed by Sakichi Toyoda, Toyota’s founder. According to Toyoda’s principles, machines “stop when there is a problem”.
Asking “why” 5 times helps to find out the origin of that problem – and thus the solution becomes clear. The concept was integrated into Toyota’s production process during the company’s expansion, and it is still a part of its lean methodology to this day.
How does the 5 whys technique work?
Imagine that you have a fever. Surely you’ll take an antipyretic to relieve your symptoms, but that’s not a cure. To cure yourself, you need to ask why you have a fever. “Why do I have a fever?” ⇢ viral infection ⇢ “Why do I have an infection?” ⇢ I contracted the influenza A virus ⇢ “Why did I contract a virus?” ⇢ I was in close contact with an infected person. See, we did not even need the 5 questions to figure out what happened!
From then on, it’s easy to figure out that not only do you need an antiviral, but the way to avoid reinfection is to keep your social distance. Of course, this is a rather simplistic example – we all know we get sick because we were close to an infected person – but it wouldn’t be so obvious if someone hadn’t already questioned “why?”.
Please note that we can’t always follow a linear train of thought to figure out the root cause. In some cases, there are several potential root causes, which force you to explore different answers to each “why”. Here’s an example where there are multiple potential answers:
The car won’t start. ➝ Why? ➝ The car battery is dead. ➝ Why has the car battery died? ➝ The headlights stayed on overnight. ➝ Why did they stay on? ➝ There was no alarm sound or warning light on the control panel.
Here’s when the diagram breaks down into two possibilities:
➝ Why wasn’t there an alarm? ➝ The sensor failed. ➝ Why? ➝ The sensor was never replaced.
➝ Why wasn’t there any warning light on the panel? ➝ There was an electrical problem. ➝ Why? ➝ The fuses are damaged.
When the 5 whys analysis branches out into many different possibilities, it’s almost always a symptom of insufficient quality control and failure detection methods. Never forget that you’re analysing the process, not the people, so never accept “human error” as the root cause. Surely, there is a quality control process that wasn’t performed, even if it is a simple checklist.
In a more complex analysis, organise all the answers in an Ishikawa diagram (also known as fishbone diagram). Combining both methods will help you visualise better all the hypotheses.
How to run a 5 whys analysis
Now, we’ll explain step by step how to perform a 5 whys analysis:
1. Bring together a team
Root causes analysis should not be performed by a single person. Bring together a team with a good know-how of the asset – but who is willing to look at things with fresh eyes and explore all the answers.
2. Define the problem
It’s preferable if everyone in the team can testify and see the failure for themselves. Every single team member should agree on a description. For example, they must agree that the most appropriate definition for the failure is “the car won’t start” (rather than “the ignition won’t start”) because that would trigger different questions going forward.
3. Start asking “why”?
Now that everyone is on the same page, it’s time to start asking “why?”. The answers must match the facts, and not suppositions about what happened. Not all team members will likely offer the same answers, so they must debate until the team reaches a consensus.
4. Learn to stop
Be wary of stopping too early – try to go through 5 rounds of “why?” questions – but you also need to learn when to stop. When answers are not useful to understand failure anymore, or when they don’t shed light on possible solutions, it’s time to stop. If you cannot find a root cause, try another root analysis tool, like the fault-tree analysis (FTA) or Failure Modes and Effects Analysis (FMEA).
5. Adapt your maintenance plan
After finishing the analysis, the team should suggest measures to avoid similar failures. During this step, it is useful to review all the answers to establish new quality control procedures.
When should you use the 5 whys analysis?
In maintenance, the 5 whys analysis may be used for root cause analysis, troubleshooting or problem-solving. It tends to be very efficient, and quick, to discover the root cause of failures with low to moderate criticality. Besides, it has great applicability as a quality improvement tool, within a lean methodology.
Unlike other tools, the 5 whys analysis cannot be used at a conceptual stage. Its use is limited to finding the cause of problems that already occurred, or analysing failures that indeed compromise functionality. On the bright side, you won’t “waste time” with hypothetical questions.
What are the limitations of the 5 whys method?
The main limitation of the 5 whys method is self-evident: since it tends to follow linear logic, it can only find a single root cause. It’s not practical when there are several lines of investigation or when there might be more than one root cause. In those cases, it’s better to use a fault-tree analysis, which will demonstrate the close relationship between several systems and failures, combine a fishbone diagram with 5 whys analysis, or even an FMEA.
Besides being more suitable for linear logic, there are other limitations to the 5 Whys method:
- Since it only assesses events that already occurred, and it’s merely qualitative, it’s not suitable for a probabilistic risk assessment.
- Like FMEA, it depends on your team’s know-how to work out the root cause. If there was an unexpected failure mode, you may never consider that answer – and never reach a conclusion.
- Your team might have a biased view, which might compromise the results of the analysis. The team might ask biased questions or offer biased answers that confirm their suspicions or theories.
- It’s not always easy to set “symptoms” and “causes” apart or to know when to stop. Occasionally, you might stop before you have time to execute a deep and thorough analysis.
- For these reasons, different teams might reach different conclusions regarding the same failure.
Learn more about this subject on our complete guide to root cause analysis.
