Mishap or Hazard…Where Should System Safety’s Focus Be? by David E. O’Keeffe When MIL-STD-882D was issued back in the year 2000, the major thrust of system safety underwent a paradigm shift from hazard prevention to mishap risk identification, mitigation and control. Now that we have a few years of experience in developing and conducting system safety programs using MIL-STD-882D, has the shift from a focus on hazard prevention to mishap risk been a real benefit to our discipline? I think not. To support my hypothesis, we need to review some pertinent definitions, all from MIL-STD-882D: Hazard. Any real or potential condition that can cause injury, illness, or death to personnel; damage to or loss of a system, equipment or property; or damage to the environment. Mishap. An unplanned event or series of events resulting in death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment. Safety. Freedom from those conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment. System safety engineering. An engineering discipline that employs specialized professional knowledge and skills in applying scientific and engineering principles, criteria, and techniques to identify and eliminate hazards, in order to reduce the associated mishap risk. It is clear, based on the definition of the term “safety,” that a determination that a system is safe depends on freeing the system from those conditions that can cause death, etc. Also from the definitions, those conditions are what we refer to as hazards. Additionally, if we refer to our definition of system safety engineering, it is clear that our mission, or goal, is to seek the elimination of hazards. Yet as we construct our risk indexes in accordance with MIL-STD-882D, we ultimately try to enumerate residual mishap risks, not the risk left over from mitigating the hazard. In other words, our focus has shifted from eliminating the condition that causes the death, etc., to mitigating the unplanned event that leads to the death. To me, that’s putting the cart before the horse.   "No amount of system engineering is going to eliminate or reduce the likelihood that an unplanned event will occur." System safety is supposed to be a bona fide engineering discipline. It is that focus on applying engineering principles that separates system safety from other safety disciplines, such as occupational safety and health, which is more regulatory-compliance centric. The system safety engineer strives to discover the conditions that can cause injury, illness or death to personnel; damage to or loss of a system, equipment or property; or damage to the environment that may be inherent in the system design — in other words, hazards — and determine appropriate mitigations to those hazards. He then works with the design teams to incorporate those mitigations into the design to either eliminate the hazard or reduce its probability of occurrence to an acceptable level. Accordingly, the system safety engineer’s effort is hazard centric. While the end result is a reduction in mishap risk, it is the focus on the hazard that accomplishes this goal. Consider this simple example of a situation we see all too frequently. At a meeting, someone invariably sets up a laptop computer on the conference room table in the middle of the room and stretches the power cord to a wall outlet across a floor where people walk. The potential mishap is someone tripping on the cord and falling. The condition is the presence of the loose power cord. What system safety tries to do is not to mitigate the event — the person tripping and falling — but rather to mitigate the condition. This can be accomplished by any number of methods. The power cord could be taped to the floor, some kind of pad could be placed on the cord, or the condition could be completely eliminated by providing power outlets under the table. In any case, we’re dealing with the condition, not the event. No amount of system engineering is going to eliminate or reduce the likelihood that an unplanned event will occur. The engineering needed is identifying the conditions that lead to the unplanned event and determining ways to eliminate or reduce that condition. While reducing mishap risk is a necessary and worthwhile goal, we, the system safety practitioners, should remain focused on our goal line: eliminating or reducing the condition that leads to the mishap. We should remain focused on the hazard itself. If we focus on mishap, we lose sight of the goal.   Copyright © 2005 by David E. O’Keeffe. All rights reserved.