Category: Quality

Posted on

How Strong Is Your Immune System?

Each day you are exposed to an unimaginable number of viruses and bacteria. Any one of them has the potential to overwhelm your body and kill you. But your immune system detects the foreign body, responds, swarms the source of infection, defeats it, and learns so that your immunity is actually strengthened in the process.

Some people, for various reasons, have weak or suppressed immune systems. They suffer from chronic infections. Even if their immune system keeps the infection under control, it is not strong enough to eliminate it. Things which someone else might not even notice take a daily toll on their energy and life.

Your immune system represents your body’s strength to deal with the unanticipated and the unexpected.

In your organization, people encounter unanticipated and unexpected things every day. A small inconsequential defect causes some inconsequential rework. A missing part causes a search and expedite. Each of these things, in turn, propagates more variation, like expanding waves, into the system around it. The variation becomes an infection in your processes, and it has the potential to grow without bounds.

Most organizations have very weak immune systems. They are chronically sick, and expending incredible amounts of time and energy dealing with these “infections.” Because each “infection” is, at best, accommodated rather than eliminated, they tend to accumulate. More and more of the organization’s energy is expended coping.

In the work place this means that the success of the process becomes totally reliant on the vigilance of each individual, working pretty much alone, to see problems and control them enough that some form of output can continue. Worse, many organizations build elaborate systems to assign blame when one of these thousands of opportunities for problems is missed.

Ironically, a lot of “blitz” type kaizen activity actually makes the the system more sensitive to these kinds of problems. If there is no corresponding effort to strengthen the response (swarm, fix, solve) to these problems, it is no wonder that things slide back pretty quickly.

Variation is an infection. And like the viruses and bacteria we are exposed to every day, it will always be there. It is only your ability to quickly detect variation, rapidly contain it, and then deal with its cause that strengthens your organization’s ability to deal with the next one.

Posted on

Listening to the Customer vs. the HiPPO

Microsoft has an internal initiative to start running controlled experiments to determine what is actually better for users. I have no data (as I have no inside scoop from Microsoft, even though they are right down the road), but there is general opinion out there is that one of their latest efforts turned out to be less than impressive to the user community.

The mascot of this initiative is a hippo.

PERHAPS, and again, this is only speculation, when they were putting in all of the snazzy page flipping and rotating cube features, they were paying too much attention to the HiPPO and not enough to the actual customer.

What is the HiPPO?
The Highest Paid Person’s Opinon.

Who do you listen to?
Your customers? Do you actually go into the field and watch them use your product?
Do you use it the way they do, in their environment, to understand their experience?

Of does your head of engineering or sales claim to speak on their behalf when you are deciding on product features?

Posted on

Watch out for drug names that look, sound alike

Watch out for drug names that look, sound alike – Yahoo! News

One of the most common errors made in the health care industry is medication – giving the wrong stuff to the patient. There are a lot of root causes, and this article highlights one of them.

I certainly understand that the commercial pharmaceutical industry wants to establish and maintain brand awareness. And I am equally certain that they don’t really consider it "their problem" if "someone doesn’t pay attention" and prescribes the wrong medication; dispenses the wrong medication; administers the wrong medication or takes the wrong medication.

This is one of the problems with a complex system – where a problem originates in one part, but is only felt in another part.

Ultimately the solution is fairly simple. Assign an alpha-numeric code, not to the brand, but to the formulation, including the strength / dosage. Use that code for all bar coding, RF tags, database records, prescriptions, etc.

If it would help, combine that code with colored labels, backgrounds, shapes, etc. Anything to help visual distinguish one product from another.

This is, of course, not a 100% bullet-proof solution. But humans are really poor at distinguishing similar looking words from one another. We don’t see letters, we hear the sounds. This is an appropriate case where technology, which is well suited for this kind of thing, can be a big help.

Will it eliminate all errors? Of course not. Mislabeling or mixing mistakes are also common. But this would attack the problem cited in the article at its root. Then the companies can name their products anything they want, and we also eliminate all kinds of overburden on the already overworked attorneys.

Posted on

Dealing With High Turnover

Jim left a great post on The Whiteboard way too long ago.

His problems seem to sum up to these statements:

Every valve is hand made one by one in batches through several processes.

…about a 10% turnover rate…Consequently we are always training new people…the supervisor needs to make sure the worker understands the job

My inclination is to somehow explain to the owners how their employee turnover rate is hurting their production and quality.

He titled his post  Hitting The Moving Train which seems appropriate on a number of levels.

Keeping in mind that I have not done my own "go and see" so I don’t have facts from the ground, only what is reported, a couple of immediate things come to mind. Other readers (especially the couple of dozen of you who never leave comments!), feel free to chime in here.

Short term: Stop the batching. Or, more specifically, flow the batches. The key point here is that just because you run batches doesn’t mean you can’t run one-piece-flow. (Pardon the double negative.)

What does that look like here? For each batch of valves, understand all of the assembly operations, set up an ad-hoc flow line that sequences all of the steps, then run them all through.

This does a couple of things, first and foremost, it gets them off the shop floor and shipped a hell of a lot quicker because now they are DONE. The downside is the supervisor needs to teach more than one person his particular sequence steps, but it eliminates all of the routing, traveler paperwork, tracking, prioritizing, and other stuff associated with having those 50 incomplete valves sitting out there. Scheduling becomes "Which jobs are we going to set up and assemble today?"

What about the parts? Don’t start assembling until you have all of the parts.

"Wait a minute, what about just-in-time?" One thing at a time. Let’s not launch a job until we have the capacity and capability of actually doing it for now.

Next, (Intermediate Term): is make the supervisor’s job a bit easier. I am assuming that, since he is training the workers, that he understands the tasks. But does he have formal training on how to break down work into steps and instruct in a way that someone remembers how to do it? Rather than reading a book about it, I would strongly suggest contacting the TWI Institute and getting, first, a handle on Job Instruction. This is, essentially, standard work on how to break down a job and teach someone to do it. The method has been taught unchanged since mid-1944. Not surprisingly, it is bread-and-butter at Toyota… and their material is pretty much verbatim from the 1944 material.. and it is the origin of standard work as we know it.

As jobs are broken down, the inherently critical tasks should emerge. These are the things which must be done a certain way or the thing just won’t go together (bad) or will go together, but won’t work (very, very bad). Those key points are where to start instituting mistake-proofing, successive checks, etc. This will start driving toward stomping out the quality issues.

For each quality issue that comes back to bite, take the time to really understand how it was even possible to make that mistake, and focus a problem solving effort on that key point to (1) incorporate it into the teaching and (2) mistake-proof and successive-check that particular attribute. Defects discovered in the plant are bad enough. Defects discovered by your customers are another story. Do what you must to keep the defects from escaping, then work on preventing them. Don’t cut out inspection just because it is muda.. unless you are 110% certain that your process is totally robust, and any problem that does occur will be caught and corrected immediately. Anyone who thinks Toyota "doesn’t do inspection" has never seen the last 60 or so positions on their assembly line… nor have they seen the checks that are continuously being made during assembly.

And finally – the turnover issue. A couple of things come to mind. First, with the right attitude and approach, the things described above can make this a lot more interesting place to work… especially if the Team Members are involved in finding the solutions to escaping quality issues, etc.

The same goes if supervisors continue to hone their leadership skills. Employee turnover is typically caused as much by the relationship with the first line supervisor and working conditions in general as it is by wages, etc. Southwest Airlines would not exist were that not true. Neither would a couple of other companies I can think of. Go look at "The 100 Best Places to Work" and see that relatively few of them cite "the highest pay and best benefits in the area." This isn’t to say that they do not offer fair, competitive compensation. But compensation, in general, is a relatively poor indicator of job satisfaction. Far more important is a daily demonstration that someone cares and is committed to the Team Member’s success.

If they really like TWI Job Instruction, they might be attracted to Job Relations – standard work for supervisors (first line leaders) for people issues. The TWI Institute has also just launched a new program called Job Safety. This isn’t one of the original TWI classes, but it was put together by experts I know and trust, and from what I have read, it follows the same reliable method format.

With all of that, perhaps the owners will be convinced that a competitive compensation program is a way to say "Thank you" to a great team that busts their butts to keep the customers happy.

Posted on

Hospital Error – Heparin in the news again

Corpus Christi, Texas: Hospital error blamed for more infant overdoses – Yahoo! News

Key points of the story are:

  • 14 babies received heparin overdoses while in intensive care.
  • Two premature twins died, though it is unknown if this was the cause.

…pharmacy workers at Christus Spohn Hospital South made what the hospital called a "mixing error." The two workers went on voluntary leave.

The heparin, which was 100 times stronger than recommended, was given to 14 infants in the hospital’s neonatal intensive care unit on July 4.

As I have cited on previous posts, medication errors are one of the most common ways hospitals unintentionally injure or kill patients in their efforts to treat them.

I am reasonably certain that the two workers who went on "voluntary leave" (yeah, right) will absorb more than their share of blame as the system solves the problem by asking the "Five Who?" questions.

The article then goes on to cite a history of similar incidents in hospitals all over the country, though it is sometimes unclear in the writing if it is talking about this case or a previous one.

So what should happen?

First, determine where the actual root error occurred. If the manufacturer shipped mislabeled product, for example, then the problem happened THERE, not in the hospital. That isn’t to say we can’t do a better job in the hospital catching those things, but that isn’t the root cause in this case.

Any investigation should center on an assumption that the workers were operating in good faith, paying as much attention as can be expected of a normal human being, and were positive that they were doing this right. They did not want to injure or kill their customers.

Somehow, then, the process of mixing (either in the hospital or at the manufacturer) allows a 100x error to go by without SCREAMING for attention. And scream it must. Humans doing routine things in routine ways operate on an assumption that everything is routine until presented with overwhelmingly compelling evidence to the contrary.

Any hunt for "who did it" is motivated by extracting retribution rather than solving the problem. Once again, I refer the reader to the great work by Sidney Dekker on human error. We can all learn and apply it to everything that people need to do correctly – safety, quality, any other process or procedure.

Posted on

Anchoring a Problem Solving Culture

More than a few organizations I know are starting to understand the importance of establishing a culture of problem solving. Hopefully they are shifting from a tools implementation model to one which emphasizes how people respond to the daily friction generators.

In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.

The organization must reset its definition of “a problem.”

I started to get at this mindset back in January with the post “Chatter as Signal.”

In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.

Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.

When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”

The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”

Maybe the term “problem” is unfortunate.

A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”

In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.

The organization must have a process for immediately detecting and responding to problems.

It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.

But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.

Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.

Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?

But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?

The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.

The organization must have a process for managing problem solving.

When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.

Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages

However it is done, however, the organizations that do it well:

  • Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
  • Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
  • They manage their talent. The organization I talked about in the “Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
    • Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
    • Don’t jerk them from one thing to the next without allowing them completion.
  • They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.

They deliberately and systematically develop their problem solving skills at all levels.

It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.

Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.

This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.

This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.

As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.

Posted on

Computers and Muda

In a short, but interesting, thread on lean.org, Emma asks an interesting question: “Can an IT system support Lean?” She goes on to point out a general trend she has seen where the “kaizen guys” offer a lot of resistance to the introduction of sophisticated I.T. systems.

“Lean” stuff aside, I offer this recent post on Tech Republic, “The Seven Habits Of Wildly unsuccessful CIOs.”

Though the article is written about individual CIO’s, it applies to the sub-culture of information technology in general. However, there are a few points where I think the scope should be expanded.

#1, “Acquire technology simply because it’s new” talks mainly about upgrades. I would expand this to discuss “Acquire technology simply because it’s cool.” I.T. folks are biased toward computerized solutions. Now that’s great, and it is what we pay them for. But often there is a simpler way, perhaps with the information system as an enabler rather than the centerpiece. One of the fundamental principles we taught at a previous company was “Simple is best.”

In #3 “Create solutions in search of a problem” the article emphasizes off-the-shelf solutions vs. an in-house solution to everything. Again, though, I want to take the title of the paragraph and expand the scope. Just because it is slick and “does this” and “does that” does not mean it is useful. More features, and for that matter, more information, is not necessarily better. I want just what is necessary for the next step in the process. Any more provides a distraction, an opportunity for error.

#4 “Reach beyond the competency level” is classic. If you don’t know how to do it, please don’t say you do. It is OK to take on an experiment, but please control it and understand it before it is imposed on everyone. And make sure the “solution” solves a “problem.”

#6 “Failing to understand the relationship between technology and business” – read the technology chapter of “Good to Great” and “The Toyota Way.” Those both offer great insights on how great companies use technology as a multiplier without making it a boat anchor.

If you are an I.T. person, and are encountering the same push-back that Emma is from your kaizen people (or for that matter, push-back from anyone), I would recommend you read the article. Then do the following:

For each key point in the article, write down how an I.T. organization that does exactly the opposite would perform and behave with its customers. This is creating the idea of the ideal supplier.

Then take a hard look in the mirror. Compare your actual attitudes, beliefs, behaviors with that list. Talk to your customers, and ask them how they perceive your organization.

You are likely to find gaps between the ideal state you defined and your actual performance. If so, develop a plan to close those gaps.

Posted on

Safety and Lean Manufacturing

This is a (belated) response to a post from Patsi Sells on The Whiteboard. She asked about safety and kaizen.

When first implementing some of the tools and mechanics of the TPS (especially in a manufacturing environment), many of the initial efforts seem to run afoul of the industrial safety professionals. My experience suggests a couple of basic causes.

  • Safety countermeasures are not seen as necessarily directly contributing to production of the product. Thus, they are often lumped in to “not value added” or “waste” – at least by implication, if not directly, by over-enthusiastic kaizen event leaders.
  • Safety professionals can be stuck on specific countermeasures vs. looking at the actual risk and identifying other possible countermeasures.
  • Safety professionals are concerned (and rightly so) about repetitive motion injury. They perceive that takt driven standard work might increase the risk of this.
  • There is overall a general lack of understanding of the difference between regulatory compliance and keeping people safe. While these two things overlap, neither is necessary nor sufficient to assure the other.

Let me start with the last point since it probably raised the most eyebrows.

An industrial safety program has two distinct and discrete objectives:

  1. To keep people from getting hurt.
  2. To comply with all laws and regulations

As I said above, while meeting both of these objectives are absolutely necessary, meeting the requirements of one does not guarantee meeting the requirements of the other. To put it more directly –

  • It is possible to be fully compliant with all health, safety and environmental regulations and still have a workplace which is extremely dangerous.
  • It is possible to have a very healthy, safe and environmentally friendly workplace and still run afoul of laws and regulations.

Thus, it is necessary to ensure that each of these things are discretely addressed in any successful program.

It is important for both kaizen and safety professionals to be aware of this. Some things are simply required by law, even if they are wasteful, and sometimes interpretation is up to the whim of a local inspector who might be having a bad day. Whatever the case, for each regulatory requirement there must be a specific, targeted countermeasure, just as there must be one for each physical risk. Sometimes these things overlap, but sometimes they do not, and that is the key point here.

I will digress for a paragraph and make this point however: If you have the basics of workplace organization in place, you make a much better first impression on a health and safety inspector than if the place is a mess. If your fire department sees the fire extinguishers are all where they should be and up to date, access aisles and evacuation doors clear, etc. he is more biased toward the assumption that you have your basic act together than if the place is a mess. Everyone has some violations, but when they are blatant, simple things it starts you off with a bad impression, and inspectors usually start digging.

Moving beyond simple regulatory compliance, the objectives of “lean manufacturing” and safety are 100% congruent. Ethically it is never acceptable to knowingly put people in harm’s way for the sake of production. At a more pragmatic level, a hazardous workplace will adversely affect quality, production, cost, delivery and morale. I will not descend to the level of cost-justifying safety simply because it isn’t necessary. But it is equally true that an unsafe workplace has higher costs than a safe one.

The good news is that the kaizen process is incredibly effective at dealing with safety hazards.

Moving up on the above list, one of the biggest places where the safety professionals can help smooth out the work is with their expertise in ergonomics.

What the kaizen people should take a little time to understand is this: Motions with poor ergonomics nearly always take longer than motions with good ergonomics. To put it a little more clearly: Ergonomic improvements are kaizen. Once a good team understands the difference between good and bad ergonomics, they can quickly see many small improvements which all accumulate.

By standardizing the method, we standardize the good ergonomics. Where there are no standard methods, the Team Members will each develop their own which may, or may not, be the safest way to do the job.

Standardizing the right motions reduces the chance of repetitive motion injury. And paying attention to why unusual motions are necessary comes back to reducing variation and overload (muri, mura) in the workplace.

At the next level up, standard work is your best friend.

To develop any process you first take a good look and specify exactly what result you expect to achieve.
Define a defect-free outcome.
Part of that definition is “perfectly safe.” No one is going to argue with this. Of course you want a process that is perfectly safe, and produces a defect free outcome. Who wants the opposite? But until “defect free” and “perfectly safe” are explicitly defined or specified, there may be room for interpretation. Do this before working on the process steps.

Next define the work you believe will deliver a perfectly safe, defect-free outcome. Define the content, sequence and timing of the work.

Now you have a specification for content, sequence, timing and outcome – the four elements of activity that Steven Spear called out in “Decoding the DNA of the Toyota Production System.”

Next – try it. Run the process exactly as you specified it. Verify two things:

  • That the Team Member can perform the process as specified – there is nothing keeping him from doing it.
  • That the Team Member actually does it that way and put in guides, controls, mistake-proofing where things go off track.

Check your results.
Was it perfectly safe? Did you see any risks? How are the ergonomics?
Adjust as necessary, then repeat.

Was the result defect free? How do you know? Is there a way for the Team Member (or an automatic step) to verify the result?

In practice, you are “trying it” and “checking the results” not just when you are developing the process, but every time it is done.

If a defect is produced at some point, then you know either:

  • The process didn’t work as you expected.
  • For some reason (which you don’t know yet), the Team Member did something different, or omitted a step.

Likewise, if the Team Member so much as skins a knuckle, you know the same things: The process is not perfectly safe or the process wasn’t (or couldn’t be) followed.

In most cases where the process was not followed you likely had a Team Member doing something in good faith to “get the job done.” This is the time to gently remind him that, when he can’t follow the process as designed, to please pull the andon and let someone know. Maybe you will have to make an exception to correct the current situation, but you HAVE to know if the process isn’t working or is unworkable.

Bottom line?
You get perfect safety exactly the same way you get perfect quality.
The methods and approach for getting it, and the methods and approach for correction and countermeasure are exactly the same.

Remember:
The right process produces the right result.

If you aren’t getting the result you want, then take a look at the process.

Posted on

Attack on Ambiguity

When real effort is spent getting to the cause of problems (vs. a reflex to find someone to blame), ambiguity often enters into the picture.

Problem solving is a process of asking questions and clarification.

Is a “defect-free” outcome of the process specified? Does the Team Member know what “success” is?
Is there a way for the Team Member to actually verify the result?
Does that check give the Team Member a clear Yes/No; Met/Not Met; Pass/Fail response? Or is there interpretation and judgment involved?

If there is good specification for “defect-free” – is there a specification for how to achieve it? Do you know what must be done to assure the result that you want? Does the Team Member know? Is the Team Member guided through the process? Are there verifications (poka-yoke, etc) at critical points?

If all of the above is in place, do you know what conditions must be in place for success? What is the minimum pressure for your air tools? Is there a pressure gage? Does it cut off the tool if the pressure is too low? Is there some visual check that all of the required parts, pieces, tools are there before work starts? Thank about the things you assume are there when the Team Member gets started.

For ALL OF THE ABOVE, if something isn’t right, is there a clear, unambiguous way to alert the Team Member immediately?
Is there a clear way for the Team Member to alert the chain-of-support that something isn’t right?

If there is a defined result, a defined process to achieve it, and all of the conditions required for success are present –
Is the Team Member alerted if he deviates from the specified process, or if a critical intermediate result is not right?
More poka-yoke.

Now you have the very basics for consistent execution.

Is the process carried out as you expect?
Is the result what you expected?

If not, then the process may be clear, but it clearly does not work. Stop, investigate. Fix it.

All of this is about getting more and more about what is SUPPOSED to happen and compare it to what is REALLY happening… continuously. I say continuously because “continuous improvement” does not happen unless there is continuous checking and continuous correction and problem solving. If you want “continuous improvement” you cannot rely on special “events” to get it. It has to be embedded into the work that is done every day.

Posted on

Adventures in Airline Travel

Today I flew from my home in the Seattle area to New York’s La Guardia airport. This seems to nearly always be an adventure, but this one was unusual, so I wanted to comment on the customer’s perspective.

The flight routed through the airline’s major hub in Minneapolis (MSP) (so now you know which airline if you fly at all). No sooner than I had turned my cell phone on at the gate at MSP than it buzzed. I answered, and it was the airline’s computer talking.

I was informed that my flight from MSP to LGA had been canceled. This is never good news. I was informed that I had been re-booked on another airline (Midwest), and to contact the gate agent before going to the other airline’s counter. I was read a confirmation number, though sitting in an airline seat I really had no opportunity to write anything down, and was informed that all of the details were available on the airline’s web site – which is really no help unless I am on line in the airport. No big deal.

The gate agent is polite, lets me know that the other airline is “way over in Humphrey Terminal” and suggests another flight into Newark. “No, that’s OK, I want to go to La Guardia.”

I was much more concerned, at this point, about my luggage. Airlines, in general, do a reasonably OK job recovering from these things and getting people where they need to go. As a group, however, they don’t seem to “get” that it is important to the passengers (at least important to this passenger) that the luggage get there more or less at the same time I do.

I was cheerfully told that my luggage would be on their next flight to LGA, and I could pick it up “at my convenience.” This choice of words was interesting, it implied that I would easily just head back to the airport when my luggage got there.

One of the blind spots of all airlines is the illusion that the airport terminal is the final destination. Their job ends once they unload you there.

My only other option was to fill out a “missing luggage” claim with the secondary carrier (since they are responsible as the last airline I flew on), then they would get with the original carrier, arrange delivery to the hotel, etc. I pretty much resigned myself to having to go through that nutroll, and hoping beyond hope that it would get to the hotel overnight so I didn’t have to show up at Corporate HQ in “Seattle Casual.”

(I should relate the story of lost luggage when I had an 18 hour stay in Berlin sometime…)

Midwest Airlines flight 5 from Minneapolis to La Guardia stops in Milwaukee. When we arrived, we were informed this 30 minute stop was going to be a 2 hour stop due to “weather delays” in La Guardia. Not sure what that was about, the weather in La Guardia is beautiful tonight, but whatever. We actually got “release” after 1 hour, got on the plane, and headed east.

One thing I have to say – Midwest has a nice little niche service, and features “the most comfortable coach seating in the industry” by their claim. The seats certainly are nice, and I can’t complain about warm, gooey chocolate chip cookies either.

When I got to LGA, I thought “what the hell”, grabbed the shuttle bus and headed over to the NWA terminal to just see if they even knew where the luggage was. I arrived, was walking toward the luggage service office and there, coming out of the conveyor was my suitcase. How the hell that happened, I will never know. I picked it up, headed out of the terminal, caught the shuttle to the rental counter, waited behind the couple who could not rent a car because HE had the credit card and SHE had the driver’s license, got my car, and here I am.

Short Story: Somtimes good customer service happens purely by accident. It shouldn’t, but sometimes it does. Of course, the airline industry does a very good job of managing my expectations (i.e. keeping them low). I am always pleasantly surprised when they manage to deliver what they minimally promised.

Note To The Airlines: I try to not be one of those people who abuses the carry-on rules. If I have too much stuff, I check it. However – as a customer, it is important to me to arrive with my luggage. Sometimes that it more important than getting to the destination as soon as possible.