Consistency – The Lean Thinker

January 25, 2024January 24, 2024

What Conversations Does Your VSM Drive?

Continuing on the theme of value stream mapping (and process mapping in general) – in the last post, Where is your value stream map? I outlined the typical scenario – the map is built by the Continuous Improvement Team, and they are the ones primarily engaged in the conversations about how to close the gap between the current state and the future state.

The challenge here is that ultimately it is the line leadership, not the Continuous Improvement Team, that drives whether or not this effort is long-term successful.

Getting a continuous improvement culture into place means changing the day-to-day patterns of interaction between people and groups of people. We can put in all of the lean tools we want, but if those conversations don’t follow, the system quickly reverts to the previous baseline.

What is interesting (to me, but I admit I’m a geek about this stuff) is that this is a meta level thing. While we are working on improving the performance of the value stream, we really have to be working on the performance of the process of leadership in the organization.

The value stream map can help with this, but we have to be deliberate about it, and realize that it will be an incremental and iterative process, just as we find in trying to improve how any process functions.

Start With Where You Want To Go

For line leadership, before we even start drawing process boxes, the first step is deciding why you are even doing this. What problem are you trying to solve? What aspect of your current performance needs to change… dramatically?

Is your system unresponsive to customers? Do customers expect deliveries inside your nominal lead times? Does that disrupt your system? What lead time capability would let you routinely handle these issues so they weren’t even issues anymore, just normal operations? That objective is going to bias your current state VSM toward understanding what is driving your lead times, where, when, and for how long, work is idle vs. actually being processed, etc.

Or maybe you need to increase your capacity while holding your costs (vs. just duplicating the existing processes). Now you are going to be focusing on the things that constrain your throughput, activities that consume time within cycles of output and the like.

Establishing that focus is a leadership / management task. It doesn’t work to just say “We need to improve” or even worse “We need to get lean.”

Sometimes these things are obvious frustrations to management, but often they are overwhelmed with general performance issues, or trying to define problems in terms of financials. That is an opportunity to focus back on the kind of performance that would address the financials.

The cool thing here is that you really can’t get this wrong. If you set a goal of radically improving your performance on any single aspect of your operation, you will end up improving pretty much everything in the process of reaching that goal. But it is critically important to have a goal to strive for, otherwise people are just trying to “improve” without any objective.

Then map your current state. The challenge gives you context. The current state map gives you a picture of how and why the system performs as it does.

Just so we don’t get sucked down the whirlpool of focusing too much on the business process in this discussion, the reason why you are getting this clarity is to get (and keep) the leaders engaged. If the objective is something abstract like “get lean” it is easy for them to think they can just get updates while they deal with the “real issues.” We want to attach this to a real issue that they are already working on.

Thus there is no “lean plan.” So many companies make “lean” somehow separate from other business objectives. I never could understand that. Maybe they are trying to separate “gains” that are a result of the “lean program” from those created by other initiatives. It doesn’t work that way. There is only one operating system in play, and that is what drives your day-to-day performance. If you don’t like the performance, you have to change the operating system. That is a management function, and it can’t be delegated.

The photo above is a current state map from a process that took several weeks to ship a part that the customer had ordered. Since it was a make-to-order shop, this was, shall we say, challenging for the customer relationship people.

As the team built the map it began to sink in that the time actually making the part was less than 30 minutes, and the value add was about six of those minutes. Their performance metric was “Past Due Hours” which was an abstraction of the programmed jobs that were behind the promised ship date.

Because the customers were always asking the business team members, “Where’s my stuff?” those customer reps were, in turn, always on the shop floor trying to get their orders expedited. They were competing with one another for a place in the production queue.

There is an icon in the middle of the map. Here is a close up:

This is Jim. He was an hourly associate whose nominal job was to pull the paperwork, match it up with raw material, and stage the work package into the production queue.

But this role made him the gatekeeper. So the customer service people (you can see their names in the lower left corner) would be pressuring Jim to jump their hot orders (and they were all hot by the time it got to the point where there was paperwork release – another story) into the queue so they could tell their customers that their orders were “in production.”

This put Jim in the position of having to make the priority decisions that the leadership wouldn’t make. Ultimately it was Jim who decided which customers would be disappointed that day. That made his day way more stressful than his pay grade. Respect for people? Hardly.

It also resulted in a staged order queue (materials and paperwork on carts) that snaked through the shop until it finally (days later) got to the actual production cell which, once they started, could actually knock things out pretty fast.

None of this addressed the past due issue. In fact, this made it worse.*

The key question for this team was “Who needs to have what conversation about work priorities so it isn’t all on an hourly associate to decide which of our customers will be disappointed?”

Who Needs To Fix This?

We want to solve problems at the lowest possible level, but no lower. In this working example, asking the shop floor workforce to fix this problem would be futile. Yes, they can propose a different structure, but they do not control how orders are released, they do not control how capacity is managed, they do not control the account managers who are fighting for a spot in the queue. They had been complaining about this bind for a long time. It wasn’t until the people running the business saw how the overall system worked that they understood that this is a systemic issue, and “the system” belongs to line management.

The facilitation question that got their attention was “Do you want Jim to be the one who decides who gets production priority?” Of course the answer was “No.” And that wasn’t about Jim, rather it was the realization that this WAS the existing process, and that wasn’t how they wanted things to operate. As my friend Brian says, “You may not like your normal, but you have to deal with it.”

That is generally the case at the value stream level. Value stream problems are usually at the interfaces between processes. The shop floor can’t, for example, transition from a push scheduling system to pull on their own. If they try, they create conflicts with the existing scheduling system and this usually tanks their metrics – even if performance is actually getting better.

These are all management discussions.

Key Point: The value stream level is a systems view. While you absolutely want input from the people who are engaged in the work every day, working on the system itself is not something that can be delegated by line leadership. They are the ones who are responsible for the overall system, and they are the ones who need to be responsible for changing it.

The Future State Map is a Hypothesis

Once you understand the current condition, the next step is to answer the question, “How does the process need to operate in order to meet our goal?”

The purpose of mapping a future state is to design process flow that you believe will meet your challenge if you can get the system to work that way.

It isn’t about seeing what you could do by removing waste. It isn’t “what could we improve,” it is “what must we change to reach our objective?” Again, this is a management function. It’s called “leadership.”

Which brings me to the title of this post.

Who Is Talking About This Stuff?

If the Continuous Improvement Team simply facilitated the process for line leadership (the actual stakeholders) to grasp the current condition and establish a target (future state) condition, what is crucial is who takes ownership of closing the gap. If the C.I. team are the ones discussing the problems they are often in a position of having to sell and justify every step of the effort to get to the future state.

Likewise, I have seen a lot of cases where the people primarily participating in building the value stream map were working level team members. Yes, it is absolutely necessary to have their insights into how things really are for people trying to get stuff done. Yes, it is critically helpful for them to understand the bigger picture context of what they do. However, all too often, I see senior leaders disengaged under the umbrella that they are “empowering” their workers.

Just to be clear: We absolutely want to create conversations about improvement at the level of the organization where value and the customer’s experience is actually created. The point here is that those conversations cannot be the exclusive domain of the working levels. It is critical for line leadership to be, well, leading. They can’t just delegate this to the continuous improvement specialists. Nor can they simply leave it to the working levels to sort it out – not if they expect it to work for any length of time.

Who reports on progress?

When an executive wants to know the progress toward an improvement goal, who do they call? Do they call the continuous improvement team to report? Or do they call the actual stakeholder who is responsible?

This is an easy trap to fall into. The C.I. Manager wants to show they are making a difference. The senior manager knows the C.I. Manager probably has better information. But that isn’t the conversation we want to create. The conversation needs to be between the line leaders. Yes, the C.I. team can (and probably should) help structure that conversation, but if they inject themselves into the middle (or allow senior management to put them there) the vital vertical connections are weakened – if they ever existed.

Thus, it is critical for the Continuous Improvement team to have a crystal clear picture of who should be having these conversations, and be actively working to nudge things in that direction. This is the process the C.I. team should actually be working to improve.

What should people talk about?

Ah, here’s the rub. For some reason managers today have a reluctance (or even disdain) to talk about operations, preferring to keep conversations in financial terms of cost, earned hours, yield and the like. These are all outcomes, but they are outcomes of process, and it is only by changing the process that those outcomes can sustainably change.

That conversation about progress I talked about above? That can’t be solely about the performance. It has to be about what is changing in the way the work is being done, and more importantly, what is being learned.

What the future state value stream map does (or should be used to do) is translate those business objectives into operational requirements for the process.

What Is Your Target Condition?

How we start to see the organic intersection between Toyota Kata and the value stream map.

The future state map defines a management goal. It also highlights the problems that must be solved to get there. (Those are the “kaizen bursts” that Learning to See has you put on the future state map.)

Those problems, or obstacles in Toyota Kata terms, at the value stream level become challenges (again in Toyota Kata terms) for the respective process owners.

Now the conversations move to the right level. Rather than asking for the status of action items for the “lead time reduction initiative,” the line leaders are discussing progress toward getting the changeover in stamping down to 17 minutes, and the cycle times in the weld cell under the takt time.

In my working example above, the first target condition was to have Jim simply pull the next order from a FIFO queue in a series of slots on the wall. The customer service reps had to meet every morning and could reshuffle the orders in those slots all they wanted, but Jim’s job was just to take the next one. That pushed the initial conversation to the one they had been avoiding: The customer service team talking among themselves, rather than making Jim the arbitrator.

There was a lot of other work as well. They established a rigid FIFO with a fixed WIP level of staged orders. Instead of pushing days of work into that queue, there was a buffer of about an hour (to absorb variation in processing times between various jobs).

At the same time, the team running machines now understood the rate of processing that was required to keep up with the volume of work. That had been totally hidden by the queues before. All they knew is that they were behind. Now the conversation shifted to “Are we going fast enough?” It shifted from discussions about backlog (which really are not productive) to discussions about rate of processing which is the only thing that affects the backlog.

Getting all of this dialed in and stable took a few weeks of daily conversations between the Operations Director and the various managers and supervisors whose work impacted the flow. It involved walking the floor, putting in visual indicators that clearly defined what should be happening – the target condition – and they discussed reasons things looked different: The actual condition now, and what obstacles were being surfaced as they worked to reduce the WIP buffers.

The net result?

Learning is Critical

The current performance is an outcome of the current system. People do their best within the system they have to work within, and we have to assume the system reflects management’s understanding of how things should operate to get the best results.

Even if someone knows a better way, that knowledge is wasted unless it is applied to the overall system of operating – the way we do things.

Epilog

You would never say “The freezer is cold enough, we can unplug it now.” You have to keep putting energy into the system just to keep the temperature where it is. Tightly performing production systems are no different. Over the course of the next year or so past due hours slowly crept back up for unknown reasons. Why? Because they didn’t talk about it every day.

*When a shop is behind, the management reflexes are (1) increasing batch sizes and (2) expediting. There really aren’t any better ways to make the throughout and response times worse.

December 9, 2022December 6, 2023

What is a “Socio-Technical System?”

Lately the term “socio-technical system has been starting to show up more and I thought this would be an opportunity to weigh in on what I think it means.

Though the concept has been around since at least 1951 (see below), I think I have tended to “bleep over” the term as jargon without giving it a lot of thought. I don’t think I am alone in that.

People who try to describe the meaning tend to describe a system “that integrates the social and technical aspects” or words like that.

I would posit that it goes much deeper, and we “bleep over” the concept at our peril if we want our organizations to function well.

The Origin of Social-Technical Theory

*Up through the 1940s, coal mining in the UK was largely pick and shovel work aided by drills and, sometimes, explosives. A work crew typically consisted of three to half a dozen men (and they were all men) who were task organized to strip the coal off the seam face, shovel it into mining carts, and move those carts to the transport system.

These teams were distributed through the mine, and because the distance and working conditions really precluded a lot of supervision, the teams largely oversaw their own work.

Since each team worked independently, the system as a whole could easily accommodate the simple fact that in some spots the coal is harder to dig out than in others.

(If you want to get more of a feel for the work and working conditions, check out the photos in this Daily Mirror article: https://www.mirror.co.uk/news/real-life-stories/britains-last-deep-coal-pit-7000879)

The work also met every definition of “difficult, dirty and dangerous.” That work environment, though, created a social bond among the team members as they worked together to accomplish the task of “mining coal.”

The system was not without its problems, however. The social structure was built around loyalty to the small work team. When “trams” (coal carts) were in short supply, for example, the “trammers” would horde carts to optimize their team’s performance at the expense of other teams being limited by the number of carts available.

This all changed shortly after WWII.

The Long Wall Method

In the late 1940s the industrial engineers turned this craft production system into a factory system with the tasks divided between three shifts.

The process would begin on the evening shift. They would drill blast holes along the top of the coal seam, then dig an undercut about six inches high at the base to allow the blast to drop the coal. This would be done along a long (up to a couple of hundred meters) face of the coal seam. (Hence the name “long wall mining.”)

Meanwhile another team would break down the conveyor system that ran parallel to the coal face in preparation for moving it forward to position it for removing the loose coal.

Then night shift had two teams. One would extend the “gateway tunnels” at either end of the coal face. This was a crew of 8 men. Simultaneously another team would rebuild the conveyer in the new position.

Once all of this work was done, the shots would be fired, dropping the coal into a pile along the coal seam face.

Day shift would take the loose coal and transfer it to the conveyor system to be taken out of the mine.

Yes, this is an oversimplification, but it suffices for this discussion.

On paper, this process was far more efficient.

In practice, though, things did not go smoothly.

“Isolated Dependence”

A “filler” loads loose coal onto the conveyor.

Looking at this work breakdown, the first two shifts are prep work. Only the day shift, the “fillers,” actually get the coal out of the mine. But their success was entirely dependent on how well the first two shifts did their jobs. If everything was not “by the book” then the fillers would be significantly hampered. Since they were paid by the ton of coal extracted, there was more at stake than just a sense of accomplishment.

If the previous shifts ran into problems – such as a “shot” that failed to separate all of the coal from the roof of the seam, or harder material, etc. these inconsistencies slowed down the “fillers” and made them less successful. If the conveyor was not completely or correctly assembled, they could not begin work until this was corrected.

Because management pressure was on the key performance indicator – the rate of coal extraction, and because the “fillers” were paid by the ton of coal extracted, this created resentment between the “fillers” and crews on the other two shifts, as well as conflicts with management which the working crews began to regard (with ample evidence) as disconnected from the realities of their work.

Then, if the “fillers” were too far behind at the end of their shift, that would delay the start of the next cycle and things spiraled downward from there.

Productivity plummeted. The study I am citing here was commissioned to determine why. Their conclusion, in short, was that the new work organization was built around the paradigm of a factory assembly line without regard for the variation of geology. Success of the three shift cycle depended on each shift meeting a rigid schedule, but that schedule did not account for the simple fact that coal seams are not uniform.

In addition, the work organization destroyed the social structure of the mining crews. Their success was dependent on people they no longer saw or interacted with. The oncoming filler shift, in particular, would be confronted with all of the obstacles left by the previous two shifts. As their resentment for being unsupported built, their willingness to put in any extra effort dropped to zero.

Again – this is an oversimplification. If you want to read the full paper there is a link at the end of this post.

Oversimplification or not, however, the effect was stark. The social structure of the organization was driven to fundamentally change by alternations in the technical structure of the work. Quoting from my source material* :

The effect of the introduction of mechanized methods of face preparation and conveying, along with the retention of manual filling, has been not only to isolate the filler from those with whom he formerly shared the coal-getting task as a whole, but to make him one of a large aggregate serviced by the same small group of preparation workers.

The work design was based on a mechanistic view that ignored the how the social structure impacted the performance of the team.

The Mechanistic View

Installed in the year 1410, the Prague Astronomical Clock is the third-oldest in the world, and the oldest still in operation. (Prague is an awesome city, by the way.) Photo © Steve Collins, used under Creative Commons license via Flickr and Wikimedia

By the turn of the last century we thought we had the ways of the universe pretty well understood. Hundreds of years (thousands of years in some early societies) earlier we had the ability to predict the motion of the stars and planets – to the point that we could build machines that were analogues of their movements.

The prevailing model in psychology was classical conditioning which, in essence, said that behavior is an almost algorithmic learned response based on previous positive and negative reinforcements.

This mechanistic model leads to a belief that we can carefully design the machine and people’s work within the machine can be carefully designed and shaped through rewards and consequences.

And as long as everything, and every one, works as they are supposed to, it’s all good. If a machine malfunctions, we fix it. If people don’t follow procedures, we “motivate them” with incentives.

This model prevails even today and even colors our teaching of continuous improvement. One of the places we need tend to inherently adopt a mechanistic view is when we use the word “system.”

The Mechanistic View of “System”

In today’s world, when people talk about “the system” they are often referring to an information system of some type. Common examples are an Enterprise Resource Planning (ERP) system, or an Electronic Health Records (EHR) system. And these information processing systems do tend to shape how the organization functions, for better or for worse.

So when people talk about a “system” I think the reflex is to think of the system as a machine that is carefully designed, built, and tuned to perform a particular function or behave in a particular way.

And people tend to assume that once it is working, it will continue to work so long as it is maintained to be kept in the same condition.

This thinking often extends to the people as well. They are often viewed as servicing “the system” – providing it with information, and following the instructions it gives. (this is particularly true in ERP / MRP environments.) Everything is part of a machine, and as long as everyone does their jobs, and the equipment functions as intended, then it all works.

In practice, though, these systems tend to isolate people from one another, or into small single task groups in much the same way as happened in the coal mine.

The Mechanistic Paradigm at Work

The reason I explained all of this is so we can look at our own workplaces through this lens. The crucial question is: Do the work structures and systems support or hamper the social structure of effective teamwork?

Let’s take another look at those ERP or EHR systems. Without the interaction with and the interaction between the people who use them, those “systems” are inert. They do nothing. The mechanistic paradigm, though, tends to look at people as performing a task to serve or enable the system. Instead, we should look at the information system as a tool that should enable people do to a job they otherwise could not.

On the Shop Floor

The sign says “Hearing Protection Required.” The reality is that it is impossible for more than 3 or 4 people to have a conversation on the shop floor, as they are shouting to be heard. The final operation is highly automated, each machine has two people working in isolation, even from one another for the most part. In addition, the machine crews are isolated from one another, both by distance and by the noise level.

The machine operator is measured on his hourly rate of production vs. a standard expectation.

Meanwhile at the opposite end of the building, the production scheduling team works to carefully orchestrate the availability of packaging materials, purchased components, as well as scheduling each phase of production so work is available for the next step.

They do all of this with their ERP system and every day they create orders to issue components, production orders to the various areas in the shop, and purchase orders to their suppliers. They adjust priorities at least daily, based not only on lead times and changing customer requirements, but also on the reality of what has actually been produced, or not, up to this point. Items are early, they are late, production runs ahead, though mostly behind, the scheduled intent.

Everyone is frustrated. The planner / schedulers because production never seems to make what they planned. And production because scheduling never seems to schedule things that can be made with the available materials, etc. Shortages are discovered, an ad-hoc plan is created to keep things moving – but that may well consume components that were earmarked for something later in the week, and the cycle continues.

To make things even more interesting, the planner / schedulers are using production capacity numbers that they know are higher than reality. They are under pressure to put in unrealistic numbers because the real numbers would make the site’s cost estimates too high and attract scrutiny from corporate.

This means “the system” produces schedules that cannot be met by actual production even if everything else works, which, in turn, means continuously over-promising, under-delivering, and adjusting priorities.

Though the work is very different, we have a social structure not unlike the British coal mine.

This is what “isolated dependence” looks like in today’s work environments. If you are seeing blame casting and conflict between groups who are dependent on one another you likely have a similar situation in your organization.

Counter-Productive Response

Unfortunately the typical management response is to increase monitoring, control, incentives, “accountability” on individual parts of the process rather than looking at the entire system.

These things tend to increase the sense of isolation and frustration as they can create a sense of victimhood between the separate groups. For example, in the above situation everyone there told me that they used to have pull system on the factory floor, and it had worked really well, operated predictably, and gave them a lot more insight into what was actually happening. But some time ago a new management team wanted to track everything in the computer “for control” so the current system was installed.

Ironically, that management team had turned over, but for whatever reason people were very reluctant to return to what they knew had worked in the past. But I digress.

The Implications

Human beings are innately social. In any organization, or casual group trying to get something done, people develop webs of social networks. The more they can interact, the more everyone stays on the same page.

There are a few things we can do to reinforce this.

Bring People Together

And I mean bring them together literally, physically. Rather than just confronting one another in the morning meeting, have them literally work side-by-side with the common goal of a smooth process.

Have a Shared, Objective, Truth

Eliminate the need to ask or query “status.” Eliminate the one person who knows the big picture. Get the truth out there in the open– literally, physically. (See a trend here?)

In a well managed operation I nearly always find rich “information radiators” that are an inherent part of the process itself (rather than being a display of information that was input just so it can be displayed). This information is not simply a passive display. It is actively used by the people doing the work to they know where they stand, what comes next, and when they need to raise a concern.

A classic example of this is a heijunka or load-leveling box. The cards, or work orders, or pick tickets, are placed in slots that are based on the time that work is expected to start if everything is working normally. Thus it is insanely easy to spot if something is getting behind, long before it would show up in the daily production report. Menlo Innovations’ Work Authorization Board does the same thing.

The goal is for conversations to be about “How to respond” rather than discussions about “what is happening.”

This is really the purpose of nearly every “lean tool” — to ask, and answer, two key questions:

What should be happening?
What is actually happening?

and then invite a conversation about any difference between the two.

The fact that “we have made 234 widgets” is meaningless without a point of comparison of “how many widgets should we have made up to this point?” The goal is to invite curiosity and foster actual conversations, and eliminate debates about what should be and what actually is.

But more often, this is what I most find lacking. People well tell me they can easily query status, look up individual orders, but even then there is rarely a timely comparison between “nominal” and “actual” in that information. Even if status can be queried, there is often a lack a “compared to what?” Or worse, the status is abstracted from reality, for example, measured in “earned hours” or some other financial metric. Often “ahead or behind” is not known until the end of the day… or the week, or sometimes even the month. The greater the lag, the bigger is the scramble to make up production with overtime.

So here is question #1 for you: If I were to ask you, right now, “Is this operation ahead or behind?” could you tell me? Can the people who are actually doing the work tell me? And by “tell me” I mean immediately, without having to go research or launch some kind of query.

Another version of this question is, “How far behind do you allow yourself to get before you actually know there is a problem?”

Social-Technical

So what we have is a technical aspect of a process that is deliberately designed to support meaningful social interactions between the people responsible for carrying out the work and accomplishing the overall task… as a team. We bring people together rather than isolating them from one another.

This is hard – Yup.

And these principles run against management “best practices” that have been taught since the 1920s.

Where to start? If any of this seems impossible, work on trust. Think about this – Why would people be reluctant to display an objective truth without the ability to first qualify it?

Why would people be reluctant to create a true dependent relationship with another department?

All of these things come down to a culture of self-defense because people feel a need to protect themselves from something or someone. Even if that force is long gone, the effects of leadership-by-fear linger, sometimes for many years, unless you take proactive and direct steps to eliminate that fear.

So… if this seems hard, work on that first.

* The original study of the interplay between social structure and work organization and technology looks to be the 1951 paper “Some Social and Psychological Consequences of the Longwall Method of Coal-Getting: An Examination of the Psychological Situation and Technological Content of the Work System” by E.L. Trist and K.W. Bamforth

August 19, 2021

Takt Time: How Slow Can You Go?

A long, long time ago – in the days when computer programs were coded as holes in punch cards – I was in ROTC* in college. Twice a year we had a “PT” (Physical Training, I think) test that consisted of measured performance on five “events.” One of those events was a 2 mile run. To get a maximum score of 100 points, the participant had to complete the 2 mile run in 14 minutes and 9 seconds. Why? I have no idea. But that was the way it was.

Yes – this old school stopwatch reads exactly 42 seconds.

My buddy John and I enjoyed running, and would often work out together. Our school was in Potsdam, New York, a place known for rather brutal winters, so we ran on a 1/10 mile indoor track.

We practiced the PT test. John would track our total time for 2 miles (20 laps around the 1/10 mile track). I would measure lap times. Since 14 minutes is 840 seconds, we knew that if we could consistently make 42 second laps, we would complete two miles in 14 minutes, and get the maximum score with 9 seconds to spare.

The track had hash marks at each quarter point, so we knew we had to hit quarter 1 between 10 and 11 seconds, half way at 21, the 3/4 mark between 31 and 32, and the lap at 42. We would check and adjust our pace accordingly, striving to hit exact 42 second laps every time.

To be clear, we could hold that pace many times further than 2 miles. It wasn’t a matter of conditioning. We weren’t going all out. We were going fast enough. And that was the point.

When we took the test, other cadets were going all out, passing us, and turning in much faster times. Others would try to “pace themselves” and then sprint as fast as they could for that last lap. As a general rule, although the instructors were calling out elapsed times as people went by, these cadets weren’t all that aware of the speed they had to hold. They were just going as fast as they could.

Meanwhile, John and I, running together, and tracking our cycle times (lap times) vs the takt time (42 seconds / lap) would come in at pretty much exactly 14 minutes and get the same score as everyone who had finished ahead of us: 100 points.

After our timed run was done, we would keep running, offering encouragement and pacing for those cadets who were struggling a bit. Everyone finishes, nobody left behind.

A couple of the instructors were curious why we didn’t go for a faster time. And many times we did when we were just working out. We were capable of breaking 12 minutes – not competitive times in a track meet, but respectable. The simple fact was that going faster wasn’t necessary to accomplish the goal.

Takt Time and Cycle Time

This is the whole point of having a takt time. It answers the question, “How fast must we go?” It doesn’t answer “How fast can we go?” nor does it answer “How fast should we go?” I fact, John and I could have run those laps almost (but not quite) half a second slower than we did – which would have eaten into the 9 second buffer we established. Aside from making the math easier, that buffer also gave us a small margin for even something as bad as taking a stumble and standing back up. Also, of course, we could make up 5-10 seconds a lap if we really had to. But we never did. Time: 14:00. We were very consistent.

Rate vs. Output

I encounter a lot of production managers who are so conditioned to focus on the daily output that they don’t even think about the critical factor: How fast are you running vs. how fast do you need to run? In other words what is your rate of output vs. your takt time?

Instead they tend to, at best, count units of output without really paying attention to the time interval between one and the next. In the worst case many units are started at once, and people swarm from one operation to the next during the day – the equivalent of that mad sprint trying to make up as much time as possible. They don’t really know if they will succeed or not until the end of the day (or month!).

It Isn’t a Race

The “just” in “just-in-time” is “just enough resources” to “just make the output you need” in any given time interval. As the operation is streamlined, the same effort is able to accomplish more. Where to put that additional capacity (which costs nothing additional since it has been there all along) to create more value should be the challenge the organization is trying to meet.

My experience has been that managers and leaders often struggle to adopt this “rate” mindset and let go of chasing an inventory number. In the words of the late great philosopher Kenny Rogers – “There’ll be plenty of time for counting when the dealings done.”

*ROTC (Reserve Officers Training Corps) is a U.S. program where college students can earn a commission in the U.S. Armed Forces while earning their degree.

March 9, 2020March 9, 2020

Ghost Victories – an excerpt from Upstream by Dan Heath

Amazon affiliate link to book listing for Upstream by Dan Heath — The link to the image takes you to the Amazon listing for the book. If you happen to order it, I get a small kickback, no cost to you, Just FYI.

Dan Heath has just published a new book, Upstream: The Quest to Solve Problems Before They Happen.

I just got the book, and am reading it now. I think there is going to be a lot of good material to discuss here.

But this post is about a marketing email with an excerpt really resonated with me, and I want to discuss that. I wrote to Dan Heath, and got his permission to use pieces of the excerpt here. (Thank you, Dan)

Management By Measurement = “Ghost Victories”

I have talked about what I call “management by measurement” in the past. In that post I told a true story of a company that placed very heavy emphasis on reducing inventory levels without digging into how that performance was achieved. The net result was a an embarrassed CEO during a quarterly analyst’s call. Not good.

Dan Heath talks about the same thing in Upstream. He calls it “ghost victories.”

[when] there is a separation between (a) the way we’re measuring success and (b) the actual results we want to see in the world, we run the risk of a “ghost victory”: a superficial success that cloaks failure.

The most destructive form of ghost victory is when your measures become the mission. Because, in those situations, it’s possible to ace your measures while undermining your mission.

He goes on to describe a case in the U.K. where the Department of Health established penalties for wait times longer than four hours in the Emergency Departments. And it worked. Wait times were reduced – at least on paper. Then the facts began to emerge:

In some hospitals, patients had been left in ambulances parked outside the hospital—up until the point when the staffers believed they could be seen within the prescribed four-hour window. Then they wheeled the patients inside.

In the old post I referenced above, I said:

If making the numbers (or the sky) look good is all that matters, the numbers will look good. As my friend Skip puts it so well, this can be done in one of three ways:

Distort the numbers.
Distort the process.
Change the process (to deliver better results).

The third option is a lot harder than the other two. But it is the only one that works in the long haul.

All of this ties very well to Billy Taylor’s keynote at KataCon6 where he talked about the difference between “Key Activities” and “Key Indicators.” It is only when we can get down to the observable actions and understand the cause-and-effect relationship between those actions and the needle we are trying to move that we will have any effect.

To avoid the “Ghost Victory” trap, Dan recommends “pre-gaming” your metrics and thinking of all of the ways it would be possible to hit the numbers while simultaneously damaging the organization. In other words, get ahead of the problem and solve it before it happens.

He proposes three tests which force us to apply different assumptions to our thinking.

The lazy bureaucrat test

Imagine the easiest possible way to hit the numbers – with the least amount of change to the status quo. The story I cited above about inventory levels is a great example.

I can make my defect rates improve by altering the definition of “defect.”

There are lots of accounting games that can be played.

This is one to borrow from Skip’s list – How can the underlying numbers be distorted to make this one look good when it really isn’t?

The “rising tides” test

What external factors would have a significant impact on this metric? For example, I was working at a large company where a significant part of their product cost was a commodity raw material. As the market price went down, “costs” went down, and bonuses all around. But when the market price went up, “costs” went up and careers were threatened and bad reviews issued.

Those shifts in commodity prices had nothing to do with how those managers were doing their jobs, the tide rose and fell, and their fortunes with it.

The question in my mind is “What things would make this number look good, or bad, without any effort or change in the process we are trying to measure?”

The defiling-the-mission test

Hmmm. This is a tough one. (not really)

And it is a really common problem in our world of quarterly and annual expectations. In what ways could meeting these numbers in the short term ultimately hurt our reputation, our business, in the long term?

For example, I can think of an ongoing story of a product development project that hit its cost and schedule milestones (what was being measured). But they did so at the cost of destroying their reputation with customers, their Federal regulators and the public (and, to a large extent, their employees). They now have a new CEO, but the deeper problem has origins in the late 1990s.

How long will it take them to recover? That story is still playing out.

In another case I was in a meeting with a team that was discussing a customer complaint. The ultimate cause was a decision to substitute a cheaper material to reduce production costs. But this is a premium brand. There was a great question asked there: “Which of our values did we violate here?” – so the introspection was awesome.

Next step? Ask that question before the decision is made: “Is this decision consistent with our values?” If that makes you uncomfortable, then time to look in the mirror.

Then there is this little incident from 2010:

Picture of burning Deepwater Horizon oil platform — BP Deepwater Horizon fire – Photo by USCG

The metric was cost and schedule. Which makes sense. But the behavior that was driven was cutting corners on safety.

Getting Ahead of Problems

The book’s subtitle says it is about getting ahead of problems. I am looking forward to reading it and writing something more comprehensive.

August 9, 2019

How Do You Know They Know?

TWI Job Instruction is built around a four step process titled “How to Instruct.”

Steps 2 and 3 are the core of the process.

Present the Operation
Try Out Performance

I want to discuss Step 3: Try Out Performance

Teaching Back as Learning

All too often I see “training” that looks like this:

Bring the team members into a room.
Read through the new procedure – or maybe even show some PowerPoints of the procedure.
Have them sign something that says they acknowledge they have been “trained.”

This places the burden of understanding upon the listener.

The TWI model reverses this paradigm with the mantra at the bottom of the pocket card which, though they vary from version to version, is some form of: If the student hasn’t learned, the teacher hasn’t taught.

Having the learner teach back to the instructor does two things:

The learner has to understand it better to be able to explain it.
It provides a verification check that the instruction has been effective.

Point two is important here. Instruction is a hypothesis: “If I teach these steps, in this way, my learner will be able to perform the process.”

Having them teach back is the testable outcome of this hypothesis. If the the learner struggles, then the instructor must re-instruct. But not simply by rewinding the script and playing it again… we know that didn’t work. Instead the instructor now has to get curious about which points are confusing the learner and why, and correct his instruction.

But that’s not what I came here to discuss. TWI is just a lead-in.

Learning to See – by Practicing

An operations manager who is learning fast was challenging my insistence on having a visual status board that showed the real-time location of product on the line.

In the same breath, he was saying that he wanted the leads and the supervisor to be able to “walk the trapline” and do better seeing issues coming before a train wreck. (Empty positions, overproduction, etc.)

My response was “Having them update the magnets on that board every time something moves forces them to practice seeing what is where.”

In other words, by making them teach you where things are, and demonstrate their knowledge, they have to learn how to see that bigger picture.

“That’s the best explanation I have ever heard.”

The operations manager can walk the line and see the status himself. He doesn’t need the board. In fact, he could see even better if he went up the mezzanine overlooking the line. It’s all there.

But the board isn’t for his benefit. It is a learning tool. It is structure for the leads and supervisors to have a joint conversation, facing the board instead of each other, and reach agreement about what is where.

It gives them a clear indication if they need to escalate a problem, and a way to be able to converse about when and how they might recover (or not).

In other words, it is “Grasp the Current Condition” continuously, in real time. This lets them compare the current condition with the target condition – the standard depicted on the board.

By seeing gaps quickly, they have a better chance at seeing what obstacle or problem prevented them from operating to the target.

That, in turn, gives the manager an opportunity – in invitation – to shape the conversation into one about improvement.

Back to Job Instruction

This is exactly the same process structure as having the learner demonstrate performance. It is a check, right after the operation (present the operation) was performed to see how well it worked.

Fine Grained Observation

All of this is about moving observations, evaluations, checks, verifications away from batching them at the end of a huge block of work and embedding them into one-by-one flow. It builds Ohno’s “chalk circle” into the work itself.

August 8, 2019August 7, 2019

If You Think “We Can’t Please Our Customers” You’ll Be Right

The center of the B Concourse at O’Hare Airport in Chicago is dominated by a Brachiosaur skeleton, part of the Field Museum exhibit for their store there.

As a reminder for those of you over the age of 14, the Brachiosaurus was 70 feet long, 30 feet tall, weighed in at around 60 tons.* It had a brain the size of an avocado. It wasn’t smart. It wasn’t fast. Its main defense against predators was that it was simply too big to catch and eat.

In the shadow of the Brachiosaurus is United Airlines’ main customer service desk for their headquarters hub.

Back in June, Chris Matyszczyk published some really interesting commentary on Inc. Magazine’s site: The CEO of United Airlines Says He Can’t Really Make Passengers Happy

In his article, he quotes from an interview Oscar Munoz, the CEO of United Airlines, gave to ABC. From the interview:

“It’s become so stressful,” he said, “from when you leave, wherever you live, to get into traffic, to find a parking spot, to get through security.”

“Frankly,” Munoz added, “by the time you sit on one of our aircraft … you’re just pissed at the world,” and improving the flying experience won’t ultimately depend on “what coffee or cookie I give you.”

My interpretation? “We have given up trying to please our customers.”

That was the interpretation of Ed Bastian, Munoz’s counterpart at Delta Airlines:

…when Munoz’s views were put to Delta CEO Ed Bastian by Marketplace.

His response was, well, quite direct:

“I disagree. Those certainly aren’t Delta customers he is speaking to.”

My Perspective as a Frequent Flyer

Just so you know my perspective: In the course of my work, I typically purchase between 10 and 20 thousand dollars worth of airfare a year. While this isn’t anywhere near the highest, I think I am the kind of customer an airline wants to get and retain.

Further, I know the system. I know what to expect, can quickly distinguish “abnormal” from “normal” and know how to maneuver to get out in front of issues I see developing. I pay attention to weather and other events that might disrupt the system, and contingency plan accordingly. I know, generally, how to arrange my stuff to get through TSA smoothly (though they can be arbitrary).

And I have the perks of a heavy frequent flier, which buffers me from a lot of the “stuff” that casual travelers have to contend with.

Munoz used some words that really identify the problem: …by the time you sit in one of our aircraft…”

This casual statement, which correlates with my experience as a former United Airlines customer** implies a belief that the customer service experience begins once you are on the plane. This isn’t where United’s reputation is created. Once you are on the plane, the customer experience of all of the major airlines is pretty similar.

My experience reflects that it is what happens on the ground that differentiates one airline from another.

Assumptions About Customers Come True

The assumption that customers are just “pissed off at the world” and there is nothing we can do about it is a self-fulfilling prophecy.

If that is the attitude from the top, then it lets the entire system off the hook for making any effort at all to understand the things that might take some of the sharp edges off the experience.

On the other hand, if the attitude is “We are responsible for the experience of our customers – even if we aren’t” then the effort can get focused on understanding exactly what kind of experience we want our customers to have, and engineering a system that delivers it to the best of our ability. That, in turn, allows reflection when we miss, and improvement for the next time.

One is a victim attitude. “We’ll get better customer satisfaction when our customers are better at understanding how hard it is.”

The other is empowering – “Even if our customers *are* pissed off at the world, we will own it and work to understand what we can do.

How Does Your System Respond to Stress?

This in my mind, is what really differentiates a good system from a broken one. Like I said, it’s easy when everything is flowing smoothly. But what happens when the system is disrupted?

Is there a mad scramble of figuring out what to do – like it is the very first time a maintenance issue has caused a flight to be cancelled? What are we going to do with all of these passengers? Process them through two people? (See the line in my photo above!)

Or is there a clear process that gets engaged to get people rebooked – leaving the true difficult cases for the in-person agents?

Ironically, the major airline with one of the very best on-time schedule records also has one of the best recovery processes. Go figure.

Then there are little gestures, like snacks or even pizza for those suffering through a long delay.

“It’s not our fault” easily leads to “you’re on your own.”

“We’re going to own it, even if we don’t” leads to “let’s see if we can help.”

Now… to be clear, the entire airline industry has a long way to go on this stuff. But my point is that some are making the effort, while others have given up.

What Experience Have You Designed for YOUR Customers?

That, ultimately, is the question I am posing here. If you start with the experience you want your customer to have – a standard – then you have a point of comparison.

Did we deliver that experience? If so, then could we do it more efficiently?

If not, what got in our way, how do we close the gap?

Without a standard to strive for, there can be no improvement – and I think this is what Taiichi Ohno actually meant.

——

* Estimates of the weight vary quite a bit.

Rough metric equivalents would be around 20 meters long, 9 meters high, 50 tons. About the weight of mid-cold war era tank.

——

** With one exception that was booked for me, I haven’t flown on United since mid 2014 after an experience that could not have been better designed to tell the customer “We don’t work as a team or talk to each other.”

I cashed in my frequent flier miles for a camera about a year later.

November 13, 2017January 9, 2019

Heavy Equipment Overhaul: Flow at Takt in 1938!

This is a great contemporary film from 1938 describing the complete overhaul of a mainline 4-6-0 steam locomotive in the U.K.

What is interesting (to me) is:

The overhaul involves stripping the locomotive down to individual parts. Each of the parts, in turn, flows through a process of inspection / repair or replacement, with a strict timing to ensure it is delivered back to re-assembly when required.
There are 6 positions with a takt time of 10 hours 44 minutes. Everything is timed to this cadence.
I can only speculate, but with that degree of rigor in the timing, they are going to be able to see a delay or problem very quickly, and get out in front of it before it causes a delay in the main-line work.
The parts that come off are not necessarily the exact once that are put back on. Everything is flowing – there are multiple locomotives in overhaul.

Flow in Overhaul and Repair

This is a great working example of a process flow that proves difficult for some organizations: Overhaul and repair. “We don’t know what we will find, so there is no way we can sequence and index it on a timetable.”

I’ve seen a similar operation overhauling helicopters. The intended flow was exactly the same.

Like the locomotive flow, they stripped everything down to the airframe. The various components had different flow paths for sheet metal, hydraulic components, power-train (engine / transmission), rotor components, electrical, avionics, and composite parts.
The objective was to deliver “good as new” items on time back to the re-assembly process.

Here is where they ran into problems:

If an item needed repair, then the repairs were done, and the item flowed back.
But if an item could not be repaired (needed to be scrapped and replaced) it was tagged, and returned to the “customer” – the parts bin in main assembly. It arrived just like any other part except this one was tagged as unusable. It was up to the assembly supervisor to notice, and initiate ordering a new one.

Who is your customer? What do they need?

The breakdown was that the repair line(s) saw themselves as providing a repair service. If it couldn’t be repaired, sorry.

What their customer needed was a good part to install on the helicopter. If they can create a good part by repairing the old one, great. But if it isn’t repairable, their customer still needs a good one and they need it on time.

The Importance of Timing and Sequencing

In the locomotive video, they emphasize the precise timing and sequencing to make sure each part arrives in the proper sequence, when it is needed, where it is needed.

Even if it actually worked like they describe, I can be sure it didn’t work like that when they first started.

The timing and sequencing is a hypothesis. Each time they overhaul a locomotive, in fact each individual part flow, is an experiment to test that hypothesis. Over time, it is possible to dial things in very precisely.

Why? So you can quickly identify those truly anomalous conditions that demand your intervention.

Normal vs Abnormal

Just because there are frequent issues does not negate the fact that most of the time things can probably flow pretty well. What we tend to do, however, is focus on the problem cases and give up on all of them. “What about this? What about that?” bringing up the legitimate issues and problems, causes us to lose sight of the fact that underneath it all there is a baseline pattern.

What is important is to define the point at which we need to intervene, and set up the process to detect that point. When we can clearly distinguish between routine work and true exceptions, and not try to treat everything as a special case.

July 30, 2016January 9, 2019

Toyota Kata: What is the Learner Learning?

In the language of Toyota Kata we have a “coach” and a “learner.” Some organizations use the word “improver” instead of “learner.” I have used those terms more or less interchangeably. Now I am getting more insight into what the “learner” is learning.

The obvious answer is that, by practicing the Improvement Kata, the learner is learning the thinking pattern that is behind solid problem solving and continuous improvement.

But now I am reading more into the role. The “learner” is also the one who is learning about the process, the problems, and the solutions.

Steve Spear has a mantra of “See a problem, solve a problem, teach somebody.” This is, I think, the role of the learner.

What about the coach?

The coach is using the Coaching Kata to learn how to ask questions that drive learning. He may also be un-learning how to just have all of the answers.

As the coach develops skill, I advise sticking to the Coaching Kata structure for the benefit of beginner learners. It is easier for them to be prepared if they understand the questions and how to answer them. That, in turn, teaches them the thinking required to develop those answers.

Everybody is a Learner

The final question in the “5 Questions” is “When can we go and see what we have learned from taking that step?” It isn’t when can I see what You have learned. It is a “we” question because nobody knows the answers yet.

May 4, 2016January 9, 2019

Delivering the Patient Satisfaction Experience

“Our challenge is to improve our patient satisfaction scores.”

This seems to be a fairly common theme as I continue to work in the health care arena.

Background

In the U.S. at least, most major health care operations use one of a couple of major service providers (such as Press Ganey) to survey their patients, and report aggregated patient satisfaction scores to them. Those scores provide a percentile rank of how that facility stacks up against others across various categories. The scores are also made public, and often influence public funding decisions within a region. Thus, they are a big deal.

Chasing the Patient Satisfaction Numbers Doesn’t Work

Here’s the problem. More than a few times I have seen an improver working on a challenge to improve these patient satisfaction numbers. It might be something like “Achieve a 70th percentile score on ___.) with a specific score that has to do with their area.

So far, that’s not a real problem. But what happens next might be.

It is very common to focus solely on the end result, without a lot of thought into the underlying things that drive that result.

Specifically, I have seen more than a couple of cases where a manager is working to directly influence how a patient (customer) will answer the questions on the survey. They parse the question, and try to determine what this word, or that word, actually means to “the patient.” The worst case was trying to introduce fairly heavy handed scripting… “Is there anything I can do for you to be more comfortable?” into every patient interaction.

I certainly can’t speak for the population of patients, but I can say that when I pick up on a scripted phrase, I become very aware of what it is, and it leaves a disingenuous taste.

It’s About the Patient Experience

The patients’ experience is what drives how (and even if) they will answer the questions on these surveys. If their experience was overall favorable, they will be biased to give favorable replies. The opposite is even more true. One bad experience will negatively bias all of their answers.

Here’s the question I ask that sometimes stumps people:

What experience to you want the patient to have?

(If you aren’t in health care, substitute the word “customer” for “patient.”)

If your scores on “Were the staff concerned for my comfort?” are low, think about what experience would give the patient confidence that staff were concerned. Being continuously asked about it with a rote phrase probably isn’t going to do it. But leaving them parked in the hallways with no interaction might be (for example), something that creates discomfort. (“Comfort” has a psychological, as well as a physical component.) People will put up with a lot of discomfort if they know the higher purpose. It’s hard to make the case for parking the patient in the hallway. That just says “I don’t have anywhere to take you.”

So think deliberately. If everything the patient experienced were something you were doing on purpose, because it contributed to the experience you want the patient to have, what would that look like?

Don’t worry right now about whether that is hard or not. Let go of your internal issues for a while. Just sketch out that awesome “insanely great” patient experience. You don’t have to think of every detail. What are the attributes? What is the flow, from the patient’s perspective – the sequence of events they will experience.

For example, construct a story, told from the patient’s point of view, of coming in for outpatient surgery.

What happens from the time they have their initial consultation until they are on their way home. (And what happens after they get home?) Again, don’t worry about “we can’t do that because…” stuff, we’ll deal with that later.

What experience, what story, would leave the patient with the impression that you are working as a team, that you know what you are doing, that there is a competent process at work to provide safe, effective care and actually care about their experience?

Don’t forget to include your administrative communications in this process – what phone calls do they get? What paperwork do they get? What does crystal-clear billing look like?

Build a block diagram, a story board, of the patients’ ideal flow through the system.

What would a wait-free, smooth flowing experience look like?

Learning From Disney

In Disney theme parks, they make a clear distinction between “On Stage” and “Off Stage.” Their employees (all of them) are referred to as “Cast Members.” Anytime a Cast Member is visible to guests, they are “On Stage.” They are performing. They are part of creating the story, the experience, they want the guest to have.

Meanwhile, behind the scenes, in the tunnels, off stage, are the processes required to create the “On Stage” performance. It’s a show.

The guest experience is designed. Once it is designed, it is created by the process.

Disney’s priorities (in order) are:

Safety
Courtesy
Show
Efficiency

Translated, they place putting an a good performance above being efficient. But if pushed, a cast member may break character if required to be courteous. And they will get snippy with someone who persists in doing something unsafe in spite of courteous requests.

What on Earth does this have to do with health care?

Everything. That is if you are trying to create a safe, professional and competent impression to your patients.

What is the Actual Patient Experience?

Now we have a sense of the ideal, it’s time to understand what is really happening. Again, start with the patient’s experience.

What happens at each interaction? What questions are asked? Who asks them? How often are they moved? Where and when are they waiting, and why?

Use “typical” rather than exceptional cases here. One thing I am seeing is, yes, every case is different but in reality, most are handled within a routine.

Pay attention to the “on stage” part of your process. This is what the patient sees, and what creates their experience.

At the same time, look at the behind-the-scenes “off stage” flow to see what might be causing a less-than-ideal patient flow. For example – The patient’s experience is that he is alone in an exam room waiting, reading Time Magazine for 20 minutes. That is the “on stage” part.

Meanwhile, “back stage” you have a nurse on the phone trying to get the results of tests that were done by another provider. (This is a real-life example.)* (There was also a physician waiting on them!)

Your Processes Create the Patient Experience

(Again, substitute “customer” for “patient” and this becomes an essay for everyone.)

Your Patient Satisfaction scores are driven by the patients’ experience.

The patients’ experience is established by your “on-stage” (patient facing) process.

Your “on-stage” process is the result of your “off-stage” execution.

The people making the improvements need to be challenged, and focused on, creating a specific experience for the patient.

Linking to Policy Deployment

All of that begs the question: Who should make the linkage between process performance and patient satisfaction, because those scores do matter, in a very big way.

Let’s look at this from a policy deployment standpoint.

Certainly Administration (the executives) should be tracking their scores. From their perspective, these are an important (along with patient safety, quality, length-of-stay, financial performance, etc) aspects of how the organization is performing.

They see the overall performance and trends. And they can see how each department is performing.

But the patient’s experience is cross-functional. The patient only sees “the hospital.” He doesn’t see, and doesn’t care, that Admissions, the lab, the Emergency Department, Outpatient Surgery, Environmental Services (who cleans his room) and Radiology are all different departments. The patient doesn’t see, and doesn’t care, that “the clinic” and “the hospital” are separate legal entities.

As part of Policy Deployment, Administration should be establishing operational standards and challenging the Department Directors to meet them. Those standards are based on what Administration believes will move the needle on the patient satisfaction scores. In reality, this is also an experiment. Does this operational standard meet our customer’s expectations?

They also are making sure the Directors are working on the cross-functional interfaces between their departments. (If it isn’t the Directors’ job to do this, whose job is it?)

Key Point: Until you are consistently delivering the product or service, there is little point in trying to change things up. Set a standard, strive to meet it. Once things are somewhat stable, then you can evaluate whether your standard is adequate or not. Think about it… what is the alternative? You have random execution that is randomly working. You don’t know why. You can’t talk to people about performance until they can demonstrate consistent execution.

Summary

Your patient satisfaction scores reflect the experience of the patient.

The patient experience is the outcome of your on stage process performance.

Your on stage process performance is ultimately driven by your back stage process execution.

If you want to improve your patient satisfaction scores, establish the operational standard you want to strive for that you think will improve patient satisfaction.

Then strive to develop a process that meets that operational standard.

THEN you can evaluate whether your process is adequate.

_________

*This was an obstacle in front of a target condition focusing on hitting a standard for “In, Seen and Out” within a specific time frame for routine pre-procedure consultations. They fixed it. Patients no longer have to sit and wait while someone hunts down those test results.

November 16, 2015January 9, 2019

Toyota Kata and Hoshin Kanri

Jeff asked an interesting question in a comment to the post Often Skipped: Understand the Challenge and Direction:

[Hoshin Kanri] seems to suggest I reach long term objectives (vision) through short term initiatives/projects as if I can (should?) know the steps. [Toyota Kata] says I don’t know the way to reach my long term vision, so I limit focus to next target condition and experiment (repeatedly) toward the vision.

Seems contradictory to me. What am I missing?

Let’s start out with digging into what hoshin kanri is supposed to do. I say “supposed to do” because there are a lot of activities that are called “hoshin kanri” that are really just performance objectives or wish lists.

First, hoshin kanri is a Japanese term for a Japanese-developed process. We westerners need to understand that Japanese culture generally places a high value on harmony and harmonious action. Where many Americans (I can’t speak for Europeans as well) may well be comfortable with constant advocacy and debate about what should be worked on, that kind of discussion can be unsettling for a Japanese management team.

Thus, I believe the original purpose of hoshin kanri was to provide a mechanism for reaching consensus and alignment within a large, complex organization.

In the late 1980’s and early 1990’s, hoshin kanri concepts emerged out of their Japanese incubator and came to western business. In this process, the DNA combined and merged with western management practices, and in many (never say “all”) western interpretations, the hoshin plan tends to be something patched onto the existing Management By Objectives framework.

That, in and of itself, isn’t a bad thing. Hoshin kanri’s origins are from MBO migrating to Japan where they took MBO and mixed in Japanese cultural DNA.

However, I’m not comfortable that what we have ended up with in the west meets the original concept or intent.

With that as background, let’s get to the core of Jeff’s question.

What is the purpose of hoshin kanri?

Let’s start with chaos. “We want continuous improvement.”

In other words, “go find stuff to improve,” and maybe report back on what you are going to work on. A lot of organizations do something like this. They provide general guidance (if they even do that), and then maybe have the sub-organization come tell and report what they expect to accomplish. I have experienced this first hand.

“I expect my people to be working on continuous improvement,” says the executive from behind his desk in the corner office. Since he has delegated the task, his job is to “support his empowered workforce” to make things better.

Flatly, that doesn’t work unless the culture is extremely well aligned and there is a
continuous conversation and stream of consciousness within the organization. That is very rare. How to achieve that alignment is the problem hoshin kanri is intended to solve. It isn’t the only way to do it, but it is an effective method.*

A Superficial Overview of the Process of Hoshin Kanri

The leadership sees or sets a challenge for the organization – something they must be able to do that, today, they cannot. This is not (in my opinion) the same as “creating a crisis.” A crisis just scares people. Fear is not a good motivator for creative improvement.

Different parts of the organization may get a piece of the challenge, or the leadership team may, as a whole, work to figure out what they need to accomplish. Here is an important distinction: “What must be accomplished” is not the same as a plan to accomplish it. A challenge, by its very nature, means “We don’t know exactly what we will have to do to get there.”

This can take the form of KPI targets, but that is not what you are doing if there is a simple percent improvement expected with no over-arching rationale.

Now comes the catchball.

Catchball is not Negotiation of the Goal

Catchball is often interpreted as negotiating the goals. That’s not it. The goals are established by a market or competitive or other compelling need. So it isn’t “We need to improve yield by 7%.” followed by “Well, reasonably, I can only give you 5%.” It doesn’t work like that.

Nor is it “You need to improve your yield by 7%, and if you don’t get it then no bonus for you.” That approach is well known to drive some unproductive or ineffective behavior.

And it isn’t “You’re going to improve your yield by 7% and this is what you are going to do to get there.”

Instead, the conversation might sound something like “We need to improve our yield by 7% to enable our expected market growth. Please study your processes as they relate to yield, and come back and let me know what you think you need to work on as the first major step in that direction.”

In other words, please grasp your current condition, and come back with your next target condition.

That sounds a lot like the Coaching Kata to me.

SIDEBAR:

Toyota Kata is not a problem solving method.

Toyota Kata is a set of practice routines designed to help you learn the thinking pattern that enables an organization to do hoshin kanri, and any other type of systematic improvement that is navigating through “We want to get there, but aren’t sure exactly how.”

An executive I am working with mentioned today that Toyota Kata is what is informing their policy deployment process. Without that foundation of thinking, their policy deployment would have been an exercise in assigning action items and negotiating the goals.

So what is the difference between hoshin kanri and Toyota Kata?

There isn’t a difference. They are two parts of the same thing. Hoshin kanri is a mechanism for aligning the organization’s efforts to focus on a challenge (or a few challenges).

Toyota Kata is a practice routine for learning the thinking pattern that makes hoshin kanri (or policy deployment) function as intended.

In hoshin planning, you are planning the destination, and perhaps breaking down individual efforts to get there, but nothing says you already know how to get there.

It isn’t an “action plan” and it isn’t a list of discrete, known action items. Rather, it is specific about what you must accomplish, and if you accomplish those things, then the results are predicted to add up to what you need.

What to Do vs How to Get It Done

At some point, someone has to figure out how to make the process do what is required. That has to happen down at the interface between people and the work actually being done. It can’t be mandated from above. Hoshin helps to align the efforts of improving the work with the improvements required to meet the organization’s challenge.

From the other side, the Improvement Kata is not about short-term objectives. The first step is “understand the challenge and direction.” Part of the coach’s job is to make sure this understanding takes place, and to ensure that the short-term target condition is moving in the direction of the challenge.

We set shorter term target conditions so we aren’t overwhelmed trying to fix everything at once, and to have a stable anchor for the next step. It enables safer learning by limiting the impact of learning that something didn’t work.

However, in Toyota Kata, while we might not know exactly how to get there, but we are absolutely clear where we have to end up.

The American Football analogy works well here. The challenge is “Score a touchdown.” But if you tried to score a touchdown on every play, you would likely lose the game. The target condition is akin to “get a first down.” You are absolutely clear what direction you have to move the ball, and absolutely clear where you need to end up in order to score. But you aren’t clear about the precise steps that are going to get you there. You have to figure that out as you go.

Hoshin Kanri focuses the effort – “What to work on.”

Toyota Kata teaches the thinking behind “How to work on it.”

*Though hoshin kanri may be effective, getting it to work effectively is a journey of learning that requires perseverance. It is much more than filling out a set of forms.