The purpose of the 5 whys is to get to the underlying cause of a problem by peeling away the layers of surface-level issues that are actually symptoms of the problem, not the cause. By repeatedly asking "Why?" and examining the responses, you can uncover the deeper and often overlooked causes of a problem. 

The goal is to reach the point where further questioning no longer provides meaningful insights and you've pinpointed the root cause. Once you've identified the root cause, you can work on implementing practical solutions to address it and prevent the problem from recurring.

Example of the 5 whys template in use

Here’s an example of how to apply the 5 whys analysis template to a problem:

Problem statement: The software application frequently crashes during heavy user load, leading to a poor user experience.

1. Why does the software crash during heavy user load?

• Answer: The server becomes overwhelmed with concurrent user requests.

2. Why does the server become overwhelmed with concurrent user requests?

• Answer: The server's capacity needs to be appropriately scaled to handle high traffic loads.

3. Why was the server's capacity not scaled to handle high-traffic loads?

• Answer: The team did not perform proactive monitoring and load testing during development. 

4. Why was there no proactive monitoring and load testing during development

• Answer: The development team lacked the necessary tools and expertise for load testing.

5. Why did the development team lack the necessary tools and expertise for load testing?

• Answer: The project's initial scope did not include load testing, and the team lacked access to proper load-testing resources. 

Root cause: The software crashes during heavy user load are caused by the absence of load testing in the project's initial scope and the lack of access to the necessary resources and expertise for load testing.

Solution: To prevent future crashes during heavy user loads, the team should include load testing as a standard part of their software development process and ensure access to the required resources and expertise for load testing. This will help identify and address performance issues early in the development cycle, ensuring a smoother user experience when the software is deployed.

In this example, the 5 Whys analysis revealed that the root cause of the frequent software crashes during heavy user load was the absence of load testing in the project's initial scope and the lack of resources to perform load testing during development. 

The solution addresses this issue directly, which creates a domino effect that solves the subsequent symptoms of the issue and, finally, the initial problem statement. 

By making load testing a standard part of the software development process and ensuring the availability of the required resources and expertise, future crashes will be prevented. This will also help the team improve the user experience.