Building upon the earlier posts about autonomy en PDSA, I automatically tumble upon a well-known, but often — during the Study phase of PDSA — ineffectively used technique: 5x why? A technique that has to prevent that a team jumps to conclusions too early and that leads to a productive and structural solution to the problem by means of a more thorough problem and root cause analysis. But it takes more than just asking five times “why?” to the team…

Solving Problems

Many organizations see the solving of problems more as a necessary evil than as an opportunity to learn about their current ways that actually cause these problems. I often see organizations showing two types of behaviors when it comes to dealing with problems:

1. A concrete problem is quickly generalized and externalized: “We’ve got a capacity issue”, “It’s the supplier again”, “The IT system doesn’t help”. The solution for these general and externally caused problems is of course also quickly found but as always typically is somewhat large and costly to implement… . Very often these solutions for instance involve investments, extra people, a new IT system or at least new functionality, … . And even if this “solution” is being presented as the “silver bullet” and actually implemented, I still would have many questions about the effectiveness of the proposed “solution”.
2. A concrete problem is trivialized and a “solution” is quickly arranged: “Wait a minute, I’ll fix it so we can get on with our work” and “If you wanna make an omelet, you gotta break some eggs” let’s say. Problems are an accepted element of the work, and the local team heroes often quickly have a solution at hand. But did we really solve something?

Work on a Concrete, Individual and Recent case

A true solution should systematically eradicate the possibility of having concrete problem cases. The best way to do this is by starting with a concrete, individual and identifiable case: an order (line), a product, subassy or part, a file, etc. Only when having a real case at hand teams can truly productively work on the analysis of the problem. Otherwise, chances are that teams will quickly visit the usual and commonplace suspects when studying causes using for instance 5x “why?”. First condition for a productive 5x “why?” session therefore is to have a concrete case at hand (physically).

A second condition for a productive problem analysis is the recency of the case. Asking five times “why?” about a case that happened three weeks ago typically leads to generalizing the case which is where we didn’t want to go. This is also the underlying reason for quick response management and low inventory levels in Lean. Delays in reacting to problems are a major roadblock in finding the actual root cause of a problem.

5x “Why?”

If the conditions of concreteness and recency have been met, the technique of asking 5x “why?” can be applied far more effectively. But in my experience, many other pitfalls remain in the actual use of the technique. I will mention five:

1. Accusations and blame: by asking “why?” it may well happen that a team or an individual associate feels being hard pressed and attacked and that the leader directly blames the team for the detected problems. It is important to stay focused on the work and how the work could have led to the actual case that shows the problem that is being investigated, not the associate or the team. Ask about how things happened and use a style in which it is clear that you’re after understanding the way the work works, not the people.
2. Excuses as an answer: something that often happens is that a team or associate puts an excuse forward when being asked after why something happened. “That was done in order to prevent…” often is the way in which you will get an answer after asking “why?”. This can be prevented by not so much asking “why?” (even if the technique is known as 5x “why?”), but to ask “how” the work was done.
3. Logic and proof: only asking “why?” is not a guarantee for finding the true cause of a problem. Make sure that the team doesn’t start generalizing in the middle of their analysis and make sure the team can still explain how the concrete case at hand was produced. Also always stay aware that any answer to your “why?” question is only a hypothesis that should be made acceptable either through logic, existing and known natural laws, or with an experiment.
4. Questioning structure: Although the technique is known as 5x “why?”, the actual number of five is of course only an indication. The essence is to continue asking the question until the whole team arrives at an acceptable explanation of how the problem case has been produced. A related aspect if the logic of the questioning. It is important to stay on the logical reasoning track. Too often I notice teams go of that track and skip logical steps. What may help is having a visual of the value stream that produced the case at hand or even actually following the case through its process on the shop floor.
5. Autonomy: people have a natural tendency to externalize causes to their problems and to provide answers that direct the team to factors outside their own circle of influence. Of course, this may truly be the case, but as the work itself was done by the team, first focus should be on evaluating the potential causes that may exist within the team’s boundaries. Also, the more causes can be eliminated by the team itself, the more autonomy the team actually has. Organizations where problems are escalated to higher organizational echelons almost without exception should therefore also be a reason for an organization to look at its organizational structure and the way autonomy has been built in.

Structured Problem Solving

Many organizations pretend to be well on their way with their Lean initiatives. Still, it strikes me that on the topic of structured problem solving in which the 5x “why?” technique is only one of the elements, many steps still can be taken. Again and again, it is clear that there is no shortcut to make Lean thinking and doing to the normal way an organization fulfils its purpose. The key thing which is maybe in the way of that can even be that many think there actually is such a shortcut…