Problem Resolution: The dual nature of problems and the 5 Whys.

Over the past months, I have been contributing to different “IT Consulting” articles, and I have seen some of the contributions to be of interest to many in my network. This is why I decided to expand on the most liked contributions with a monthly article. So here comes the first topic: "Problem Resolution and the dual nature of problems"

Problem resolution affects all of us almost every day, both in our professional and in our personal lives. The funny thing is that this key competence is a skill that I have not seen taught formally anywhere. I have myself gone through different Masters’ Degrees in different disciplines (technical, management, business…) plus a PhD in Business Administration, and I have not seen anything about this in any syllabus. And yet, it is a competence that defines our ability to deal successfully with problems.

The nature of the problem is actually very wide; it can be technical (for example, a bug in a piece of code), related to interpersonal conflict or any other nature; either way, all are problems that need to be fixed.

I have found different models for problem resolution during my professional career, but the one that has been the most effective due to its simplicity is the 5 Whys. In the world of problem-solving and continuous improvement, the 5 Whys methodology stands out as a simple yet powerful tool. It is so simple and so effective that even the NTSB uses it as one of its frameworks for the investigation of air accidents. Developed by Sakichi Toyoda, the founder of Toyota Industries, this technique is integral to the Toyota Production System. It is widely used in various industries to identify the root causes of problems. This article will explore the true nature of problems alongside the origins, principles, and applications of the 5 Whys methodology and how it can be a game-changer in your problem-solving toolkit.

Origins of the 5 Whys

The 5 Whys technique was developed in the 1930s by Sakichi Toyoda, a Japanese industrialist, inventor, and the father of the Japanese industrial revolution. Toyoda's innovative approach was born out of a desire to improve manufacturing processes and enhance product quality. His methodology was later incorporated into the Toyota Production System, which is renowned for its focus on efficiency, quality, and continuous improvement.

The Principles of the 5 Whys

At its core, the 5 Whys methodology is about asking "Why?" repeatedly until the root cause of a problem is identified. Here’s a step-by-step breakdown of how it works:

1. Identify the Problem: Clearly define the problem you are facing. This could be anything from a manufacturing defect to a customer service issue.

2. Ask Why?: Ask why the problem is occurring. Write down the answer.

3. Repeat the Process: Take the answer from the first "Why?" and ask "Why?" again. Continue this process until you have asked "Why?" five times. This typically leads to the root cause of the problem.

4. Address the Root Cause: Once the root cause is identified, take corrective actions to address it. This prevents the problem from recurring.

One real anonymised example:

Problem: The software application is slow and unresponsive.

Why is the software application slow and unresponsive?

Because the operations on the data structures are taking too long to execute.

Why are the operations on the data structures taking too long to execute?

Because the developers are using ListArrays instead of more efficient data structures.

Here is where everyone tends to stop. They go, fix the code and everyone happy. With the exception that very soon, another totally different code problem will occur, and the company will end up in an endless, very expensive, vicious cycle of bug fixing…. Sakichi Toyoda said: “Just be the typical annoying kid and keep asking why again.”

Why are the developers using ListArrays instead of more efficient data structures?

Because they are not familiar with AVL-balanced trees or other efficient data structures.

Why are the developers not familiar with AVL-balanced trees or other efficient data structures?

Because they have not received training in advanced data structures and algorithms.

Why have the developers not received training on advanced data structures and algorithms?

Because the company does not have a structured training program to enhance the developers' knowledge and skills and the hiring practices do not mandate higher education on computers for developers.

At the end of the 5th Why, you will realize that the true nature of a problem is typically dual: one side is very tactical (the immediate fix for the actual moment, in our case, is code to fix by using a different data structure); and the second one is strategic, and that is the long-term one that will prevent many wider future problems from happening, in our case is either changing hiring practices or adding training on advanced data structures for all developers.

Never stop being curious like a kid.