Some PDCA Cycles

We had five sequential operations. Although the lowest repeatable times for each were well within the planned / target cycle time, there was a lot of variation.

Though Operation 3 was working pretty continuously, Operations 4 and 5 (downstream) were getting starved on occasion, and the empty “bubble” was working its way to the output. The exit cycles, therefore, were irregular enough that they weren’t making rate.

The team set their target to stabilize Operation 3, with the expectation that doing so would smooth out the overall exit cycles.

To that end, they went back and started to study Operation 3 in a little more detail to better understand the obstacles that were impacting the Team Member’s ability to complete the work smoothly.

Then a wrinkle – a different team member was now doing the work, and his cycles were faster.

This actually was an opportunity. Why is one Team Member faster than another?

Their hypothesis was that the faster Team Member had some knack or technique, that enabled him to perform more consistently. And indeed, he did have a few tricks.

So the first experiment was to capture this work cycle in a Job Breakdown, then see if using Job Instruction and teaching it to the first Team Member they could duplicate the results of the second.

Then another wrinkle. The first team member was back on the job. Armed with the knowledge gained by breaking down the steps, key points and reasons for Team Member #2, they took more baseline data from Team Member #1 to set up their experiment.

…only to discover that Team Member #1 was also doing things that #2 didn’t do.

One of those things was unbending a part that was sometimes being bent by an upstream operation.

It seems that #2 was just passing those along as he got them. With that background, the conversation went something like this:

“What obstacle are you addressing?”

“The manual rework in Operation 3 is adding variation and extending his cycles.”

“What experiment are you running next?”

“We think the jig being used in Operation 1 is a bit undersize, allowing the part to deform. We are going to adjust the jig to the proper size.”

“What do you expect from that?”

“We expect to eliminate bent and deflected parts, and see more consistency in Operation #3’s cycles.”

Then they tried it. Skipping ahead a bit:

“What actually happened?”

“The parts are now more consistent, and there Operation #3 has a lot less variation, and is running closer to the planned cycle time… except that now he is waiting on parts from the upstream operation.”

“Huh. What is happening there? What did you just learn?”

“Well, it looks like Operation #3’s variation was masking inconsistent delivery from Operation #2. That team member is operating in small batches, then turning and delivering 3-5 parts at a time. When there was a lot of variation in Op #3, those parts were kind of buffering everything. Now he is working more consistently and faster, and ends up waiting on parts.”

“Because of the layout, the Operation #2 Team Member has to turn to his left and pass the parts behind him. He said he batches so he doesn’t have to turn so often. So what we are thinking is we want to…”

“Hang on, I want to stick to the structure so you guys can practice hearing and responding to it… So – what is your next step?”

“We talked to the team members, and they all agree that if we straighten out that bend in the layout, this will be a lot easier on them, so we are going to do that during the lunch break.”

“And what do you expect from that?”

“Operation #3 will get his parts one-by-one, as they are ready, and won’t have to wait on them.

“Great, so when can we see what you have learned?”

“Give us about 30 minutes after lunch break is over.”

You can probably surmise that things smoothed out a bit.

Then they went back to capturing a hybrid of the best practices of both operators in a job breakdown. At this point, the Team Members were genuinely interested in how they were doing, and both were quite open to learning the “tricks” of the other, so “Get the worker interested in learning the job” had pretty much been done.

A lot was learned over a few hours.

Reflection:

The “real world” is often quite a bit messier than the real world. There was actually a lot more dialog than I reconstructed here to keep the “learners” on track and focused on their stated target vs. resorting to an action of “improvements.”

In addition, merely beginning to work on one obstacle revealed enough information that they were dealing with a different underlying problem.

At another point in the week, they also believed they saw a need for more consistent part presentation. I happened to agree with them, but…

when pressed for what result they expected, the initial response was “The parts will be consistently presented.”… but what does that have to do with your target?

That was tough because, at the time, they were looking at the cycles of the 2nd operator that were, actually, pretty consistent, and lost sight of the fact that they were working on reducing the overall variation of output from that position.

They had a very hard time articulating why consistent part presentation would address the issue, even though they knew it should.

I think this is the result of years of conditioning that the “tools” – such as consistent part presentation – are good for their own sake, without really examining the underlying problems and causes that are being addressed.

If we lean practitioners are scratching our heads wondering why people don’t see this stuff helps, it would be a lot easier to deal with if we could point to the issue being addressed at the moment.

More tomorrow.

High-Speed Automation

While we lean practitioners seem to have earned a reputation of distain for high-speed automation, industries like mass production consumables, and the food and beverage industry, would not be viable without that approach.

These plants are capital intensive, and the main focus of the people is to keep the equipment running. I hinted at some of these things a couple of years ago from the Czech Republic.

Here are some more recent thoughts.

 

Even though it is about equipment, it is still about people.

This is not a paradox at all. People are the ones who are getting cranky equipment to run, scurrying about clearing jams, clearing product that got mangled. Until you have a “lights out” plant, people are critical to keeping things running.

Robust problem solving and improvement skills are more critical.

In a purely manual world, you can get away with burying issues under more people and more inventory.

With interconnected automated equipment, not so much. The hardware has to run. It all has to run or there is no output.

How the organization responds to a technical problem makes the difference between quickly clearing the issue, or struggling with it for a couple of hours while everything else backs up.

This is where standard processes are critical, not only to short-term success, but also to capture new information as it is learned. This is the “chatter as signal” issue I have written about a couple of times.

Quoting from the above link:

Most organizations accept that they cannot possibly think of everything, that some degree of chatter is going to occur, and that people on the spot are paid to deal with it. That is, after all, their job. And the ones that are good at dealing with it are usually the ones who are spotlighted as the star performers.

The underlying assumptions here are:

  • Our processes and systems are complex.
  • We can’t possibly think of and plan for anything that might go wrong.
  • It is not realistic to expect perfection.
  • “Chatter is noise” and an inevitable part of the way things are in our business.

Those underlying assumptions say “Our equipment is complicated and difficult to get adjusted. All we can do is try stuff until it runs.”

That assumption actually lets people off the hook of actually understanding the nuances of the equipment; as well as letting them off the hook of a disciplined approach to troubleshooting. The assumption essentially says “We can’t do anything about it.”

A dark side of this designed ignorance is that the only thing leaders are really able to do is hover about and apply psychological pressure to “do something” or, at best, contribute to the noise of “things to try.”

Neither of those is particularly helpful for an operator who is trying to get the machine running. Both of those actually have a built-in implication that the operator (1) Does not know how to do his job or (2) Is somehow withholding his expertise from the situation.

But we get a different result from the alternative assumptions:

On the other hand, the organizations that are pulling further and further ahead take a different view.

Their underlying assumptions start out the same, then take a significant turn.

  • Our processes and systems are complex.
  • We can’t possibly think of and plan for anything that might go wrong.
  • But we believe perfection is possible.
  • Chatter is signal” and it tells us where we need to address something we missed.

What does this look like in practice?

A known starting condition for all settings, that is verified.

A fixed troubleshooting checklist for common problems (that starts with “Verify the correct initial settings).

What things should be verified, in what sequence? (Understand the dependencies).

If a check reveals an issue, what immediate corrective action should be taken?

I would also strongly recommend using the format of a Job Breakdown (from TWI Job Instruction) for all of this. It is much easier to teach, but more importantly, it really forces you to think things through.

Of course, the checklist is unlikely to cover everything, at least at first. But it does establish a common baseline, and documents the limit of your knowledge.

The end of the operator checklist then defines the escalation point – when the operator must involve the next level of help.

It takes robust problem solving skills (and willingness to take the time to use them) to develop these processes; but doing so can save a mountain of time that pays back many times over.

The alternative is taking the time to mess with things until it sort of works, and never really understanding what was done or what had an effect – every single time there is an issue.

Cry once, or cry every day.

What does this have to do with improvement?

The obvious answer is that, if done well, it will save time.

The more subtle effect is that it sharpens the organization’s knowledge base, as well as their ability to really understand the nuances of the equipment. But this must be done on purpose. It isn’t going to happen on its own.

By getting things up and running sooner; and reducing the time of stoppages; it increases equipment capacity.

But more importantly, all of this increases people capacity.

It gives people time to think about the next  level of problems rather than being constantly focused on simply surviving the workday. Of course you need the right organizational and leadership structure to support that.

Visual Key Points

(Apologies for this post being “Password Protected” – I posted it from my smart phone, and obviously need to mistake-proof  something in the interface.) – MR

A key element of TWI Job Instruction is breaking down the job into important steps, key points, and reasons why.

An important step advances the work.
A key point is a critical aspect of the work that would:

  • injure the worker (or anyone else).
  • make or break the job.
  • make the job easier to do (a knack or technique that an experienced operator knows).

If it is worth making a key point over, it is worth putting a visual cue in the workplace.

If the key point is about something that would injure the worker, or make or break the job, you have a rich opportunity for mistake proofing.

In other words, a key point is something you are asking the team member to remember.

Help him out by reminding him or even better, engineering the work so that he doesn’t have to remember.

5S With Purpose

The team was driving toward a consistently executed changeover process as a target condition.

In the last iteration, the process was disrupted by a scrapped first-run part. The initial level cause was an oversize bit in the NC router resulting in an out-of-spec trim and oversize holes.

This occurred in spite of the fact that there are standard tools that are supposed to be in standard locations in the tool holders on the back of the work pallet.

Upon investigation, the team found:

  • The previous part had a programming error calling out the oversize tool from the wrong location.
  • All of the operators were aware of this, and routinely replaced the “standard” tool with the one the program required.
  • After that part was run, the standard condition had not been restored.
  • There was likely a break in continuity between operators here, but that was less clear.
  • The two bits are only 1/8 different, and hard to distinguish from one another across the 10 feet or so of the work pallet.

The team addressed the programming error, but among the thousands of other programs out there, they were reasonably certain that there were other cases where the same situation could be set up.

They wanted to ensure that it was very clear when there were non-standard tools in the standard locations.

Their initial approach was to create a large chart that called out which tools were to be in which holders. Their next experiment was to be to put that chart up in the work area.

 

“What do you expect to happen?”

That turned out to be a very powerful question. After a bit of questioning, they implied that the operator was to verify that the correct tools were in the standard positions before proceeding.

“How does this chart help them do that?”

They can see what the standard is.

“Don’t they all already know what the standard is?”

Yes…..

“So how does this chart help them do that?”

Now, to be clear, the conversation was not quite this scripted, but you are getting the idea. The point was to get them to be specific about what they expected the operator to do, and to be specific about how they expected their countermeasure to help the operator do it.

One team member offered up that maybe they could color-code the standard tools and their holders so it would be easy to check and easy to see if something was off-standard. That way, even IF the situation came up where the operator needed to deviate from the standard, anyone could easily see what was happening.

(I should add that they have already put an escalation process into place that should trap, and correct, these programming errors as they come up as well.)

The tools were color-coded over night, and in place the next day.

Color coded tool holders.

This wasn’t a “5S campaign,” nor is there an audit sheet that tries to measure the “level” of visual control in the work space.

Rather, this is using a visual control to visually control something, and reduce the likelihood of another scrapped part (and therefore, disrupted changeover).

Over the last week, the work cell has been improving. When things are flowing as they are supposed to, changeovers are routinely being done within the expected time.

But there are times when their standard WIP goes low; there are times when someone gets called away; when the flow doesn’t go as planned. When those things happen, they get off their standard.

The next countermeasure is to document, clearly, the normal pattern for who works where, for what inventory is where. Then the next question is “How can anyone verify, at a glance, whether or not the flow is running to the normal pattern?”

More visual controls. Ah.

Now we are seeing the reason behind 5S. It will come in to that work area, step by step, as the necessity to make things more clear arises.

Make a Rule / Keep a Rule

I was driving home today and saw a construction sign on the sidewalk. It read: “Sidewalk Closed, Use Other Side.” Ahead was a section of the sidewalk which was, indeed, closed off and impassible.

By the time a pedestrian encounters this sign, he is well into the middle of a long block.

The sign is at least implying that the pedestrian should cross the street in the middle of the block to get around the construction. The alternatives are:

  • Ignore the sign, and walk on the street around the torn up sidewalk.
  • Backtrack to a legal crosswalk, and cross the street where it is legal to do so.

This situation is actually fairly common in a lot of companies. There is a rule “Don’t cross the street in the middle of the block.” Then there is an expectation that is incompatible with following the rule.

  • “Be careful, but hurry.”
  • “Stop and fix problems, but don’t lose production.”
  • Stop for quality, but make the numbers.”
  • Get 90 minutes of work done in an hour.

The team member has the same alternatives as above – ignore the expectation, or ignore the rule.

This is a slightly higher level than Hirano’s observation that “the words ‘just for now’ are the origin of all waste.” Here we are putting the team member in an untenable situation because there is no action available that is clearly OK.

Take a look at the rules you have. Take a look at the actual behaviors. Remember that what people actually do is generally what they sincerely believe you expect of them.

If it is impossible to follow a rule, consider why the rule exists.

The words “Do the best you can.” are a warning that you are in this kind of situation.

Don’t Outrun Your Headlights

I am finding good resonance with my management training sessions. Rather than doing an overview of the “tools of lean” I go in depth into the fundamental things that the leaders need to

  1. Learn to do, and do.
  2. Ensure are done.

in order to build this on a solid foundation.

But “resonance” seems to mean “in a hurry to get to the good stuff” and a temptation to skip some of the foundational work.

We need to start off in learning mode, working to build a foundation of stability and consistent execution.

Without consistent execution, all of the great plans are nothing but ideas. The first hoshin to work on is establishing a stable process of daily improvement. Once you have that, your improvement management process becomes an exercise in priorities and direction setting.

Without consistent execution, your improvement plan is application of brute force against the momentum of business as usual.

That isn’t “resistance to change” at work. It is “we barely have time to survive down here, so we’ll get to your improvements when we have time.”

You have to create that headroom first. Honestly, it is mostly about instilling confidence, both in themselves, and in you. They have to believe they can carry out the plan. They have to trust you to be consistent with your purpose and not cut their legs out by asking them to change course in the middle.

All of this takes practice. With the right kind of practice comes teambuilding. (That shouldn’t be a separate activity.)

Step by step. You can move quickly, but only if you embrace “smooth is fast.”

Steve Spear on Creative Experimentation

On Monday MIT hosted a webinar with Steven Spear on the topic of “Creative Experimentation.”

A key theme woven throughout Spear’s work is the world today is orders of magnitude more complex than it was even 10 or 15 years ago. Where, in the past, it was feasible for a single person or small group to oversee every aspect of a system, today that simply isn’t possible except in trivial cases. Where, in 1965 it was possible for one person to understand every detail of how an automobile worked, today it is not.

My interpretation goes something like this:

Systems are composed of nodes, each acting on inputs and triggering outputs. In the past, most systems were largely linear. The output of upstream nodes was the input of those immediately downstream. You can see this in the Ford Mustang example that Spear discusses in the webinar.

Today nodes are far more interconnected. Cause and effect is not clear. There are feed-back and feed-forward connections and loop-backs. Interactions between processes impact the results as much as the processes themselves.

Traditional management still tries to manage what is inside the nodes. Performance, and problems, come from the interconnections between nodes more than from within them.

The other key point is that traditional management seeks to first define, then develop a system with the goal of eventually reaching a steady state. Today, though, the steady state simply does not exist.

Product development cycles are quickening. Before one product is stable, the next one is launched. There is no plateau anymore in most industries.

From my notes – “The right answer is not the answer for very long. It changes continuously.”

Therefore, it is vital that organizations be able to handle rapid shifts quickly.

With that, here is the recorded webinar.

(Edit: The original flies have been deleted from the MIT server.)

A couple of things struck me as I participated in this.

Acknowledging that Spear has a bias here (as do I), the fact that Toyota’s inherent structure and management system is set up to deal with the world this way is probably one of the greatest advantages ever created by happenstance.

I say that because I don’t believe Toyota ever set out to design a system to manage complexity. It just emerged from necessity.

We have an advantage of being able to study it and try to grasp how it works, but we won’t be able to replicate it by decomposing its pieces and putting it back together.

Like all complex systems, this one works because of the connections, and those connections are ever changing and adapting. You can’t take a snapshot and say “this is it” any more than you can create a static neural net and say you have a brain.

Local Capability

One thing that emerges as critical is developing a local capability for this creative experimentation.

I think, what Spear calls “creative experimentation” is not that different from what Rother calls the “improvement kata.” Rother brings more structure to the process, but they are describing essentially the same thing.

Why is local capability critical? Processes today are too complex to have a single point of influence. One small team cannot see the entire picture. Neither can that small team go from node to node and fix everything. (This is the model that is used in operations that have dedicated staff improvement specialists, and this is why improvements plateau.)

The only way to respond as quickly as change is happening is to have the response system embedded throughout the network.

How do you develop local capability? That is the crux of the problem in most organizations. I was in an online coaching session on Tuesday discussing a similar problem. But, in reality, you develop the capability the way you develop any skill: practice. And this brings us back to the key point in Kata.

Practice goes no good unless you are striving against an ideal standard. It is, therefore, crucial to have a standardized problem solving approach that people are trying to master.

To be clear, after they have mastered it, they earn a license to push the boundaries a bit. But I am referring to true mastery here, not simple proficiency. My advice is  to focus on establishing the standard. That is difficult enough.

An Example: Decoding Mary – Find the Bright Spots

Spear’s story of “Decoding Mary” where the re-admission rate of patients to a hospital directly correlated with the particular nurse handled their transfer reminded me of Heath & Heath’s stories from Switch. One of the nine levers for change that they cite is “find the bright spots.”

In this case the creative experimentation was the process of trying to figure out exactly what Mary did differently so it could be codified and replicated for a more consistent result independent of who did it.

The key, in both of these cases, is to find success and study it, trying to capture what is different – and capture it in a way that can be easily replicated. That is exactly what happened here.

A lot of organizations do this backwards. They study what (or who) is not performing to determine what is wrong.

Sometimes it is far easier to try to extract the essence what works. Where are your bright spots for superb quality? Does one shift, or one crew, perform better than the others? Do you even know? It took some real digging to reveal that “Mary” was even the correlating factor here.

Continuous Improvement Means Continuous Change

Since “continuous improvement” really means “continuously improving the capability of your people,” now perhaps we have “to do what.” I have said (and still say) that the “what” is problem solving.

What you get for that, though, is a deep capability to deal with accelerating change at an accelerating rate without losing your orientation or balance.

It is the means to allow the pieces of the organization to continue to operate in harmony while everything is changing. That brings us back to another dilemma: What is the ROI on learning to become very, very good? You don’t know what the future is going to throw at you, only that you need the capability to deal with it at an ever quicker pace.

But none of this works unless you make a concerted effort to get good at it.

Here is the original link to the MIT page with the video, and a download link for PDFs of the slides:

http://sdm.mit.edu/news/news_articles/webinar_010912/webinar-spear-complex-operating-systems.html

The Annual Operating Wish

As we approach the end of the calendar year, many companies are starting to work on their Annual Operating Plans Wishes for next year.

Why do I say wish? Because all too often these plans dictate what they wish would happen. Throughout the year, performance is “measured” against the plan. Positive variances are rewarded. Negative variances are, well, not rewarded.

To make things more interesting, each department: Sales, Production, Purchasing, etc., is responsible to meet the plan independently of the others. That makes sense, it is the only way they can be “held accountable.”

So when sales fall short in 1st quarter, production keeps producing. They have to. Otherwise they wouldn’t meet their AOP numbers.

To make things more interesting, if the sales mix changes from the original plan, and there is a raw material shortage that prevents shifting the production to match sales, production just makes whatever the can, whether it is selling or not.

It is pretty easy to think this through to a process of running overtime on weekends to build a product that was sold at a discount to “make the numbers” in the AOP.

The hilarious thing is that I have yet to meet a manager, at any level, who does not agree that this is exactly what happens, and that it is a poor way to run the business.

Yet we keep doing it over and over.

OK, so what to do about it?

The most important thing to grasp is that “the plan” is just that. It is not a fact. It is a working hypothesis, a prediction. It is wrong the day it is made. (If you can perfectly predict the future, why are you reading this?)

The purpose of making a plan is to identify the unexpected. If the sales mix and numbers start to depart from the plan, the entire system responds. This isn’t every department for themselves. (or shouldn’t be) This is about running the company to maximize total margins.

That means working together as a team with one plan, not a separate one for everyone.

The Tough Decision: What Not To Do

Today’s Dilbert strip highlights a situation that is only funny because it happens so often:

The idea that a company can focus on 25 key areas, or 125 key performance indicators (yes, I said 125 because I have seen it myself) is obviously ludicrous.

Of course a manager has a legitimate concern to ensure people don’t take their eyes off things that are important to focus on something else.

But the leader’s role here is to ensure there are processes and systems in place that anchor the routine things. Further, those processes and systems need to be designed to alert the appropriate people when something goes out of control, or past a boundary.

Without having any routines the manager has no choice but to make everything something to focus on.

Because there is no standard process, everything must be managed as an exception.

This stresses the organization because in reality they can only micro-manage a few things at a time. It is left up to the people to decide what isn’t going to get done. The bosses response at that point is going to be negative no matter what they accomplish. “Respect for people” does not play here.

Leader’s toughest job is deciding what we are not going to work on right now. It isn’t as tough as it seems because if a focus or challenge is selected well, it actually organizes the problem solving effort to pull just about everything else in behind it.

Let’s take an example from a previous post: On time delivery.

If we say “We are going to emphasize “on time delivery” as a theme or challenge this year, what kind of things might people end up working on?

  • Having every operation start on time.
  • Sources of delay.
  • Quality issues (which cause delays)
  • Safety issues (also cause delays)
  • Visual controls and good response to problems (to get on top of problems quickly)
  • Equipment reliability.
  • Setting a good operational takt time.

The list goes on. But by having a decent challenge, the local area can focus on the things that are impacting their ability to deliver on time. It isn’t necessary to make a laundry list of everything that could cause a delay and measure it from the top of the organization. If you do, everyone’s energy is dissipated working on problems that they don’t necessarily have.

Of course this is all based on having a leadership process that gets down to the work area, grasps what people are actually working on, and coaches them through the process of aligning their efforts and solving the right problems in the right way.

Hmmmm… so does that mean that the #1 thing to focus on if you want consistent on-time delivery might be leadership development?

I guess I need to get back to the Liker and Convis book.

Bill Costantino: Toyota Kata “Unified Field Theory”

Mike Rother and Bill Costantino have shared a presentation titled “Toyota Kata Unified Field Theory.”

I think it nicely packages a number of concepts in an easy-to-understand flow.

I want to expand on a couple of points but first take a look at the presentation.

This is a direct URL to the original SlideShare version: http://www.slideshare.net/BillCW3/toyota-kata-unified-field-theory

Challenges and Campaigns

First of all, this presentation differentiates between a “challenge” and the target condition. That is important, and (in my opinion) had not been as clear in Rother’s original book.

I have been advocating setting a challenge, or campaign if you well, for some time. This is where we address a class of problems that are a major issue. Things like:

  • Too much cash tied up in working capital. (Which can be expressed a number of ways, such as improving inventory turns.)
  • Poor schedule performance – “on time delivery” becomes the theme.
  • Quality issues (too much rework, scrap, etc.)
  • Our nurses don’t have time to prepare rooms for the next patient.
  • Of course, safety can come into this arena as well, as can other issues that impact the organization’s health.
All of these things are not really problems in the sense that they can’t really be solved. These are the aggregated symptoms of lots of smaller underlying problems that accumulate into things on this list.

Setting a specific challenge doesn’t mean you ignore the other stuff. You have been coping with it and working around it for years. But you know you haven’t had time to fix everything, so stop believing that you do.

The point here is to galvanize the effort.

Chip and Dan Heath address the importance of setting the challenge in their book Switch (which I have reviewed here). They emphasize the importance of “scripting the critical moves” and “pointing to the destination” so that people have a good grasp of what is important.

Once the challenge is addressed, say “on time delivery,” it can be broken down into target objectives that are both local (large organizations need to have things broken down to what the local group is expected to work on) as well as those which cut cross-functionally. The scope of the effort is really defined by the depth of the organization’s skill at addressing the issues at this point.

Bill Costantino correctly points out that setting the vision, and deciding the theme or campaign, is a leadership function. This can’t be done by your “lean team” in a way that sticks. The discipline required here is for the leaders to maintain what Deming referred to as “consistency of purpose.”

Simply put, to say “this is the challenge” and then continuously ask about other stuff jerks people around and serves only to paralyze the organization until the leaders decide what people should spend their limited time on.

The good news is that it really doesn’t matter. If the organization can focus on One Big Thing long enough, their efforts will eventually touch on the other stuff anyway.

Jim Collins uses different words to make the same point in Good to Great with the “Hedgehog Concept.”

The Path to the Target Condition

One place where I think we can still use some more clarity is in the illustration of the path to the target condition.

This is the illustration from Slide 20 in the Slideshare version of the presentation:

The presentation (and Rother’s coverage in Toyota Kata) is quite clear that navigation through “the grey zone” is a step-by-step process (kind of like driving off-road at night where you only see as far as your headlights).

But the “plan and execute” paradigm is very strong out there.

My experience is that people in the field see this illustration, and fully expect the green path to be set out, and the “dots” identified, along with a time line and resources required to get there. It becomes a “project.”

This is a strong symptom of the “delegate improvement” paradigm that we should all be actively refuting.

Let’s look at how I think this process actually plays out dynamically.

Initially we know where we are, we have target condition, so we know the direction we need to go to get there.

We are still inside the red line of the “current knowledge threshold.” Solving these problems is generally application of things we already know how to do, perhaps in new ways.

And having solved one problem, we now identify the next known barrier:

Once that one is cleared, we see a couple of choices. Which one?

All other things being equal, pick the easiest, and move on. (As we said when I was learning rapid maneuver tactics in the Army – “haul ass and bypass.”)

Up to this point, we have been operating inside the “current knowledge threshold.” Our efforts are better focused by pursuing a clear target objective, but we aren’t really learning anything new about the process. (Hopefully we are becoming better practiced at problem solving.)

Pretty soon, though, we reach the edge, and have to push out the red line. Why? Because we can’t solve a problem we don’t understand. As we approach the boundary, things get harder because we have to do a better job assessing, and extending the knowledge threshold around the problem.

This is the essence of the problem solving process – If you can’t see the solution, you need to better understand the problem.

The process becomes one of progressively solving problems, identifying the next, and expanding our understanding. Once there is sufficient understanding to anchor knowledge and take the next step, do so. Step and repeat.

Putting the whole thing in motion, it looks like this:

The key is that the “green path” isn’t set out as a predictable trajectory. It is hacked out of the jungle as you go. You know you are going, are confident you can get there, but aren’t sure of exactly what issues will be encountered along the way.

Let me apply my “Project Apollo Test” to this process.

Vision: “The USA will be the undisputed leader in space exploration.” Vague, a long way out there, but compelling.

Challenge, Theme: “…before this decade is out, […] landing a man on the moon and returning him safely to the Earth.” In 1961, a serious challenge, but considered do-able based on extrapolating what we knew.

At this point, though, space exploration was exploring a lot of different things. Building a space station, reusable launch vehicles, pretty much the whole gamut was being explored by someone, somewhere. The effort wasn’t focused. The “man on the moon” goal focused it. Every thing was pretty much dropped except solving the problems that were in the way of making Lunar Orbit Rendezvous work.

There were four target conditions that had to be cleared.

Build and test the Big Honkin’ Rocket called the Saturn V plus the infrastructure to launch them in rapid succession.

And they had to answer three questions:

  1. Can people spend two weeks in space without serious physical or psychological problems?
  2. Can we build a space suit that lets someone operate outside the protection of a space craft?
  3. Can one space craft maneuver, rendezvous and dock with another?

Of course each of these objectives, in turn, had lots of smaller challenges. NASA’s effort between 1962 and 1966 was focused on answering these three questions.

In doing so, the threshold of knowledge expanded well beyond the immediate issues.

Yup, I’d say this thinking works, and it scales up.

Why did I go through this little exercise? Because if this thinking can put people on the moon, it is probably powerful enough to move your organization into new territory.

Back on Earth, a company undertaking “lean” needs to really grasp that they need to be committing to embracing this process. There are clear things that leaders need to do to make it work, and those things go beyond “supporting” or “sponsoring” the effort. We’ll get into some details on the next few posts as we continue to build on Rother’s and Costantino’s work.