The 5 Why Framework to get to Root Cause

Mistakes happen. I like the quote “New mistakes are OK. Old mistakes are not.”

The 5 Why Framework was developed by Sakichi Toyoda years and years ago.

This is a great video that explains The 5 Whys and the Countermeasures that need to be taken to correct and avoid future mistakes.

I also had this video transcribed, and here is the text:

Hello and welcome to today’s lesson, where we’re looking at the five whys, which is a technique that can help you find the root cause of a problem. Now, it’s a fact of life and business, that sometimes things go wrong, software fails, equipment breaks, communication is misunderstood, and the master plan you’ve spent the last month putting together, falls apart after just five minutes. Now, to prevent these types of problems from recurring, you usually need more than just a quick fix. So, the five whys, can be a useful tool in helping you to get to the root cause, of what went wrong. And by understanding the root cause of the problem, you can solve it in such a way that it doesn’t reoccur. Now, the technique works by asking, why, five times to find the root cause of your problem. And it was originally developed by Toyota in the 1930s. So let’s take a look at an example.

Suppose that your company’s website is down. Now, you obviously need to get the site back up and running ASAP. So that’s just what you have to do. You can’t just leave it there while you go away to conduct your five whys. You have to address that as a priority. But, immediately after the site is back up and running, you might then find it useful to use the five whys technique, to ensure that all the causes of the problem are addressed, so that it doesn’t happen again. So let’s take a look, at what might have caused your website to go down. So, why did the website go down? Well, it ran out of memory. Why did it run out of memory? Well, because it was incorrectly configured. And why was that? Well, because the site administrator made a mistake. And why did they make that mistake? Well, because development hadn’t provided adequate instructions. And why was that? Well, it was because they assumed it was obvious how to do the work.

Now, in our example, what appears at first, to be a technical problem, ends up being a human problem. Someone made a mistake. In this case, the development team, they made an assumption that the work was obvious. Now, so far you might be thinking that this technique, is so basic and simple that it doesn’t really require an entire video to explain it. Well, it’s actually the next step where the real power of the five whys is revealed. And in this step, you need to take corrective action, and corrective action is called countermeasures in the model. And you take that corrective action at every level of the five whys. So for example, the first cause was that the website ran out of memory. So you might take the countermeasure, get the site up and running again immediately. The second cause was incorrect configuration. So here our countermeasure is, to create a standard operation procedure to verify configuration before every update. Third answer or cause, was the site admin made a mistake. So here our countermeasure might be, make sure the site admin knows how to run the new verification test.

The fourth cause was the development team hadn’t provided adequate instruction. And here our countermeasure might be to train the development team to provide sufficient instructions. And our final cause, our root cause was, they made the assumption it was obvious. And here our countermeasure might be to have a word with the development team manager, to ensure they speak to their team about the importance of being precise, no matter how obvious something may seem.

SO the real key point here, in this example, is that we’re addressing the causes of the problem at every level, so it doesn’t happen again. So based on that, the diagram you see here more adequately reflects the five whys whereby, we’re deploying countermeasures at every level of our analysis of why the problem occurred. Now, over time, as you fix problems in this way, you will build more robust processes and systems, and that should result in fewer problems happening in the first place. Now, another important thing to note from this example, is that often what our first glance appears to be a technical problem, transpires to be a human problem, or a process problem at its root. And, the final thing to be aware of here, is that asking why five times, is simply a rule of thumb. You may have to ask why just three times, or you might need to ask it 10 times, to get to the real root of the problem.

So, if you want to run your own five whys meeting, then these are the steps you should follow. So step one, organize your meeting. So arrange for everyone to get together who might be affected by the problem, or have input into its solution. Now, if you’re not leading the session yourself, then make sure that somebody is. It’s the session leader’s responsibility, to lead the meeting and the process and assign people as being responsible for countermeasures. Step two is to define the problem statement. So, at the start of the meeting, define the problem you’re trying to solve. You might want to write it on a whiteboard if you can. Step three, ask the first “Why?” So, ask your assembled team why the problem is occurring. Now, if there’s more than one reason given for the problem, then ask your team to vote on the most likely cause. And write their answer next to your first why on the whiteboard.

Step four is to ask “Why?” four more times. And each time you do that, use the previous answer to base your next question on. And once you’ve done this, you’ll have five reasons, one for each why? question. Finally, step five is to determine your countermeasures. So agree what counter measures you will take to address each of your five reasons, that are now on the whiteboard. Step six is important, it’s assign responsibilities. So for each countermeasure, agree who is responsible for it, and how they will measure the success of that countermeasure.

Step seven is to monitor progress. So agree how progress will be monitored, and usually that’s going to involve a followup session. That could be in a few hours, a few days, or even a few weeks. And then finally, step eight, close the meeting. Now that you’ve determined all the causes of your problem, including the root cause, you’ve determined your countermeasures, and how you’ll monitor progress, it’s time to bring your meeting to a close.

So there are a number of advantages and disadvantages associated with the five whys technique. In terms of advantages, it allows you to identify the cause of your problem, not just its symptoms. It’s simple, and it’s easy to use, and it helps you avoid taking immediate action, without considering if you’ve identified the real root cause of your problem. In terms of disadvantages, [inaudible 00:07:10] different people may get different answers as to the cause of the exact same problem. And that raises the question about the reliability of the technique. It’s only as good as the knowledge and experience of the people in the room, using it. And finally, you may not dive deep enough to uncover the actual root cause of the problem entirely.

So, in summary, to prevent some problems from recurring, you need more than just a quick fix. Now, the five whys is a useful technique, that can help you analyze and fix problems so that they are eliminated for good. The technique works by asking why five times. And for each answer you discover, you deploy countermeasures to stop it happening again. Continue asking why, until you’ve recovered and addressed the root cause of the problem. And if you over time solve problems in this way, then eventually you should begin to encounter less and less problems in general. So that’s it for this lesson. Really hope you enjoyed it. And I look forward to speaking to you again soon.