Navigating the Learning Hairball

Credit: A lot of stuff comes across my screen, sometimes more than once. I have seen this illustration several times, but don’t remember where it originally came from. If you created it, PLEASE comment so I can give appropriate credit.

Improvement is messy. Science is messy. Research and Development is messy. These are all cases where we want an outcome, are pretty sure what that outcome looks like, but there isn’t really a clear path to get there.

This illustration has illustrates two very different mindsets.

On the left is how many people believe the improvement / organizational development / learning process works. We set out a phased project plan to transform the organization. We carry out a set of pre-defined steps, and when they are completed, we are at the goal.

Sadly our education process is largely constructed on this model. Take the classes, pass the tests, the student is educated.

This thinking is appropriate when the outcome is something we have done before, like constructing a house. Even if this house is a bit different, the builders have rich experience in carrying out all of the constituent process steps. Further upstream, the designer carefully followed building and construction codes. In those cases, we are applying a rich body of experience (or the documented experiences of others) to reach the end goal.

These tasks can be scheduled and sequenced in a project plan. The steps are known, the result is known.

 

image

On the right is the hairball of learning and discovery.

We know where we are starting.

We know where we want to end up.

We are reasonably certain we can get from Point A to Point B. But we don’t know precisely which detailed steps or experiments will give us the results we need.

We don’t know for sure that the next result will be a forgone conclusion from the next action step.

Each step gives us more information about the next step.

In the world of continuous improvement, we live in an interesting paradox.

We often believe we are operating in the set-piece model on the left. We see a situation, we apply tools to duplicate a solution we have seen work in a similar situation before.

An interesting thing happens at this point. The Real World intervenes, and we discover that the situation was actually more like the right side. We thought we knew the right answers. We might have even been mostly right. But at the detail level, things don’t work quite as we predicted.

Now… if the system has been deliberately set up to flag those anomalies, and we are recording them and being curious to discover what we didn’t understand then we are in learning mode.

But all too often the experts who guided the original installation have moved on, leaving the people executing the process behind. The assumption was “It works, we can go to the next problem.”

The people in the process did what they were told, or guided, to do. We might have even asked for their input on the details. But that process rarely leaves them with additional skills they need to deal with anomalies in ways that make the process more robust.

So they do what they must to get things done. Mostly that means adding some inventory here, some additional checks or process steps there. Over time, the process erodes back to something close to its original state.

Why? Because we thought we knew everything… but were wrong. And didn’t notice.

This model applies to any effort to shift how an organization performs and interacts. We outrun our headlights and take on the Big Change because that company “over there” does it, and we just copy the end result.

What we missed was doing the work.

More about this later.

Standards: Notes On A Whiteboard

image

I saw this on a client’s whiteboard this morning. (Actually I saw it a while ago, but just took the photo.)

By having a clear expectation about what is supposed to happen, they can work to converge the process toward some kind of consistency. The opposite is just accepting whatever happens as OK.

By having a degree of stability, it is easier to see issues and opportunities, that in turn, allow them to set the next level of standard.

He put it up there to remind him when he is distracted in the day-to-day fray that “What are we trying to achieve?” is the important first question to ask.

Remember, there is no dogma. Your choice of words and definitions may vary. But these work for him.

…And we’re back

Some of you likely noticed the site was down for about 12 hours over Jan 2/3.

I had been the target of a “brute force” attack to attempt to login to the site administration, presumably to install malicious scripts, etc.

The attack was not successful, however it did consume all of the CPU cycles of my host’s server, so they shut off access to the site.

I have installed countermeasures, none of which are visible to readers.

It’s the wild west out there.

The Problem with “Best Practices”

This post was inspired by today’s Dilbert cartoon:

“Best practices” usually means copying the mechanics of what successful companies do, and trying to shoehorn them into your processes and culture.

For example, lots of companies “benchmarked” Toyota for decades, and never really gained understanding of the underlying culture and thinking.

Other companies, even today, struggle to try to find working examples of improvements applied to their exact industry and circumstances.

This is an especially deadly combination when they have a culture where experts (or their bosses) provide the solutions, and they simply have to carry them out. Where creative thinking has been effectively stamped out (at least around how the business is run), it is hard to get people to quickly embrace what “empowerment” really means.

Dogbert is selling a quick fix that doesn’t require the client to engage in struggle, hard work, or learning to think for himself. (In the case of THIS client, that is probably appropriate. Winking smile )

I’m going to resist the temptation to add a lot more to this one right now.

Happy New Year.

Learning To See in 2013

With the publication of Learning to See in 1999, Mike Rother and John Shook introduced a new genre of book to us – a mix of theory, example, and practical application. The story invites the readers to follow along and actually do for themselves.

This is one of those books that gives a bit more every time I read it. The more thorough my baseline understanding of TPS, the more I get from some of the nuances of Rother and Shook’s intent.

At the same time, I am beginning to formulate an idea that perhaps this book is often used out of its intended context – maybe a context that was assumed, but left unsaid.

I’d like to share some of the things I have learned over the years, especially as I have worked to integrate the concepts in Learning to See into other facets of the TPS – especially research by Steven Spear, Jeff Liker, and of course, Mike Rother’s follow-on work Toyota Kata with my own experience.

Value Streams

Learning to See introduced the term “value stream” to our everyday vernacular.

Although the term is mentioned in Lean Thinking by Womack and Jones, the concept of “map your value streams” was not rigorously explained until LTS was published.

To be clear, we had been mapping out process flows for a long time before Learning to See. But the book provided our community with a standard symbolic language and framework that enabled all of us to communicate and share our maps with others.

That, alone, made the book a breakthrough work because it enabled a shorthand for peer review and support within the community.

It also provided a simple and robust pattern to follow that breaks down and analyzes a large scale process. This enabled a much larger population to grasp these concepts and put them to practical use.

Learning to See and “Getting Lean”

In Chapter 11 of Lean Thinking, Womack and Jones set out a sequence of steps they postulate will transform a traditional business to a “lean one.”

The steps are summarized and paraphrased in the Forward (also by Womack and Jones) of Learning to See:

  1. Find a change agent (how about you?).
  2. Find a sensei (a teacher whose learning curve you can borrow)
  3. Seize (or create) a crisis to motivate action across your firm.
  4. Map the entire value stream for all of your product families.
  5. Pick something important and get started removing waste quickly, to surprise yourself with how much you can accomplish in a very short period.

Learning to See focuses on Step 4, which implies establishing a future-state to guide you.

In the Forward, Womack and Jones commented that people skipped Step 4 (map your value streams). Today, I see people skipping straight to that step.

Let’s continue the context discussion from the Forward, then dig into common use of the value stream mapping tool..

“Find a change agent (how about you?)” is a really interesting statement. “How about you?” implies that the reader is the change agent. I suspect (based on the “change agents” discussed in Lean Thinking that the assumption was that the “change agent” is a responsible line leader. Pat Lancaster, Art Byrne, George Koenigsaecker were some of the early change agents, and were (along with their common thread of Shingijutsu) very influential in the tone and direction set in Lean Thinking.

Today, though, I see job postings like this one (real, but edited for – believe it or not- brevity):

Job Title: Lean Manager

Reports To: Vice President & General Manager of Operations

Summary:

Lead highly collaborative action-based team efforts to clean out, simplify and mistake-proof our processes and our strategic suppliers’ processes.

This includes using proven methodological approaches, applying our culture and providing our team with technology, best cross-industry practices and all other resources needed to attain ever higher levels of productivity and customer delight.

Essential Duties and Responsibilities:

Endlessly define, prioritize and present opportunities for applying AWO’s, GB/BB projects and other LEAN principles to our supply chain and customer deliverables.

Develop, plan and execute the plans as selected by the business leaders.

Train all team members (and other selected individuals) in LEAN principles and mechanisms to be LEAN and preferred by customers.

Document procedures/routines, training, team results/best practices and the like.

Coaches business team members in the practical application of the Lean tools to drive significant business impact.

Leads and manages the current state value stream process.

Develops and implements future state value stream processes.

[…]

Responsible for planning and assisting in the execution of various Lean transformation events targeted towards improving the business’s performance on safety, quality, delivery, and cost.

Focuses on business performance that constantly strives to eliminate waste, improve customer satisfaction, on-time delivery, reduce operating costs and inventory via the use of Lean tools and continuous improvement methodologies.

[…]

Acts as change agent in challenging existing approaches and performance.

Whew. With all of that, here is my question: What is the line leadership expected to do? In other words, what is left for them to do? And what, exactly, are they supposed to be doing (and how) during all of this flurry of activity?

While all of the “change agent” examples outlined in Lean Thinking (which, in turn, provides context for Learning to See), are line leaders, all too often the role of “change agent” is delegated to a staff member such as the above.

I believe it is entirely possible for a line-leader change agent to also be the “sensei” – Michael Balle’s The Lean Manager shows a fictional scenario that does just that.

But if your “sensei” is a staff technical professional, or an external consultant, the “change agent” function is separate and distinct, or should be.

Which leads me to the first question that is never asked:

Why Are You Doing This At All?

That question can be a pretty confrontational. But it is a question that often goes unasked. 

This is especially true where “getting lean” is an initiative delegated to staff specialists, and not directly connected to achieving the strategic objectives of the business. In these cases, “Lean” is expressed as a “set of tools” for reducing costs.

I do not believe that “creating a crisis” is constructive, simply because when motivated by fear people tend to (1) panic and lose perspective and (2) tend to apply habitual responses, not creative ones. If there are high stakes at risk, creativity is not what you should expect.

On the other hand, a narrow and specific challenge that is set as Step Zero helps focus people’s attention and gives them permission not to address every problem all at once (which avoids paralysis and gridlock).

So, if I were to edit that list of steps, I’d change “Create a crisis” to “Issue a challenge to focus the effort” and move it to #1 or maybe #2 on the list. The “Find a sensei” then becomes a countermeasure for the obstacle of “We need AND WANT to do this, but don’t have enough experience.” (That assumption, in turn, implies a driving need to learn doesn’t it?)

These are appropriate roles for the “change agent” – and they are things that can only be effectively done from a position of authority.

Which brings us to back to Learning to See.

Beyond “Value-Added”

Someone, a long time ago, proposed that we categorize activities as “value-added” or “non-value-added.”

We say that a “value-added step” is “something the customer is willing to pay for.” A “non-value-added step” is anything else. Some non-value-added steps are necessary to advance the work or support the business structure.

While this analysis is fundamentally correct at the operational level, and works to get a general sense of what it possible, this approach can start us off on a journey to “identify and eliminate waste” from the process. (Not to mention non-productive debates about whether a particular activity is “value added” or not.)

Right away we are limited. The only way to grow the business using this approach is to use the newly freed up capacity to do something you aren’t doing now. But what?

If that decision hasn’t been made as a core part of the challenge, the leaders are often left wondering when the “lean initiative” will actually begin to pay – because they didn’t answer the “Why must we do this?” question from the beginning.

Without that challenging business imperative, the way people typically try to justify the effort is to:

  • Analyze the process.
  • Try to quantify the waste that is seen. This would be things like inventory, walking distance, scrap, etc. that are easily measurable. More sophisticated models would try to assign value to things like floor space.
  • Add up the “proposed savings”
  • Determine a return on the investment, and proceed if it is worth it.

The idea, then, would be to deliver those savings quickly with some kind of rapid improvement process.

This fundamental approach can be (and is) taken at all levels of the organization. I have seen large-scale efforts run by a team of consultants doing a rapid implementation of an entire factory over a timespan of a few weeks.

I have also seen that same factory six months later, and aside from the lines that were painted on the floor and the general layout changes, there was no other sign the effort had ever been undertaken. In this case, no matter how compelling the ROI, they didn’t get anywhere near it.

One of the tools commonly (ab)used for this process is value stream mapping.

This approach is SO common that if you search for presentations and training materials for value stream mapping on the web, you will find that nearly all of them show describe this process:

  • Map your current state map.
  • Identify sources of waste and other opportunities on the current state map.
  • Depict those opportunities with “kaizen bursts” to show the effort you are going to make.
  • Based on what opportunities you have identified, and your proposed kaizen bursts, develop the future state map to show what it will look like.
  • Develop the new performance metrics for the future state.
  • Viola – make the case to go for it.

Now – to my readers – think for a minute. Where are the “kaizen bursts” in Learning to See? They are on the current state map, right?

Nope.

Here is the current state map on page 32:

image

 

If, on the other hand, I were to ask “What value do we wish we could create for our customers that, today, we cannot?” I open myself up to a host of possibilities, including creating a new value stream that currently doesn’t exist at all – using freed up resources, at essentially zero net cost (or at least heavily subsidizing the new effort).

Now I ask “What must I do to make these resources available to me?”

In the “find and eliminate waste” model, the staff-change agents are often responsible for the “lean plan.” Like the job description above, they are charged with convincing the leaders (who hired them!) that this all makes business sense.

A Manual for How to Meet a Challenge

In “Part III: What Makes a Value Stream Lean” (the green tab) there is a strong hint of the original intent in the second paragraph:

To reduce that overly long lead time from raw material to finished goods, you need to do more than just try to eliminate obvious waste.

This statement implies that the value stream mapper is dissatisfied with the current lead time, and has a compelling need to change it.

What you are looking for in the Future State is how must the process operate to get to the lead time reduction you must achieve.

For example, given a target lead time and a takt time, I can calculate the maximum amount of work-in-process inventory I can have and still be able to hit that objective.

I can look at where I must put my pacemaker process to meet the customer’s expectations for delivery.

Based on that, I can look at the turns I must create in the pull system that feeds it.

Based on that, I can calculate the maximum lot sizes I can have; which in turn, drives my targets for changeovers.

As I iterate through future state designs, I am evaluating the performance I am achieving vs. the performance I must achieve.

What is stopping me from making it work?

What must I change?

If something is too hard to change, what can I adjust elsewhere to get the same effect?

In the end, I have a value stream architecture that, if I can solve a set of specific problems, will meet the business need I started with.

This is my view on the fundamental difference between creating a generic “crisis” vs. stating a compelling performance requirement.

The process outlined in the book is to develop the future state, and then identify what is stopping you from getting there.

Of the eight KEY QUESTIONS FOR THE FUTURE STATE that are outlined in page 58, What process improvements will be necessary for the value stream to flow as your future state design specifies?” is question #8.

It is the last thing you consider.

The kaizen bursts are not “What can we do?”

They are “What must we do?”

The first thing you consider is “What is the requirement?”

“What is the takt time?”

In other words, how must this process perform?

Here is a clip of the future state map from page 78:

image

The “bursts” are not “opportunities” but rather, they represent the things we have to fix in order to achieve the future state.

In Toyota Kata terms, they represent the obstacles in the way of achieving the target condition, just at a higher level.

What this is saying is “To achieve the future state we need to rearrange the work flow AND:

  • Get the stamping changeovers down to 10 minutes or better.
  • Get the weld changeovers to where we can do them within the takt.
  • Get the welder uptime to 100%.
  • Get the work content for weld + assembly down to under 168 seconds.”

These are the obstacles to achieving the performance we want from the future state value steam.

Notice that the stamping press only has an uptime of 85% on the current state map. There isn’t a corresponding kaizen burst for that – because, right now, it isn’t in the way of getting where we need to go. It might be an issue in the future, but it isn’t right now.

But if we were just “looking for waste” we might not see it that way, and spend a ton of time and resources fixing a problem that is actually not a problem at the moment.

Putting This Together

Thus, I suspect that Learning to See, like many books in the continuous improvement category, was intended for value stream leaders – managers who are responsible for delivering business results.

In my experience, however, most of the actual users have been staff practitioners. Perhaps I should use the 2nd person here, because I suspect the vast majority of the people reading this are members of that group.

You are a staff practitioner if you are responsible for “driving improvement” (or a similar term) in processes you are not actually responsible for executing on a daily basis. You are “internal consultants” to line management.

Staff practitioners are members of kaizen promotion offices. They are “workshop leaders.” They are “continuous improvement managers.” The more senior ones operate at the VP and Director level of medium and large size companies.

No matter what level of the organization, you are kindred spirits, for most of my post-military / pre-consulting career has been in this role.

The people who actually read and study books like Learning to See are staff practitioners.

This creates a bit of a problem, because Learning to See is very clear that the responsible manager should be the one actually building the value stream map. But often, that task is delegated to the staff practitioner.

“Map this value stream, and please present your findings and recommendations.” If you have gotten a request or direction like that, you know what I am talking about. Been there, done that.

In my personal experience, although it gave me valuable experience studying process flows, I can honestly say that relatively few of those proposed “Future States” were actually put into practice.

The one that I vividly remember that was put into practice happened because, though I was a kaizen promotion office staffer, I had start-up direct responsibility for getting the process working, including de-facto direct reports. (That is a different story titled “How I got really good at operating a fork lift”)

Into 2013

Today we see Toyota Kata quickly gaining popularity. The Lean Bazaar is responding, and “coaching” topics are quickly being added to conference topics and consulting portfolios.

I welcome this because it is calling attention to the critical people development aspect that distinguishes the Toyota Management System from the vast majority of interpretations of “lean” out there.

But make no mistake, it is easy to fall into the tools trap, and the Lean Bazaar is making it easier by the way it positions its products.

Just as value stream mapping isn’t about the maps, establishing an improvement culture isn’t about the improvement boards, or the Kata Kwestions.

It is about establishing a pervasive drive to learn. In that “lean culture,” we use the actual process as a laboratory to develop people’s improvement skills. We know that if we do the right job teaching and practicing those skills, the right people will do the right things for the process to get better every day. Which is exactly what the title of Learning to See says.

Creating an Empowered Team

EDIT: There is a follow-on post here: David Marquet: Turn the Ship Around

In the past couple of decades, we went through an “empower your people” fad. We saw work teams in world class companies that were largely self directing, surprisingly well aligned with the overall goals of the organization, and getting things done.

“Well,” we thought, “since empowered teams are obviously more effective, we’ll empower our teams.”

harry potter wandThey brandished their wand uttered some wizard’s chant, and bing! empowered their teams.

“What did you expect to happen?”

“We expected our newly empowered teams to self-organize, get the work done, plan all of their own vacations and breaks, and continuously improve their operations on their own.”

“What actually happened?”

“Work ground to a halt, people argued and squabbled, quality went to hell, and labor hours went up 20%”

“What did you learn?”

“That empowerment doesn’t work.”

Which is obviously not true, because there are plenty of examples where it does. Perhaps “Empowerment doesn’t work the way we went about it” might be a better answer. That at least opens the door to a bit more curiosity.

The last place I would expect an experiment in true empowerment would be onboard a U.S. Navy nuclear submarine.

Take a look at this video that Mike Rother sent around a couple of days ago, then come back.

A U.S. Navy submarine skipper isn’t generally inclined to swear off ever giving another order. It runs against everything he has been taught and trained to do since he was a Midshipman.

I’d like to cue in on a couple of things here and dissect what happened.

First is the general conditions. I think he could do this just a bit faster than normal because everyone involved was sealed inside a steel can for six months. Just a thought – groups in those conditions tend to have a lot of team cohesion.

But the mechanics are also critical. He didn’t just say “You are empowered.” Rather, this was a process of deliberate learning and practice.

What is key, and what most companies miss, are the crucial elements that Capt. Marquet points out must be built as the pillars of an empowered team.

GiveControl

Let’s put this in Lean Thinker’s terms.

As the Toyota Kata wave begins to sweep over everyone, there is a rush to transition managers into coaches.

“What obstacles do you think are now in the way of reaching the target?”

See the illustration above.

Competence and clarity.

I am going to start with the second one.

Clarity

Or… where the hell are we trying to go?

Capt. Marquet points out the critical element of commander’s intent. I learned this during my decade or so as a military officer (U.S. Army). When preparing operations orders, I had to clarify the overall commander’s intent. Why? So that when everything went to hell in a handcart, everyone knew what we were trying to get done even if the how to do it entirely broke down.

What that means in the lean thinking world is “What is the business imperative” or “What is the challenge we are trying to achieve?” If nobody knows “why,” then all they can know is “what” and that comes down to “implement the tools,” which, in turn, comes down to “because I said so” or “Because we need a 3 on the lean audit.”

Doesn’t work. Never has.

But I’m beating that topic to death right now, so I want to move the pillar on the left.

Competence

In my book, that means “The leader has a good idea how to do it.”

What does that mean in practical terms? In Capt. Marquet’s world, it means that, fundamentally, the crew knows how to operate a nuclear submarine. Additionally, it means they understand the ramifications of the actions they are taking on the overall system, and therefore, the contribution they are making to achieving the intent.

It doesn’t matter how clearly anyone understands what they are trying to get done if they have no idea how to do it.

In Lean Thinking world, competence means a few things.

  • The leader knows how to “do the math.” She understands the overall flow, the impact of her decisions on the system and the overall system.
  • The leader / coach has a good understanding of at least the fundamentals of flow production, and why we are striving to move in that direction.

While these things can be taught through skillful coaching, that implies that the coach has enough competence to do that teaching.

But if the coach doesn’t fundamentally grasp the True North, or doesn’t consistently bias every single conversation and decision in that direction, then Clarity is lost, and Competence is never built.

We end up with pokes and tweaks on the current condition, but no real breakthrough progress.

Day to day, this means you are on the shop floor interacting with supervisors and front line managers. You are asking the questions, and guiding their thinking until they grok that one-by-one flow @ takt is where they are striving to go.

In my Lean Director role in a previous company, I recall three distinct stages I went through with people calling me for “what to do” advice.

First, I gave them answers and explanations.

Then I transitioned to first asking them what they thought I would give as an answer.

Then they transitioned to “This is the situation, this is the target, this is what we propose, this is why we think it will work, what do you think?”

“Captain, I propose we submerge the boat.”

“What do you think I am thinking?”

“Um… you would want to know if it is safe?”

“How would you know it is safe?”

In other words…

What are you trying to achieve here? How will you know?

So here is a challenge.

If you are a line leader, especially a plant manager, take one week and utterly refuse to issue direction to anyone. Ask questions. Force them to learn the answers. Test their knowledge. Have them teach you so they must learn.

You will learn a lot about the competence of your team. You will learn a lot about your own clarity of intent. Try it on. No matter what, you will learn a lot.

Curiosity

The tenor of what “lean” is about is shifting, at least in some places, toward the line leader as improver, teacher and coach. Successfully adopting that role requires a qualification that I wish I saw more of as I work with industrial clients – curiosity.

To succeed in this role, a supervisor must be intently curious about, not only the minute-by-minute performance, but what things are affecting it, or could affect it.

Even if he is just walking by, his eyes must be checking – is there excess inventory piling up? Are all of the standard WIP spots filled? Is anyone struggling with the job? Are the carts in the right places? Pressures and temperatures OK? Kanbans circulating correctly? Workers all wearing PPE? Safety glasses? Ear plugs? Does the fork truck driver have his seatbelt fastened?

Though there should also be deliberate checks as part of his standard work, a leader needs to be intently curious about what is happening all of the time.

To improve things requires even more curiosity. “What obstacles do you think are now keeping you from reaching the target?” is not a question that should be answered casually. Rather, the preparation to answer it properly requires careful study – being curious – about what operational conditions must be changed to reach the target.

Sadly, though, my experience is that true curiosity is a pretty rare commodity. A plant manager that can spout off a barrage of facts and figures about how things have to be, but is surprised every time the math doesn’t reflect his view of reality doesn’t impress me much.

Niwa-sensai said once (probably many times) “A visual control that doesn’t trigger action is just a decoration.”

You have to be curious about what those visual controls are telling you. What good is a gage if it is supposed to read between 4 and 6, but drops to 0 and nobody notices?

That supervisor walking through the area needs to be visually sweeping those gages, looking for leaks, anything unusual or abnormal, and taking action.

“How did that stain get here?” Run the trap line. The process, as designed, shouldn’t let anything leak. Why did it? What is really happening?

All we practitioners can do is patiently, again and again, walk the line with them, ask what they see, stand in the chalk circle with them, and do our best to teach them to see what we do.

Show them the system, show them the future consequences of letting this little thing slide – how second shift is going to be brought to their knees because the work isn’t being processed according to the FIFO rules.

I suspect, though, that at least a few leaders get promoted and somehow believe they reach a level where they are exempt from checking and teaching. That’s someone else’s job.

But if not them, who? And how do they know it is getting done?

Active Control

Imagine you are driving an automobile with a high-performance suspension. You are on a perfectly straight stretch of road, with smooth pavement. Get yourself up to, say, 65 miles per hour (100 km/h). Got it pointed down the middle of the road?

OK, close your eyes, let go of the steering wheel and wait. (Actually closing your eyes is optional.)

Can you predict what will happen, more likely sooner than later?

It doesn’t matter how “stable” your car is.

There are small, random things that are eventually going to cause your car to drift away from the centerline and off the road, into the ditch on one side, or over the cliff on the other. (Didn’t I mention those?)

I often see people set up a well performing process and treat it the same way – as though it will continue to work the same way forever, without any intervention.

But your process is going to encounter random chatter, and when it does, what typically happens?

In most cases, the team members can find a way to work around the issue, and likely continue to get things done, though they will have added a bit of friction, requiring a bit more effort, to do so. They will add a redundant check to make sure no mistake got made. They will add some inventory under the work bench, in case something runs out. They will carry the product over to the other machine because the one they are supposed to use isn’t working as it should be.

They will clean up the spilled coolant, catch the leaking oil.

They will head up-line to borrow a team member’s grease bucket.

They’ll tap out paint clogged or unthreaded holes, cut wires that are delivered too long to length, even drill new holes to mount the part that doesn’t fit.

In the office, they get one more signature, send an email to back-up the “unreliable” ERP messages, and make screen prints so they can enter the data into another system.

“Waste is often disguised as useful work.”

All of this easily goes unnoticed, and eventually (maybe) the process becomes cumbersome enough that someone decides to address it with an improvement activity. And the cycle starts again.

How do we stop the cycle?

The point of intervention is in the last paragraph… “All of this goes unnoticed.”

It isn’t a matter of standing and watching for problems. Sakichi Toyoda figured that out almost 100 years ago. It is about designing your process to detect anomalies in either execution (how it is done, how long it takes) or results immediately, signal, and trigger some kind of response.

Here are some fundamental questions to ask yourself:

Before the process even begins, does the team member have everything he needs to succeed? How does he know? I’m talking about parts, information, tools, air pressure, assistance… whatever you know is needed to get the job done.

If the team member doesn’t have everything needed exactly what do you want him to do?

Is the team member carrying out the process in a way that gets the desired result? How does she know? Is there a sequence of steps that you know will give her the result you want? What alerts her if one of them is skipped?

If the team member, for whatever reason, isn’t able to carry out those steps in sequence, exactly what do you want her to do? Go find a grease bucket? Or let you know?

How long do you want to allow your team member to try to fix something or make it work before letting you know there is a problem? Related to this – how far behind can you allow him to get before he can’t catch up, even with help?

Once the team member has completed the process, how does he know the result is what was expected? If the team member doesn’t have a way to positively verify a good outcome, who does detect the problem, when, where and how? It might be your customer!

An Active Control System

Even if you have all of those checks in place, however, you still need to answer a few more questions starting with “Once the team member detects a problem, what do you what exactly do you want them to do?”

I alluded a little to this above, but let’s go a bit deeper.andon-pull

On a production line, a typical way for a team member to signal a problem is with some kind of andon. This might, for example, take the form of a rope along the line that the team member can pull in order to trigger a signal of some kind.

But that is the easy part. Lots of factories have copied the mechanics of Toyota’s andon only to see them fall into disuse following a period of cynicism.

The hard part is what is supposed to happen next?

Now we are back to the original questions because the andon is nothing more than a trigger for another process.

Who is the designated first responder? (Remember, if it is everybody’s problem, it is nobody’s problem.) Does that person know who he is?

What is the standard for the response? What is the first responder supposed to do, and how long does she have to do it?

When we had takt times on the order of dozens of minutes, our standard for the first response making face-to-face contact with the team member who signaled was 30 seconds.

How much intervention can the first responder make before being required to escalate the problem to the next level?

As a minimum

As a minimum, the first responder’s primary goal is to restore the normal pattern of work. This might be as simple as pitching in and helping because something minor tripped up the team member’s timing.

This is active control – a system or process that detects something going outside the established parameters, and applying an adjustment to get it back. Active control requires a process to detect abnormalities, a trigger, and a response that restores things. It is no different than maintaining thickness in a rolling operation – the machine measures the output, and adjusts the pressure accordingly – or an autopilot that keeps an airplane on course.

Without some kind of active control system, your process will erode over time as the team members do the only things they can do in an effort to keep things moving: They can overproduce and build inventory to compensate, they can add extra process steps, they can add just about any of the things we call “waste.”

The only question is what do you want them to do?

Eiji Toyoda 1913-2013

Reuters reports the death of Eiji Toyoda today, 3 days after his 100th birthday.

In the late 1940’s, the fledgling Toyota Motor Company was in financial difficulties, and was forced to lay off workers. As part of the agreement, Kiichiro Toyoda resigned in 1950 and turned the helm of the company over to his cousin, Eiji.

Kiichiro had developed the early concepts of Just In Time production, and his father, Sakichi, had developed the early concepts of stopping a process that was having quality issues (jidoka).

Eiji had to deal with a turnaround situation, and challenged the company to reach U.S. levels of productivity on a very short timeframe. As part of that effort, he assigned Taiichi Ohno, a machine shop manager, to make it all work. The result was what we today call “The Toyota Way.”

Though there were obviously many people involved, Eiji has a huge share of the credit for creating “The Machine that Changed the World.”

Checklists: “Do.” vs. “Did you do?”

When operations or steps get omitted, a common countermeasure is to establish a checklist.

A typical checklist has a list of items or questions – sometimes even written in the past tense.

“Was the _______?”

There are a couple of common problems with this approach.

First, the time to actually, physically make the checks is not included in the planned cycle time. This implies we are expecting the team member to review the checklist and remember what she did.

The second issue is that the team member often does remember doing it even if it wasn’t done.

This is human nature, it isn’t a fault or flaw in the individual. It is impossible to maintain continuous  conscious vigilance for any length of time. There are techniques that help, however they require some discipline from leaders.

Overall, a checklist that asks “Did you___?” in the past tense is mostly ineffective in practice.

We make things worse when the checklist is used as a punitive tool and we “write up” the team member for signing off on something that, actually, didn’t get done. Most of the time it does get done, but everyone in this system occasionally misses something. Sometimes those errors get caught. This kind of “accountability” is arbitrary at best.

Where checklists work is in “what to do next” mode – referring to the check list, doing one item, checking off that it was done, then referring to the next item on the list. This is how it works in an airplane cockpit.*

CAPTAIN: okay, taxi check.

FIRST OFFICER: departure briefing, FMS.

CAPTAIN: reviewed runway four.

FIRST OFFICER: flaps verify. two planned, two indicated.

CAPTAIN: two planned, two indicated.

FIRST OFFICER: um. takeoff data verify… one forty, one forty five, one forty nine, TOGA.

CAPTAIN: one forty, one forty five, one forty nine, TOGA.

FIRST OFFICER: the uh weight verify, one fifty two point two.

CAPTAIN: one fifty two point two.

FIRST OFFICER: flight controls verify checked.

CAPTAIN: check.

FIRST OFFICER: stab and trim verify, thirty one point one percent…and zero.

CAPTAIN: thirty one point one percent, zero.

FIRST OFFICER: the uh…. engine anti-ice.

CAPTAIN: is off.

FIRST OFFICER: ECAM verify takeoff, no blue, status checked.

CAPTAIN: takeoff, no blue, status checked.

FIRST OFFICER ON PA: ladies and gentlemen at this time we’re number one for takeoff, flight attendants please be seated.

FIRST OFFICER: takeoff min fuel quantity verify. nineteen thousand pounds required we got twenty one point eight on board.

CAPTAIN: nineteen thousand pounds required, twenty one eight on board.

FIRST OFFICER: flight attendants notified, engine mode is normal, the taxi checklist is complete sir.

(This is also how it works when assembling a nuclear warhead, but I can’t tell you that.)

This is also very effective for troubleshooting. For example, I was working with a team in a food processing plant. The obstacle being addressed was the long (and variable) time required to change over a high-speed labeling machine and get it “dialed in” and running at full speed without stops and jams.

Some operators were much better at this than others. We worked to capture an effective process of returning the machine’s settings to a known starting point, then systematically adjusting it for the specific bottle, label, etc. It worked when they were able to slow down enough to use it. That was an instance of “Slow is smooth; smooth is fast.”

The act of reading out load, performing the action, and verbally confirming is very effective when it is actually done that way. Even so, people who are very familiar with the procedure will often take shortcuts. They don’t “need” the checklist… until they do.

Still, you have a sequence of operations, and it is critical that they are all performed, in a specific order, in a specific way.

What works?
I’d say look around.
If you are reading this, you likely have been at least dabbling, and hopefully trying to apply “lean” stuff for a while.

What is a basic shadow board? It is a “checklist” of the tools to confirm they are all there – and a lot faster because missing items can be spotted at a glance. At a more advanced level, companies move away from shadow boards and to having the visual controls outlining what should be where to perform the work.

Color coded tool holders.

If you kit parts, you can set them out in a sequence – a “checklist” that cues the team member what order they should be installed.

I could continue to cite examples, but here’s the point.

When things are being left out, there is a high temptation to say “Let’s make a checklist” and sometimes make it worse by saying “…and we’ll have the worker sign it off for accountability.” That is more often than not simply a “feel good” solution. You feel like you have done something, and I’ve even heard “Well, it’s better than nothing.” I’m not sure it IS better than nothing – at least not in very specific conditions.

Instead, you need to study the actual work. Don’t try to ask questions, just stand and watch for a while. (Explain what you are doing to the team member first, otherwise this is creepy. “Hi – I’m just trying to understand some of the things that might get in your way. Do you mind if I just watch for a while without bothering you?”)

What cues the team member which step to perform next? Does he have to know it from memory? Or is there something built into the way the workplace is organized?

Does he end up going back and doing things he forgot?
Does he set out parts and tools in order on his own so he doesn’t forget?
Does he get interrupted, by anyone or anything, that takes him out of his mental zone?
(I go through airport TSA security checkpoints at least twice a week. I have a routine. When the TSA agent tries to “help” by talking to me, my routine gets broken, and that is when I forget stuff.)

If you are coaching someone, it helps if you go there with them, help the see the details by spotting these things and “asking” about them; then taking them to another area and challenging them to see as many of these issues as they can. See who can spot more of them.

What you are seeing are obstacles that impact the team member’s ability to do quality work.

Checklists don’t help remove those obstacles.

___________________

*The checklist transcript here is a cleaned up version of the Cockpit Voice Recorder transcript from Cactus 1549, the US Airways A320 that successfully landed in the Hudson River after multiple bird strikes knocked out both engines. I used it here because it is authentic, and the accident was one where everything went right and no one was seriously injured.