Recently I saw Karen Martin post a PDSA flowchart on Twitter. The graphic does a wonderful job of outlining the steps of problem solving and PDSA thinking, highlights the importance of defining your problem and how much time you might need to spend before moving forward in the process, and covers the question of “what does adjust really mean?”. There’s a good chance printing this out and handing it to my leadership team in our next capability building session will generate some rich refresher discussion.
But there was one line on there that really sparked something in me as I read through it. Line 3 says “Set a Target Condition”. Seems simple, seems in line with most problem solving training… so why was I so interested? What sent my brain off racing to analyze this line? This line really resonated with me because many recent kaizen events I’ve been involved in struggle and bog down at the point of discussion about the target, especially if they are trying to go somewhere they’ve never been before vs. getting back to a level they’ve obtained sometime in the past.
Yes, the problem is the difference between target and actual, and understanding the target condition is critical – you have to know where you need to be in order to understand why you aren’t there. But this is not always easy, especially in fledgling lean organizations. I believe manufacturing environments in a company attempting to go through a lean transformation are able to understand and articulate a target condition much faster than those in the office or product development organization. That’s still not saying it’s easy! But they tend to have more historical data, understanding of their manufacturing process and where defects occur, where their problem modules are and where to focus, and how quality, cost, and production rate have trended. Many times you can go back several months or even years in the data and say, “oh, we clearly have trended downwards from where we once were”, or “oh, we clearly made an acute shift in June, you can see it right here on the timeline”. It’s much easier to do this step when you have relevant data available, and when you have people who know how to mine it.
But take for example people in an organization dedicated to innovation, who are attempting to do a kaizen event. Many times the most difficult question is “what should the target be?” because you don’t have a database telling you what the health of your innovation process is, or how many defects that process produced over the past 3 months… or even a clear definition of what a defect is! The same holds true for most office processes: there simply is not a plethora of data to sift through in order to identify targets and potential causes. So in these types of kaizens, either as prework or as a part of the kaizen itself, sometimes the group must develop a system to measure what is going on in order to even understand if they really have a problem!
So back to step 3 – “Set a target condition”. I just like the meaning of the process behind this so much better than something along the lines of “What is the target condition?” Asking “what is it” implies that there IS one out there in your organization and you either don’t know it or can’t find it. The concept of “setting” a target condition seems to empower the group to define what that target should be: either because they know what it should be, or because they decide to set a target that corresponds with some level of improvement from where they think they are. And if they are able to do that, they are able to move to the next step!
I haven’t put it into practice yet, but I believe sending that strong message of empowerment to a kaizen team will enable them to align much more quickly in an event, and move forward to defining causes and countermeasures rather than arguing over what the target actually is. Because no matter what – you’re in that room because something was not up to snuff, and the bottom line is that is doesn’t even matter what the target is – all that matters is that you are not yet where you need to be.