Tuesday, June 24, 2014

Getting Ahead of the Game: Design For Safety

As safety professionals sometimes it feels a bit like we’re chasing our tails. We come in to an organization and are asked to help facilitate safety management, but typically only after things have been put in place by the organization. Work processes, equipment, management practices, etc. are all typically well established before we’re asked to get to work. Unfortunately this means we’re inherently in reactive mode. We like to call it “safety whack-a-mole.” For those who are unfamiliar with the game “Whack-a-mole”, in the game a “mole” pokes his head up out of a hole and the player’s job is to quickly knock it back down again. As the game progresses the moles come up faster and faster, making it more difficult to deal with all the moles popping up their heads.

Look familiar?

Safety whack-a-mole happens when we constantly are playing catch-up. We are trying to fix problems after they already exist. Whether it’s hazards, risks, incidents, or just general issues that relate to safety management, if all we do is wait for them to show up and then deal with them we will often find ourselves never able to get ahead.

Enter the Prevention through Design movement, or, as we like to call it, Design for Safety (we like our version better because DFS is more than just prevention). Design for Safety (DFS) is about getting safety considerations involved earlier in the management, procurement, and engineering processes in your organization. So, for example, rather than waiting for that loud new piece of equipment to be purchased and only then trying to protect employees from the noise, DFS would involve the development of safety criteria for the purchasing of that equipment, which would include ensuring that the equipment is designed to protect employees from the noise exposure (e.g. sound dampeners).

Or, to use another example, as your organization is developing a new bonus structure that rewards employees for production markers, rather than waiting to see what the unintended consequences of this structure will be, DFS would have us analyze the incentive structure to identify any competing goals it may create and search for ways to either eliminate those trade-offs, when possible, or to provide employees with coping skills for managing the trade-offs so that safety is not compromised.

Obviously the development of an effective DFS system is not something we can completely cover in a short blog such as this. Any effective DFS system must be aligned with the specific work processes and management practices within your organization to be successful. There is an ANSI standard on Prevention through Design that can provide you with a framework for implementing DFS in your organization. However, there’re a few elements that either aren’t covered in the standard, or are sufficiently important that they need additional emphasis. So here’s a brief list of additional considerations that you can use to help in the implementation of an effective DFS system.
  • A common reaction to DFS by safety professionals is fear, because they may not have an engineering background. That’s ok! You don’t need to be an engineer. You bring to the table an understanding of hazards, risks, controls, and regulations that others do not have. You likely also can bring to the table knowledge about human performance that most engineers don’t possess. You don’t have to be an expert in design to champion the implementation of DFS.
  • You MUST include line employees in the design process. A big problem in most organizations is the gap between work-as-imagined and work as it actually gets done. Bridge that gap by getting employees involved in the process. They often can provide innovative solutions to problems, or, at least can help you avoid making mistakes that are brought on by insufficient knowledge of the operating environment. Employee participation is at least as crucial a management commitment to the process.
  • If you’re conducting analysis of a design it often helps to have analysis tools to help make the process systematic. Typical ones include FMEAs, Fault Tree Analysis, HazOps, etc. To add to this we like using the System-Theoretic Process Analysis (STPA) that was developed by Nancy Leveson. In head to head comparisons with other hazard analysis tools STPA has been shown anecdotally and through research to identify more hazards than other traditionally used methods. For more information about STPA check out this book by Leveson.
  • Always document assumptions. If you implemented a particular design feature make sure it’s very obvious why that design feature is there. Ask the question – what happens if everyone who’s involved in the design process leaves the organization? Would people know why you did what you did in a way that would allow them to work safely with your designs?
  • Understand that no planning process is perfect. As they say in the military, no plan survives contact with the enemy. To account for this we need to implement our designs, plans, etc. with an understanding that they will need adjustment. Therefore, build in resilience to allow for those operating with the new design or equipment to adapt to any imperfect parts of the plan. To help with this, in the design process consider implementing feedback structures that help make it obvious that a change is needed.

Again, in a short blog we can’t list everything. So what other elements are needed to ensure the success of a DFS system?

No comments:

Post a Comment