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?

Toyota Kata, Kaizen Events and A3

I’ve been asked to explain the relationship between “Toyota Kata” and Kaizen Events, and I am guessing that the person asking the question isn’t the only one who has the question, so I thought I’d take a crack at it here.

To answer this question, I need to define what I mean when I say “kaizen event.”

Kaizen Events

In a typical western company, a kaizen event is geared toward implementing lean tools. There are exceptions, but I think they are different enough to warrant addressing them separately. (If you don’t read this, I changed my mind as I was writing it.)

At this point, I am going to borrow from an earlier post How Does Kaizen Differ From a Kaizen Event:

The kaizen event leader is usually a specialist whose job is to plan and lead these things, identifies an improvement opportunity. He might be tasked by shop floor management to tackle a chronic or painful problem, or might be executing the “lean plan” that calls for a series of implementation events.

It is his job to plan and execute the event and to bring the expertise of “how to make improvements” to the work force and their leaders.

Here’s the Problem

The full-time kaizen event leaders typically get really good at seeing improvement opportunities, organizing groups for improvement, and quickly getting things done. They get good at it because they do it all of the time.

The area supervisors might be involved in a kaizen event in their area a few times a year if that. Some companies target having each employee in one kaizen event a year.

That’s 40 hours of improvement. All at once. The question is: What do they do (and learn) the other 1900 hours that year?

What do they do when something unexpected happens that disrupts the flow of work? Usually kaizen events don’t deal with how to manage on a day-to-day basis other than leaving an expectation for “standard work” in their wake.

But “standard work” is how you want the work to go when there aren’t any problems. When (not if) there are problems, what’s supposed to happen?

This is why many shop floor leaders think “kaizen” is disconnected from reality. Reality is that parts are late, machines break, things don’t fit, Sally calls in sick, and the assembler has to tap out threads now and then. In the hospital, the meds are late, supply drawers have run out, and there is a safari mounted to find linens.

These things are in the way of running to the standard work. They are obstacles that weren’t discovered (or were glossed over as “resistance to change”) during the workshop.

The supervisor has to get the job done, has to get the stuff out the door, has to make sure the patients’ rooms are turned over, whatever the work is. And nobody is carving out time, or providing technical and organizational support (coaching) to build his skills at using these problems as opportunities for developing his improvement skills, and smoothing out the work.

OK – that is my paradigm for kaizen events. And even if they work really well, the only people who actually get good at breaking down problems, running PDCA cycles, etc. are the professional facilitators or workshop leaders. Many of these practitioners become the “go-to” people for just about everything, and improvement becomes something that management delegates.

What are they good for? Obviously it isn’t all negative, because we keep doing them.

A kaizen event is a good mechanism for bringing together a cross functional team to take on a difficult problem. When “improvement” is regarded as an exception rather than “part of the daily work,” sometimes we have to stake out a week simply to get calendars aligned and make the right people available at the same time.

BUT… consider if you would an organization that put in a formal daily structure to address these things, and talked about what was (or was not) getting done on a daily basis with the boss.

No, it wasn’t “Toyota Kata” like it is described in the book, but if that book had been available at the time, it would have been. But they had a mechanism that drove learning, and shifted their conversations into the language of learning and problem solving, and that is the objective of ALL of this.

Instead of forcing themselves to carve out a week or two a year, they instead focused on making improvement and problem-solving a daily habit. And because it is a daily habit, it is now (as of my last contact with them a couple of months ago), deeply embedded into “the way we do things” and I doubt they’re that conscious of it anymore.

This organization still ran “event” like activities, especially in new product introduction.

In another company, a dedicated team ran the layout and machinery concepts of a new product line through countless PDCA cycles by using mockups. These type of events have been kind of branded “3P” but because changes and experiments can be run very rapidly, the improvement kata just naturally flows with it.

Kaizen Events as Toyota Kata Kickstarts

If you take a deeper look into the structure of a kaizen event, they generally follow the improvement kata. The team gets a goal (the challenge), they spend a day or so grasping the current condition – process mapping, taking cycle times, etc; they develop some kind of target end state, often called a vision, sometimes called the target and mapped on a “target sheet.” Then they start applying “ideas” to get to the goal.

At the end of the week, they report-out on what they have accomplished, and what they have left to do.

If we were to take that fundamental structure, and be more rigorous about application of Toyota Kata, and engage the area’s leader as the “learner” who is ensuring all of the “ideas” are structured as experiments, and applied the coaching kata on top of it all… we would have a pretty decent way to kickstart Toyota Kata into an area of the organization.

Now, on Monday morning, it isn’t what is left to do. It is the next target condition or the next obstacle or the next PDCA cycle.

Toyota Kata

If we are applying Toyota Kata the correct way, we are building the improvement skills of line leadership, and hopefully they are making a shift and taking on improvement is a core part of their daily job, versus something they ensure others are doing.

One thing to keep in mind: The improvement kata is a practice routine for developing a pattern of thinking. It is not intended to be a new “improvement technique,” because it uses the same improvement techniques we have been using for decades.

The coaching kata is a practice routine to learn how to verify the line-of-reasoning of someone working on improvements, and keep them on a thinking pattern that works.

By practicing these things on a daily basis, these thought patterns can become habits and the idea of needing a special event with a professional facilitator becomes redundant. We need the special event and professional facilitator today because a lot of very competent people don’t know how to do it. When everybody does it habitually, you end up hearing regular meetings being conducted with this language.

We can be more clear about what skills we are trying to develop, and more easily assess whether we are following sound thinking to arrive at a solution. (Luck is another way that can look the same unless the line of reasoning is explained.)

What About A3?

When used as originally intended, the A3 is also a mechanism for coaching someone through the improvement pattern. There are likely variations from the formal improvement kata the way that Mike Rother defines it.

However, if you check out John Shook’s book Managing to Learn, you will see the coaching process as primary in how the A3 is used. Managing to Learn doesn’t describe a practice routine for beginners. Rather, it showcases a mature organization practicing what they use the Improvement Kata and the Coaching Kata to learn how to do.

The A3 itself is just a portable version of an improvement board. It facilitates a sit-down conversation across a table for a problem that is perhaps slightly more complex.

An added afterthought – the A3 is a sophisticated tool. It is powerful, flexible, but requires a skilled coach to bring out the best from it. It can function as a solo thing, but that misses the entire point.

For a coach that is just learning, who is coaching an improver who is just learning, all of the flexibility means the coach must spend extra time creating structure and imposing it. I’ve seen attempts at that – creating standard A3 “templates” and handing them out as if filling out the blocks will cause the process to execute.

The improvement kata is a routine for beginners to practice.

The coaching kata is a routine for beginners to practice.

Although you might want to end up flying one of these (notice this aircraft is a flight trainer by the way):

T-38

They usually start you off in something like this:

image

The high-performance aircraft requires a much higher level of instructor skill to teach an experienced pilot to fly it.

And finally, though others may differ, I have not seen much good come from throwing them up on a big screen and using them as a briefing format. That is still “seeking approval” behavior vs. “being coaching on the thinking process.” As I said, your mileage may vary here. It really depends on the intent of the boss – is he there to develop people, or there to grant approval or pick apart proposals?

So How Do They All Relate?

The improvement kata is (or absolutely should be) the underlying structure of any improvement activity, be it daily improvement, a staff meeting discussing changes in policy, a conversation about desired outcomes for customers (or patients!).

The open “think out loud” conversation flushes out the thinking behind the proposal, the action item, the adjustment to the process. It slows people down a bit so they aren’t jumping to a solution before being able to articulate the problem.

Using the improvement kata on a daily basis, across the gamut of conversations about problems, changes, adjustments and improvements strengthens the analytical thinking skills of a much wider swath of the organization than participating in one or two kaizen events a year. There is also no possible way to successfully just “attend” an improvement activity if you are the learner being coached.

Notes From Day 2 of Kata-Con

Perfection is the enemy of progress.

  • The longer it takes, the higher the expectation.
  • The higher the expectation, the longer it takes.

My thoughts: I’ve seen this a lot. It is magnified when the leaders are detached from the process.

Process improvement is messy, and if the leaders aren’t comfortable with that messy process, they develop unrealistic expectations of what “progress” looks like.

The people getting the work done, meanwhile, end up working hard to manage those expectations. They actually conceal problems from the boss, for fear of him misinterpreting problems-that-must-be-solved with my-people-don’t-know-what-to-do.*

Trying to layer Toyota Kata over the wrong organizational structure will overwhelm people.

The organizational structure follows necessity. This lines up with Steven Spear’s research.

The organizational structure must match the needs of the process, and the target condition for learning.

If your supervisor has 20 direct reports, it is unlikely he will have the time to work on improvement in a productive way. Toyota’s team leader structure is specifically engineered for improvement, development, and getting a car off the line every 58 seconds.

 

Improvement takes time and people.

The End.

This isn’t free, nor can you calculate an ROI ahead of time. Get over it.

Start with what you MUST accomplish and look at what is required to get there. It doesn’t work the other way around.

If you don’t continually strive, you die.

If you aren’t striving to go forward, you are going backward.

My thoughts: I make the following analogy: Continuous improvement is like a freezer. There is never a time when you can say “OK, it’s cold enough, I can unplug it now.” You must keep striving to improve. Without the continuous addition of intellectual energy, entropy takes over, and you won’t like the equilibrium point.

All of our failures have come to good things.

My thoughts: By deliberately reflecting and deliberately asking “What did we learn?” you can extract value from any experience. The way I put it is “You have already paid the tuition. You might as well get the education.”

We had sponsorship challenges as the leaders caught up with the people.

My thoughts: Yet another instance of the leaders falling behind the capability of their people. When the people become clear about what must be done, and just start doing it, the only thing an uninformed leader can do is either get out of the way or destructively interfere.

People don’t like uncertainty. Kata deliberately creates uncertainty to drive learning. You have to be OK with that.

My thoughts: Another expression of the same point from yesterday.

“Learning only” has a short shelf life.

“Cool and Interesting” is not equal to Relevant.

Those are the words I wrote down, rather than the words I heard. The key point is that you can, for a very short time, select processes to improve based on the learning opportunities alone. But this is extra work for people. The sooner you can make the results important the quicker people get on board.

A business crisis should not stop improvement or coaching. Does it?

My thoughts: This is a good acid test of how well you have embedded. When a crisis comes up, do people use PDCA to solve the problem, or do they drop “this improvement stuff” because they “don’t have time for it.” ?

Inexperienced 2nd coaches coaching inexperienced coaches coaching inexperienced learners… doesn’t work.

A lot of companies try to do this in the interest of going faster. Don’t outrun your headlights. You can only go as fast as you can. Get help from someone experienced.

Just because you have gone a long way doesn’t mean you can’t slip back. You must continue to strive.

The “unplug the freezer” analogy applies here as well.

You don’t have to start doing this. But if you choose to start, you may not stop. You have to do it every day.

Don’t take this on as a casual commitment, and don’t think you can delegate getting your people “fixed.” (they aren’t broken)

Everybody gets it at the same level. Senior managers tend to lose it faster because there is no commitment to practice it every day at their level.

Awareness is a starting point, but not good enough. A 4 hour orientation, however, is not enough to make you an expert… any more than you can skim “Calculus and Analytic Geometry” and learn the subject.

Results do get attention.

“I’ll have what she’s having”

But don’t confuse results with method.

My challenges to the plant managers weren’t about P&L or service levels. They were about moving closer to 1:1 flow, immediate delivery, on demand.

Challenges must be in operational terms, not financial terms.

Move from “These are the measures, and oh by the way, here is the operational pattern” – to –> “This is the operational pattern I am striving for. and I predict it will deliver the performance we need.”

Gotta catch a plane. More later.

 

______________

*When I was in the Army, we got a new Battalion Commander who listened to the logistics radio net, where the staff officers discussed all of the issues and problems that had to be solved. He would jump to a conclusion, and issue orders that, if carried out, would interfere with getting those problems solved.

Although he spoke of initiative and taking action, his actions revealed he wasn’t willing to trust us to let him know if there was a problem we couldn’t handle, and expected perfection in execution in situations that were chaotic and ambiguous.

We ended up finding an unused frequency, and encrypting our traffic with a key that only we shared, so the commander couldn’t hear us. Yup… we were using crypto gear, designed to keep the Soviets from hearing us, to keep our boss from hearing us.

As the information channels to him slowly choked off, he was less and less informed about what was actually happening, and his orders became more and more counter-productive, which in turn drove people to hide even more from him.

This, I think, is a working example of “getting bucked off the horse.”