Overproduction vs. Fast Improvement Cycles

A couple of weeks ago ago I posted the question “Are you overproducing improvements?” and compared a typical improvement “blitz” with a large monument machine that produces in large batches.

I’d like to dive a little deeper into some of the paradoxes and implications of 1:1 flow of anything, improvements included.

What is “overproduction” – really?

In the classic “7 wastes” context, overproduction is making something faster than your customer needs it. In practical terms, this means that the cycle time of the producing process is faster than the cycle time of the consuming process, and the producing process keeps making output after a queue has built up above a predetermined “stop point.”

If the cycle times are matched, then as an item is completed by the upstream process, it is consumed by the downstream process.

If the upstream process is cycling faster, then there must be an accumulation of WIP in the middle, and that accumulation must be dealt with. Further, those accumulated items are not yet verified as fit-for-use by the downstream process that uses them.

The way this applies to my “Big Improvement Machine” metaphor is that we are generating “improvement ideas” faster than we can test and incorporate them into the process.

“Small Changes” Doesn’t Mean “Slow Changes”

No matter how good your solution or idea, it is just an academic exercise until it is anchored as the an organizational norm. The rate limit on improvement is established by how quickly people can absorb changes to their daily, habitual routine.

Implementing and testing small changes one-by-one is generally faster than trying to make One Big Change all at once. When we do One Big Change, it is usually actually a lot of small changes.

I hear “we don’t have time to experiment,” but when I ask what really happens if a big change is made, what I hear almost every time is they had to spend considerable time getting things working. Why? Because no matter how well the Big Change was thought through, once you are actually trying it, the REAL problems will come up.

Key Point #1: Don’t waste time trying to develop paper solutions to every problem you can imagine. Instead, “go real” with enough of the new process to start revealing the real issues as quickly as possible.

In other words, the sooner you start actively learning vs. trying to design perfection, the quicker you’ll get something working.

Slow is Smooth, Smooth is Fast

Your other objective here is to develop the skill within the organization to test and anchor changes quickly, as a matter of routine. This will take time.

When we see a high-performance organization making rapid big changes, what we are typically seeing is making small changes even more rapidly. They have learned, through practice over time, how to do this. It isn’t reasonable to expect any organization to immediately know how to do this.

Key Point #2: If managers, or professional change agents (internal or external consultants, for example) are telling people exactly what to do, this learning is not taking place.

It is critical for the organization to develop this learning skill, and they are only going to do it if they can practice. Learning something new always involves doing it slowly, and poorly at first. If your internal or external consultants are serving you, their primary focus is on developing this basic competence. Their secondary focus is on getting the changes into place. This is the only approach that actually strengthens the organization’s capability.

The same is true for an operational manager who “gets” lean, but tries to just direct people to implement the perfect flow. It will work pretty well for a while. But think about how you (the operational manager) learned this stuff: Likely you learned it by making mistakes and figuring things out. If you don’t give your people a chance learn for themselves, you limit the organization in two ways:

  1. They will never be any better than you.
  2. They will wait to do what they are told, because that is what you are teaching them to do.

Think about what you want your people to be capable of doing without your help, and make sure you are giving them direction that requires them to practice doing those things. It will likely be different than telling them what they layout should look like.

Improve your Cycle Time for Change

Coming back to the original metaphor, if you want fast changes to last, you have to work speeding up the organization’s cycle time for testing improvement ideas. Part of this is going to involve making that activity an inherent and deliberate part of the daily work, not a special exception to daily work.

Part of that is going to be paying attention to how people are working on testing their ideas. The Improvement Kata and Coaching Kata are one way to learn how to deliberately structure this work so that learning takes place. Like any exponential curve, progress seems painfully slow at first. Don’t let that fool you. Be patient, do this right, and the organization will slingshot itself past where you would be with a liner approach.

Small changes, applied smoothly and continuously become big changes very quickly.

Are You Overproducing Improvements?

Imagine a factory with a large monument machine. It takes several days to set up. When it does run, it runs very fast, much faster than you can actually use its output. Therefore, you take the excess output and store it to use later. Actually, you don’t know how many items you need to make, so you make as many as you can while the machine is available to you.

image

Some of that excess output may prove to be less useful than you thought, but there is pressure to use it all anyway since it was so expensive to produce.

After a run making items for one process, you change it over to make items for a different process, and build up a queue of output there.

When all of the output is used, it all may or may not work the way you expected it to.

Most of us would see this as a classic case of “overproduction” – overwhelming the system with excess output that hasn’t been checked for quality, that isn’t needed right now, and might or might not be useful in the future. But it seemed like good efficiency to make it while we could.

Our lean thinking tells us we want to do a few things here. Ultimately, we want to work hard to break up the batches, and make the value flow more evenly to each of the customer processes, and ultimately to the end customers. The work we must do to keep things moving smoothly and evenly will pay off in both tangible and intangible ways.

One of the primary reasons we push hard for 1:1 flow in the lean world is to enable one-by-one confirmation.

We want to test each item of output to confirm that it actually performs as expected rather than making lots of them without knowing if they are any good.

How Do You Produce Improvements?

Now, imagine doing improvements this way. What would it look like?

A process would be scheduled to receive the rapid output of the Improvement Machine.

The Improvement Machine would be set up over a period of several days to produce improvements for the target process.

Once it was running, we would run the Improvement Machine very fast for a week or so. It would produce improvements faster than the target process can really absorb them.

At the end of the run, we might test the improvements as a batch. We might not test them at all, but rather report that they have been implemented with the assumption that they will work. We would also have excess improvements stored on a to-do list for future use.

Those excess improvements might, or might not, prove to be useful, but we would have huge pressure to implement them because they are on the list.

Once the machine was done producing improvements for one process, it would be set up to produce improvements the same way for another.

We would measure how many times we were able to run the improvement machine in a year, not so much the actual sustained impact we were making.

Improvements that were made without the machine might not be measured or credited at all. Or worse, these rogue improvements might actually be discouraged since they are made by people who aren’t certified to run the machine.

Now… substitute “kaizen event” for “improvement machine” and see if it makes any sense.

Why Are Big Batches Necessary?

The reason the Large Monument Machine has to cycle batches of output to different customers is because those customer processes don’t have the internal capability to do what it does. We need an outside resource to do it.

The countermeasure we strive to apply in these cases is to identify the capability that the customer process does need. We then work hard to develop it on a scale they can incorporate into their daily work. This is typically smaller, more specialized, and scoped to their needs.

My purpose here, though, is to apply a metaphor, not to discuss the economics of large capital equipment.

When we “batch improvements” it is often for the same reason: The area that is being improved can’t do it themselves, so we have to dedicate a scarce outside resource – an improvement expert – to lead them through it. Since that improvement leader can’t be there 100% of the time, he has to work as hard and fast as he can when he IS there.

Making Improvements vs. Teaching How to Make Improvements

The countermeasure in both scenarios is the same: Develop the capability within the process. In the case of making improvements, this means asking ourselves “Why can’t they do it?”

All of these are harder than just doing it for them. But if we want improvement to flow, this is the work that must be done.

Think Big, Change Small

Anton, my Dutch friend, had a study mission group of Healthcare MBA students from the University of Amsterdam visiting Seattle last week.

Friday morning I spent about four hours with them going through the background and basics of the Improvement Kata and Coaching Kata, and worked to tie that in to what they observed in their visits to local companies. They were a great, engaging group that was fun to work with.

One thing I do to close out every session I do with a group is ask “What did we learn?” and write down their replies on a flip chart. I find that helps foster some additional discussion and consolidate learning. It also gives me feedback on what “stuck” with them.

Sometimes I get a gem that would make a good title for a blog post. The title of this post is one of those.

Think Big

Alice and the Cat

Alice went on, “Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where…“ said Alice, “…so long as I get somewhere,” Alice added in explanation.

“Oh, you’re sure to do that,” said the Cat, “if only you walk long enough.”

The question, of course, is whether or not where Alice ends up is where she intends to go. A lot of continuous improvement activity takes this approach –  Look for waste. Brainstorm ideas. Implement them. Just take steps. And, like Alice, you will surely end up somewhere if you do this enough.

I had a former boss (back in the late 90’s) advocate this approach. “We are painting the wall with tennis balls dipped in paint.” The idea, I think, was that sooner or later all of the splotches would start to connect into a coherent color. Maybe. But, at the same time, he was also very impatient for tangible results. Actually that isn’t true. He was impatient for tangible activity which is not the same thing at all.

Direction and Challenge Establish Meaning

In her journeys through Wonderland, Alice learns that objective truth has no meaning in a world of random nonsense. The story, of course, is a parody of the culture and times of Victorian England. It does, however, reflect the frustrations many practitioners can feel when they are just trying to “make improvements.”

As one thing is “fixed,” another pops up for any number of reasons:

  • The “new” problem may well have been hidden by the “fixed” one.
  • Leadership may be chasing short-term symptoms and constantly redirecting the effort.

Day to day it just seems like random stuff, and can get pretty demoralizing.

The point of “Think Big” is that being clear about where WE (not just you) are trying to go helps everyone understand the meaning of what they are doing. That is the whole point of “Understand the Direction and Challenge” as the first step of the Improvement Kata. “What is the meaning behind what you are working on?” It is really a verification check by the coach that the coach has adequately communicated meaning to the learning.

Establish “Why” not “What”

At the same time, it is important for the organization to be clear on why improvement is necessary. I have discussed this a number of times, but keep referring back to Learning to See in 2013 where I ask “Why are you doing this at all?” as the question everyone skips past.

“Where we are going” should not simply be your model of your [Fill Company Name In Here] Production System.

No matter how well explained or understood, a model does not directly address the “Why are we doing this at all?” question that provides meaning to the effort.

It may well establish a good representation of what you would like your process structure to look like, but it does not give people any skill in actually putting these systems into practice, nor a reason to put in the effort required to learn something completely new.

Change Small

Small changes = fast progress as long as there is a coherent direction.

The classic 5 day kaizen event is often an attempt to make a radical improvement in a short period of time. Things usually look really impressive at the end of the week, and even into the next few weeks. What happens, though, is that the follow-up is usually more about finishing up implementation action items than it is working to stabilize the new process.

The problem comes from the baseline assumption that we already understand all of the problems, and our changes will solve them. We line things up, get 1:1 flow running, and yes, there is a dramatic reduction in the nominal throughput time simply because we have eliminated all of the inventory queues.

There is tons of research that backs up the assertion we can’t expect people to be creative when they are under pressure to perform. They are going to revert to their existing habits. During the event itself,  the short time period and high expectations put pressure on people to just implement stuff. People are likely to defer to the suggestions and lead of the workshop leader and install the standard “lean tools” without full understanding of how they work or what effect they will have on the process and people dynamics.

Come Monday morning, we put all of those changes to the test… at once. The people are working in a different way. The problems that will be surfaced are different. The tighter the flow, the more sensitive the system will be to small problems. It is pretty easy to overwhelm people, especially the supervisors who have to decide right now what to do when things don’t seem to be working.

That same pressure to perform exists, only now it is pressure to produce, and possibly even catch up production from what was lost during the previous week. Once again, we can’t expect people to think creatively when these new issues come up, they are going to revert to what they know.

When we do see successful “big change” it is usually the result of many small changes that have each been tested and anchored.

So why is the “blitz” approach so appealing? I think I got some insight into the reason in a conversation with a continuous improvement director in a large corporation. He had so little opportunity to actually engage and break things loose that, when he did, he felt the need to push in everything he could.

My interpretation of this goes back to the first line above: Small changes = fast progress as long as there is a coherent direction. In his case, there wasn’t coherent direction. He had a week, maybe two, to push as hard as he could in the direction he felt things should go. The rest of the time, things were business as usual.

This is why “think big” is important. It provides organizational alignment, and reduces the pressure to seize a limited opportunity and, frankly, inject chaos.

Small, Quick Changes

Because we often don’t see just how long it takes to stabilize a “quick, big change,” we tend to think that quick small changes are slower. I disagree. In my experience the opposite is true.

When there is a clear Challenge and Direction, and frequent check-ins via coaching cycles (or less formal means) on what changes are being made, no time is wasted working on the wrong things.

When small changes are made and tested as part of experiments vs. just being implemented, then there is less chance of erosion later. Rather than overwhelming people with all of the problems at once from a bunch of changes, one-by-one lets them learn what problems must be dealt with. They have an opportunity to always take the next step from a working process rather than struggling to get something that is totally unfamiliar to work at all.

That, in turn, builds confidence and capability.

In a mature organization that has practiced this for years, an outside observer might well see “big changes” being made. But that organization is operating from a base of learning and experience, and what might look big to you might not be big to them. It is all a matter of perspective.

What Do You Think?

I’m throwing this out there, hoping to hear from practitioners. What have you struggled with getting changes made that actually shift people’s behavior (vs. just implementing tools and techniques). What has worked? What hasn’t worked? I’d love to hear in the comments.

Push Improvement vs. Pull Improvement

I’m writing up a proposal for a benchmarking and study week, and just typed the term “push improvement” as a contrast to a true “continuous improvement culture.” I wanted to explore that a bit here, with you, and perhaps I’ll fill in the idea in my own mind.

Push Improvement

A few years ago I was working with a few sites of a multi-national corporation. In one of their divisions, their corporate lean office was pushing various programs into place. Each site was required to implement, and was graded on:

  • 5S
  • Jidoka
  • Heijunka
  • Toyota Kata

plus a few other things. Those are the ones I really remember. Each of these programs was separate and distinct, they had been deployed on some kind of phased time-table over a few years. They also had requirements to maintain some number of Six-Sigma Black Belts and Green Belts in their facilities, with the requirement to report on a number of projects.

They brought me in to teach the Toyota Kata stuff.

In reality, while people taking the class generally thought it was worthwhile, the leadership teams were also a little resentful that all of this stuff was being, in the words of one plant manager, “pushed down our throats.”

Even the Toyota Kata “implementation” had a specific sequence of steps that the site was expected to check off and report their progress on. In addition, there were requirements for how the improvement boards would look, including the position of the corporate logo and the colors used – all in the name of “standardization.”

At the same time, of course, the plants were also measured on their performance – financial, delivery, quality, etc. These metrics were separate and distinct from their audit scores on all of the lean stuff.

On the shop floor, they had the artifacts in place – the boards, the charts, the lines on the floor, but were struggling with making it all work. There was no integration into the management system. Each of these was a program.

I should also point out that, ironically, the plant that was getting the most traction with continuous improvement at the time was the one that was pushing back the hardest against this rote, “standard” approach.

A few years before that, I had been working (as an employee) in another multi-national company. There was a big push from the executives at the very top to develop a set of metrics they could use to determine if a site was “doing lean correctly.” They wanted a set of measurements they could monitor from corporate headquarters that would ensure that any business performance improvement was the result of “doing lean” rather than something else.

Both of these organizations were looking at this as an issue with compliance rather than developing their leaders.

Implementations like these typically involve things like:

  • Developing some kind of “curriculum” and rolling it out.
  • Requiring sites to have a “value stream map” and a “lean plan.”
  • Audits and “lean assessments” against some kind of checklist.
  • Monitoring the level of activity, such as how many kaizen events sites are running.

I have also seen cases of an underlying assumption that “if only we can explain it well enough, then managers will understand and do it.” This assumption drives building models and diagrams that try to explain how everything works, or the relationships between the tools. I’ve seen “pillar models,” puzzles, gears, notional value stream maps, and lots of other diagrams.

In summary, “push improvement” is present when implementing an improvement program is the goal. Symptoms are things such as a project plan with milestones for specific “lean tools” to be in place.

The underlying thinking is that you are doing improvement because you can, not because you must.

This is, I believe, what Jeff Liker and Karyn Ross refer to as mechanistic lean in their book The Toyota Way to Service Excellence.

Relationship to the Status Quo

One of the obstacles that organizations face with this approach is the traditional relationship to the status quo. Most business leaders are trained to evaluate any change against a financial return based on the cost. In other words, we look at the current level of performance as a baseline; evaluate the likely improvement; look at what it would cost to get to that new level and ask “Is it worth doing this?”

If the answer comes up short of some threshold of return, then the answer is “no,” and the status-quo remains as a rational optimum.

Implication: The status-quo is OK unless there is a compelling reason to change it.

For the lean practitioner, this presents a problem. We have to convince management that there is a short-term return on what we are proposing to do in order to justify the effort, time and expense. Six Sigma black belt projects are intently focused on demonstrating very high cost benefit, for example. And, honestly, if you are spending the money to bring in a consultant from Japan and an interpreter, I can see wanting some assurance there is a payback.1

If the discussions are around “What improvements can we make?” and then working up the benefit, you are in this trap. Those benefits, by the way, rarely find their way to the actual P&L unless there is already a business plan to take advantage of them.

The root cause of this thinking may well be disconnection of continuous improvement from whatever challenges the organization is facing; coupled with assumptions that a “continuous improvement program” can be implemented as a project plan on a predictable timeline.

Pull Improvement

Solving Problems

The purpose of any improvement activity is to solve problems. Real problems. In my classes, I often ask for a show of hands from people who have a shortage of problems on a daily basis. I never get any takers. Since there are usually lots of problems – too many to deal with all of them – we need to be careful to work on the right ones. The ROI approach I talked about above is a common way to sort through which ones are worth it. We can also get locked into “Pareto Paralysis”

So which ones should we work on?

Inverting this question, when someone wants to make a change, put in a “lean tool,” etc., my question is “What problem are you trying to solve?” And “we don’t have standard work” is not a problem, it is lack of a proposed solution. In these cases I might ask “…. and therefore?” to try to understand the consequence of this “lack of…” The problem might be buried in there somewhere. But if the issue at hand is trying to raise an audit score for its own sake, we are pack to “Push Improvement.”

A meeting gets derailed pretty fast when people are debating which solution should be applied without first agreeing on the problem they are solving. The Coaching Kata question “Which one [obstacle] are you addressing now?” is intended to get help the learner stay clear and focused on this.

But long before we are talking about problems, we need to know where we are trying to end up. This is why the idea of a clear and compelling challenge is critical.

Challenge First

Organizations that are driven by continuous improvement have a different relationship with the status-quo. Those organizations always have a concrete challenge in front of them. In other words, the status-quo is unacceptable. “Today is the worst we will ever be.”

Cost enters into the discussion when looking at possible ways to reach that destination. But it does not drive the decision about whether or not to try. That decision has already been made. The debate is on how to do it.

The Challenge with Challenges

“Wait a minute… we have objectives to reach too!” Yes, lots of organizations set out objectives for the year or longer. Here are some of the scenarios I have seen, and why I think they are different.

The goal setting is bottom-up. The question “What can we improve?” cascades down the organization, and individual managers set their goals for the year and roll them back up. There may be a little back-and-forth, and discussion of “stretch goals,” but the commitment comes from below. In most of the cases I have seen these goals are carefully worded, the measurements delicately negotiated, with bonuses riding on the level of attainment of these objectives. I have used the word “goal” here because these are rarely challenges or even challenging.

The goal is based strictly on hitting metrics. I have discussed the dangers of “management by measurement” a few times in the past.

A pass is given if there is a strong enough justification made for missing the goal. Thus the incentive to carefully define the metrics, and include caveats and loopholes.

There are measurements but not objectives. Any improvement is OK.

Any true challenge is labeled as a “stretch goal” meaning “I don’t really expect you to be able to reach it.”

And, sometimes the end of the year is an exercise in re-negotiating the definition of “success” to meet whatever has been achieved.

None of this is going to drive continuous improvement, nor align the effort toward achieving something remarkable or “insanely great.”

But here is the biggest difference: FEAR.

Fear of failure. Fear of committing to something I don’t already know how to achieve. Fear of admitting “I don’t know.”

And fear breeds excuses and other victim language that makes sure success or failure was beyond my control.

Fearless Challenges

So maybe that’s it. The key difference is fearless challenge. So what would that look like?

Here I defer to Jeff Liker and Gary Convis’s great book The Toyota Way to Lean Leadership. But I have seen this in action elsewhere as well.

Some key differences here:

  • The challenge comes from above. It isn’t a bottom-up “what can we improve?” It is a top-down “This is what we need to be able to do.”
  • It is an operational need, not a process specification. In other words, it isn’t the “lean plan.” The process specification is what is created to meet the challenge.
  • The challenge is an integral part of developing people’s capability. Perhaps this is the key difference.
  • There is no fear because the challenge comes with active support to meet it. That support, if done well, is both technical and emotional. We’re in this together – because we are.

Improvement = Meeting the Challenge

Given that there is a business or operational imperative established, we are no longer trying to push improvement for its own sake. We have an answer to “Why are we doing this?” beyond “to get a higher 5S score.”

Now there is a pull.

In my Toyota Kata class, I give the teams a challenge that, in the moment, is seemingly impossible. That is intentional. I hear air getting sucked in through teeth. “No way!” is usually the reply when I ask how it feels.

Then, for the next few hours, the teams are methodically guided through:

  • Grasping the current condition – understanding their process as a much deeper level.
  • Breaking down the problem into pieces, taking on one at a time. First a target condition, then specific obstacles.

Depending on how much time they have, 1/4 to 1/3 of the teams crack the problem, a few excel and go beyond, and those that don’t usually acknowledge they are close.

The teams that get there fastest are the ones who get into a quick cadence of documented experiments and learning. They see the problems they must solve much quicker, and figure out what they need to do. I tell them at the start, as I hold up my blank Experiment Records, “The teams that get it are the ones who burn through these the quickest.”

In the process of tackling the challenge, they learn what continuous improvement is really about. I don’t specify their solution. Any hints I give are about what to pay attention to, not what the solution looks like. I don’t deploy tools or give them a template for the solution. At the same time, most teams converge on something similar, which isn’t surprising.

Taking this to the real world – I see similar things. Teams taking on similar challenges on similar processes often arrive at similar looking solutions. But each got there themselves, for their own reasons, often following quite different paths.

While it seems more efficient to just tell them the answers, it is far more effective to teach them how to solve the problem. That is something they can take beyond the immediate issue and into other domains.

Pull Improvement = Meeting a Need

In my post Learning to See in 2013, I posed the question nobody asks: Why are you doing this at all? I point out that, in many cases, value-stream mapping is used as a “what could we improve?” tool, which is backwards from the original intent.

If there is a clear answer to “Why are we doing this?” or, put another way, “What do we need to be able to do that, today, we can’t?” or even “What experience do we aspire to deliver to our customers that, today, we cannot?” then everything else follows. Continuous Improvement becomes a daily discussion about what steps are we taking to get there, how are we doing, what are we learning, what do we need to do next (based on what we learned)?

This is pull. The people responsible for getting a higher level of performance are pulling the effort to get things to flow more smoothly. The mantra here is “not good enough,” but that must be the form of a challenge that inspires people to step up, not punitive.

Then it’s easy because “they” want to do it.

image

Epilogue: For the Practitioner

If you are reading this, you are likely a practitioner – someone on staff who is responsible for “continuous improvement” in some form, but not directly responsible for day-to-day operations. I say that because I know, in general, who my subscribers are.

This concept presents a dilemma because while you are challenged with influencing how the organization goes about improving things, the challenge of what improvements must be made (if it exists at all) is disconnected from your efforts.

That leaves you with trying to “drive improvement into the organization” and “be a change agent” and all of those other buzzwords that are probably in your job description.

Here are some things to at least think about that might help.

Let go of dogma. If you think continuous improvement is only valid if a specific set of tools or jargon are used, then you are already creating resistance for your efforts.

Focus on learning rather than doing. You don’t have all of the answers. And even if you did, you aren’t helping anyone else by just telling them what to do. No matter how much sense it makes to you, logical arguments are rarely persuasive, and generally create a false “yes.”

Seek first to understand. Listen. Paraphrase back. Try to get the words “Yeah, that’s right.” to come out of that resistant manager you are dealing with. Remember your purpose here is to help line leadership meet their challenges. Often those challenges are vague, are negative – as in trying to avoid some consequence – or even expressed as implied threats. You don’t have to agree, but you do need to “get it.”

That’s the first step to rapport, which in turn, is necessary to any kind of agreement or real cooperation. As a friend of mine said a long time ago: “You can always get someone’s attention by punching them in the nose, but they likely aren’t going to listen to what you have to say.” Making someone wrong is rarely going to increase their cooperation.

All of this, by the way, is harder than it sounds. I’m still learning these lessons, sometimes multiple times. I’ve been on my own journey of explicit / deliberate learning here for a couple of years.

We have a couple of generations now of improvement practitioners who have been trained with the idea that “lean is good” (or Six Sigma is good, or Theory of Constraints is good, or…). Therefore, it follows, that these things need to be put into place for their own sake – because all of the best companies do them.

This approach, though, reflects (to me) a shallow understanding of what continuous improvement is all about. It skips the “Why?” and goes straight to “How” and “What.” My experience has also been that relatively few of the practitioners steeped in this can actually articulate how the mechanics of these systems actually drive improvement on a daily basis after all of the mechanics are in place beyond a superficial statement like “people would see and remove waste.”

It seems that implementing the mechanics is equated with improvement, when in reality, those mechanics are simply an engine for starting improvement.

Yes, the mechanics are important, but the mechanics are not the reason. We are leaving out the people when we have these discussions. What are they doing every day (other than “following their standard work”)? How do these mechanics actually help them move, as a team, toward a goal they cannot otherwise attain?

————–

1In its worst manifestation, this thinking can be a cancer on the integrity of the company, for example, GM has had a couple of scandals where it has been revealed that they calculated the ROI of fixing a safety defect vs. the cost of paying off wrongful dealt lawsuits. Don’t even go there!

The Lean Plateau

Many organizations trying to deploy lean get great results for the first couple of years, then things tend to stall or plateau. This is in spite of continued effort from the “lean team.”

image

We Still Don’t Have a Lean Culture

This was the comment by the Continuous Improvement director of a pretty large corporation. They had been running improvement events for several years, everyone had pretty much been through one.

Each of the events had made pretty good strides during the week, but the behavior wasn’t changing. Things were eroding behind the events, even though everyone agreed things were better.

It was getting harder and harder to make more progress. They had hit the plateau.

What Causes the Lean Plateau?

While it might not be universal, what I have seen happen is this:

The implementation is led by a small group of dedicated technical experts. They are the ones who are looking for opportunities, organizing the kaizen event teams, leading workshops, and overseeing the implementation of lean techniques.

While this works in the short term, often the last implemented results begin to erode as soon as the lean experts shift their attention elsewhere.

At first, this isn’t noticed because the implementation is proceeding faster than the erosion.

However the more areas that are implemented, the faster the erosion becomes. There is simply more “surface area” of implemented areas.

At some point, the rate of erosion = the rate of implementation, and the lean team’s efforts start to shift from implementing new areas to going back and re-implementing areas that have eroded.

The lean team’s capacity becomes consumed re-implementing, and they spend less and less time going over new ground. They are spending all of their time “spinning the plates” and no time starting new ones.

Key Point: The lean plateau occurs when the level of implementation effort and the rate of erosion reach an equilibrium.

In the worst scenario, sooner or later financial pressures come into play. Management begins to question the expense of maintaining an improvement office if things aren’t getting significantly better on the bottom line. What they don’t see is that the office is keeping things from getting worse, but they aren’t called the “maintain what we have office” for a reason.

Breaking the Lean Plateau

When I was a lean director in a large company, we were confronting this very question. We had a meeting to talk about it, and quickly started blaming “lack of management commitment.”

Leaders Weren’t Stepping Up

In any given area, after education and planning, our last step was always to have a major effort to put flow production into place. Since the performance of the area would be substantially better, we expected the leaders to work hard to continue that performance.

What actually happened in an area was “implemented,” was the line leaders in that area – supervisors, managers, senior managers – weren’t working to look for erosion and correct it.

Instead, when a problem was encountered, they were making some kind of accommodation that compromised flow. The effect of the problem went away, but things had eroded a bit.

What we thought we learned: The weren’t “supporting the changes.”

What we really learned – though it was only realized in hindsight: This is the mechanism of “erosion.”

Flow production is specifically designed to surface small problems quickly. If there is no mechanism to detect those problems, respond, correct, and learn, then the only thing leaders can do is add a little inventory, add a little time, add an extra operation.

As Hirano put it so well decades ago:

All waste is cleverly disguised as useful work.

But Our Current Condition was Incomplete

There were outliers where it was working.

As we talked, we realized that each of us had experience with an outlier – one or two areas that were actually improving pretty steadily. Trying to understand what was different about these bright spots, we looked for what they all had in common. Surprisingly:

  • They were areas with no dedicated improvement teams.
  • They ran few, if any, 5-day kaizen events.
  • They were geographically close to one of us (senior “Directors”).
  • One of us had decent rapport with the area management team.
  • We each had an informal routine with them: We would drop by when we had time, and walk the work area with the area leader. We could discuss the challenges they were facing, how things were operating, go together to the operations concerned, and look at what was happening. We could ask questions designed to “sharpen the vision” of the leader. Sometimes they were leading questions. Most of the time they were from genuine curiosity.
  • By the time we left, there was generally some action or short term goal that the leader had set for himself.

Even though we “lean directors” had never worked together before, our stories were surprisingly consistent.

The Current Condition (Everywhere Else)

aka Dave’s Insight

The next logical question was “If that is what we do, what happens everywhere else? What do the lean staff people do?”

Now we were trying to understand the normal pattern of work, not simply the outcome of “the area erodes because the leaders don’t support the changes.”

Dave confidently stood up and grabbed the marker. He started outlining how he trained and certified his kaizen leaders. He worked through the list of skills he worked to develop:

  • Proficiently deliver the various topical training modules – Waste vs. Value Add; Standard Work; Jidoka; Kanban and Pull;
  • “Scan” an area to find improvement opportunities.
  • Establish the lean tools to be deployed.
  • Organize the workshop team.
  • Facilitate the “Vision”
  • Manage the “Kaizen Newspaper” items
  • etc

and at some point through this detailed explanation he stopped in mid sentence and said something that brought all of us to reality (Please avert your eyes if you are offended by a language you won’t hear on network TV):

“Aw… shit.”

What we realized more or less simultaneously was this:

Management wasn’t engaged because our process wasn’t engaging them.

Instead, our experts were essentially pushing them aside and “fixing” things, then turning the newly “leaned” area over to the supervisors and first line managers who, at most, might have participated in the workshop and helped move things around.

Those critical front line leaders were, at best left with a to-do list of ideas (kaizen newspaper items) that hadn’t been implemented during the 5 days.

There was nothing in the structure to challenge them to meet a serious business objective beyond “Look at how much better everything runs now.” The amount of improvement was an after-the-fact measurement (or estimate) rather than a before-we-begin imperative.

So it really should be no surprise that come Monday morning, when the inevitable forces of entropy showed up, that things started to erode. The whole system couldn’t have been better designed for that outcome.

Why the Difference in Approach?

In retrospect, I don’t know. Each of us senior “lean directors” had been taught, or heavily influenced by, Toyota-experienced Japanese mentors, teachers, consultants.

When we engaged the “outlier” areas, we were following a kinder, gentler version of what they had taught us.

On the other hand, what we were teaching our own people was modeled more on what western consultants were doing. Perhaps it is because it is easier to use forms and PowerPoint for structure than to teach the skills of the conversations we were having.

Implement by Experts or Coached by Leaders

That really is your choice. The expert implementation seems a lot easier.

Unfortunately the “rapid improvement event” (or whatever you call them) system has a really poor record of sustaining.

Perhaps our little group figured out why.

There are no guarantees. No approach will work every time. But a difficult approach that works some of the time is probably better than an easy path that almost never works.

Using Takt Time to Compute Labor Cost

How can I use takt time in computing labor cost?

Sometimes the searches that lead here give us interesting questions.

While simple on the surface, this question takes us in all kinds of interesting directions.

Actually the simplest answer is this: You can’t. Not from takt time alone.

Takt Time

Takt time is an expression of your customer’s requirement, leveled over the time you are producing the product or service. It says nothing about your ability to meet that requirement, nor does it say anything about the people, space or equipment required to do it.

Cycle Time

Cycle time comes in many flavors, but ultimately it tells you how much time – people time, equipment time, transportation time – is required for one unit of production.

Takt time and cycle time together can help you determine the required capacity to meet the customer’s demand, however they don’t give you the entire story.

In the simplest scenario, we have a leveled production line with nothing but manual operations (or the machine operations are trivially short compared to the takt time).

If I were to measure the time required for each person on the line to perform their work on one unit of the product or service and add them up, then I have the total work required. This should be close to the time it would take one person to do the job from beginning to end.

Let’s say it takes 360 minutes of work to assemble the product.

If the takt time says I need a unit of output every 36 minutes, then I can do some simple math.

How long do I have to complete the next unit?  36 minutes. (the takt time)

How long does it take to complete one full unit?  360 minutes (the total manual cycle time)

(How long does it take) / (How long do I have) = how many people you need

360 minutes of total cycle time / 36 minutes takt time = 10 people.

But this isn’t your labor cost because that assumes the work can be perfectly balanced, and everything goes perfectly smoothly. Show me a factory like that… anywhere. They don’t exist.

So you need a bit more.

Planned Cycle Time (a.k.a. Operational Takt Time and “Actual Takt”)

How much more? That requires really understanding the sources of variation in your process. The more variation there is, the more extra people (and other stuff) you will need to absorb it.

If we don’t know, we can start (for experimental purposes) by planning to run the line about 15% faster than the takt time. Now we get a new calculation.

85% of the takt time = 0.85 x 36 minutes = ~31 minutes.  (I am rounding)

Now we re-calculate the people required with the new number:

360 minutes required / 31 minutes available = 11.6 people which rounds to 12 people.

Those two extra people are the cost of uncontrolled variation. You need them to ensure you actually complete the required number of units every day.

“But that cost is too high.”

Getting to Cost

12 people is the result of math, simple division that any 3rd grader can do. If you don’t like the answer, there are two possible solutions.

  1. Decide that 360 / 30 = something other than 11.6 (12). (or don’t do the math at all and just “decide” how many people are “appropriate” – perhaps based on some kind of load factor. This, in fact, is a pretty common approach. Unfortunately, it doesn’t work very well for some reason.
  2. Work to improve your process and reduce the cycle time or the variation.

Some people suggest slowing down the process, but this doesn’t change your labor cost per unit. It only alters your output. It still requires 360 minutes of work to do one unit of assembly (plus the variation). Actually, unless you slow down by an increment of the cycle time, it will increase your labor cost per unit because you have to round up to get the people you actually need, and/or work overtime to make up the production shortfall that the variation is causing.

So, realistically, we have to look at option #2 above.

This becomes a challenge – a reason to work on improving the process.

Really Getting to Cost

Challenge: We need to get this output with 10 people.

Now we have something we can work with. We can do some more simple math and determine a couple of levers we can pull.

We can reverse the equation and solve for the target cycle time:

10 people x 30 minute planned cycle time-per-unit = 300 minutes total cycle time.

Thus, if we can get the total cycle time down to 300 minutes from 360, then the math suggests we can do this with 10 people:

300 minutes required / 30 minutes planned cycle time = 10 people.

But maybe we can work on the variation as well. Remember, we added a 15% pad by reducing the customer takt time of 36 minutes to a planned cycle time (or operational takt time, same thing, different words) of 30 minutes. Question: What sources of instability can we reduce so we can use a planned cycle time of 33 minutes rather than 30?

Then (after we reduce the variation) we can slow down the process a bit, and we could get by with a smaller reduction in the total cycle time:

330 minutes required / 33 minutes planned cycle time = 10 people.

(See how this is different than just slowing it down? If you don’t do anything about the variation first, all you are doing is kicking in overtime or shorting production.)

So which way to go?

We don’t know.

First we need to really study the current process and understand why it takes 360 minutes, and where the variation is coming from. Likely some other alternatives will show themselves when we do that.

Then we can take that information, and establish an initial target condition, and get to work.

Summarizing:

  • You can’t use takt time alone to determine your labor cost. Your labor cost per unit is driven by the total manual cycle time and the process variation.
  • With that information, you can determine the total labor you need on the line with the takt time.
  • None of this should be considered an unalterable given. Rather, it should be a starting point for meeting the challenge.

And finally, if you just use this to reduce your total headcount in your operation, you will, at best, only see a fraction of the “savings” show up on your bottom line. You need to take a holistic approach and use these tools to grow your business rather than cut your costs. That is, in reality, the only way they actually reach anywhere near their potential.

 

 

 

Toyota Kata: Don’t Change The Target Condition Date

A target condition has three main elements:

  • An achieve-by date.
  • A level of performance that will be achieved.
  • The operational process that will be in place.

The details of the #2 and #3 can take a number of forms, but today I want to talk about the achieve-by date.

Keep the time horizon fairly short, especially at first. For a typical process that is carried out every day, I usually suggest a two week time horizon. My rationale is this: I don’t want the target condition to seem big or complex. Two weeks is enough time to understand and significantly improve a handful of steps in a complex process. It is a short enough time to keep the improver from trying to fix a complex or global issue all at once.

For example, if a process is carried out in multiple departments, two weeks is enough to try experiments in one of them, but not enough to implement a change across the whole organization. Having that time horizon helps establish the principle of small, quick, steps rather than trying to develop some kind of implementation plan.

It is important to set an actual date, not just “in two weeks” – in two weeks from when?

But here is the most important part: Once the date is set, don’t change it.

If the date comes up, and the target condition hasn’t been reached, it is very tempting to say “Just a few more days.” But once a date is slipped, the date means nothing, because it can be slipped again.

Instead, missing the date is time to step back, reflect, and go back through the steps of the improvement kata.

This is the same thing you should do when you hit your target condition.

If you hit your target way early, or miss the date, it is also time to reflect on what you didn’t understand about your current condition when you established that target. Then:

  • Confirm understanding of the direction and challenge.
  • Grasp the current condition. This is important. Don’t just assume you know what it is. Take the time to do some observations and confirm everything is working the way you think.
  • Establish the next target condition. This means erasing the old target condition, starting with a clean obstacle sheet, looking at the current condition and establishing a new target condition. I would discourage you from simply re-stating the old one. List the obstacles that you think are now preventing you from reaching the new target.
  • Pick one obstacle (an easy one, not the one you were beating your head on for the last two weeks!), and design your next experiment. Start your PDCA iteration.

Coaches: Don’t let your learner just adjust the date. There is a learning opportunity here, be sure to capitalize on it.

 

Toyota Kata in Health Care

I’m about four months into helping a major regional hospital develop a solid foundation for applying the Improvement Kata and Coaching Kata to learn “improvement thinking.”

They now have active improvement boards running in pre-op, post-op, surgery, radiology, the lab, the emergency department, the cardio-vascular floor, medical-surgery floor, ICU, cardiac rehab, billing, admissions, case management, and supplies. I think that’s everything going right now.

Several of these departments have more than one board, and a few are beginning to get started spontaneously.

We are starting to see the culture begin to shift in many of these departments. Staff are getting engaged in improving the work flows, administration team members are more engaged with the staff.

Directors and managers are starting to reach across organizational boundaries to deal with obstacles and problems at the departmental interfaces.

And the organizations are starting to shift how they talk. When confronted with a list of problems, leaders are starting to ask “OK, which one are we addressing first?” Leaders are asking “What do you expect to happen?” and “What did we learn?” when talking about actions. They are working to engage thinking in their organizations vs. just giving direction.

Is it all rainbows and unicorns? Of course not. But the effort is clearly being made, and it shows. My overall process coaching is getting much more nuanced, because they are “getting” the fundamentals.

OK, so what did we do?

We started out with two weeks of pretty intense “kick-start.” One week was half-days of training and simulation (with a morning and afternoon group), getting a feel for the rhythm of the improvement kata, and a taste of the coaching kata, and culminating with the first round of improvement boards getting set up with at least a direction, if not a clear challenge.

We deliberately did not use industrial examples. And now that I’ve done it a few times, I can incorporate more health care language and examples into the sessions, which just makes it easier.

Week two was pairs of learners/coaches being coached through grasping the current condition, establishing a target condition, and the first couple of PDCA cycles / experiments.

But what made it work is they kept at it.

The next month, we did it again. We coached the established boards to tighten up their game, while establishing a series of new ones.

Because they had kept at it, the first round of boards now had a routine for their improvement cycles and coaching. And once there is a pattern, then we can work on improving it.

What I am learning.

Just get them going, then leave them alone for a while to keep at it. That lets the team establish a baseline routine for how they are practicing. Then I can come back periodically and propose adjustments on one or two items that let them step it up to the next level.

I am finding this much more effective than demanding they get it perfectly from day one. There is just too much to think about.

Establish a target condition, have them practice to that pattern, grasp the current condition, establish a new target… for the team’s practice. Get the improvement engine running, even if roughly, then work on tuning it for performance.

To be clear, this is my normal approach (and it is different, I am told, from what a lot of others try to do), but I am getting a lot of validation for it here.

Results

A member of the administration (leadership team) who is actively coaching shared this chart with me today. I have “sanitized” it a bit. Suffice it to say these three lines represent the percentage of deliveries of three separate (but related) processes within or before the target turn-around time of 30 minutes. Their challenge is to turn 95% of them around in 30 minutes or less.

The vertical red line represents when they started applying the Improvement Kata to this process.

Otherwise, the picture speaks for itself.

image

They have recognized that there is no silver bullet here. Rather, there have been dozens (or more) of changes that each save a little bit of time that is adding up.

As one of my early Japanese teachers said “To save a minute, you must find sixty ways to save a second.” and that is exactly what they are doing here. They are finding a minute here, a few seconds there, and anchoring them in changes to the way they organize the work flow.

Lab Team: “Way to go!”

Prediction Doesn’t Equal Understanding

Lunar Eclipse over Everett, WA. Photo by Mark Rosenthal, © 2015Sometimes people fall into a trap of believing they understand a process if they can successfully predict it’s outcome. We see this in meetings. A problem or performance gap will be discussed, and an action item will be assigned to implement a solution.
Tonight those of us in the western USA saw the moon rise in partial eclipse.

We knew this would happen because our understanding of orbital mechanics allows us to predict these events… right?

Well, sort of. Except we have been predicting astronomical events like this for thousands of years, long before Newton, or even Copernicus.

The photo below is of a sophisticated computer that predicted lunar eclipses, solar eclipses, and other astronomical events in 1600BC (and earlier). Click through the photo for an explanation of how Stonehenge works:

Photo of Stonehenge
Creative Commons flickr user garethwiscombe

Stonehenge represented a powerful descriptive theory. That is, a sufficient level of understanding to describe the phenomena the builders were observing. But they didn’t know why those phenomena occurred.

Let’s go to our understanding of processes.

The ability to predict the level of quality fallout does not indicate understanding of why it occurs. All it tells you is that you have made enough observations that you can conclude the process is stable, and will likely keep operating that way unless something materially changes. That is all statistical process control tells you.

Likewise, the ability to predict how long something takes does not indicate understanding of why. Obviously I could continue on this theme.

A lot of management processes, though, are quite content with the ability to predict. We create workforce plans based on past experience, without ever challenging the baseline. We create financial models and develop “required” levels of inventory based on past experience. And all of these models are useful for their intended purpose: Creating estimates of the future based on the past.

But they are inadequate for improvement or problem solving.

Let’s say your car has traditionally gotten 26 miles-per-gallon of fuel. That’s not bad. (For my non-US readers, that’s about 9 liters / 100 km.) You can use that information to predict how far a tank of fuel will get you, even if you have no idea how the car works.

If your tank holds 15 gallons of fuel, you’ll be looking to fill after driving about 300 miles.

But what if you need to get 30 miles-per-gallon?

Or what if all of a sudden you are only getting 20 miles-per-gallon?

If you are measuring, you will know the gap you need to close. In one case you will need to improve the operation of the vehicle in some way. In the other case, you will need to determine what has changed and restore the operation to the prior conditions.

In both of those cases, if you don’t know how the car operated to deliver 26 miles-per-gallon, it is going to be pretty tough. (It is a lot harder to figure out how something is supposed to work if it is broken before you start troubleshooting it.)

Here’s an even more frustrating scenario: On the last tank of fuel, you measured 30 miles per gallon, but have no idea why things improved! This kind of thing actually happens all of the time. We have a record month or quarter, it is clearly beyond random fluctuation, but we don’t know what happened.

The Message for Management:

If you are managing to KPIs only, and can’t explain the process mechanics behind the measurements you are getting, you are operating in the same neolithic process used by the builders of Stonehenge. No matter how thoroughly they understood what would happen, they did not understand why.

If your shipments are late, if your design process takes too long, if your quality or customer service is marginal, if the product doesn’t meet customer’s expectations, and you can’t explain the mechanisms that are causing these things (or the mechanisms of a process that operates reliably and acceptably) then you aren’t managing, you are simply directing people to make the eclipse happen on a different day.

“Seek first to understand.”

Dig in, go see for yourself. Let yourself be surprised by just how hard it is to get stuff done.

 

 

Another Homework Question

Another interesting homework question has shown up in the search terms. Let’s break it down:

23. if the slowest effective machine cycle time in a cell is 55 seconds and the total work content is 180 seconds, how many operator(s) should operate the cell so that labor utilization is at 100%?

I find this interesting on a couple of levels.

At a social level, the idea of cutting and pasting a homework question into Google hoping to find the answer is… interesting. Where is the thinking?

What are we teaching?

The question is asking “How many people do we need to run as fast as we can?” (as fast as the slowest machine). But how fast do they need to run? Maybe they only need a part every 95 seconds. If that is true, then I need fewer people, but I am going to run the slowest machine even slower.

In other words, “What is the takt time?” What does the customer need? How often must we provide it?

Then there is the “labor utilization” metric, with a target of 100%. Assuming the planned cycle time is actually 55 seconds (which it shouldn’t be!), we need 3.3 people in this work cell. (180 seconds of labor cycle time / 55 seconds planned cycle time: “How long does it take?” / “How long do you have?” = Minimum Required Capacity)

How about improvement? What do we need to do to get from 3.3 people to 3 people? We can solve for the labor cycle time.  55 seconds of planned cycle time * 3(people) = 165 seconds of total labor. So we need to get that 180 seconds down to a little less than 165 seconds.

Now we have a challenge. We need to save a bit over 15 seconds of cycle time. That might seem daunting. But we don’t have enough information (the current condition) to know where to begin. Then we can establish the next target condition and get started making things better.

These types of questions bother me because they imply all of these things are fixed, and they imply we run “as fast as we can” rather than “as fast as we must.”

Edit: Today I saw two more searches for:

total work content divided by slowest machine cycle time

so it looks like at least two others are working on the same assignment.  🙂

Thoughts?