Needs to be covered again, because most people act as though we don’t know it.
Simply put, Liker and Convis (legitimately) feel the need, once again, to let us know the things which reliably fail when trying to build a sustaining culture of continuous improvement.
“So let’s train some Lean Six Sigma experts to grab the tools and start hacking away at the variability and waste that stretch out lead time; this will make us more successful, both for our customers and for our business. What could be simpler?”
What indeed.
I am, once again, reminded of a saying that “People will exhaust every easy thing that doesn’t work before they try something difficult that will.”
The authors cite some of the same things that we have heard before:
Trying to determine ROI for each individual process step, or each individual improvement, doesn’t work.
Trying to motivate the right behavior with metrics and rewards doesn’t work.
Trying to copy the mechanics doesn’t work.
Trying to benchmark, and copy, a “lean company” in your business doesn’t work.
Yet, even though we have been hearing these messages for at least a decade, actually longer, I continue to encounter managers who try to work this way.
The authors assert, and I agree, that this is the result of people trying to fit Toyota’s system into a traditionally taught management paradigm that is so strong people aren’t even aware that there is a paradigm, or can’t conceive there is anything else.
This reminds me of the Edwin Abbot’s 1884 story of Flatland, a two-dimensional world populated by creatures who cannot conceive of “above” and “below” their planer existence.
Although his story is often read by students struggling to grasp models with four, five and more dimensions to them, it is really a story of social change and paradigms.
Our management systems are a “flatland” with Toyota’s system existing in a space that we have to work hard to grasp. We can see pieces of it where it touches ours, but like the creatures in Flatland who only see two dimensions of three dimensional objects, we only see the pieces of TPS that we can recognize.
One of the graphics in Bill Costantino’s presentation really struck me, but my thought was out of context so I wanted to make a separate post about it.
It was the concept of the “current knowledge threshold” illustrated here:
As I interpret it, the red line depicts the “we know how to do this” area. It is the domain where the team is comfortable working, they have a good grasp of cause and effect.
For problems which are outside the red line, the organization needs to engage in deliberate activity to gain understanding, to push the boundary of knowledge until the problem is enclosed by it. I tried to illustrate that process at the end of the original post.
Sadly, this doesn’t happen often enough.
Instead what happens is the organization develops a comfort zone inside the red line. Things that are outside the red line come labeled with “That doesn’t work here” and “We have reached the limit of what we can improve.”
Organizations, even sub-organizations within the same company that out-perform the baseline knowledge – who have cracked problems outside the red line – get dismissed as “no different” or “nothing special” or are attributed with special, unrepeatable, circumstances to account for their different performance. (I have seen this up close.)
If you are serious about kaizen, it is important to be operating right at the edge of the red line.
“What have we done today that, yesterday, we didn’t know how to do?”
“What will we try tomorrow that, today, we don’t know how to do?”
Those are questions that push learning.
By the way – if you are spending all of your time inside the red line, and solving the same problems again and again, your performance is likely flat lined. This is the “improvement plateau.” That is another topic for later.
I am starting to read a review copy (courtesy of McGraw-Hill) of Jeff Liker and Gary Convis’ new book, The Toyota Way to Lean Leadership. (The hot link goes to my Amazon page.)
In the spirit of one-piece-flow, I am to share key thoughts as I go rather than save everything for a thousand word review at the end.
One of the first points that comes out – in the prologue no less – is the acknowledgement that people development is a constraint to growth that you ignore at your peril.
One of the results of Toyota’s breakneck pace of growth in the first half of the last decade was that they were still making North American decisions in Japan.
They were doing this because, in the authors’ words, “…Toyota did not develop enough leaders, or did not develop leaders that it trusted sufficiently, in the North American operation to allow decisions making and problem solving to be as close to the gemba as they should have been.”
But rather than say “we grew too fast,” the President, Akio Toyoda sees the limits and the relationship:
“The problem was that the pace of growth was faster than the pace of human resource development… It is not the growth pace itself, but it is the relationship between the pace of grown and the pace of [people development].”
When traditionally trained managers think about constraints to growth, they typically think about things they can buy. “People” as a constraint comes in only as a hiring problem.
But it takes time to develop “people” into a team that thinks and moves in unison. Today’s leaders, up to this point Toyota included, underestimate both the time and the effort it takes to do that.
Any good sports team knows what it takes to build a team. So does the military. We understand the science, the psychology. But perhaps because it is difficult and sometimes messy to deal with people (and it is certainly impossible to reduce the effect of good teamwork to a stoplight report and a spreadsheet), “people development” gets delegated to HR, or people are sent to classroom training and given “certifications.” Doesn’t work, never has.
Akio Toyoda was acknowledging an uncomfortable truth – that they had fallen behind on people development and they had continued anyway, without pulling the metaphorical andon and addressing the issue as soon as it came up.
This simple insight hits at the very core of what we, as a community, need to address, and what the flag-bearing institutions in our community still need to fully embrace.
“Continuous Improvement” means “continuously improving people.”
While just about every “lean overview” I have ever seen uses some form of lip service to the concept of “people based system” everything then goes straight into describing the technical characteristics of everything but how people are developed.
What I like is that in the last couple of years the mainstream books are starting to address this topic in a meaningful way. This, of course, isn’t the first of Jeff Liker’s books to hit here. And Toyota Kata is really the first to address the mechanics of people development as thoroughly as we have addressed the mechanics of kanban.
I am liking what I am reading in this book so far, and I’ll be working to correlate what I read with other works out there plus my own experiences. This should also tie in nicely with points I want to continue to make on Bill Constintino’s presentation.
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.
“Experience by itself teaches nothing… Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.”
–W. Edwards Deming, The New Economics for Industry, Government, Education – 2nd Edition
The field of psychology, it seems, shares an issue with the field of operations management.
This is fairly heavy reading since it is likely from outside your field, but the core message is here (paragraph breaks added for readability):
Theory in Science As I try to teach my students, the role of theory in science is to provide structure to your data. A good theory rules explanations in and out, and if it rules out the wrong explanation that will become clear over time as you pursue your theory guided research.
Good science means a) restricting your explanatory mechanisms to include things your theory allows, and b) keeping an eye on how well that’s working out for you, while c) allowing yourself to rest on your well supported theory to resist breaking the rules as long as you can.
As Deming points out in the quote at the top of this post, having a theory – a solid statement of what you believe is true is a prerequisite for learning to take place. Without that theory, events and information simply get filed away as “interesting.”
With a theory, each is compared against the prevailing thought and forces us to reflect on our understanding.
Sure, we run into confirmation bias (where we unconsciously exclude things that contradict our beliefs) and other logical flaws, but honestly – if scientific thinking were easy, we wouldn’t have to discuss it.
This is pertinent to us at a couple of levels.
At the macro-level we have the proliferation of “solutions” out there for management. We all talk about “flavors of the month” and “alphabet soup” as we see companies cycle through the various structures for “world class performance.”
Wilson and Golonka’s message, and our problem, is that in attempting to embrace everything, we embrace nothing.
Of course part of the problem is that book authors and management consultants are not, by and large, researchers who are interested in unifying the theory. Quite the contrary. They are interested in differentiation. This causes problems for people who see these various “solutions” as competing somehow. (In reality, they are mostly re-packaging of subsets of the same overall stuff.)
OK, we can’t do much about that in the larger sense, but within your company, you can.
I have yet to encounter a situation that is outside of my baseline theory of “what TPS is.”
As I said in a talk I gave last week, the only faith-based position I am asking you to embrace is that if your results seem incompatible with TPS, look at your understanding and deployment before rejecting it as unworkable.
While we wait for the MBA programs and influential institutions in our field to catch up, we can continue to identify in forums like this one which authors and researchers we think are largely congruent with one another and some kind of common baseline.
The other area where this message is applicable is in our daily approach to process design and problem solving.
Almost all of the “tools of lean” (and many techniques not especially associated with TPS) are really designed to develop and test a working theory of how the process should be working.
Takt time is a great example, though far from the only one.
I set up a process to operate at a certain speed. I say, in effect, “if the process has no unexpected problems, this is how long it should take.”
That is a theory.
I test the theory each and every time I run the process.
When (not if) something unexpected happens – when the team member can’t meet the standard work for some reason, then we have data that is not congruent with our baseline theory.
Now we can get into understanding why – what happened that we didn’t count on. Likely (in this example) something uncontrolled tripped him up. In experimental terms, we didn’t have the baseline conditions.
In our process terms, we now have a problem to solve – how do we keep that issue from coming up again, so that our team member can do the work in the time expected?
As we cycle through this thinking again and again, each iteration either cleans up some issue in the operation (which is continuous improvement), or we realize that we should have included this factor in the original plan (we modify the working theory).
Either way, our knowledge of the process is improved.
In reality, these two cases – micro and macro – point to the same thing. We need the macro (the theory of management) to reflect that we need to incorporate this thinking into the way we manage everything.
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.
A common topic of discussion in many companies is how to document and share what has been learned as they improve their processes.
The most common approach is some kind of database (either online or on paper) that documents the various “best practices” solutions to various problems.
They might, for example, show the before and after of the development of a work cell, how their visual controls are set up, or a particularly clever tool or gadget they developed.
Perhaps not so surprisingly, these bits of information turn out to be far less useful than people think they should be.
Why is that?
Let’s back up a bit and look at a larger scale.
Toyota, and other companies that are doing these things well, have all been pretty open about letting people come on and see what they are doing.
Other companies seeking to benchmark these companies then want to find one that faces similar types of problems, say “low-mix / high-volume production” or similar process flows.
Our community has developed a sense of what a “lean system” looks like. We express it in terms of the solutions to problems that have been developed.
Work cells.
Kanban.
Clever tools or gadgets.
But we also (hopefully) know that seeing examples of these things with the intent of copying them doesn’t really help that much.
Oh, they can be copied… but the track record for sustaining is pretty poor.
Nope, we know (again, hopefully) that it is not about the solutions, but about the process of solving the problem. In other words, it is the method used to develop the solutions that is important to grasp. Seeing the solutions after the fact actually gives very little insight into how to develop the skills required to do it yourself, or sustain it yourself.
OK, back to the original topic.
IF we know that copying another company’s solutions doesn’t work very well, and that we need to instead get a grasp of the thinking process that resulted in those solutions, then what should we be sharing internally, and how should we be sharing it?
The classic way to share is with a single page that says “Before Kaizen” on one side, and “After Kaizen” on the other. There might be a space for “problem” but when it is filled in, the words are usually pretty superficial. 85% of the space is devoted to a couple of pictures.
Even if it does state the problem clearly, it still doesn’t get into the process used to solve the problem.
Nor does it get into what was learned about the process of solving problems.
Now… before you leap in and say “Sure, that is what an A3 is for!” I will agree with you. Except that unless an A3 is written with that specific purpose in mind, most of the ones I have seen tend to do little better than the Before-and-After pages. Or they are so full of charts and graphs that they are really impossible to follow.
In other words, they are too complicated to convey the message, because the intended message wasn’t clear when they were developed..
It really comes down to intent.
If you are trying to share, be crystal clear on what you are sharing. What are you trying to communicate?
I believe it would be far more valuable to depict where your problem-solving process was faulty, what mistakes you made, where you went back and corrected yourself, and what you want to pass along about problem solving.
That would be a far more useful for the next person to come along.
Note – this post was written pretty much simultaneously with a post on the lean.org forum.
Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”
Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.
The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.
Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.
There are some interesting assumptions embedded in the “wedge thinking.”
The first one is that “the standard can be ‘held’ by the people doing the work.
That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”
With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.
Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)
This is the approach of control. The standard is fixed until we decide to change it.
Taiichi Ohno didn’t teach it this way.
Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.
Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.
We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.
The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.
Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.
The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.
I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.
It is time to actively refute the model.
If you own your corporate training materials, find that slide (it is in there somewhere) and change it.
If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”
One of the problems facing all of us – from pundits to practitioners alike – is “too much information.” We look at a complex state, like the way Toyota operates, try do describe it in great detail, break it down, build models, and say “OK, make it look like that.”
So one of the most common questions is “Where do I start?”
The platitude is “start with 5S” but in reality, that doesn’t really work very well either. It doesn’t really drive a cultural and behavioral shift. If you have to audit people into compliance, that’s how it is working for you.
What we know today is that TPS is much less about how it looks than it is about what people do.
I have seen a handful of other companies who have managed to get a true continuous improvement culture running (at least for a while). There is something very different about them vs. a standard “lean implementation.”
Yet these companies have the same caliber of people, the same resources, the same baseline problems as everyone else. They operate in the same environment, and yet operate differently.
A key point in Switch is “find the bright spots.” That is – look at who has success in the same environment, and grasp what few factors are actually making a difference.
Perhaps, rather than “looking for waste” we ought to be looking at what few things make a big difference. Just a thought.
One of the paradoxes of TPS is the inherent distaste for ambiguity. A TPS practitioner doesn’t like to leave things to hope and chance that someone will work it out.
What makes this a paradox is that we simply can not see accurately more than a few steps ahead. The world just has too many variables that we can’t control.
And even if there IS the possibility of developing a 100% certain plan – a set of instructions that simply require execution, actually doing so is overwhelmingly complex.
Consider this trivial example.
Here is game #9121 in Microsoft Freecell:
If a Freecell game is winnable (and there are a very few that are not), then by looking at the starting point it is theoretically possible to construct a list of moves which will result in a win.
Game 9121 is winnable. I guarantee it.
OK – given that you know are certain there IS a winning combination of moves, please look at this starting point and develop a plan – a list of the moves which will result in a win. Let me know when you are done, then we will try to execute and see if you are right or not.
Done?
Great. How did that feel?
Keep in mind that you have two real advantages here –
You knew that winning the game is possible – there is a solution to the problem. In the real world, that isn’t always the case.
This is a simple game. It is trivial compared to even the simplest real-world cultural and technical change problem.
Yet, in spite of those advantages, you probably didn’t see a really clear path from the starting point to the final state.
Now, take a look at this state of the same game:
If you know anything about the game, you know that, with two more moves, the rest of the cards will be free to auto-clear to the top. (the five of clubs / four of diamonds to a free space – which will auto-clear the two of clubs; then the queen to either a free space or to the black king)
This state requires no challenge at all. What to do next is obvious, it is simply a matter of doing it.
In the middle of the game, though, it looked like this:
To the experienced eye (which I have, sadly), this game is clearly winnable from this point. We aren’t down a dead-end condition that has no path out.
The next couple of moves are pretty clear, and I am 100% confident those moves will, in turn, reveal more, and the game will be won. (Truthfully, it reached that point much earlier, but wasn’t as obvious as it is here.)
Scripting the moves from this point is still more difficult than just playing them, though.
So what’s the point here?
As you construct improvement objectives and plans –
It is impossible to script every single move from the beginning. What you can do is be clear where you are trying to go, understand the rules, and be willing to try a few things and back out if you end up at a dead end.
It is important to have an overall strategy in mind. That gives you intermediate targets and goals that, if reached, should be progressing you toward the final objective. In this game, for example, I am generally trying to free up the aces, and build stacks on kings. Anything that advances me toward those intermediate goals is also advancing me toward winning.
Once the solution is obvious just execute it. Don’t call it “problem solving” or patronize people by making them build an A3 for something that requires no thought.
Seeing clear progress is important. So is a general sense that the game is winnable. Without that, people lose hope, which they demonstrate by losing interest.
