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.

 

 

 

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?

Output vs. Takt Time

The team’s challenge is to reach steady output of 180 units per hour.

Their starting condition was about 150 per hour. Their equipment and process is theoretically capable of making the 180 per hour with no problem.

They calculated their takt time (20 seconds) and established a planned cycle time of 17 seconds.

Some time later, they are stuck. Their output has improved to the high 160s, but those last 10-12 units per hour are proving elusive.

This is the point when I saw their coaching cycle.

Looking at their history, they had set a series of target conditions based on output per hour. Their experiments and countermeasures had been focused on reducing stoppages, usually on the order of several minutes.

“Does anybody have a calculator?”

“Divide 3600 seconds by 180, what do you get?”

“20 seconds.”

“Do you agree that if your line could reliably produce one module every 20 seconds that you would have no trouble reaching 180 modules per hour?”

Yes, they agreed.

“So what is stopping you from doing that?”

They showed me the average cycle times for each piece step in the process, and most were at or under 15 seconds. But averages only tell a small part of the story. They don’t show the cumulative effect of short stoppages and delays that can cascade through the entire line.

The team had done a lot of very good work eliminating the longer delays. But now their target condition had to shift to stability around their planned cycle time.

Performance vs Process Metrics

This little exercise shows the difference between a process metric and the performance metric.

Units-per-hour is a performance metric. It is measured after the fact, and tells the cumulative effect of everything going on in the process. In this case, they were able to make a lot of progress just looking at major stoppages..

Stability around the planned cycle time or takt time (you may use different words, that’s OK) is a process metric.

It shows you what is happening right now. THIS unit was just held up for 7 seconds. The next three were OK, then a 10 second delay. It’s those small issues that add up to missing the targeted output.

The team’s next target condition is now to stabilize around their planned cycle time.

Since they averaged their measurements, their next step is to (1) take the base data they used to calculate the averages and pull the individual points back out into a run chart and (2) to get out their stopwatches and go down and actually observe and time what is really going on.

I expect that information to help them clarify their target condition, pick off a source of intermittent delay, and start closing the remaining gap.

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.

Lean Thinking in 10 Words

Pascal Dennis, in his book Getting the Right Things Done sums up lean thinking in 10 words:

“What should be happening?”

“What is actually happening?”

“Please explain.”

I would contend that everything else we do is digging out answers to those questions. (yes, there is a bit of hyperbole here, but I want to get you to think about how true this is vs. how false it might be.)

I think “lean thinking” is really a structured curiosity. Let’s take a look at how these questions push us toward improvement.

“What should be happening?” is another form of Toyota Kata’s “What is your target condition?” In our conversations, we often jump straight to “We need to…” language, a solution, without being clear what the problem is.

I’ll set that back by asking questions like “What would be happening if the problem is solved?” “Can you describe that?”

When Toyota trained people ask “What is the standard?” this is what they want to know, because, to them, a “problem” = “a deviation from the standard.”

“What is actually happening?” or “What is the actual condition now?”– Once we are clear where we are trying to go, it is important to grasp where we are now in the same terms as the target.

Something I see quite a bit is a target condition expressed with different terms, measures, and variables than the current condition. You must be able to relate between the two in a way that defines and quantifies the gap that must be closed.

“Please Explain” cuts across the current condition and the obstacles (in kata terms). What do you understand about the gap between what should be happening and what is actually happening?

If the process has deteriorated, what has changed? Why is it that we cannot hit the standard today when, last week, we could? When did it change? What do we know about that? Why did it change?

If you tried to run to the new level, what would keep you from doing it that way? (what obstacles do you think are now preventing you from reaching your target?)

Depending on which of these conditions we are dealing with will fundamentally change the path toward a solution, so it is critical we understand “What should be happening?” or “What is the target condition?” as a first step, then look at the history of the actual condition.

If the process has eroded, what do we know about what has changed in the environment?

All of this is the foundational baseline… the minimum understanding I want to hear before we entertain any discussion about what actions to take, what to change, what to do.

How Does Kaizen Differ From A Kaizen Event?

The title of this post is a search term that hit the site today. It’s an interesting question – and interesting that it gets asked.

“Kaizen” is now an English word (it’s in the OED) and defined as such:

Definition of kaizen in English:

NOUN

A Japanese business philosophy of continuous improvement of working practices, personal efficiency, etc.

Origin

Japanese, literally ‘improvement’.

 

Let’s talk a bit about that “Japanese, literally ‘improvement” bit.

Jon Miller of the Kaizen Institute was raised in Japan and offers up this nice breakdown of the meaning behind the meaning:

image

Jon explains:

•Kai = Change is made from two characters “self” and the picture “to whip”. You can see the stripes across the poor fellow’s back.So Change is something you do to yourself.

•Zen = Good. In this case a sacrificial lamb which means “righteous” is offered between two characters for “word”. In this case word = clear and precise speech. So good sacrifice with precise speech all around it is “Good”. The Zen character we are using today is a simplified version. Also, Zen in this case is not the same character as Zen Buddhism.

•Kaizen = Change for the better. Or in our case whip yourself so that you can make a nice sacrifice and always have clear speech / thoughts surrounding you. Smile

As I understand it, in vernacular Japanese, “kaizen” is regarded as a business term. The word is not used in day-to-day context.

From Jon’s explanation, there is also a very personal aspect to it. Change is something you impose on yourself.

With all of that, “kaizen” is simply a word that generally refers to any systematic disciplined activity of improvement.

Kaizen Events

Now things get tricky, because here in the West, we have often regarded “kaizen events” and “kaizen” as the same thing. They aren’t. While you can certainly make improvements with kaizen events, that isn’t the only way to improve things, and I’ll add it isn’t necessarily even the best way.

A typical Western kaizen event (and there are lots of variations, though most companies that use them tend to impose fairly rigorous attempts to standardize them) is a 5 day focused effort with a 100% dedicated team.

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.

So… sometimes, “kaizen events” implement changes, but don’t necessarily do much for that personal drive for improvement.

The Shift

We’re starting to see a shift, as we realize those front line leaders are actually the ones who need to be the experts. That’s where Toyota Kata comes in – as a tool to learn to coach those leaders so they learn to keep the improvement going rather than just fighting erosion and working around problems.

OK – it’s late, and this was actually a diversion from something else I’m working.

Coaching: Getting Specific, Finding the Knowledge Threshold

When coaching, I often find improvers / learners who tend to be superficial or vague about target conditions, current conditions, the experiments they intend to run, the results they expect, what they learned.  Huh… I guess I should have said “vague about everything.”

As several of my clients would tell you, one of my themes is “drive out ambiguity.”

Recently I’ve been trying a simple follow-up question that seems to be working to help people dig a little deeper without pushing them back as much as other questions might.

“Could you be more specific?”

I will plead completely guilty to stealing this from an unlikely source.

In his book “The Cuckoo’s Egg“, Clifford Stoll describes a line of questioning during his oral defense of his PhD thesis in astronomy:

I remember it vividly. Across a table, five profs. I’m frightened, trying to look casual as sweat drips down my face. But I’m keeping afloat; I’ve managed to babble superficially, giving the illusion that I know something. Just a few more questions, I think, and they’ll set me free. Then the examiner over at the end of the table – the guy with the twisted little smile – starts sharpening his pencil with a penknife.

“I’ve got just one question, Cliff,” he says, carving his way through the Eberhard-Faber. “Why is the sky blue?

My mind is absolutely, profoundly blank. I have no idea. I look out the window at the sky with the primitive, uncomprehending wonder of a Neanderthal contemplating fire. I force myself to say something—anything. “Scattered light,” I reply. “Uh, yeah, scattered sunlight.”

“Could you be more specific?”

Well, words came from somewhere, out of some deep instinct of self-preservation. I babbled about the spectrum of sunlight, the upper atmosphere, and how light interacts with molecules of air.

“Could you be more specific?”

I’m describing how air molecules have dipole moments, the wave-particle duality of light, scribbling equations on the blackboard, and . . .

“Could you be more specific?”

An hour later, I’m sweating hard. His simple question—a five-year-old’s question—has drawn together oscillator theory, electricity and magnetism, thermodynamics, even quantum mechanics. Even in my miserable writhing, I admired the guy…

[Emphasis added]

As you can see from Stoll’s experience, his professor was seeking to find his knowledge threshold – something a kata coach should be doing as well.

Now, I’m not going to push the “5 Whys” quite as deep as quantum effects (except, perhaps, at one client who DOES deal with things at that level…), but I find this is a far more effective question than “Why?” or asking leading questions. It, obviously isn’t universal, but it has been working reasonably well with a client whose corporate culture drives indirect assertions and vague predictions.

Try it… leave a comment if it works for you (or bombs). But please… be specific.  🙂

P.S. – In this video, Cliff Stoll tells the same story, likely more accurately, and makes another valuable point:  “It’s obvious” is a statement which often hides limited understanding of what is being discussed. It might be “obvious,” but… let’s go see.