Blog posts on mistake proofing

Posts selected fromManagement Blog - Engineering Blog - Investing Blog and other blogs

• Mistake Proofing and Mistake Making Less Easy

  Making it harder to make mistakes and making them more visible is good. Preventing them is even better.

  continue reading: Mistake Proofing and Mistake Making Less Easy
• Practicing Mistake-Promoting Instead of Mistake-Proofing at Apple

  Mistake proofing is a wonderful management concept. Design systems not just to be effective when everything goes right but designing them so mistakes are prevented.

  ...

  But guess what, the unnecessary steps Apple decided to force me through are broken so I can’t just waste my time to make them happy. No. They have created a failure point where they never should have forced the customer in the first place.

  continue reading: Practicing Mistake-Promoting Instead of Mistake-Proofing at Apple
• Mistake Proofing Using Enhanced Stop Signs

  The video shows a system that cascades a sheet of water and displays a stop sign directly in the path of trucks ready to crash into a tunnel (because the truck is too tall).

  The driver had ignored several less obvious signals that they were headed for danger. This is an application of one of my favorite management (and industrial engineering) concepts: mistake proofing. As I have stated before, often it is really mistake making more difficult (as it is in this case) rather than mistake proofing.

  continue reading: Mistake Proofing Using Enhanced Stop Signs
• Visual Management and Mistake-Proofing for Prescription Pills

  Mistake proofing is often really mistake-making-more-difficult (for some reason this term of mine hasn’t caught on).

  But the idea is pretty simple: when you have processes that are important and at risk of failure, design processes with elements to make mistakes hard (and ideas such as mistake-proofing and visual management can help you guide your mind to ways to create better processes).

  The entire process needs to be considered...

  continue reading: Visual Management and Mistake-Proofing for Prescription Pills
• Add Constraints to Processes Carefully

  Frequently I see unnecessary constraints creating the edge case excuse. By burdening your process with unnecessary constraints you create edge cases that fail and then use the excuse that each of the edge cases is rare and therefore you can’t justify the expense of fixing them.

  But if you designed the process sensibly in the first place the edge case never would have failed and you wouldn’t need special work arounds for such “edge cases.” A simple example of this is unnecessarily complex web page code that fails if to submit a button without javascript. Yes, a small number of users won’t have enabled all javascript to run (today anyway) so it is an “edge case” to deal with if you don’t have the form work without javascript. But there is no decent reason to have it fail in most cases.

  continue reading: Add Constraints to Processes Carefully
• Poka-Yoke Assembly

  Poka-Yoke (mistake-proofing) is one of my favorite ideas. I just love the idea of not only making something that works well but making something that is difficult to use misuse or use in a way that leads to problems, waste and disappointment.

  continue reading: Poka-Yoke Assembly
• Zero Defects

  I do not believe you succeed by declaring your goal to be zero defects. You succeed by creating a culture of never ending improvement, of customer focus, of fact based decision making, of learning, of “empowerment”…

  Part of that improvement is reducing variation, reducing defects, implementing smart new mistake proofing but innovation is too. Effectively zero defects is not really achievable in most cases. Defects are largely a matter of definition. As performance improves expectations will often rise. When you eliminate anything you would have called a defect years ago, standards are higher and things that would not have been called defects are no longer acceptable. At some point the system process advances to such a level where zero defects is possible in some cases but in many (say medical care, air transportation, education, computer software, restaurants, government, management consulting, civil engineering, legal services…) I really think it is basically impossible.

  continue reading: Zero Defects
• Find the Root Cause Instead of the Person to Blame

  Why did they make that error? Why did the process let them make that error? When you follow the why chain a couple more steps you can find root causes that will allow you to find a much more effective solution. You can then pilot (PDSA) an improvement strategy that doesn’t just amount to “Do a better job Joe” or “that is it Joe we are replacing you with Mary.” Neither of those strategies turns out to be very effective.

  But investigating a bit more to find a root cause can result in finding solutions that improve the performance of all the workers. 

  continue reading: Find the Root Cause Instead of the Person to Blame
• Designing In Errors

  When you design products that create more possibilities for more errors you create products that will in fact fail more often.

  Related: The Edge-case Excuse

  continue reading: Designing In Errors
• European Blackout: Human Error-Not

  The focus seems to be that we didn’t do anything wrong, just some “human” made an error, which seems to be implied is out of their control. Why would the organization not be responsible for the people and the system working together? Management needs to create systems that works. That system includes people and equipment and process management and suppliers

  …

  If management tries to claim a failure was due to "human error" they have to provide me a great deal more evidence on why the system was designed to allow that error (given that they say the error is "human" implies that they believe the system should have been able to cope with the situation). Requesting that evidence is the first thing reporters should ask any time they are given such excuses. At which time I imagine the response options are:

  1. no comment
  2.  we had considered this situation and looked at the likelihood of such an event, the cost of protecting against it (mistake proofing) and the cost of failure meant and decided that it wasn't worth the cost of preventing such failures
  3. we didn't think about it
  4. we think it is best not to design systems to be robust and mistake proof but rather rely on people to never make any mistakes

  What they will likely say is we have these 3 procedures in place to prevent that error.
  Are they every followed? You have something written on paper, big deal? What actually happens?
  Yes they are always followed by everybody, this one time was the only time ever that it was not followed. Why?
  This person made a mistake.
  Why did the system allow that mistake to be made?
  What? You can't expect us to design systems that prevent mistakes from being made.
  Yes I can. That is much more sensible than expecting people never to make a mistake.

  continue reading: European Blackout: Human Error-Not
• How to Improve

  Good management systems are about seeking systemic adoption of the most effective solutions.

  Here is a simple example. Years ago, my boss was frustrated because an award was sent to the Director’s office to be signed and the awardee’s name was spelled wrong (the third time an awardee’s name had been spelled wrong in a short period). After the first attempts my boss suggested these be checked and double checked… Which they already were but…

  I was assisting with efforts to adopt TQM and the time and when she told me the problem and I asked if the names were in the automated spell checker? They were not. I suggested we add them and use the system (automatic spell checking) designed to check for incorrect spelling to do the job. Shift from first looking to blame the worker to first seeing if there is way to improve the system is a simple but very helpful change to make.

  This example is simple but it points to a nearly universal truth: if an improvement amounts to telling people to do their job better (pay attention more, don’t be careless, some useless slogan…) that is not likely to be as effective as improving the process.

  continue reading: How to Improve
• Systemic Failures Lead to Many Fatal SWAT Raids in the USA

  ...people being killed in raids by police on the wrong house: police in full swat gear storming the wrong house by accident and then killing occupants. The media in general sees these as “special causes” – isolated incidents. So while tragic the strategy is then to examine what mistake in this unique situation lead to tragedy. I believe this is a systemic problem and therefore see the proper examination to undertake is to look at the whole system. That is, to use the common cause improvement strategy – when the tragedy is seen not as an isolated incident but the result of a system.

  continue reading: Systemic Failures Lead to Many Fatal SWAT Raids in the USA
• The Best Form of Fire Fighting is None at All

  The best form of problem solving is to avoid problems altogether.

  At the point you have a “fire” in your organizaiton you have to fight it. But it is better to create systems that avoid fires taking hold in the first place.*

  This is a simple idea. Still many organizations would perform better if they took this simple idea to heart. Many organizations suffer from problems, not that they should solve better, but problems they should have avoided altogether.

  continue reading: The Best Form of Fire Fighting is None at All
• Great Visual Instruction Example

  This does a great job of explaining what you need to know clearly. While this presentation for Azithromycin doesn’t prevent a mistake it sure makes it much more likely that the process can be completed successfully. We need more effort in creating such clear instructions.

  Visual clarity is more important than lots of words. Applying that concept is not as easy as it sounds but it is a very important idea for instructions to end use and instructions for processes in your organization.

  continue reading: Great Visual Instruction Example
• Improving Software Development with Automated Tests

  ... Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. Automated software testing tools are a huge help in preventing many errors from affecting customers.

  It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

  continue reading: Improving Software Development with Automated Tests