Problem-Solving is a difficult exercise, whoever practices it knows this. But difficulties do not always appear where you would expect them. During a recent event, I had the chance to witness a methodical Problem-Solving performed by true beginners.
Today’s example will be that of a group of 12 IT managers, who wish to experience actual problem-solving “as Lean Management does it”. They have a problem case on which to practice, e.g. “Packaging applications for distribution on production servers takes too long”. Their knowledge of Lean Management and its artefacts, such as Gemba or PDCA or Work Standards, is void.
But they are highly experienced and self-confident. They are decisive and acute. They even are open to new techniques. In other words, they are good and acknowledged managers.
On my end of the rope, I have a few simple questions to guide them to express that problem “PDCA-Style”. I go first.
- What are the last cases of that issue you witnessed?
Their replies mention various factors for delays such as performance issues or failure causes in the packaging process (eg. “Packaging is delayed because packages don’t work”). It takes quite some time and discussions to lay one specific case on the table, as this question takes them off guard.
In Lean Management, PDCA problem-solving starts with “Analyze your red bins, sort and count problems, pick one faulty case and look at it”. This is a slippery first step, you really do want to have one case before your eyes. If you don’t, you will engage in useless general considerations (aka meeting-room discussions).
Beginners in problem-solving are not used to this, our current workshop group is no different. Nevertheless, we do have one case so we will take it from here. Next question.
- How long did this packaging take? How long should such a packaging take?
The first part is easy: 7 months. The second part takes the discussion completely out of focus for more than 20 minutes, with answers ranging from “it depends” to “perhaps we should set SLAs on this contractor team”. The group struggles as its answers are rejected as ‘Not a Number’. In the end, an investigation action is taken as the group recognizes it doesn’t know the answer.
There are 2 distinct difficulties here. The first is to provide no answer if no answer is known. A very painful abandonment for self-confident professionals, all-the-more painful when said professionals are managers. The second is to trade an action for an investigation: would you? Not very likely, since companies put a lot of pressure on quick results on their staff.
Realize you don’t know and investigate instead of acting. This is a call to “Go to the Gemba: collect cases to provide figures, look at more cases. Our group learns to slow down to take safer actions. Moving on.
- What is the packaging process, and where do problems occur?
Here again, an unusual question for people who are action minded. This question puts a stop to the growing flow of action ideas: no ideas just yet, let’s just draw the process and spot the problems on it first.
The packaging process is a 7 steps process involving 5 different teams. It can take up to 7 months for delivery, with unknown quality level. It holds many problems, waste, variabilities. These will only be addressed with an organized action plan, which in turn will only emerge from targeted cause analysis. Therefore, we need to know what distinct problems appear where on the process.
Once the process is drawn, people in the group start pointing at specific places where specific issues occurred. A little drawing goes a long way; it visually separates issues and helps people focus on those relevant to them.
The group keeps slowing down and tries to understand the problem by splitting it into smaller parts. And this is what we do now: take one issue, dig into it.
- The assembly of the package (step 4 in the process) shows many quality issues due to return codes wrongly interpreted, what is the cause for that?
Believe it or not, one of the first reply I got with this question was “Because there are no penalties on this contractor team for non-quality deliveries”. Can you see what is wrong with the reasoning beneath this reply?
First and most obvious: this is clearly not a cause, this is an action disguised as a cause, a new form of “action now!”. Second: you can hardly see the connection between return codes wrongly interpreted, and a penalty applied at the end of the month to a company which delivers packages all day long. Third, and worst: this is an automatic reasoning “non-quality + contractor = needs for penalties”.
We need true hypotheses here, and a way to confirm them on the Gemba. This vital discipline is painful too; it requires that we suppress our reflexes and engage in deeper thinking.
At that stage, we spent 90 minutes kick-starting our problem solving about the packaging process. This is the end of our workshop, and the group ultimately provides better answers after reworking on their first attempts. Most participants tell me they found this enlightening.
As a conclusion, let’s imagine we are a few months later: the group improved the lead time on the packaging process and provided a nice PDCA report about it. You are reading, perhaps thinking “this is great, and it must have been difficult for them”. You would be right, and here is what has been the hardest for them:
- They wanted to brainstorm on the general situation, instead they took one specific case and studied it
- They wanted to act immediately, instead they went to the Gemba to find the real problem
- They wanted to “eat the elephant” (solve it all), instead they made the problem visual and separated the issues
- They wanted to quickly apply well-known solutions, instead they investigated deeper
Changing from the original mindset to the Lean Management – mindset is hard. Teams that practice PDCA problem-solving deserve credit for this, on top of acknowledgement for “Problem solved”.
How do you engage your teams in this change of mindset?
Emmanuel Richard
Better, Faster, Together - Operae Partners blog 