“Five whys” is known as a simple way to get to the root cause of a problem — but the simple methodology is better suited to simple problems rather than complex ones.
Quality Assurance requires analyzing incidents and taking measures to prevent them in the future, and that analysis often requires more troubleshooting than the 5 whys process can provide. So while the idea behind this problem-solving technique sounds great, it’s not always the best way to solve complex problems.
In fact, using the 5 whys method can sometimes be risky or completely counterproductive.
What is the 5 whys technique?
The 5 whys method involves asking 5 why questions designed to explore the cause and effect associated with a specific problem. The questions guide you through a root cause analysis with the goal of the final “why” revealing the root cause of the problem.
The 5 whys method came from Toyota Motor Corporation’s production system, defined by Taiichi Ohno:
“The basis of Toyota’s scientific approach is to ask why five times whenever we find a problem ... By repeating why five times, the nature of the problem as well as its solution becomes clear.“
Examples of 5 whys analysis
The most famous 5 whys example is the tale of the Lincoln Memorial problem of fast deterioration.
Why 1: Why is the monument deteriorating?
Answer: Harsh chemicals are frequently used to clean the monument
Why 2: Why are harsh chemicals needed?
Answer: To clean off the large number of bird droppings on the monument
Why 3: Why are there a large number of bird droppings on the monument?
Answer: The large population of spiders in and around the monument are a food source to the local birds
Why 4: Why is there a large population of spiders in and around the monument?
Answer: Vast swarms of insects, on which the spiders feed, are drawn to the monument at dusk
Why 5: Why are swarms of insects drawn to the monument at dusk?
Answer: The lighting of the monument in the evening attracts the local insects
The fifth answer is called the root cause of the problem. The idea behind the 5 whys is to determine the underlying cause of the problem and propose a solution. In this 5 whys example, the root cause is the monument lighting, so the solution is to change how the monument is illuminated in the evening to prevent the attraction of swarming insects.
However, that solution only addresses one of many problems. A report detailing the causes for the monument's rapid decay, along with the steps implemented to halt it, shows that there are multiple causes and a range of solutions are needed to mitigate the ongoing decay.
The 5 whys technique in the workplace
The Lincoln Memorial example shows that the 5 whys are too simple for difficult problems with various external factors. But what about issues related to engineering, quality improvement, control, and assurance, or people management?
Imagine there is an engineering issue in the production environment, resulting in users encountering an error while attempting to make a purchase.
A 5 whys analysis for this problem might be as follows:
Why 1: Why did the users get an error message while placing the order?
Answer: The database didn’t have the fields for the new order placing backend call
Why 2: Why didn’t the database have the fields?
Answer: The database migration failed
Why 3: Why did the migration fail?
Answer: The deployment pipeline failed to execute the migration script
Why 4: Why did the deployment pipeline fail to execute the migration script?
Answer: Because the database administrator (DBA) upgraded the database (DB) version on production and there was a DB version mismatch
Why 5: Why did the DBA upgrade the DB version on production?
Answer: The security audit found a security issue in the previous DB version
The response to the fifth question is suggested as the root cause of the problem. A potential solution for this problem might be ensuring that any database alterations post-audit are adequately communicated to the developer groups.
However, the mere use of the 5 whys method shifts focus away from the proper solution and to the one derived from the last answer. No one considered that the proper solution here could be to make sure that the teams own the infrastructure (both organizationally and technically, for example through IaC) so the team members could apply changes to the infrastructure while the DBA merely consults them.
Now let’s explore a team management example. Imagine the key developer, Yara, leaves the organization, resulting in the loss of their specific expertise for a particular system, like single sign-on (SSO).
Using the 5 whys technique in this context could look something like this:
Why 1: Why was the knowledge lost?
Answer: Yara was the only one working on SSO and the workflow wasn’t documented
Why 2: Why wasn’t the work documented?
Answer: Yara always took care of SSO without issues, no one saw a need to document it
Why 3: Why didn’t anyone see a need for documenting Yara’s work on SSO?
Answer: The organization does not have a formal process for documentation
Why 4: Why doesn’t the company have a formal process for documentation?
Answer: The CTO hasn’t set it up
Why 5: Why didn’t the CTO set it up?
Answer: They’re a recent hire and haven’t had time yet
The response to the fifth question is suggested as the root cause of the problem. A potential solution for this problem might be making sure the CTO has enough time and priority to enforce the documentation process.
Once again, the mere use of the 5 whys method shifts focus away from the proper solution and to the one derived from the last answer. No one even considered that maybe the proper — and cheaper in the long-term — solution would be to prevent people from leaving the organization by providing competitive pay and benefits and putting a stronger focus on employee engagement.
Looking at these examples we can see a peculiar thing — use of 5 whys technique on any incident narrows the scope of the investigation to just one path, the path of the supposed casual relationship.
The problem with the 5 whys theory in practice
Every incident or problem involving humans is a result of multiple interconnected factors affecting different people in a complex interplay.
For example, understanding why a person commits a crime is usually complex and includes analyzing various factors such as socioeconomic background, education, neighborhood, family influence, mental health, and personal choice. Trying to pinpoint a direct cause and effect would overlook how all of these elements influence each other and affect the outcome.
In the previously mentioned engineering problem example, there are at least two perspectives on the original problem:
- Organizational: DBA is distorting the system the team is responsible for
- Technical: The pipeline is failing due to the changes done by the DBA
Investigating the problem from only a technical perspective makes us discard the organizational one and dive deeper into the technical details. Each subsequent question with a single answer discards more factors influencing the problem.
In the management example, there are at least two major perspectives of looking at the problem:
- Documentation
- Developer retention
A simple flowchart exposes several other potential causes to the problem and thus suggests various corrective actions that could be taken.
On the right side of the diagram we see the 5 whys method yielding one simple path of investigating the documentation perspective. On the left side, we see a draft of the retention perspective analysis. Even in these two oversimplified examples, we end up with five different root causes of the problem.
Consider the complexity of your problem before attempting the 5 whys method
While the 5 whys technique may be a helpful decision-making tool for simple problems, be cautious of trying to apply it to complex situations.
Using the 5 whys method clearly discourages us from properly investigating all the factors which led to the problem. There’s no way to answer an open “why” question with just one answer as there are always multiple factors leading to the specific problem. Additionally, answers are always limited by boundaries of our existing knowledge and our cognitive biases.
Ready to solve more complex problems? Sign up for a demo to see how Qase can help.
References:
- https://www.frontiersin.org/articles/10.3389/fpsyg.2015.00888/full
- https://www.taproot.com/best-5-why-examples/
- https://pubs.usgs.gov/of/1996/0518/report.pdf
- https://www.frontiersin.org/articles/10.3389/fpsyg.2015.00888/full
- https://www.knowledgehut.com/blog/agile/root-cause-analysis-agile-teams#5-whys-analysis-in-action%C2%A0
- https://kanbanize.com/lean-management/improvement/5-whys-analysis-tool
- https://wine2021-exp.github.io/
- https://dspace.mit.edu/handle/1721.1/2137
