Sparring about your Lean issue?
Call René
FEATURE - This insightful piece explores the true meaning of problem solving, looking at the common mistakes leaders make when implementing some of the most important practices.
Words: Csaba Bereczki, Lean Institute Hungary
During gemba walks or problem-solving activities, to eliminate a problem or help the problem-solver, it is important to develop a deep understanding of the situation by uncovering all the hidden relationships that exist between the various elements of the work. The lean literature suggests asking "why?" but I often see leaders struggle to use this as it should be used. I have had managers come to me and ask, "How can I ask an employee a question in a way that leads them to realize what I want?"
Oh dear...
What this tells me is that it is crucial to learn how to use the "why" question correctly; otherwise, it can backfire.
Why didn't you produce the expected amount on time? Why didn't you notice the deviation? Why don't you know the root cause? Why didn't you follow the standard? Why didn't you consider using this solution? Why can't you adjust the machine properly? Why is there no standard? Why is there no 5S in your environment?
When managers try to employ the "5 whys" approach to root-cause analysis, they often overwhelm employees with countless questions, only to get stuck on the first or second why. Although this impedes progress and makes everyone frustrated, many leaders pat themselves on the back after their "coaching session" with employees and walk away thinking that they have just brilliantly applied a questioning technique that helped arrive at a solution.
But here's the thing ... It's not enough to ask "why." You have to ask "why" the right way. So, after asking their question, leaders need to do a quick check: does the question prompt the other person to think or defend? Does he feel comfortable or does he panic? If the employee defends or justifies himself as a result of the question - or, worse, freezes - then you haven't asked the question properly. And if your question involves a suggestion, your colleague will probably just accept your suggested action without really understanding the real situation or underlying problem. These scenarios are not conducive to effective collaboration, and they make front-line staff feel terrible.
The problem with hidden causes is that they must be discovered. Asking alone is not enough: to really understand the root cause of a problem, you must investigate further, by going to the gemba - where the problem occurred - and observing carefully. This is the only way to properly understand the situation you are observing. This is why Lean Thinking places so much emphasis on the concept of genchi gembutsu - going and seeing: even the process owners themselves will see the interconnections within the work more clearly during a gemba walk than in a meeting room. Yet most fishbone diagrams are born in meeting rooms, during brainstorming sessions in front of a flipchart. The ideas that emerge from such scenarios are usually based on assumptions. However, it is worth remembering that the creation of a fishbone diagram (like any other problem-solving activity) should not be the result of merely exchanging ideas, opinions or wishes - which is why we don't call it a "wishbone diagram" - but of process observation and insight.
During the gemba walk, if you ask about the circumstances, factors and activities that led to the abnormality or problem and the person to whom you ask begins to really think about it, you are already halfway there. Remember, "I don't know" is an excellent answer that calls for more investigation and emphasizes that the person is not clear about cause-and-effect relationships related to the problem.
As a leader, it is your responsibility to help people discover and understand those hidden causes. You can do that by:
What if you cannot clearly identify the causes of the problem based on your current understanding? That's what experiments are for! Determine the activities, settings and expected outcome of the experiment, run it and see what happens. If it is well thought out, you will get the result you expected, reinforcing the cause-effect relationship. If not, it means your hypothesis is wrong. In that case, you need to conduct another experiment. This is what the scientific approach to PDCA teaches us.
Let's look at a 5 Whys example that refers to an industrial process that often has to be stopped because of missing labels. This is how the query would go:
Why did the process stop?
Because the colleagues responsible for printing delivered fewer labels to the line.
Why did they provide fewer labels than necessary?
Because they didn't count them or counted them wrong.
Why didn't they count them or count them wrong?
Because they are not paying attention.
Why aren't they paying attention?
.......
Finding root causes often leads to dead ends, where it feels like you can't dig deeper. People just make mistakes and there is nothing we can do about it. After all, it's a human thing! But if we accept this, we also accept that we are unable to make cause-and-effect relationships. Unfortunately, this does not stop us from taking what we think are countermeasures, such as:
We may think these are possible solutions, but all these measures do is institutionalize a value-added activity and crystallize a flawed process. The explanation - or rather, the excuse - will always be the same, "human error."
How can we approach this differently? By focusing on the process, not the person (while keeping in mind that the person is part of the process). With this in mind, our 5 why exercise for missing labels would look like this: Why did the process stop?
Why did the process stop?
Because fewer labels ended up in the box during printing.
Why?
Because the printer printed some labels incorrectly, and did not make up for it with the correct amount (this is just one of many reasons that can be included in a Pareto chart).
Why?
Because the machine is old.
Why?
Because we haven't bought a new one yet.
Great! With one more "why" left, we've already found the root cause of our problem! If only we bought a new printer, the problem would no longer exist. I'm sorry to disappoint you, but no.... this is not the solution either, because we did not learn anything specific about the cause of the problem, nor did we identify any observable event.
Don't worry... There is a way out! To understand why random errors occur, we need to go one step further. Several things could be going wrong in the machine that are causing the missing label problem, and it could take a long time to figure that out. We could say that this should be the focus of a longer-term investigation, but what if we want to partially solve the problem now? Until we have uncovered and eliminated all the causes, we at least want to prevent the error (the missing labels, in this case) from recurring and affecting the next step in the process. To do that, we must first focus on why we cannot detect the anomaly when it occurs.
Thus, the analysis of the deviation (problem) can change as follows:
Why are there fewer labels in the box?
Because the employee responsible for printing delivered fewer labels.
Why?
Because they don't know exactly how many to provide for a large batch.
Why?
Because as they print, they remove and discard the defective labels and mentally calculate the quantity to be replenished. By the end, when they are unsure of the quantity, so much has already happened.
Now we can do something. For example, by making it easy for them to determine the number of labels to be replenished until we solve the technical problem with the printer (without buying a new one, of course). In this case, the question we need to answer is: how can we help them determine the number of labels to refill?
Anyone can come up with alternative solutions on their own. Your only task is to develop a deep understanding of cause-and-effect relationships and, if you get stuck, identify what you are doing wrong. Design an experiment to identify the root causes of a problem, rather than constantly and blindly repeating "why, why, why."
To be a good problem solver, you have to be like Columbo: ask that famous "One more thing" question and keep thinking about the case until he figures it out.
This article is here also available in Hungarian.
THE AUTHOR
Sign up for our newsletter
