In the Kaizen process, we ask everybody to identify problems (or opportunities) and then to write down an idea that could potentially solve the problem (or at least solve it to some extent).
What's written down on the card (or submitted into KaiNexus software) is the starting point for discussion within a team and/or with a supervisor.
When coaching an organization on Kaizen recently, I got a really good question from a physician who had taken the excellent week-long Lean healthcare training at the University of Michigan. She said that, in the Lean training, they said you should never “jump to a solution” in the course of problem solving. She raises a good point.
Many of the problems identified and brought forward through this Kaizen process don't require any root cause analysis. That might sound shocking. Isn't Lean all about “the 5 whys” and root cause analysis? Sure, where it's needed. Root cause analysis happens a lot in Lean.
Some relatively problems, “Our IV trays are disorganized” have a somewhat obvious solution, “Organize the trays and remove unneeded items.”
We can just fix the trays and then recognize those who did so, share the idea with others, and then check back to see if the idea really worked and if it was sustained.
Some problems are more complex, such as “Patients are waiting too long in the waiting room.” We couldn't really jump to a simple solution there. We'd want to do root cause analysis and maybe manage this through an “A3 problem solving process” or something more rigorous like a “Rapid Improvement Event” or a longer-project.
Or, we can break a bigger problem down into smaller pieces, taking care to not sub-optimize anything.
As Kaizen leaders, we learn how to triage things that are submitted through the Kaizen process. It this idea an easy “just fix it”? If so, we can have a bias for action and test ideas experimentally, in the PDSA approach. If it's a more complicated problem or something with a non-obvious solution, we can start an A3 or get a Rapid Improvement Event sponsored.
This can all work together. We can't oversimplify everything, nor should we overcomplicate everything.
A similar contrarian thought is that not every improvement needs to be a formal “Rapid Improvement Event.”
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
According to Daniel Kahneman, jumping to solutions is advantageous if: 1. the solution is likely to be correct (i.e., the answer is fairly obvious), 2. the environment is predictable (low variability) and 3. the penalty for being wrong is small.
When jumping to a solution, the study/check process in PDSA/PDCA becomes paramount. Despite our best efforts to assess a situation, the things we believe should be obvious just aren’t sometimes. Better to study/check thoroughly than pay the price later.
Yes, I usually recommend that if a proposed solution/countermeasure is small, inexpensive, easily testable, is not risky, and easy to undo (low penalty for being small), then the bias should be for quick action AND following up.
We can’t just Plan-Do or Do-Do, we have to remember to Study and Adjust to close the loop. Otherwise, we’re just randomly doing stuff.
Kaizen can have a bias for action, but can be disciplined and systematic (without being bureaucratic).
Mark,
This is a very good point. You do want to solve the symptom but know the root cause of the issue first. Leaders are pressured in getting results that they miss going through the process on fixing the issue permanently. Now, I always advise clients to make the decision based on what the data is telling them before they go out and start fixing issues. The response in many cases “what data?” That is where they need the most help in creating a process that helps capture the right data to make an informed decision on which issues have the most impact. During the process there will be issues what will be considered ” quick fixes” as long you can quickly identify the root cause. Thanks for sharing .
I like Joel’s filter above. Plan to use on Monday with a new group.
Additionally, why do we want every employee to be a problem solver?
My answer is we want everyone engaged and then we want the benefits of actual improvement.
Focus on engagement first. Rigorous RCA is often an extra burden, especially for the newbie. After folks are engaged, then focus on structured problem solving including RCAs. My personal experience is that you can have an engaging and meaningful kaizen system without RCA, but the ideal is to get to RCA thinking in the end.
Hi Mark,
I find table 9-3 in Gemba Kaizen very relevant here. Mr. Imai divides problems into three categories according to their nature, then he estimates their respective percentages and gives some example:
Type A: Causes are clear Countermeasures can be taken immediately (70-80%) examples: Standard was not followed, out of spec materials and supplies.
Type B: Causes are known but countermeasures cannot be adopted (15-20%) example: Occurs at the time of setup adjustment; example 2: Occurs during frequent stoppages of equipment.
Type C: Unidentified causes (10-15%) Example: Situation suddenly went out of control
I like it because it gives a clearer picture on what to expect in a workplace.
Thanks
Sami
I love this conversation! As a coach, I’m always looking to improve my skill at helping our folks find the sweet spot between analysis paralysis and jumping to solutions.
I agree that we can harness our people’s bias for action by accepting the just-do-it approach in the right situations….as long as the PDSA mindset is being utilized. It doesn’t even have to be a formal PDSA cycle using standard templates or anything, so long as the individual is pursuing the just-do-it in a scientific method-like manner.
Regardless of whether an idea falls into the “just-do-it” or “requires deeper RCA” category, there’s another factor at play, and that’s the question of whether the improvement effort is a step toward something or simply a stand-alone improvement. A stand-alone improvement that is not connected to any goals/plans/strategies/visions/etc. is still highly valuable just for the way that it engages our people and teaches them skills. But if that same improvement effort was connected to a bigger challenge, it becomes much more meaningful to both the individual and organization.
Mark,
The example you use:
Has an implicit “why” in there, i.e. “Why are our IV trays disorganised?” It could be that they have never been organised so the solution is as above. But it could be that there is a method for organisation and people aren’t following it, which begs another why: “Why are people not following the method?”
I suppose my point is that, especially at the beginning of learning improvement,it is sometimes useful to slow down, just a little, and for coaches to tease out the implicit “why?” even when it looks like there is an obvious solution. Mainly because it will stand people in good stead for more complex situations.
That’s a great point. Asking “wny?” once might be a helpful question, but that’s still not a formal root cause analysis.