The 5 Whys Explained Root Cause Analysis

The fact that things can go wrong occasionally is a reality of both life and business. The master plan you spent a month creating falls apart in five minutes due to software errors, equipment breakdowns, miscommunication, and broken equipment.

Usually, a short remedy isn't enough to stop these kinds of issues from happening again. Finding the cause of what went wrong can be aided by using the five whys. Understanding the underlying cause of the issue can help you find a permanent solution.

It can be tempting to fly into "crisis" mode when something goes wrong, seeking to solve it right away and finding someone to blame. An improved course of action is to approach the issue as a teaching moment. The 5 Whys Technique can assist us in pinpointing all the root reasons of the issue after our initial repair has been put in place, allowing us to permanently solve the issue.

The method involves asking why five times to identify the source of your issue.

Background

In the 1930s, the Toyota Motor Corporation devised the five-whys technique.

One of the technique's creators, Taiichi Ohno, stated in his book, Toyota Production System: Beyond Large-Scale Production, "... by stating why five times, the essence of the problem, as well as its solution, becomes evident."

The method is now widely applied outside of Toyota in Kaizen, lean manufacturing, and Six Sigma. In his book The Lean Startup (description here), Eric Ries wrote extensively about the 5 Whys Technique, demonstrating how businesses may use it to effectively solve their problems..

5 Whys Example

Think about a website outage at your business. Naturally, your top goal should be to get the website back online. To make sure that all of the root causes of the issue are addressed so that it doesn't happen again as soon as the site is back up and running, you might find it helpful to employ the 5 Whys technique.

Let's examine the potential reasons why your website might have gone down.

Website outage is the issue.

Why did that occur? Its memory was exhausted.

Why? because of a misconfigured configuration.

Why? due to a mistake by the site administrator.

Why? because development had not supplied sufficient guidance.

Why? Since they believed it to be evident.

You may be thinking that this method is so simple that it doesn't need its own whole post to be explained. The full strength of the 5 Whys is, however, shown in the following stage. At each level of the five whys, you must now take corrective action (referred to in the model as countermeasures). Consider this:

Cause 1: The website ran out of memory.

Countermeasure: Get the site up and running again.

Cause 2: Incorrect configuration.

Countermeasure: Create a Standard Operating Procedure to verify configuration before every update.

Cause 3: Site admin made a mistake.

Countermeasure: Make sure site admin knows how to run the new verification test.

Cause 4: Development hadn’t provided adequate instructions.

Countermeasure: Train dev team to provide sufficient instructions.

Cause 5: Assumed it was obvious.

Countermeasure: Have a word with dev team manager to ensure they speak to their team about the importance of being precise no matter how obvious it seems.

The diagram above has been updated to reflect the entire 5 Whys process:

As you work to resolve issues in this manner over time, you will develop stronger systems and processes, which will lead to fewer issues developing in the first place.

One thing to take away from the example is that many times, a problem that at first look seems technical is actually caused by a person or a process.