Also known as: The Many Why’s, 5 Why’s
The Five Whys is an iterative technique for investigating the cause(s) of a given effect, and is most often done as part of quality management, problem-solving or root cause analysis efforts. However, Eric Ries Lean Startup process has also encouraged the use of this technique as an organizational learning method anytime something unexpected occurs.[6, 7, 8]
The goal of the technique is to continue asking ‘why’ until the underlying cause(s) of an issue have been determined, with the answer to the first ‘why’ providing the question input to the next ‘why’, and continuing on until only causes outside the control of the organization are left or no further causes can be identified.
It’s called Five Why’s because five is considered a likely number of times this iteration will need to occur before the true root cause has been identified,[2] but in reality it may take 2 iterations or it may take many more than 5. The point is do it more than once and to continue asking ‘why’ and analyzing until you are confident you have found the root cause(s).
Additionally, a key tenet of the 5 Whys technique is that the root cause should be a process that is not working well or that does not exist. This means you should avoid blaming a person because your only remedy at that point is to punish them,[10] which may not solve your problem or might even make it worse. If a person is identified as a causal factor, you need to look at the processes or systems that influenced that person’s behavior. Or as Eric Ries put it, “Even in the case of a person making a mistake, we have to ask ‘why do our tools make that mistake so easy to make?’”[8]
For example, there might be a tendency among project practitioners to say that something was not done on schedule “because the execution team did not have enough time”. But the next step would be to ask ‘why’ they didn’t have enough time and to look at processes such as work assignment, work scheduling, or even such processes as hiring and budgeting.
But if you want a humorous example of the Five Why's in action, watch this video on YouTube first.
The technique was developed by Sakichi Toyoda of Toyota Motor Corporation and was a key element of the problem-solving training provided as part of the Toyota Production System.[1,2,3] Taiichi Ohno, the pioneer of the Toyota Production System would tell his staff to “Observe the production floor without preconceptions” and to “Ask ‘Why’ five times about every matter”.[1]
Ohno would use the following example to demonstrate the usefulness of his method:[1]
Q1: "Why did the robot stop?"
A1: The circuit has overloaded, causing a fuse to blow.
Q2: "Why is the circuit overloaded?"
A2: There was insufficient lubrication on the bearings, so they locked up.
Q3: "Why was there insufficient lubrication on the bearings?"
A3: The oil pump on the robot is not circulating sufficient oil.
Q4: "Why is the pump not circulating sufficient oil?"
A4: The pump intake is clogged with metal shavings.
Q5: "Why is the intake clogged with metal shavings?"
A5: Because there is no filter on the pump.
The technique spread beyond Toyota and is now a common part of other process improvement methods such as Six Sigma and Lean.[1]
The Five Whys technique promotes problem solving through questioning and encourages the analysis team to move significantly beyond the immediately identifiable causes of an issue. The recommended level of at least five ‘whys’ almost guarantees that the analysis team will get to deep, underlying causes of any issue that is identified.[5]
There are a number of potential challenges to effectively using the Five Whys technique, which include:[2, 3, 5]
The first step is to select the general or specific problem that will be investigated with the Five Whys process.
Once you know the problem, the next step is to identify the individual(s) who will be taking part in the Five Whys analysis exercise. Although the technique can be executed by a single person, it is most effective when done by team of multiple individuals who have at least knowledge of (and preferably expertise in) the whole range of factors that may relate to the issue being investigated.
At a minimum, the person who discovered the problem should be part of the team.[8] It’s also a good idea to include representation of all stakeholders who are impacted by the problem being investigated (if they weren’t already included based on the knowledge and expertise factors).
Lastly, it’s a good idea to designate someone as the facilitator or leader for the Five Whys exercise.[8, 10] This is preferably someone with experience in the Five Whys technique and strong facilitation skills.
NOTE: If root cause analysis (whether using Five Whys or any other RCA technique) is going to be a recurring activity, you might want to have pre-defined RCA teams for a given organizational unit, process, facility, tool, etc. Or if not an entire team, at least a designated facilitator.[8]
The next step is to carefully define the problem statement that will guide the Five Whys analysis. This is where the general problem from Step 1 above is refined, made specific, and the scope narrowed if possible. The idea is to try to define the problem in such a way that the team does not end up investigating all aspects of the organization if that isn’t really necessary.
The statement should be agreed upon by the entire team and documented in some way that the team can refer back to it during the analysis. It may also be that the team determines at this stage that there are several related problems that need to undergo separate Five Why’s processes, and they will need to select which specific one they will be investigating.
Once you have completed and agreed upon the problem statement and have a greater understanding of the problem and scope of analysis, you should re-evaluate the team composition to ensure you have the knowledge and expertise available that you can reasonably expect to need. This usually means adding one or more new members with specific expertise, but if the scope has been narrowed sufficiently it may result in some team members being dropped.
The next step is to decide on how you will document the findings of the analysis. There are actually a number of different ways, including:
The simplest way to document a Five Whys analysis is with sticky notes, something to write with, and a blank surface to attach the notes to (be that a wall, a table, a window, or whatever). Place the issue statement at the top middle and build out a descending tree structure from that point with sticky notes that document a single causal factor each.
This makes it very easy to change or move individual factors around, is an easy process for the whole group to see and interact with, and when you are done all you need to do in order to document your findings is to take a good picture that captures everything (at a READABLE level). Or you can formalize the results into a Fishbone Diagram or other more formal archival format.
Another easy way to document a Five Whys analysis is to use a spreadsheet.[4] You can use a layout similar to the one below or come up with something that works for your particular situation. The nice thing about a spreadsheet is that it is simple to insert additional rows where needed when there multiple answers to the previous ‘why’.
If you have access to it, mind-mapping software is probably the easiest tool for documenting a Five Whys analysis due to its native tree-like structure. Your problem statement becomes the central node and each level of causal factors becoming nodes off the item you last asked ‘why’ about.
See the Fishbone Diagram wiki page for more info.
NOTE: I strongly recommend you start with a simple method such as sticky notes, a spreadsheet, or a mind map. Once you have finished your analysis it may then be worthwhile to transfer the information to a more graphical structure like the Fishbone Diagram for sharing with others.
A key step in the Five Why’s process that is often overlooked is for the team to gather data and information about the effect that is being analyzed. What exactly is occurring? What is the sequence of observable or known factors that contribute to the occurrence of the undesirable event? Do you know which process and where in the process the undesirable event is occurring? How often does the event occur? Does the event occur most often at certain times? And any other information the team feels is relevant to the Five Why’s investigation.
This data should firmly guide the team to identifying specific causes and asking specific questions. It should also guide the team away from some potential causes because there is no data or information indicating that the cause is relevant.
This is best done through direct observation or through hard data. The team should not just sit back in a meeting room and assume they know all of this information. Or that ‘what is supposed to be happening’ is matching ‘what is actually happening’.
The team should continue to gather data and information throughout the process, as each new ‘Why’ directs them to analyze different potential causes.
Once you have the team, issue, and initial data the next step is to ask the first ‘why’. Why is this issue occurring?
You may want to initially document as many causal factors as you think of, but this can quickly lead to a mass of potential causes that lead to unnecessary dead ends, waste time, and that can distract from the analysis. However, you also don’t want to dismiss every potential cause that is brought up because you want to identify non-obvious causes and because you want to avoid confirmation bias.
So for each potential cause that is raised you want to ask a series of questions to determine whether it should be captured and further evaluated or not. Those questions include: [5, 9]
| Question # | Question | Action if True | Action if False |
|---|---|---|---|
| 1 | Does the proposed cause precede in time the effect we are analyzing? | Keep | Abandon |
| 2 | Can we identify a correlation or association between the proposed cause and the effect? In other words, “If proposed cause X occurs, then result Y occurs”. Or “If proposed cause X is absent, then result Y is absent”. | Keep | Abandon |
| 3 | Can we find any data or proof of the proposed correlation or association? | Keep | Abandon or Defer |
| 4 | Can we identify a mechanism linking the proposed cause and effect? | Keep | Abandon or Defer |
| 5 | Can we find any data or proof of the proposed linkage mechanism? | Keep | Abandon or Defer |
| 6 | Is there anything else needed in addition to this proposed cause for the effect to happen? | Keep | Abandon or Defer |
| 7 | Are there alternative causes or mechanisms, besides those identified so far, that could cause the effect? | Keep | Abandon or Defer |
The key point is that there should be strong (or at least sufficient) evidence that the proposed causes you identify can actually cause the effect being investigated AND that you have considered all viable alternatives.
NOTE: There may be some instances where it is worthwhile to document every conceivable cause and why it was included for further investigation or not. The Five Whys technique does not have clear guidance on this this that I can find. Just be aware that this can potentially increase the time and effort required by a very significant amount.
For each answer identified in the prior step, repeat the process above one at a time by asking ‘why’ that particular causal factor is occurring.
Continue repeating the steps above for each factor identified until asking why yields no further answers or information, or all identified factors are completely outside the control of the organization. Note that just because an organization does not conduct an activity themselves or create the item identified by the factor does not mean the factor is outside the control of the organization. The organization may still have influence through purchasing, contracting, or other processes.
Once you have captured all of your causes, the next step is to identify the systemic and root causes.[10]
Root Causes can be identified because they are the ‘initiating’ factors.[15] Meaning that if they were not present the other causal factors identified would not (or be very unlikely to) trigger the undesirable result.
Systemic causes (or systemic causal factors) are causal factors that spread the impact of your root cause through the rest of the process or system being analyzed, or which enhance the likelihood or impact of other causal factors. They may not be the ‘root’ cause but they often represent a location where mitigating actions can have a large likelihood of success. Systemic causes are likely to show up multiple times in your analysis, often under multiple lines of inquiry.
The remaining causal factors (those neither root or systemic) can be thought of as contributing causal factors. They may still be worth addressing through mitigation efforts, but they usually do not provide as much of a ‘bang for the buck’ as root and systemic causes.
After you have identified all of the relevant causes (both systemic and non-systemic) the next step is to identify the actions that will be taken to address them.
In some cases these actions might include further research to identify or gather supplemental information about specific causes where the team does not feel comfortable making action recommendations, but in general the team should recommend actions that will eliminate or prevent at least the root and systemic causes that were identified.
Joel Spolsky recommends that for every root cause you identify that you “fix it two ways”.[11] What he means is that you should do an immediate fix to solve the problem and a deeper solution that prevents the problem from occurring again. So for example if the customer can’t use their SAAS software because a server went down, you need both a short-term fix (get the server back up and running) and a long-term fix (make changes to prevent the server from going down again or so that the SAAS software can continue functioning even if one or more servers go down).
Eric Ries takes it one step further and recommends that you make a proportional investment in corrective action at EVERY level of causality you have identified.[7] So if you identify a causal factor that has a small impact on your organization, you should commit to making small effort at mitigating or correcting it. Conversely, if you identify a causal factor that has a very large impact then you should commit to a large effort to mitigate or correct it. This is to help prevent you from over or under-reacting to the issues you identify and to ensure that resources and effort are allocated appropriately. However, it’s important to note that you should be taking corrective action at EVERY level, not just the root cause. This enables repeated minor corrections to build up over time at all levels of the problem domain so that the problem domain (or domains) is constantly improving.
When the analysis is complete and remedial actions identified, the next step is to communicate this information. Eric Ries recommends sharing the results widely to the whole company, division, or business unit.[8] For his Fog Creek Software venture, Joel Spolsky actually created a public blog so that they could share the results of their Five Why’s activities with their users.[12,13]
There are several goals with this step. First, it diffuses the lessons learned by the Five Why’s analysis to a broader audience so that they can gain from the knowledge as well.[8] Second, it provides evidence that problems are taken seriously by the organization and shows the remedial actions being taken.[8] And third, it provides an opportunity for others to provide feedback on both the analysis and suggested remedial actions in order to identify potential errors, additional information, or potential unintended consequences of the remedial actions.
The last step, which may be concurrent with the step above, is to act. To implement the remedial actions that were recommended and/or to gather the additional information that was needed for further action to be taken.
For a good example of a Five Why’s process, you may want to read this post by Joel Spolsky.[14]