Expectations

This is a bit of a more pragmatic breakdown from the “How Strong Is Your Immune System?” I plan to follow-up with some practical approaches and tools to implement and conduct the kind of problem solving that needs to be done every day.

As we “promote lean,” what expectations to we set?
How well do those promises match up with what is delivered?
If there is a gap, does it dampen the enthusiasm of “management support?”

I think this is important for us to understand.

In the enthusiasm to “make the case” many lean manufacturing proponents point (and rightly so) to the higher performance levels of organizations that have done it. They talk about greatly improved quality, much faster inventory turns, greater returns on capital, much quicker response and throughput. By whatever measure, these systems clearly perform better.

The implementers start teaching the system through its mechanics. Takt time to pace everything; one-piece-flow; pull systems, supermarkets and kanban; quick changeovers; standard work; mistake-proofing.

Now I will be the first to tell you – this is how I was taught – the “just do it, and you will understand” approach. But no matter how well-intended, there is the danger of a diluted message: “Copy the mechanics of how these operations work, and you too can have these results.” Or, put another way, it “Don’t ask questions, just do it” gets (mis)translated into “You don’t have to understand it.”

Wrong. You do.

An expectation is created that, by implementing the basic mechanics of takt, flow and pull, these terrific results can be achieved and sustained.

Here’s the rub. All of the “tools of lean” are designed to force problems to the surface and make them too obvious to ignore. There is an implied expectation that the organization will see these problems and take on the challenge of tackling them as they emerge – true kaizen.

Of course all of this presumes that the organization has the resources, skill and most importantly the stomach to deal with these problems quickly and efficiently.

Bluntly, most don’t. If they did then none of this would have been necessary in the first place.

By implementing the tools alone, they are in effect taking a Newcomen steam engine – primitive, big, inefficient, slow, but functional through brute force- and replacing it with a state of the art steam turbine.

Yes, the turbine is much more efficient, but if you took one and dropped it into the year 1715 it wouldn’t run for very long. They didn’t have the resources or the skill to operate or maintain it.

So, in our lean- implementing factory, the new system is put in and in fairly short order, all of the previously hidden and tolerated problems are now revealed.

And it reveals the problem of “no process to devote the time or to develop the resources and skills to handle those problems” – to detect them, fix them, understand them and solve them.

Lacking the time and skills, the first line leaders do what they must to get the job done… they return to the tried-and-true countermeasures that keep the problems from disrupting things too much:

Kaizen Deterioration Reinforcing Loop

This is the fate of many so-called “kaizen events” which seek to make great change in a hurry.

So why does this happen?

I can speculate that it is a combination of ignorance on the part of some implementers who “got” the “just do it” part but didn’t pick up the “think for yourself” part.

Somewhere, sometime, someone established a precedent that making dramatic but unvalidated changes to a system was “kaizen.” Perhaps, at some point, a sensei said “Don’t ask questions, try this…” with the intention that people would try it and learn what problems came up, only to have it turned into “Do this” without any follow-up or understanding.

Others, perhaps, have an underlying fear that if they revealed just how much work and change was really involved that the leaders would be scared off and not take the first steps.

Now, to be clear, a certain amount of “just try it” is required to anchor that initial leap of faith. But the implementers must be prepared to immediately guide, lead, teach, coach and build the problem solving capability of the organization.

But, in the end, digging further into “Why?” doesn’t give us any more actionable information. “The system is designed to surface problems, and there is no process to handle them” is a root cause that can be directly addressed. It is simply important to acknowledge the truth.

What to do about it. I’ll get into more detail in future posts, but to begin, here are some things to think about:

  1. Small steps. (Note that “small steps” ≠ “slow steps”). Kaizen can be done rapidly, but it must be done deliberately in a context of understanding. Understand why things are the way they are, understand the effect your change should have. Try it out – ideally simulate if first – and see what problems surface. Solve those problems, then implement your change.
  2. Dedicate and manage time for solving problems. This is briefly covered by a couple of previous posts, “Why Doesn’t Daily Kaizen Happen?” and “Systematic Problem Solving” but is worth repeating. Problem solving and kaizen are work, just like anything else. If you want it to happen, you need to allocate time, resources and management to organize it.
  3. Develop a systematic approach, then follow it. I am going to go into some detail on this over the next few posts, but I need to emphasize the last part: then follow it. Too many “standards” are declared, then ignored.
  4. Don’t wait for “the next event” to make improvements.
  5. Just get started. Don’t wait until you are ready, you never will be. The only way to learn is to practice, observe yourself, see what works, what doesn’t, and learn. This, in turn, requires something that is sadly in very short supply in most corporations: humility. Learning means acknowledging, usually in public, that “we don’t have the answers” and perhaps that is the most important lesson.

I could digress into a leadership roles discussion here, but I won’t. But if you want to do a bit of pre-reading for future discussions, find a copy of “Learning to Lead at Toyota” by Steven Spear, and as you read it think about the role of the leader in that story. Bob, the protagonist, starts out with one role, and learns his role is actually quite different. There will be a quiz later.

3 Replies to “Expectations”

  1. Wonderful message Mark. You’ve got me at the edge of my seat.

    My company has been trying to implement Lean for about 5 years. So all you have said here is spot on.

    Starting next month we are finally starting our real Lean journey. We are training three Lean Champions. We will be doing lots of Lean changes during the next two years.

    Thank you for your insight.

  2. We’re struggling with a “go do it” problem – often our kaizens become great idea generators with a day or two of results. Then the event is over and normal day to day takes priority again. Not really sure how to change the mentality that leaving those ideas on the table is costing us. ROI on paper isn’t building the case.

    1. Bill –
      You hit at the core of the issue: When kaizen is an “event” rather than embedded into the way things are managed every day, improvements end up as extra things to do vs. a core part of running the business.

      Breaking the cycle involves managers and leaders changing how they lead, and in many cases, developing skills that they have never had in the past.

      The mechanics of what that looks like are discussed in the next post “Andon Leadership” Developing the skills to get there SHOULD BE (but rarely are) the actual goals of most “kaizen events.”

      The first step is to recognize the actual target condition (leadership learning vs. tools implementation), then to focus the implementation process on closing THAT gap vs. “lack of tools implementation.” Hopefully some future posts will toss out some thoughts on how to go about that.

      Anyone else – feel free to chime in here!
      Mark

Leave a Reply

Your email address will not be published. Required fields are marked *