Tag Archives: poka yoke

Bad Weather is Part of the Transportation System

The job of managers is to create a robust system that delivers value to customers. A system that fails constantly (fails during the continual variation the system faces) is a failed system. Bad weather is part of the variation airlines face. Any management system has to cope with the variation that it faces. The management system must be designed and managed so that the organization successfully delivers value to customers under the conditions the organization will face.

The air travel system in the USA is a disgrace for so many reasons it is hard to catalogue them all. One, of many, is how fragile the system is; causing massive (nation-wide) customer harm multiple times a year due to weather. Weather is sometimes bad. If your organization fails when there is bad weather, fix that problem (make your system robust in the face of bad weather), because you are not going to be able to fix the weather to let your un-robust system be effective as it is.

Instead airlines only response seems to be to get their friends in government to approve anti-competitive mergers to eliminate competition and allow failed organizations to become even larger and harm even more people. Airlines should design robust systems that work in the environment they will face (which they don’t do now).

Their planes don’t fall out the sky when they face bad weather. The engineers behind designing planes have made them very robust. Pilots have been trained to handle variation they will face. And yes, the system has been designed with adjustments to avoid flying into conditions that are risky.

The safety of the air transportation system is very good. The management of airlines in most every other aspect is pitiful, and has been for decades.

The managers running the airlines have done amazingly bad job of creating robust organizations capable of delivering given the variation they know they will face (weather, mechanical problems, IT problems, etc.) for decades. Poor management is the cause of these failures that result in harm to customers. Weather is not the cause. Poor management, over decades, resulting in incredible fragile systems that constantly punish customers is the responsibility of the airlines. And they have done an incredibly bad job at creating a robust system to deliver value to customers.

Continue reading →

Accept Taking Risks, Don’t Blithely Accept Failure Though

For discussion by ASQ’s Influential Voices this month, Paul Borawski looks at Risk, Failure & Careers in Quality.

There is a bias toward avoiding the possibility of failure by avoiding actions which may lead to failure or even any action at all. This is a problem. The need in so many organizations to avoid failure means wise actions are avoided because there is a risk of failure.

Many times the criticism of such cultures however gets a bit sloppy, in my opinion, and treats the idea of avoiding failure as bad. Reducing the impact of failure is very wise and sensible. We don’t want to sub-optimize the whole system in order to optimize avoiding as much failure as possible. But we don’t want to sub-optimize the whole system by treating failure as a good thing to welcome either.

Part of the problem is sloppy thinking about what failure is. Running an experiment and getting results that are not as positive as you might have hoped is not failure. That is going to happen when run experiments. The reason you run PDSAs on a small scale is to learn. It is to minimize the cost of running the experiments and minimize the impacts of disappointments.

Running an experiment and having results that negatively impact customers or result in costs that were not planned may well be failure. Though even in that case calling it failure may be less than useful. I have often seen that a new process that eliminated 10 problems for customers but added 2 is attacked for the 2 new problems. While those new problems are not good that you have a net gain of 8 fewer problems should be seen as success, I would argue, not failure. However, often this is not the case. And the attitude that any new problem is blamed on those making a change, regardless of the overall system impact does definitely hamper improvement.

As I said in a previous post, Learn by Seeking Knowledge, Not Just from Mistakes:

It isn’t an absence of people making mistakes (including carrying out processes based on faulty theories) that is slowing learning. People are very reluctant to make errors of commission (and errors of commission due to a change is avoided even more). This reluctance obviously makes learning (and improvement) more difficult. And the reluctance is often enhanced by fear created by the management system.

The culture I want to develop is one where systems thinking leads to optimizing the overall system. And to the extent that to do so it is wise to take risks that may include some failures taking risks is good. But we need to also use the long known practices to reduce any costs of adverse results.

Continue reading →

Visual Management with Brown M&Ms

When you hear about rock musicians having a clause in their contract that they must have a bowl of M&Ms in their dressing room with all the brown M&Ms removed you could be excused for thinking: what will these crazy celebrities do next. Well it might just be those crazy celebrities are using visual management (granted I think there could be better methods [a bit more mistake proofing where the real problems would be manifest] but it is an interesting idea). Basically if they didn’t have the bowl of M&Ms, or if the brown M&Ms were not removed, they could distrust the thoroughness of the contractors. And they would check to see what other, actually important, contractual requirements were not followed.

Righting The Wrongs: Van Halen and M&Ms

The staff at venues in large cities were used to technically-complex shows like Van Halen’s. The band played in venues like New York’s Madison Square Garden or Atlanta’s The Omni without incident. But the band kept noticing errors (sometimes significant errors) in the stage setup in smaller cities. The band needed a way to know that their contract had been read fully. And this is where the “no brown M&Ms” came in. The band put a clause smack dab in the middle of the technical jargon of other riders: “Article 126: There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation”. That way, the band could simply enter the arena and look for a bowl of M&Ms in the backstage area. No brown M&Ms? Someone read the contract fully, so there were probably no major mistakes with the equipment. A bowl of M&Ms with the brown candies? No bowl of M&Ms at all? Stop everyone and check every single thing, because someone didn’t bother to read the contract. Roth himself said:

“So, when I would walk backstage, if I saw a brown M&M in that bowl . . . well, line-check the entire production. Guaranteed you’re going to arrive at a technical error. They didn’t read the contract. Guaranteed you’d run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening.”

Improving Software Development with Automated Tests

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

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.

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. Expecting people to read much is just setting yourself up for failure when they don’t bother (you should consider psychology, and how people will actually use your instructions not how you want them to).

via: Prescription UI

Zero Defects

Zero Defects by Norman Bodek:

Do you believe it is possible to have Zero Defects? I am not talking about six sigma at all.

I believe it is possible to have zero defects (in a sense). But I do not believe it is a good management strategy to practice what those I have heard in the past preaching zero defects.

A Dichotomy by Norman Bodek. Wow, you really have to look to find this article after you follow the link [I removed the link – additional site defect is now a completely broken link, violating basic 1998 guidance that web links must live forever]. I think the site could really benefit from improving the usability of the site (similar to lean ideas on making things visible and easy to find):

In truth, you should be making lots of mistakes. We do want you to learn, but for the sake of your customers you should not allow mistakes to become defects. That is the dichotomy! Make mistakes but don’t allow them to become defects.

I know many people talk about this conflict (aiming for zero mistakes means missing the most important ideas – because they might be risky). However, I have never really understood it as a conflict. You want to take risks to try new things to experiment to learn. Doing those things can be done in a manner that doesn’t provide your customers a defect. I suppose there are times when you take a risk your customers may be disappointed, but I don’t see why this need be the case with most experiments.

Continue reading →