5 Whys Analysis

Things don’t always go as planned. In such situations, it’s important not only to correct the mistake but also to ensure it doesn’t happen again, preventing future losses. To do this, you need to identify the root cause of the problem and review the entire process that led to it. Today, I want to talk about a very simple yet effective method for finding the real cause of an issue. This method is part of “Kaizen”, a philosophy of continuous improvement, and was developed by Sakichi Toyoda, the founder of Toyota, in the 1930s. The method is known as the "5 Whys Analysis".

How It Originated

Before diving into the details, I’d like to quote Taiichi Ohno, one of the presidents of the Toyota production system in the 1950s: “You may encounter many problems, which are opportunities in disguise, but the biggest problem is not encountering any problems at all. Don’t think of any issue as negative; see it as an opportunity for improvement.” Ohno emphasized the need for every problem in the system to be analyzed down to its root cause, often requiring an average of five “Why” questions to be asked. The number five is an average, as the aim is to keep asking questions until you’re confident you’ve identified the real cause.

In Toyota’s approach, the questions are directed to the right people those who are directly involved in the work to get to the heart of the issue. The idea is to avoid making decisions at the management level without sufficient information, instead focusing on understanding the problem thoroughly before taking action. This reflects the “go and see” philosophy of Kaizen.

How to Apply It

The method is quite simple to apply. Let’s continue with a real-world example, even from the software industry. First and foremost, asking the questions to the right people is crucial for getting accurate answers.

Problem: A “Service not found” error appears on the screen.

Question: Why is the “Service not found” error appearing?

Answer: Because the service is not defined in production.

Q: Why is the service not defined in production?

A: Because it’s a service for a request that hasn’t completed testing yet, so it’s normal for it not to be there.

Q: Why is the screen calling this service?

A: Because there was an error in versioning, and the wrong version was created.

Q: If that’s the case, why wasn’t it caught in the pre-production test?

A: Because the pre-production test wasn’t conducted.

Q: Why wasn’t the pre-production test conducted?

A: Because the pre-production environment didn’t have enough data to perform the test.

Q: Why isn’t there enough data in the pre-production environment?

A: Because the EDW doesn’t generate meaningful data here and we have to create test data manually, which takes time.

We could continue asking “Why” even further, as we’ve already done it six times. If you hadn’t asked at all, you might have simply defined the service in production and faced other problems down the line. We’ve gone from a service error to uncovering deeper issues, haven’t we? At a certain point, you’ll realize you’ve reached the root cause and may even encounter chronic problems. These issues might seem unsolvable or difficult to address, but in Toyota’s culture of continuous improvement, they focus on finding the root cause and solving it there.

Perhaps when you reached the third question and discovered the wrong version, you might have stopped and thought, “Hmm, I understand the rest,” and quickly focused on solving the problem. This was an example we experienced, and as a team, we understood the issue and, most importantly, focused on solving the main screen problem by addressing the answer to the third question. Of course, we’re aware of the issues related to questions four, five, and six, and discussed the need to take precautions and manually provide the necessary data for testing next time.

I don’t see the “5 Whys” method as just a problem analysis tool. In the world of software or in real-life situations, finding the underlying cause of an issue and reaching the right solution often requires asking several iterative questions. A great example of this is the requests we receive from business units. Some of these are presented to us as solutions rather than requests. To ensure that the proposed solution is correct, you need to find the real reason behind the request and understand which problem it’s supposed to solve. Here’s another experience:

X: We need to write a batch process that returns the "National ID"s of customer's spouses and the information retrieved from "National Database API" for these spouses in a file.

Y: Why do they need this batch process, and where will this information be used?

X: This information will be used in the application evaluation system.

Y: How will they use it, and at which stage?

X: They will use the "National ID"s during the approval stage, placing them in a file to get the results.

Y: Why are they handling this manually rather than seeing the spouse information directly on the approval screen? Wouldn’t it be better if the spouse information was queried online and displayed when the approval screen is opened?

X: Hmm, yes, let’s discuss this with the business unit.

X: Yes, you’re right, that would be better.

Conclusion

In the end, whether it’s a problem or any other issue, it all comes down to following the topic until it makes sense to you and reaching the root cause. Not every issue may be straightforward, and there may be points of confusion, but I believe the “5 Whys” method is always worth applying.

Lastly, if I were to ask you who applies this method the most, or where you see it most often, what would you say? Children... They apply the right methods to understand this world, which they are unfamiliar with and trying to adapt to, by asking a series of “Why” and “How” questions. “Why do we stop questioning so much as we grow older?” I believe the answer is this: once we reach the same point, the same fundamental issue, we stop asking questions, thinking, “I get the rest.” Perhaps because we know the rest, or maybe we’ve given up... When children ask questions, let’s not cut them off in frustration; let’s not dampen their curiosity and make them give up too soon. I hope you may give this technique

Thanks for reading.