Team Member Saves


Now and then one of your team members makes a great save. They catch something that could have caused a defect, an accident, or done harm in some way.

Often we celebrate these saves, sometimes informally, sometimes formally. And that is well and appropriate.

But let’s make sure we are celebrating for the right reasons.

The save isn’t what should be celebrated.

Rather, the celebration should be a big THANK YOU for finding a gap in your process.

Somehow the process is capable of producing a defect, resulting in an accident, or doing harm. Your team member noticed that.

We usually just celebrate correcting the immediate problem.

But What is preventing exactly the same thing from happening tomorrow?*


That front-line customer-facing team member is your last line of defense.

They only get an opportunity to make a “save” when every other point in the process has failed to detect the  problem.

Given enough “shots” at this front line team-member, sooner or later, one is going to get through.

What happens then? Is the inverse logic applied? “You should have caught that.”

Perhaps, but where in the process was the problem actually created?

Somewhere, long before this diving catch, there is an instant when the process went from operating safely and defect free to creating an opportunity, an opening, for a problem to pass undetected.

Where and when was that moment?

Or is that how the process normally operates, and we are just lucky most of the time?

Dig in, think about it.

And thank that team member for saving you, but don’t count on it every time.


*Thanks to Craig for this great way to sum up the question.

Averages, Percentages and Math

As a general rule I strongly discourage the use of averages and “percent improvement” (or reduction) type metrics for process improvement.

The Problem with Averages

Averages can be very useful when used as part of a rigorous statistical analysis. Most people don’t do that. They simply dump all of their data into a simple arithmetic mean, and determine a score of sorts for how well the process is doing.

The Average Trap

There is a target value. Let’s say it is 15. Units could be anything you want. In this example, if we exceed 15, we’re good. Under 15, not good.

“Our goal is 15, and our average performance is 20.”

Awesome, right?

Take a look at those two run charts below*. They both have an average of 20.

On the first one, 100% of the data points meet or exceed the goal of 15.

Run chart with average of 20, all points higher than 15.

On the one below, 11 points miss the goal


But the both have an average 5 points over the goal.

In this case, the “average” really gives you almost no information. I would have them measure hits and misses, not averages. The data here is contrived, but the example I am citing is something I have seen multiple times.

Why? Most people learned how to calculate an arithmetic mean in junior high school. It’s easy. It’s easier to put down a single number than to build a run chart and look at every data point. And once that single number is calculated, the data are often thrown away.

Be suspicious when you hear “averages” used as a performance measurement.

Using Averages Correctly

(If you understand elementary statistical testing you can skip this part… except I’ve experts who should have known better fall into the trap I am about to describe, so maybe you shouldn’t skip it after all.)

In spite of what I said above, there are occasions when using an average as a goal or as part of a target condition makes sense.

A process running over time produces a range of values that fall into a distribution of some kind.

Any sample you take is just that – a sample. Take a big enough sample, and you can become reasonably confident that the average of your sample represents (meaning is close to) the average of everything.

The move variation there is, the bigger sample you need to gain the same level of certainty (which is really expressed as the probability you are wrong).

The more certain you want to be, the bigger sample you need.

Let’s say you’ve done that. So now you have an average (usually a mean) value.

Since you are (presumably) trying to improve the performance, you are trying to shift that mean – to change the average to a higher or lower value.

BUT remember there is variation. If you take a second sample of data from an unchanged process and calculate that sample’s average, YOU WILL GET A DIFFERENT AVERAGE. It might be higher than the first sample, it might be lower, but the likelihood that it will exactly the same is very, very small.

The averages will be different even if you haven’t changed anything.

You can’t just look at the two numbers and say “It’s better.” If you try, the NEXT sample you take might look worse. Or it might not. Or it might look better, and you will congratulate yourself.

If you start turning knobs in response, you are chasing your tail and making things worse because you are introducing even more variables and increasing the variation. Deming called this “Tampering” and people do it all of the time.

Before you can say “This is better” you have to calculate, based on the amount of variation in the data, how much better the average needs to be before you can say, with some certainty, that this new sample is from a process that is different than the first one.

The more variation there is, the more difference you need to see. The more certainty you want, the more difference you need to see. This is called “statistical significance” and is why you will see reports that seem to show something is better, but seem to be dismissed as a “statistically insignificant difference” between, for example, the trial medication and the placebo.

Unless you are applying statistical tests to the samples, don’t say “the average is better, so the process is better.” The only exception would be if the difference is overwhelmingly obvious. Even then, do the math just to be sure.

I have personally seen a Six Sigma Black Belt(!!) fall into this trap – saying that a process had “improved” based on a shift in the mean of a short sample without applying any kind of statistical test.

As I said, averages have a valuable purpose – when used as part of a robust statistical analysis. But usually that analysis isn’t there, so unless it is, I always want to see the underlying numbers.

Sometimes I hear “We only have the averages.” Sorry, you can’t calculate an average without the individual data points, so maybe we should go dig them out of the spreadsheet or database. They might tell us something.

The Problem with Percentages

Once again, percentages are valuable analysis tools, so long as the underlying information isn’t lost in the process. But there are a couple of scenarios where I always ask people not to use them.

Don’t Make Me Do Math

“We predict this will give us a 23% increase in output.”

That doesn’t tell me a thing about your goal. It’s like saying “Our goal is better output.”

Here is my question:

“How will you know if you have achieved it?”

For me to answer that question for myself, I have to do math. I have to take your current performance, multiply x 1.23 to calculate what your goal is.

If that number is your goal, then just use the number. Don’t make me do math to figure out what your target is.

Same thing for “We expect 4 more units per hour.”

“How many units do you expect per hour?” “How many are you producing now?” (compared to what?)

Indicators of a W.A.G.

How often do you hear something like  “x happens 90 percent of the time”?

I am always suspicious of round numbers because they typically have no analysis behind them. When I hear “75%” or “90%” I am pretty sure it’s just speculation with no data.

These things sound very authoritative and it is easy for the uncertainty to get lost in re-statement. What was a rough estimate ends up being presented as a fact-based prediction.

At Boeing someone once defined numbers like this as “atmospheric extractions.”

If the numbers are important, get real measurements. If they aren’t important, don’t use them.

Bottom Line Advice:

Avoid averages unless they are part of a larger statistical testing process.

Don’t set goals as “percent improvement.” Do the math yourself and calculate the actual value you are shooting for. Compare your actual results against that value and define the gap.

When there is a lot of variation in the number of opportunities for success (or not) during a day, a week, think about something that conveys “x of X opportunities” in addition to a percent. When you have that much variation in your volume, fluctuations in percent of success from one day to the next likely don’t mean very much anyway.

Look at the populations – what was different about the ones that worked vs. the ones that didn’t — rather than just aggregating everything into a percentage.

Be suspicious of round numbers that sound authoritative.


*These charts are simply independent random numbers with upper and lower bounds on the range. Real data is likely to have something other than a flat distribution, but these make the point.

Prediction Doesn’t Equal Understanding

Lunar Eclipse over Everett, WA. Photo by Mark Rosenthal, © 2015Sometimes people fall into a trap of believing they understand a process if they can successfully predict it’s outcome. We see this in meetings. A problem or performance gap will be discussed, and an action item will be assigned to implement a solution.
Tonight those of us in the western USA saw the moon rise in partial eclipse.

We knew this would happen because our understanding of orbital mechanics allows us to predict these events… right?

Well, sort of. Except we have been predicting astronomical events like this for thousands of years, long before Newton, or even Copernicus.

The photo below is of a sophisticated computer that predicted lunar eclipses, solar eclipses, and other astronomical events in 1600BC (and earlier). Click through the photo for an explanation of how Stonehenge works:

Photo of Stonehenge
Creative Commons flickr user garethwiscombe

Stonehenge represented a powerful descriptive theory. That is, a sufficient level of understanding to describe the phenomena the builders were observing. But they didn’t know why those phenomena occurred.

Let’s go to our understanding of processes.

The ability to predict the level of quality fallout does not indicate understanding of why it occurs. All it tells you is that you have made enough observations that you can conclude the process is stable, and will likely keep operating that way unless something materially changes. That is all statistical process control tells you.

Likewise, the ability to predict how long something takes does not indicate understanding of why. Obviously I could continue on this theme.

A lot of management processes, though, are quite content with the ability to predict. We create workforce plans based on past experience, without ever challenging the baseline. We create financial models and develop “required” levels of inventory based on past experience. And all of these models are useful for their intended purpose: Creating estimates of the future based on the past.

But they are inadequate for improvement or problem solving.

Let’s say your car has traditionally gotten 26 miles-per-gallon of fuel. That’s not bad. (For my non-US readers, that’s about 9 liters / 100 km.) You can use that information to predict how far a tank of fuel will get you, even if you have no idea how the car works.

If your tank holds 15 gallons of fuel, you’ll be looking to fill after driving about 300 miles.

But what if you need to get 30 miles-per-gallon?

Or what if all of a sudden you are only getting 20 miles-per-gallon?

If you are measuring, you will know the gap you need to close. In one case you will need to improve the operation of the vehicle in some way. In the other case, you will need to determine what has changed and restore the operation to the prior conditions.

In both of those cases, if you don’t know how the car operated to deliver 26 miles-per-gallon, it is going to be pretty tough. (It is a lot harder to figure out how something is supposed to work if it is broken before you start troubleshooting it.)

Here’s an even more frustrating scenario: On the last tank of fuel, you measured 30 miles per gallon, but have no idea why things improved! This kind of thing actually happens all of the time. We have a record month or quarter, it is clearly beyond random fluctuation, but we don’t know what happened.

The Message for Management:

If you are managing to KPIs only, and can’t explain the process mechanics behind the measurements you are getting, you are operating in the same neolithic process used by the builders of Stonehenge. No matter how thoroughly they understood what would happen, they did not understand why.

If your shipments are late, if your design process takes too long, if your quality or customer service is marginal, if the product doesn’t meet customer’s expectations, and you can’t explain the mechanisms that are causing these things (or the mechanisms of a process that operates reliably and acceptably) then you aren’t managing, you are simply directing people to make the eclipse happen on a different day.

“Seek first to understand.”

Dig in, go see for yourself. Let yourself be surprised by just how hard it is to get stuff done.



Scientific Improvement Beyond The Experiment

“How do we deploy this improvement to other areas in the company?” is a very common question out there. A fair number of formal improvement structures include a final step of “standardize” and imply the improvement is laterally copied or deployed into other, similar, situations.

Yet this seems to fly in the face of the idea that the work groups are in the best position to improve their own processes.

I believe this becomes much less of a paradox if we understand a core concept of improvement: We are using the scientific method.

How I Think Science Works

In science, there is no central authority deciding which ideas are good and worth including into some kind of standard documentation. Rather, we have the concept of peer review and scientific consensus.

Someone makes what she believes is a discovery. She publishes not only the discovery itself, but also the theoretical base and the experimental method and evidence.

Other scientists attempt to replicate the results. Those attempts to replicate are often expanded or extended in order to understand more.

As pieces of the puzzle come together, others might have what seems to be an isolated piece of knowledge. But as other pieces come into place around them, perhaps they can see where their contributions and their expertise might fit in to add yet another piece or fill in a gap.

If the results cannot be replicated at all, the discovery is called into serious question.

Thus, science is a self-organized collaborative effort rather than a centrally managed process. All of this works because there is a free and open exchange among scientists.

It doesn’t work if everyone is working in isolation… even if they have the same information, because they cannot key in on the insights of others.

What we have is a continuous chatter of scientists who are “thinking out loud” others are hearing them, and ideas are kicked back and forth until there is a measure of stability.

This stability lasts until someone discovers something that doesn’t fit the model, and the cycle starts again.

How I Think Most Companies Try To Work

On the other hand, what a lot of people in the continuous improvement world seem to try to do is this:

Somebody has a good idea and “proves it out.”

That idea is published in the form of “Hey… this is better. Do it like this from now on.” image

We continue to see “standardization” as something that is static and audited into place. (That trick never works.)

What About yokoten. Doesn’t that mean “lateral deployment” or “standardize?”

According to my Japanese speaking friends (thanks Jon and Zane), well, yes, sort of.  When these Japanese jargon terms take on a meaning in our English-speaking vernacular, I like to go back to the source and really understand the intent.

In daily usage, yokoten has pretty much the same meaning [as it does in kaizen] just a bit more mundane scope…along the lines of sharing a lesson learned.

Yokogawa ni tenkai suru (literally: to transmit/develop/convey sideways) is the longer expression of which Yokoten is the abbreviation.

Yoko means “side; sideways; lateral. Ten is just the first half of “tenkai” to develop or transmit. Yokotenkai..

If you take a good look at the Toyota internal context, it is much more than just telling someone to follow the new standard. It is much more like science.

How the Scientific Approach Would Work

A work team has a great idea. They try it out experimentally. Now, rather than trying to enforce standardization, the organization publishes what has been learned: How the threshold of knowledge about the process, about a tricky quality problem, whatever, has been extended.

We used to know ‘x’, now we know x+y.

They also publish how that knowledge was gained. Here are the experiments we ran, the conditions, and what we learned at each step.

Another team can now take that baseline of knowledge and use it to (1) validate via experimentation if their conditions are similar. Rather than blindly applying a procedure, they are repeating the experiment to validate the original data and increase their own understanding.

And (2) to apply that knowledge as a higher platform from which to extend their own.

But Sometimes there is just a good idea.

I am not advocating running experiments to validate that “the wheel” is a workable concept. We know that.

Likewise, if an improvement is something like a clever mistake proofing device or jig (or something along those lines), of course you make more of them and distribute them.

On the other hand, there might be a process that the new mistake-proofing fixture won’t work for. But… if they applied the method used to create it, they might come up with something that works for them, or something that works better.

“That works but…” is a launching point to eliminate the next obstacle, and pass the information around again.

oh… and this is how rocket science is done.

Edit to add:

I believe Brian’s comment, and my response, are a valid extension of this post, so be sure to read the comments to get “the rest of the story.” (and add your own!)

Often Skipped: Understand the Challenge and Direction

I’ve been practicing, teaching (and learning) the Toyota Kata for about four years now, and I’m seeing some pervasive patterns that are getting in people’s way of making it work.

The one I’d like to address today is skipping over “Understand the Direction.”

As designed by Mike Rother, the Improvement Kata has four basic steps:


Graphic © Mike Rother  (click on the graphic to download the Improvement Kata Handbook)

This fact (that there are four steps) is often lost on beginning practitioners. They tend to associate “Toyota Kata” only with the “Five Questions” of the Coaching Kata, which guide Step 4 (above). On the surface, that is understandable, because we hear the coaching cycles a lot more frequently, and they are a hallmark of the kata principle.

But we (hopefully) wouldn’t think of jumping right into the Five Questions until the answer to “What is your target condition?” is something more definitive than “To improve this process.”  (We only used to do that, right? hmmm.)

One of the reasons to set a clear target condition is to get away from general “waste safari” improvement efforts, and focus the improver’s attention on what must be done to get to the next level.

Without a sense of direction, it is easy for the improver to see every improvement opportunity (or none of them), and get locked up trying to find a way to fix them all.

It’s frustrating for everyone, because little progress is made, and those improvements that are made have a tough time finding their way to any higher level meaning.

Someone, long ago, pointed out to me that the geometric figure “frustum” seems to have the same Latin root as “frustration.” This is the graphic that comes to mind:


Though the concept of a clear target condition is fairly easy to get across, organizations seem to get locked into a cycle of Steps 2, 3 and 4 without ever going back to Step 1, except in the most general terms.

Here’s what I think happens:

When an organization is just getting started, we’ve commonly told them to pick an area to practice, based on quick cycles and other practice criteria, and get to learning the improvement kata, striving toward a general challenge like one-by-one flow.

That pattern of seeking improvement opportunities gets engrained, and it is hard to shift off it and start to set clear direction and challenges. Further, it is very similar to the “old way” of planning kaizen events where the goal is to “implement lean tools” … like one-by-one flow.

Setting that direction also seems to run counter to the idea of empowered workers are in the best position to know what to work on. (It doesn’t, in fact direction is required for this to really take hold.)

In another sense, though, the Challenge for one level is, in reality, the Target Condition (or at least a major obstacle) for the level above. If I am asking the VP-Operations what his target condition is, I am going to hear things that sound a whole lot like a Challenge for the next level down.

And if the senior leaders don’t have a clear sense of where they are trying to take the organization next… what is their scope of their responsibility?

What to do differently?

(It might help if the leadership team themselves got a coach.)

1) Be clear that your initial sessions are practice drills. You are not yet playing the game, or even a scrimmage. You are flipping tires. Be conscious that this is a transitory learning stage.

2) Establish a target condition for proficiency you are striving for in your practice. Check it weekly against your current condition. This is the job of the advance / steering team.

Challenge Light

For the first pass, it isn’t necessary to dig headlong into hoshin planning, and in many cases, you can issue a compelling challenge with a theme.

Look at what is bugging your customers about your current operation, and challenge yourself to fix it.

For example, one client had lead times and response times that were getting longer and longer, so the challenges issued by the leadership team revolved around lead time and removing “sources of delay.”

Another company had rework and quality escapes going out of control. Their first step was to “grasp the current condition” and identify where these problems were happening.


Each dot represents the origin of a defect or rework. (The colors don’t mean anything, they ran out of red, then orange, then yellow dots.) (You can see exit cycle run charts taped up there as well.)

This gave them a quick picture of where to focus their attention, and which leaders they needed to challenge, and then coach, through the process of improving their quality.

Note that for these guys, integrating the flow of material and information though the plant isn’t a target condition, or even a challenge yet. It is in the vision, but the first priority is simply to ship what the customer ordered, and then to only make the product once to do so.

By the way, profit is measurably up, rework instances have been cut by about 3/4 from the starting point, and they are well on their way.

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.

Eliminating Key Points

TWI Job Instruction is a structured process for breaking a job or task into teachable elements, and a 4 step process for teaching that job to someone.

I am not going to try to explain everything about breaking down a job here, this post is primarily for people who use job breakdowns and job instruction already.

The process of breaking down a job involves:

  • Identifying the Important Steps – the sub-tasks that materially advance the work.
  • Then identifying Key Points within important steps. These are things which the team member must pay special attention to, or perform a specific way. The guideline is that a key point is something which:
    • Is a safety issue – could injure the worker, or someone else.
    • Would “make or break the job” – critical to quality or the outcome of the work.
    • Is a “knack” or special technique that an experienced team member would use to make the job easier to do.

Breaking down a job this way takes practice, but it is a great way to identify the elements that are critical to safely getting a quality job done, and ensuring that the team member understands them.

But I want to propose this is only the first step.

Every key point is something the team member must remember in order to to not get hurt (or hurt others); to avoid scrapping or damaging something; to perform at the level you need.

Take it to the next level.

Think of these key points and the training that they drive as temporary countermeasures.  They are stop gaps you have in place until you can do something more robust.

Take one key point at a time. Why is it necessary? Why is it possible to do this step any way but the best way?

Can you alter the work environment – the product, the process, the equipment, the visual controls to reduce the things the team member has to remember (and you have to remember to teach)?

Can you make it impossible to perform that step in any way other than the way it should be done?

If you can’t, can you make it impossible to proceed until the error is corrected, before any harm is done?

If you can’t, can you make it so obvious that it is impossible to miss?

If you can’t, can you put in a robust reminder? (Signs and placards generally DON’T WORK for this unless they are especially “sticky.”

Every key point is something you have identified as critical to doing the job directly. Therefore every key point should drive a focused effort to mistake-proof the work.

You want to have as few as possible… but no fewer.

The Value of Mistake Proofing

Most companies use some version of the words “respect for people” in their HR mantras. But how is that respect demonstrated?

A team member made a mistake today. He is building a sub-assembly on a mixed model line. He picked a part from a small blue bin with a divider in it.

On one side of that divider is the part he should have picked and installed.

On the other side of the divider is a very similar part.

Guess which one ended up in his hand?

The issue wasn’t caught until a couple of positions down line. When it was caught, it was quickly reworked and corrected.

This particular team member is coming up on the end of his 90 day probationary employment period.

He has seen co-workers who “didn’t make it” (not cut out for assembly work). But he is a smart guy, hard worker, has participated in a lot of improvements for the work he is doing.

Nevertheless, he is worried about the consequences of making this mistake so close to his 90 day evaluation. He just wrote, it seems, what he hopes is his last COBRA check* that will cover him and his wife until his health insurance kicks in at the end of the month.

What is the value of mistake-proofing this operation?

Actually, the consequences of this error are minor. It is easily caught and quickly corrected in a subsequent operation. It is very, very rare. You could make the argument that there are better returns spending the limited problem solving time on bigger issues, and you’d be right… to a point.

But what if this team member’s experience was to see attention focused, not on him, but on what it was about the layout of the work area, about the presentation of parts, about the structure of the work, made it possible to make this error.

What if they acknowledged, overtly, that this kind of mistake is a consequence of being a human being, and that it was only that he happened to be the one standing there when the random chance generator came up?

What if he saw the team leader and supervisor engage him in conversation about what might be done to at least eliminate some of those possibilities? (We don’t really know what happened, though there are some likely guesses.)

What if he was also asked to look for other similar error opportunities, even in his co-worker’s areas, and help eliminate those as well?

What would be the return?

Might this team member work just a little harder to make things even better in the future?

Maybe he would help turn around a cynical or skeptical co-worker.

Maybe he would feel a bit appreciated for what he is contributing instead of losing sleep about his job.

Maybe, at some point in the future, when he is a shop steward, he might remember that “they” are all to human as well.

Who knows.

Before you say “it isn’t worth it” remember what Deming pointed out – “Management’s real job is to manage the unmeasurable.”

Good news – in this (real life) case, they are, for sure, eliminating the split bin and separating the two similar parts from one another; plus likely separating two other bins holding similar bolts. Maybe more, there are some ideas being kicked around.

In the end, though, consider if you will the ROI on team members knowing you will support them in their quest to succeed every day.

*For my non-US readers: COBRA is a program where someone can continue employer-provided health care after termination of employment for up to 18 months by paying the cost yourself. This is sometimes cheaper than purchasing private health insurance.

Appearances vs. Reality

I’m looking at a form labeled as an X-Bar / R-Bar SPC chart. It is filled out pretty consistently by the operators.

But the “control limits” are actually specification limits, and the “standard deviation” looks like it is calculated as 1/3 x the spec limits to force the lines to where they want them from the mean… er ah… nominal.

When I asked about it, at least one company leader was under no illusion that this was a statistical process control, it is simply a means to develop a run chart of actual parameters vs. a nominal value and the specification limits.

I’ve seen far worse, like the time an engineer didn’t understand the difference between “in control” and “in specification.”

But what do they say in their everyday conversations? Do they talk about this process being “within specification” or “in control?” I expect the later.

Another Customer Story

I was in a newly opened store of a large big-box outdoor sports store, and saw an item on display that I had already decided to buy this summer. The displayed price was actually a bit less than what I had been encountering online, so I went ahead.

Unfortunately the one “in stock” on the shelf turned out to be a different model (in the wrong slot), and I didn’t complete the transaction. (A retail nightmare, where the customer clearly wants to buy a big-ticket item you thought you had, but actually didn’t.)

The salesperson behind the counter offered that I could order the item from their web site, have it shipped to the store, and I could pick it up without incurring any shipping charges. Seemed fair enough.

I went online, but the online price was higher than the in-store price. In a sort of reverse from the story I told in December, I emailed customer service and asked if they would match the in-store price for the item.

In a few minutes I got a reply, with an “Incident Number” that said they would, but I would have to call in the order to the 800 number.

All well and good.

I called, and of course “catalog sales” had to refer me to customer service.

Customer service, in turn, had no way to look up the “Incident Number” on the email. “I don’t have any way of referring to that…” (Yeah, go ahead and tell the customer what you can’t do.)

I was referred to someone else (in email? I don’t know). He could not look up the number either, so I read the email exchange back to him. He honored the price, took the order, and it is on the way.

But really?

What is the “incident number” even for if nobody can reference it? In this day and age of networked and cross-linked everything…. what can I say? Perhaps my old I.T. background showing here.

Bottom line:

Turn around and face your systems from the customer’s perspective. Spend some time in the chalk circle. Think through how your process responds to unusual situations.

If a customer refers to something that you should know about your own process, but don’t, there is a kaizen opportunity here. You have an obstacle in the way of smooth seamless customer service. What concrete steps(s) will move you toward eliminating that barrier and smoothing things out?