How Many Controls do we Need to Reduce Risk?
When we’ve identified a risk to our design or user process – and that risk can pose a potential harm – how many controls do we need to add?
We discuss prevention vs. detection controls, ALARP, as low as possible, and some scenarios where we could (and maybe couldn’t) justify a risk as acceptable without adding additional controls.
ALARP = As Low As Reasonably Practicable
One reason we could easily justify accepting of risk as ALARP is if the controls we think to put in place don’t actually reduce additional risk. Another is that adding another risk control is not possible. We talk about examples of these in the podcast.
What is the reason that might not be justifiable to using ALARP? “We didn’t think to design it that way and we’re too far down the design path.” Implementing a control might add time, money and cost to the project. Would this reason be justifiable to release a product with risk?
Our original question was how many controls do we need to put into place? And my answer to that is, “It depends.” If we’re willing to accept the risk to a user (or environment, use-process, property…) we need to be clear about our reasons and justify our decisions of why we think we have adequate controls.
We’ve identified a risk something could happen during the use of our product. And it could potentially cause harm to the user, so it’s pretty serious. What controls should we put in place? How many controls do we need? We’ll talk more about the types of controls and the meaning behind ALARP after this brief introduction.
Hello and welcome to quality during design the place to use quality thinking to create products others love, for less. My name is Dianna. I’m a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join the conversation at QualityDuringDesign.com.
First, let’s talk controls. There are two types, detection and prevention. Detection are those controls we put into place to be able to detect the cause of our problem before it gets to our customers. These are activities we take to monitor, inspect, or test the quality characteristics of our product before they get shipped out the door. Detection controls at a cost to the organization. It takes time, personnel, inspection or test equipment…all of these things need to be maintained to be able to continue controlling our risks using detection.
On the other side of controls is prevention. And they’re largely a part of our design. We’re designing products or user processes in a way that prevents that cause-and-effect chain from ever happening in the first place. Benjamin Franklin’s quote is, “An ounce of prevention is worth a pound of cure.” Prevention controls don’t add ongoing cost to the organization like detection controls. Maybe there’s an added cost of a safety feature component, but that extra cost is likely way less than the level of detection controls we’d need to maintain. Maybe even more than that, there’s also a social responsibility that we have as designers to put out product that isn’t going to cause injury or harm. Prevention controls do take design effort and diligence. If we start assessing and analyzing risks early in the design development phase (even at the black box phase), we can begin using those analyses to guide us to design features, factors of safety, user interfaces, materials, and even create designs meant for test and inspection, which could lower any detection controls we’d end up meeting anyway.
If we’ve discovered a risk as part of a thought process early in our concept design phase, then perfect! We can rework our design on paper or even rework our prototypes. When implementing risk controls, no matter at what design phase we’re in: how far do we go? Do we change our design to institute prevention controls? Do we change the incoming inspection methods or threshold to detect our causes? Or do we conclude that we can’t do either of those things and instead need to just accept the risk? Given our current controls and considering the chain of events from cause to a serious event, are we going to consider a risk acceptable? If it’s not acceptable, we need to add a prevention or detection control.
There is a lot of regulation and management of safety-critical and safety-involved systems, these systems that if they don’t work properly it cause death or serious injury to someone. Or, destroy or cause a lot of damage to property. Within these realms we have regulations about how far we need to take risks. I’m going to discuss these without getting into the regulations themselves.
ALARP is an acronym for As Low As Reasonably Practicable. What does practicable mean? In the Merriam Webster Dictionary, it’s “capable of being put into practice or of being done or accomplished”. Its synonym is feasible. ALARP, as low as reasonably practicable, could be as low as is reasonable to put into practice. Another phrase used in industries is As Far As Possible. Both with ALARP and As Far As Possible, this is where we weigh a risk is against the time, money and trouble needed to control it.
We can see that when we’re designing safety critical and safety involved systems, how ALARP can be a tricky place to be. The organization is defining what is reasonable. But then, those decisions are also available for regulators (or anyone else overseeing the project) to question. Did we have sufficient evidence or reason to claim that our risk was controlled as low as our organization was able to put into practice? Depending on what we’re designing, we may have to be pretty strict about this decision.
One reason we could easily justify accepting of risk as ALARP is if the controls we think to put in place don’t actually reduce additional risk. The clearest example of this is an alarm to the user. Think if we used an alarm like our mobile phone ringing: it makes a noticeable noise, shows lights, and vibrates. Adding another alarm to that series wouldn’t actually reduce additional risk. It would be redundant; it would just annoy the user. The other reason we could easily justify accepting a risk as ALARP is that adding another risk control is not possible. Maybe we’re already using the best materials available for our engineering design. Maybe we already have an effective control, but the nature of that control prevents us from adding another one. There might also be inherent risk because of the nature of how our device is used. And we may have constraints in our manufacturing capabilities.
What is the reason that might not be justifiable to using ALARP? “We didn’t think to design it that way and we’re too far down the design path.” Not implementing a control because of this might add time, money and cost to the project. Would this reason be justifiable to release a product with risk? We would need to explain why this is OK.
Remember that these risk analysis don’t spit out an answer. They’re not like a math problem where if we follow the steps and are careful, we’ll get an answer. These quality and reliability analysis help us gather information about our designs. People decide if the risk of a new design are acceptable or not. And we need to be able to change our minds about that risk acceptability when we’re given new information. The best way to build this type of information into the design process is to do those risk assessments, analysis, and evaluations early in the design process. So, we can use them as inputs into our design. We don’t want to analyze risk because of our design.
Our original question was, “How many controls do we need to put into place?” And my answer to that is, “It depends.” If we’re willing to accept the risk to a user, we need to be clear about our reasons and justify our decisions of why we think we have adequate controls. And that we’ve reduced risk As Low As Reasonably Practicable.
Please visit this podcast blog and others at qualityduringdesign.com. Subscribe to the weekly newsletter to keep in touch. If you like this podcast or have a suggestion for an upcoming episode, let me know. You can find me at qualityduringdesign.com, on LinkedIn, or you could leave me a voicemail at 484-341-0238. This has been a production of Denney Enterprises. Thanks for listening!