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.
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.
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 Greatwith 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:
Can people spend two weeks in space without serious physical or psychological problems?
Can we build a space suit that lets someone operate outside the protection of a space craft?
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.
I spent last week teaching three sessions of Job Instruction. One session at the end of night shift starting at 5am, the second session catching the start of day shift at 7am, then the third session for swing shift at 1:30.
What is cool, though, is there is a senior member of the site leadership team in every session. They are not just observing, they are active participants.
Next week those leaders, with input from the team members in the class, are going to caucus and discuss the ramifications and how to deploy this method across their operations.
This is critically important because just teaching a few dozen people a skill and expecting them to each apply it independently doesn’t work. The company has to also develop the ecosystem that it can flourish in.
But this has been the pattern from this company from the beginning.
The Operations Manager has been leading the operations kaizen teams, working hard along side the team members to develop disciplined, effective pull systems. This is a high-variety product mix, with lots of different routings, so there were some real challenges to overcome. I was really impressed with their application of what would normally be very advanced thinking.
Results? Over the last six months, their metrics have taken a clear turn upward. You can see the inflection point on the graphs. Their company sister operation is starting to take notice. Good things all around.
A plant manager once shared a conversation he had with his CEO. The teaching is important, but what makes it work is willingness to be taught.
When we talk about management involvement, this is the crux. This team has been curious, willing to try and explore things – in front of their team members – and willing to keep at it until they figure out how to make it work.
I was in a conversation today and we ended up boiling 5S down to three key points:
You have everything you need.
You need everything you have.
You can see everything clearly belongs where it is.
Of course at the next level, these statements are the standards you are continuously checking against.
Presumably we have cleared out everything else, leaving only what we thought was needed, and established visual controls to verify we have those things, and only those things, in the work area.
Then, as the work is done, the moment someone discovers something else is needed, THAT is the time to deal with the issue.
– Ask “Is this something we should need in the normal course of the work?”
If so, then you learned something that you didn’t know or didn’t remember when you first organized the area. Add that item, find a place for it, and establish a visual control. Right now.
If not, then “Why did we need it this time?”
What broke the normal pattern of work?
This is where 5S breaks down – when we don’t discriminate between something that is needed in the normal course of work, and something that is needed as an exception.
If we just “get it” and add it to the work area, then we normalize deviance and incrementally erode the process. If we ignore the issue, we add “getting this when it is needed” to the work cycle.
If, on the other hand, we seek to understand what broke the normal pattern and deal with the core issue, we have a shot at real kaizen. (It is perfectly OK to get what you need and keep it around as a temporary countermeasure. Just put it someplace where you will KNOW when you used it.)
The worst thing you can do is allow these small problems to accumulate and try to correct them en-mass as some kind of “corrective action.”
Kanban
Likewise, kanban can be expressed the same way. It is more dynamic, but is really answering the same questions in the context of materials.
Standard Work
If you paraphrase these key points to just about any other “tool of lean” then the purpose of surfacing problems and driving solution becomes apparent.
You are doing everything that is required.
Everything being done is required.
Everything being done clearly is part of the sequence.
Take a look at the other classic “tools of lean.” How would they fit into the same pattern?
Aside from his intended point that you never get good at anything but “business as usual” if “business as usual” is what you do most of the time, there are some other implied questions.
First of all, if there were only 15 days between improvement events, that would be overwhelmingly better than what I normally see. Typically a particular area can see months go by between scheduled improvement events.
Most organizations (how about yours?) seem to believe that once an improvement event (or a “belt project”) is concluded, that people should just “follow the new process” to hold the gains.
No wonder we see the advice to “fix it again!” We have to fix it again just to restore it to where it was after it erodes.
But there is a deeper question here.
What kind of “improvement processing” is this? Are we moving toward “one by one flow of improvements” or are we running improvements in batches?
This is batch improvement. We are doing a changeover, running the improvement process, then doing another changeover, and running business as usual.
Unless business as usual includes a robust and reliable process for detecting small problems, responding immediately, clearing them, and solving them, nobody but the event facilitators are learning how to do improvements. People may be learning about improving, but unless they are doing it every day, they are not getting particularly good at it.
Want to see evidence of this? What happens between the events? Do things get better or worse? If “business as usual” includes improvement, things will get progressively better, and you can stop reading this because your organization gets it.
So here are a few questions for you.
Assuming you want to strive for true, daily, continuous improvement, what is the next step you plan to take in that direction?
How will your “business as usual” operate when you take that step?
How is it operating now? What is the gap?
What is stopping you from doing that now? If nothing, then do it now, and cycle back to the first question.
Which of those problems are you working on next?
When are you going to be able to check your results and learn what the next incremental target is?
Now – head down to your work area and ask yourself how you expect problems to be handled. Then watch and see what is actually happening when problems are encountered.
In other words, let’s manage improvements the same way we are asking everyone else to manage production.
27 months ago I wrote a piece about a “firefighting culture” where I described the actual process used to fight fires – following PDCA.
I have learned a few things since then, and I want to tighten my analogy a bit.
What is the core thinking behind true firefighting? This is actually closer to home than you may think. Many companies have situations that are on fire – in that they are destructively out of control.
I recall Mr. Iwata lecturing a group of managers in a large aerospace company in Seattle. He listened patiently to their grand plans about how the transformed operation would look. Then his remarks cut to the chase.
“Your house is on fire. This is not the time to be thinking about how you will decorate it.”
The question is – does urgency force a change in the thinking or approach?
I say it does not. However urgency does stress people’s skills and capabilities to deal with the situation to the limit – and beyond. Thus, it is best if those skills are thoroughly developed before there is a crisis, when the stakes are not so high. This is how high-risk professions train. They work to develop ingrained habits and skills for handling chaos before it is real.
So let’s go to our hypothetical burning building and look at what happens – as a matter of routine – even though every situation is different.
The target condition is a generally a given: The fire is extinguished, things are cooled down enough that there will be no re-ignition.
What is the current condition? Yes, the building is on fire. (doh!) But there is more to it than that.
What is stopping us from putting this fire out right now?
What is the layout of the building? Its construction? Where are the air shafts, sources of fuel, oxygen? Are there hazards in the building? Is there a basement under the main floor? Is there anyone inside?
Because they are (hopefully) skilled and practiced, gaining this information is routine, and hopefully they are getting most of it on the way.
The fire chief on site is going to develop an overall strategy for attacking the fire, and deploy his forces accordingly.
Neither do they have a detailed “action plan” that they can blindly follow. Simply put, they are in an vague situation with many things that are still not known. These things will only be revealed as they progress.
What is the first problem?
The initial actions will be more or less routine things that help the effort, and gain more information. They are going to ventilate the roof to clear smoke, and they are going to first work to rescue any people who are trapped.
This is their initial tactical target condition.
As they move toward that target, they will simultaneously gain more knowledge about the situation, decide the next objective, and the actions required to achieve it.
Cycle PDCA
As they carry out those actions, either things will work as predicted, and the objective will be achieved or (more likely) there will be surprises. Those surprises are not failures, rather they are additional information, things that were not previously understood.
Because this is dangerous work, if things get totally strange, they are going to back-out and reassess, and possibly start over.
As they go, they will work methodically but quickly, step by step, never leaving fire (unsolved problems) behind them, always having an escape path.
And, at some point along the way, what must be done to accomplish the original objective, put out the last of the fire will be come apparent.
Why are they so good at this?
Simple. They practice these things all of the time, under constant critical eyes of trainers. Every error and mistake is called out, corrected, and the action is repeated until they routinely get it right. Even though they are very good at what they do, they know two things:
They can get better.
Their skills are perishable.
So, although each fire is different, they have kata that they practice, continuously – from basic drills to training in more complex scenarios. They are putting these things to use now that there is real urgency.
What about the rest of us?
In business, we tend to assume that crisis will either not occur, or when it does will be within our domain of being able to handle it… but we often get surprised and our problem solving skills are stretched to the breaking point.
Why?
Because we have never really practiced those skills, and if we have, we have not been critical enough of how we went about solving routine problems, and we are sloppy.
When there is no urgency, we can get away with being sloppy. When method is not critical, anything more or less works. But when things are complicated, messy, and right now, there isn’t time to practice. “You go to war with what you’ve got.” What that really means is that, however ill-prepared you are, you now have to deal with reality.
Problem solvingis as important to a business (and I include any human enterprise, profit or not in this) as it is to the firefighters. Business has technical skills, as firefighters have handling hoses, operating their equipment, etc. But no matter how competent firefighters are at their technical tools, they are lousy firefighters if they have not practiced quickly solving problems related to putting out fires.
Likewise, no matter how good you are at keeping your books straight, managing your order base, scheduling production, whatever routine things you do, if you have not practiced problem solving skills on a daily basis, you are likely not very good at it. Daily kaizen is practice solving problems. The side-benefit is your business gets better as a result.
The difference is that firefighters know it is important, so they practice, subject themselves to the critical eye of professional trainers and coaches. In business, nobody teaches “problem solving” except in the most vague way.
Now and then, usually when coaching or teaching someone, I get what I think is a flash of insight. Then I realize that, no, there is nothing new here, it is just a different way to say the same thing. Still, sometimes finding a different way of expressing a concept helps people grasp it, so here is one I jotted down while I was working with a plant.
One of the myths of “lean production” is the idea that, at some point, you achieve stability in all of your processes.
Nothing could be further from the truth.
Failure is a normal condition.
The question is not, whether or not you have process breakdowns.
The question is how you respond to them. Actually, a more fundamental question is whether you even recognize “process failure” that doesn’t knock you over. Our reflex is to try to build failure modes that allow things to continue without intervention. In other words, we inject the process with Novocain so we don’t feel the pain. That doesn’t stop us from hitting our thumb with the hammer, it just doesn’t hurt so much.
But think about it a different way.
“What failed today?”
Followed by
“How do we fix that?”
Now you are on the continuous improvement journey. You are using the inevitable process failure as a valuable source of information, because it tells you something you didn’t know.
There is a huge, well established, body of theory in psychology and neuroscience that says that we learn best when three things happen:
We have predicted, or at least visualized, some kind of result.
We try to achieve that result, and are surprised by something unexpected.
We struggle to understand what it is that we didn’t know.
In other words, when we (as humans) are confronted with an unexpected event, we are flooded with an emotional response that we would rather avoid. In simple terms, this translates to “we like to be right.” The easiest way to “be right” is to anticipate nothing.
This takes a lot of forms, usually sounding like excuses that explain why stability is impossible, so why bother trying?
Why indeed? Simple – if you ever want to get out of perpetual chaos, you first have to embrace the idea that you must try, and fail, before you even know what the real issues are.
While the dentist was looking over my x-rays, he saw something he would like checked out by a specialist. He used words like “sometimes they..” and “might be…” when describing the issue he saw.
I get a referral. The information on the referral slip is the name of the referring dentist (which I can’t read), no boxes checked, and “#31” in the comments.
I call the specialist and start getting technical questions about what my dentist wants them to look at / look for, etc.
So the process is to use the patient as a conduit for vaguely expressed (in layman’s terms) technical information between highly trained specialists.
Sadly, I think this happens all of the time in the health care industry. It seems that there is so much focus on optimizing the nodes that nobody really “gets” that the patient’s experience (and ultimately the outcome of the process) is defined more by the interactions and interfaces than it is by the nodes themselves.
I am really not sure how fundamentally different this is from a pilot asking a passenger to find the maintenance supervisor and tell the mechanic about a problem with a plane.
The net effect is, as I am writing this, the specialist’s office is calling the referring dentist and asking them what, exactly, they want done.. a net increase of 100% in the time involved for all parties to communicate.
While the national debate is on how we pay for all of this, we aren’t asking why it costs so much (or kills more people than automobile accidents do).
I will be the first to tell you that this is probably repetition of a fairly narrow theme you have seen here before. But I think of different ways to frame it, or get different thoughts, so I share them.
“Problems first” is one of the mantras used by Phil Jenkinson, the CEO character in The Lean Manager by Michael and Freddy Ballé. Now that I have had a few weeks to let it sink in and synthesize with my mental models, I am seeing a concept that is so fundamental I would think it would be hammered into students in every management and leadership course taught in the world.
Of course, though, it isn’t.
Instead it seems alien in most company cultures.
Yet without a “problems first” culture, the leaders really have no idea – none at all – what they should be focusing their attention on. How could they? They don’t know what their people are struggling with until it is too late. By that point, a small unresolved problem has grown to the point where it cannot possibly be ignored, and now it must be dealt with. Task teams are formed, initiatives are launched. Action item lists are made and presented every week, and after enormous expense and effort, the illusion of control is returned. And so many companies are run just like this.
I am pretty sure that anyone reading this knows exactly what this feels like. Let me call it a “hidden problems” culture for now. Maybe I will think of a better term later.
Enough about what it isn’t.
Ironically, a lot of companies in the pursuit of “being lean” actually go blindly through the motions of “problems first,” but so in a way that raises questions about their understanding of this concept.
Let’s look at a simple action item review at a staff meeting.
Typically it looks like this:
For each action, the responsible person reports on the status, whether or not it is “on time” (usually against an arbitrarily assigned due date), and any “problems.” The manager asks if any help is needed, and perhaps assigns more actions to someone else to assist.
One common management tool for these things is a “Stoplight Chart” where actions are assigned color codes of Green, Yellow, or Red, usually depending on progress against the deadline (how late they are).
Red items get the most attention in the meeting (as they should, more about that in a minute), but that attention is usually in the framework of review and reporting.
At the end of the meeting, the senior leader has a good feel for what is happening (or what is not happening).
Contrast this with a world-class automobile assembly line.
Just like the actions items, every task has a deadline. Only in this case, the timing is much tighter – measured in seconds, not days. The assembler knows that if he gets more than 3-4 seconds behind, for any reason at all, he cannot possibly catch up and complete the work cycle on time. He is going to be late.
He pulls the andon cord, to let the team leader know there is a problem.
Key Point: This is not a report of a problem. This is transfer of the problem. The assembler is responsible for carrying out the work as it is designed. If he can’t, for any reason, then exceptions are transferred to the team leader.
The team leader can deviate from the standard work sequence to complete the job, but not the timing. If he cannot clear the problem by the end of the takt cycle, that section of the line will stop, and the andon will go red.
This is not a report of a problem, this is transfer of the problem. The team leader is responsible for assuring the work can be completed within the takt time. If he can’t, for any reason, then exceptions are transferred to the supervisor.
The supervisor is now responsible for clearing the problem and getting things moving again. If he can’t, then within a few minutes, another section of the line will be stopped and the responsibility for clearing the problem transfers to the next level in the chain.
And so it continues.
Of course this increasing level of responsibility does not mean that the others walk away. They are clearly working very hard to get the problem cleared. But each level of escalation brings more resources to bear on the issue.
Note that I haven’t talked about root cause and problem solving yet. Although the escalation procedures are designed to help gain better understanding of the underlying cause, the first priority is to get the problem cleared so that production can resume without compromising safety or quality in any way.
There may be a temporary countermeasure put into place to do this – some short term action that, while it might introduce some extra resources into the process, allows safe, quality production to proceed long enough to get to the underlying cause. One test of understanding that cause can be to remove this temporary crutch and see what happens.
OK, back to the staff meeting.
What is different about that?
The main thing is that typically the problems are being reported, but not escalated. The responsible person may have to come with an action plan to clear the issue, but it is still Management by PowerPoint, and the senior leader’s role is approval vs. involvement. If the senior leader does become involved, it is often driven by a perception that the responsible person is incapable rather than a process of professional development.
What would this look like if it were managed exactly the same way as the assembly line?
What if that monthly review were treated the same as the fixed stop position?
A couple of ideas come to mind.
“Green” means “on track, as originally scheduled.”
“Yellow” means “behind, but we have a plan to get back to green.”
“Red” means behind, and we don’t know how we are going to recover.”
How would those meanings change the tenor of these meetings?
“Problems first” is more than just a discussion about problems. It is a culture that is focused on finding them, clearing them, and solving them, and doing so with the same priority that comes with production.
