I have been noticing a significant linguistic difference between those who still embrace the “implement the tools” paradigm, and a much smaller (but growing) group are are adopting the PDCA thinking structure as a framework for everything else.
It comes down to how a problem is stated.
We were looking at an operation with a lot of variation from one team member to another, both in terms of performance, and actually, what precisely was being done.
When asked what the obstacle was, the immediate reply was “Lack of standard work.”
While this may have been true, it is not a statement of the problem. Rather, it is defining the problem as “lack of a specific solution.”
This may seem to be an semantic discussion, but consider what the responsible supervisor hears, and interprets, from these two statements:
“There isn’t any standard work.”
or
“There is a lot of variation from one operator to another.”
In the first case, we are telling the supervisor what she isn’t doing, hasn’t done, needs to do. It isn’t even teaching.
In the second case, we are pointing out something that we can both agree on. I haven’t even said it is a problem, and honestly, in some cases it might not be (yet). It is a simple observation.
If, then, we agree that this variation is leading to some undesirable effect, then we can talk about countermeasures. That might include trying to capture a baseline, teach it to a few of the team members, and see if that helps. We can name it later.
Which of those approaches is more likely to enlist the support of the supervisor, which is more likely to put her on the defensive?
Lean thinking is not a checklist of which tools are in place. It is a step-by-step convergence on smoother flow, dealing with observed obstacles and problems.
This isn’t to say that the coach doesn’t have intimate knowledge and experience with flow, with standard work, and everything else. But the approach must be respectful of the people who are struggling with the real world issues every day. Saying “You need to implement standard work” isn’t helpful no matter how much logical justification is wrapped around it.
Teaching someone to observe the impact of variation on the process might seem slower, but it will get them there much faster because it engages their curiosity.
Mark,
I can’t speak for to many others but the practice of teaching variation is key to understanding Lean and probably a great many other frameworks for improvement.
In our “process” we start by getting staff to define what it is they are trying to achieve, this allows them to own this. In the manufacturing teams this is often straight forward, in the knowledge sector, individuals or small teams are often working on a series of different customer requirements for different clients at the same time.
Focussing on these requirements, they often find they are the same across the many clients they have, just dispersed over a period of time.
Having common outputs then allows us to build the Value Streams and the variation in processes used by different teams or for different clients is exposed.
At this point, in our experience, individuals and teams are much more comfortable asking the question “Why do we use different process, if the requirement/output is the same?”
Where the requirements are different the question is then around suitability of the process for the output.
Finding the reason for the variation helps in identifying solutions and ultimately then, which tools and techniques are suitable.
regards,
Mark Greenhouse