Archive for category Lean Tools

Reading Backwards – Proofreading Causal Relationships

Problem-solving tools are powerful things.

But, not so powerful that they are immune to human error. Few things are.

Analogously, this is one reason why our school teachers strongly encouraged proofreading (clearly, something that I do not do too effectively at Gemba Tales).

You know, critically reading what you just wrote to ensure that it is clear, well-organized, flows logically, without misspelled words…so that no one thinks you’re a total idiot.

Well, the same type of proofreading reasoning applies to problem-solving.

Two tools come to mind. One is 5 Whys and the other cause-effect diagrams (a.k.a. fishbone diagrams or Ishikawa diagrams).

5 Whys

Many folks are familiar with Taiichi Ohno’s “famous” 5 why example. It can be found on page 17 of his classic book, Toyota Production System: Beyond Large-Scale Production, published by Productivity Press.

In response to a downed machine –

  1. Q: Why did the machine stop? A: There was an overload and the fuse blew.
  2. Q: Why was there an overload? A: The bearing was not sufficiently lubricated.
  3. Q: Why was it not lubricated sufficiently? A: The lubrication pump was not pumping sufficiently?
  4. Q: Why was it not pumping sufficiently? A: The shaft was worn and rattling.
  5. Q: Why was the shaft worn out? A: There was no strainer attached and metal scrap got in.

[I must admit, to me it seems like Mr. Ohno’s example should have reflected 6 whys. The fifth answer would have been metal scraps wore the shaft down. The sixth why would have queried why metals scraps ended up contacting the shaft, with an answer pointing to the missing strainer.  But, who am I?]

So, how can you check the 5 Why analysis for soundness?

Read it backwards, with the word “therefore” or “so” between each response. For example (and pardon the run-on sentence), the strainer was missing, therefore metal scraps contacted the shaft, therefore, the shaft wore out, therefore, the pump did not pump sufficiently, therefore…you get the point.

This simple practice will help the problem-solvers identify if they are perhaps missing something and/or if their “train” of causal relationships does not make sense somewhere. The practitioner needs to sufficiently understand the root cause(s) in order to identify effective countermeasures.

Consider it 5 Why proofreading.

Fishbone Diagrams

Fishbone diagrams require a logic check as well. The diagram is an effective means of organizing and displaying theories of potential root causes.

Often the diagram has a number of primary, secondary and tertiary “bones” leading into the “head.” The bones represent (potential) causes and the head represents the effect.

Because the diagram can have a lot visually going on, it makes sense to proofread it – not just at the end of the diagramming, but as it is being constructed as well. This will reinforce the cause and effect discipline of the folks creating the fishbone.

One effective way to proof is to read the diagram from most minor bone(s) to more major bone(s), all the way to the head – for each causal “thread.” Just like the 5 why example above, you can throw the word “therefore” or “so” in between to make sure that it makes sense.

An example, the driver was inattentive, therefore he was tired, therefore, he had the accident. Oops, looks like the most minor bone (secondary bone) and the major bone (primary) are reversed.

(Yes, inattentiveness is probably a major bone, with fatigue, texting, and eating as discrete secondary causes.)

Fishbone diagrams “tell” a story of potential causes. Reading them aloud helps people to hear the story and then see it among the many bones (sometimes a challenge for the newly indoctrinated) and is an excellent way to make sure the causal relationships make sense.

So, while I didn’t quite appreciate my 5th grade English teacher, Ms. Cahill’s request to more rigorously  proofread my own work, I can appreciate it within a lean context. I hope that you do as well.

Related posts: Show Your Work, Animated Cartoon: “What’s the Problem?”, When You Want to Ask Why 5X, Just Because You’re Curious…

Tags:

Guest Post: Sleeping Air Traffic Controllers. Mistake-Proofing Anyone?

Recent headlines have screamed about third shift air traffic controllers who have fallen asleep on the job, causing some inconvenience to inbound aircraft. I use the word inconvenience because there are procedures to follow when landing aircraft lose communication.  The pilots do the actual flying, not the air traffic controllers.

There are a lot of reasons why an air traffic controller may fall asleep on the job, particularly if he/she is the sole person on duty.  Late night air traffic control can be very boring.  Perhaps they haven’t had enough rest prior to their shift (another matter, indeed). In certain locations, there may be very few flight arrivals over several hours.  Tower cabs and radar rooms have subdued lighting and playing radios or other electronic devices are not allowed.

So, you have several red flag conditions contributing to an environment that make it easy for a controller to fall asleep. So the reaction from the FAA administration?

  • Suspend/fire the offenders.
  • Hire a second controller for each facility.

So with the additional personnel, you are now going to have an already light work load divided between two workers, making the non-value added situation even worse.

Let’s look at it from a mistake-proofing point of view.  What is the source error?  While there are several contributing factors, the source error is the controller falling asleep because there is not enough activity to keep him awake.

Once you have determined the source error to any defect, finding a mistake-proofing device is relatively easy.  We simply need some kind of automatic control to keep the controllers attention. Let’s brainstorm for a solution.

  • Take the controllers chairs away, so they must stand.
  • I once heard that in Australia there is a railroad track that runs absolutely straight for hundreds of miles, and because of poor track, the train can only travel at 30 mph.  To keep the engineers from falling asleep, every 3 minutes or so he has to push a button.  If the button is not pushed, the train slows to a stop.  Interlocks are in place to prevent the engineer from bypassing the intent of the button.  Perhaps we could devise a similar device for our sleepy controllers.

Here are a few suggestions taken from readers on a blog at AvWeb:

  • If there is so little traffic the controllers can’t stay awake, then I say close the tower during those hours. Spokane/GEG has airlines landing at night with the tower closed. Why double your costs when you can eliminate them? In this time of budget cuts is no time to increase costs unnecessarily. As pilots, we all know that night ops can be safely flown at night with no tower. (Note:  many smaller air traffic control towers in the USA close at night.  After hours, the pilots simply broadcast their intentions on the tower frequency.  We’ve been doing it that way since day one. Air Traffic Controllers don’t land the plane, pilots do.)
  • Anyone suggest a $200 CCTV camera run to the nearest night shift security guard? Too simple to be elegant?
  • What if the feds considered staffing the midnight shift with one controller, and one student in an ATC program. Perhaps offering college credit, a guaranteed interview, and perhaps even meager pay to the college kid would be enough to entice them, and it would be much better experience than they’ll get in the classroom. If nothing else, the night shift guys would have someone to play cards with in the off time!

Can you think of some more?

The whole point is, throwing an additional person at an under-tasked job is making a wasteful condition even worse and many companies do it.  Mistake-proof it instead.  Look at your source error, then devise a low cost/no cost method to keep it from happening. Don’t just throw more people a the problem.

How do you think we could keep a lone air traffic controller awake? Send in your comments and let’s hear your ideas.

This post was written by Sam Hoskins, CSSBB, MS, president of MistakeProofing.Net. Sam is an experienced hands-on mistake-proofing trainer and facilitator, who has conducted dozens of events for a diverse range of industries such as explosives manufacturing, processed food companies, welding and fabricating shops, and healthcare.  He learned lean and mistake-proofing while at the Ensign-Bickford Company and authored the mistake-proofing portion of their successful application for the 2001 Shingo Prize.  In addition to mistake-proofing, he is currently conducting Lean 101 training for a variety of companies through Parkland College in central Illinois. You may reach Sam at sam.hoskins@mistakeproofing.net.

Related Post: Guest Post: Preventing Mistakes – Not Just Chump Change

Tags:

Guest Post: Preventing Mistakes – Not Just Chump Change

Companies just seem to love big initiatives.  The thinking perhaps goes: If we hire an expensive consulting firm, we can transform the way we do business, we can start big projects, we can give out lots of new titles, and at the end of the year we can analyze our results and see if we had a gain.

Or…we can do some simple mistake-proofing and pick up the change that’s lying on the floor.

When we look at our value stream, we want to see an unobstructed flow, without detours, hiccups, or reversals.  When we create defects, we throw a monkey wrench into the works and our flow is interrupted.

To make the situation worse, many of us tend to institutionalize our waste.  We create quality systems to document our defects.  Some companies have even created re-work departments.  Talk about non-value added!

I need you to change a bit of your traditional thinking. In order to implement successful mistake-proofing, we have to accept the reality of human error. We have to acknowledge that humans (and machines) will make mistakes.  Once we accept that fact, we can set about putting things in place that will prevent the error or defect; but if we don’t embrace the reality, we are doomed to repeat the waste over and over again.

One of the exercises I like to do is have folks make a list of 10 recent defects in their workplace. We then target one from that list and do a thumbnail cost analysis along with a list of all the aggravations associated with that problem.  It’s quite eye-opening.

A frequent contributor to the list is setup errors.  After all, when you set up a job incorrectly you typically make the entire job wrong, but the root cause is often something simple.  Someone entered an incorrect date code or someone used the wrong product label, those types of things.  (I have seen simple order entry errors cost upwards of a million dollars when a large order had to be scrapped.)

Next, I ask “What did your company do to make sure it never happens again?”

“Well, we had people work overtime to re-work the product so we could get the order out and satisfy the customer.  We also issued a stern e-mail telling all the supervisors to keep a closer eye on things and to try harder.”  That accomplishes little.

Do a gemba walk and take a close look at how much time you are spending fighting fires.  Look at what your supervisors are doing at the moment.  Are they facilitating or firefighting?

Rather than accept the situation, institute a strong mistake-proofing program and put things, lots of things, in place that will eliminate the opportunity for the error.

Simply put, a mistake-proofing device is something that makes it impossible for the error or defect to occur.  It could be a mechanical gizmo, a change to a form, or a change to software.  The possibilities are limitless.

Toyota has an average 14 mistake-proofing devices at EVERY workstation. You should, too!  Go ahead and take away the opportunity to make a judgment error, an identification error, an entry error – the list goes on forever.

There are number of things that contribute to effective mistake-proofing in the workplace:

  • Accept that errors are inevitable and that we will implement real devices to prevent the error.
  • Educate our workforce in the concept of effective mistake-proofing.
  • Avoid blame.  Ask ourselves, “Have we provided the worker with all the tools necessary to ensure success, or are we setting them up for failure?”
  • Use a standard method when mistake-proofing.  I like using a source error chart.  Don’t rush the investigation process.  Take a little time to get it right.
  • Use small cross-functional teams in mistake-proofing events.  I like groups of six or seven people and would normally devote four hours or so for a particular defect.
  • Don’t get too hung up on the root cause.  I know this may sound sacrilegious in quality circles, but sometimes the root cause is simply “I forgot.”  By accepting the fact that people forget things, we can look for a device to help us remember.

After you put your device in place, keep looking for more opportunities.  I don’t usually recommend you look for “What if?” scenarios for something that might go wrong.  I like to look at the big pile of things that actually did go wrong and caused us grief.  There is plenty of action without looking for something that might happen. For instance, look at the re-work area and strive to eliminate it.

If something happened once, it’s very likely to happen again – and again – and again. So don’t put up with it. Use mistake-proofing to pick that change up off the floor.

This post was written by Sam Hoskins, CSSBB, MS, president of MistakeProofing.Net. Sam is an experienced hands-on mistake-proofing trainer and facilitator, who has conducted dozens of events for a diverse range of industries such as explosives manufacturing, processed food companies, welding and fabricating shops, and healthcare.  He learned lean and mistake-proofing while at the Ensign-Bickford Company and authored the mistake-proofing portion of their successful application for the 2001 Shingo Prize.  In addition to mistake-proofing, he is currently conducting Lean 101 training for a variety of companies through Parkland College in central Illinois. You may reach Sam at sam.hoskins@mistakeproofing.net.

Tags: