Cool Email Mistake Proofing

My main desktop computer runs Ubuntu Linux. The default email client is called Evolution. A recent upgrade introduced a very cool feature. When I hit “Send” it looks for language in the email that might indicate I meant to include an attachment. If there is no attachment, it pops up this handy reminder:


Maybe Microsoft Outlook does this too, I haven’t used the latest version, so I don’t know. But in any case, this is a great example of catching a likely error before it escapes the current process. I can’t count the number of times I have hit “Send” only to get an email reply “You didn’t include the attachment.” Obviously I was about to do it again, or I wouldn’t be writing this. 😉 Since I am sending out things like resumes right now, that is something I would really like to avoid.

When talking about mistake proofing, or poka-yoke, there are really three levels.

The first level prevents the error from happening in the first place. It forces correct execution of the correct steps in the correct order, the correct way. While ideal, it is sometimes easier said than done.

The next level detects an error as it is being made and immediately stops the process (and alerts the operator) before a defect is actually produced. That is the case here.

The third level detects a defect after it has occured, and stops the process so that the situation can be corrected before any more can be made.

Each has its place, and in a thorough implementation, it is common to find all of them in combination.

Related to this are process controls.

Each process has conditions which must exist for it to succeed. Having some way to verify those conditions exist prior to starting is a form of mistake-proofing. Let’s say, for example, that your torque guns rely on having a minimum air pressure to work correctly. Putting a sensor on the air line that shuts off the gun if the pressure drops below the threshold would be a form of stopping the process before a defect is actually produced.

A less robust version would sound an alarm, and leave it to the operator to correctly interpret the signal and stop the process himself. Your car does this if you start the engine without having the seatbelt fastened. (back around 1974-75 the engine would not start (see above), but too many people (i.e. Members of Congress) found this annoying so the regulation was repealed.)

Consider the question “Do I have all of the parts and tools I need?” What is the commonly applied method to ensure, at a glance, that the answer to this question is “Yes?”

If you answered “5S” then Ding! You’re right. That is one purpose of 5S.

A common question is how mistake-proofing relates to jidoka.

My answer is that they are intertwined. Jidoka calls for stopping the process and responding to a problem. Inherent in this is a mechanism to detect the problem in the first place.

The “respond” part includes two discrete steps:

  • Fixing or correcting the immediate issue.
  • Investigating, finding the root cause, and preventing recurrance.

Thus, the line stop can be initiated by a mistake-proofing mechanism (or by a person who was alerted by one), and mistake-proofing can be part of the countermeasure.

But it is not necessary to have mistake proofing to apply jidoka. It is only necessary for people to understand that they must initiate the problem correction and solving process (escalate the problem) whenever something unprogrammed happens. But mistake-proofing makes this a lot easier. First, people don’t have to be vigilant and catch everything themselves. But perhaps more importantly, they don’t have to take the (perceived) psychological risk of calling out a “problem.” The mechanics do that for them. It is safer for them to say “the machine stopped” than to say “I stopped the machine.”

Back to my email…

5 Replies to “Cool Email Mistake Proofing”

  1. I agree that is a great email feature. I first experienced it in Pegasus Mail (I think – if not then in Eudora) over 5 years ago. Other software certainly should adopted this feature as missed attachments is such a common error. At least one more email program has picked up on this good idea.

  2. Hi Mark,

    Ubuntu is awesome. I’ve been running it now for almost one year. I haven’t had any stability issues with it. The only thing I can say is that OpenOffice doesn’t seem to have the claimed compatibility, or is it a Microsoft issue?

    At any rate, the real reason I commented is that my observation after using Linux for one year is that the high level of open source standardization that is occuring in the Linux community is a great lesson to be learned for companies struggling with the problems of standardization. Being a Linux user, what are your thoughts on this?

    1. Hi Bryan –
      Thanks for the comments.

      I started experimenting with Linux about 5 years ago, and agree that Ubuntu is the best out there at the moment. The only problem I have with it is that, now and again, something kills Firefox so quickly that its crash message doesn’t even have time to come up.

      Compatibility between OpenOffice and Microsoft is a guessing game for OpenOffice because Microsoft’s file formats have to be reverse engineered. That being said, I find the latest round to be a lot less troublesome going back and forth – even presentations work OK.

      I think that one of the key points about standardization is that it succeeds from necessity, not from being a rote requirement imposed from outside. I’m going to comment further in another post in a day or so, but that was a key point I made during a visit to a hospital today.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.