‘Error Proofing’ is about ‘Getting it right, first time’
‘Error Proofing’ or ‘Mistake Proofing’ is about ‘Getting it right, first time’.
Depending upon the situation, the cost of not ‘getting it right first time’ can have a compounding effect and can be enormous. Just think of the costs of product recalls to a business, or, if you think about the COVID situation, the cost of allowing a single inadvertent transmission of the virus to spread to others in a domino effect.
In some fields of engineering, we use disciplined procedures such as DFMEA (Design Failure Model and Effects Analysis) and PFMEA (Process Failure Model and Effects Analysis) for risk analysis and management. I don’t want to go into much detail here, but it’s essentially about proactive trying to identify what the risks are, the likely hood of an error occurring, how easily an error is detected, and the potential consequence (impact or cost) if an error were to occur. Based on the overall risk level, we then implement ‘countermeasures’ to reduce or manage the risk. You don’t always have to use highly technical tools though. Sometimes simple brain-storming, cause-and-effect diagrams, and a modicum of common sense will get you a long way.
The Key Point
The point is, in any business, there are a range of risks, and if you don’t proactively try to identify them and manage them, then you might be caught out, at great cost. This could be anything from having your website hacked…without a backup, to having some super-critical resource in the business that becomes unavailable, having a devastating effect on the business.
Dennis (Lean Logic Founder) remembers a particular case, not too long ago, when he was doing a general assessment for a business, and as part of it he included a risk assessment. On the first day Dennis found that the computer system they were using for managing their inventory and related production tasks was DOS based (i.e. Disc Operating System, many years old and prior to Windows, and with zero back-up support in the industry anymore!), and the only person who could use it properly ‘protected his territory’ and was approaching retirement. The system worked fine, but WHAT WOULD HAPPEN if it failed? WHAT WOULD HAPPEN if the key user left the company for any reason?
At the end of that first day, the company manager was very thankful, and red-faced, when Dennis alerted him to this risk. It was simply one of those things that had been working, and was ‘out of sight, out of mind’. They didn’t realise there was a problem that needed fixing.
What has that to do with Crash Test Dummies and Spinning and Engine Backwards?
It’s about risk management. For example, it’s about looking at your systems and trying to predict what could happen if people use the system in a manner that it’s not designed for, then to prevent them using it in that ‘wrong’ manner in the first place.
Dennis remembers a particular case as a young engineer, responsible for an engine test facility, where they had some very large electric motors used for testing the power and torque of petrol engines they were developing. These electric motors had a shaft sticking out of each end, and the operator would choose which engine to connect and then control the dynamometer to spin in the ‘correct’ direction.
The dynamometer could be used as a brake, to put a load on the engine, OR, it could be used to spin the engine (with the engine ignition switched off) to measure the friction in the engine. The problem was, choosing which way to spin the engine relied on the operator taking enough care.
One of the operators in question should really never have been employed! He had a regular knack of doing the unexpected and breaking things. (He’d developed a real reputation and fitting nickname his mates gave him that won’t be repeat here). In this one particular case he managed to carelessly choose the wrong direction of rotation of the dynamometer and spun the engine backwards at 6,000 rpm… something the engine and its intake system was certainly not designed for! Poor engine had a heart attack!
After witnessing that, and being responsible for the facility and the equipment within it, Dennis was constantly trying to predict what could inadvertently be done to/with the equipment and manage the risk. Dennis installed various forms of interlocks and visual controls to limit the number of mistakes people could make… regularly using this particular operator as a means of testing new changes to various systems to see if he might use them differently from how they were intended. This operator was in effect, his ‘crash test dummy’ and proof of whether Dennis had done a good job in his risk management efforts.
The real point here is, if you want to make your systems robust, challenge those systems. Actively try to find the weak points. Try to make them ‘mistake proof’ if the consequences and cost of mistakes warrant it.