|
While we were attending the San Diego ISSC this past August, one of our newer Chapter members asked me a most intriguing question. He asked why, if most accidents have been shown to be caused not by random hardware failures but by simple lapses in good safety management (the MORT syndrome, if you will), does there seem to be such a disproportionate number of papers dealing with technical esoterica? Although not its stated purpose, the paper presented at the Conference by Messrs. Holloway and Johnson clearly indicated that organizational problems were the cause of at least half of all the accidents (84) they investigated. Organizational aspects, combined with individual errors, accounted for about 80% of all accidents they investigated, while equipment failures — the stuff of fault trees — accounted for less than 20%. We suspect that these statistics are fairly typical. Why, then, does the softer side of system safety seem to be getting such short shrift?
That got us both to thinking, and to do an actual tally of the 100 or so papers and tutorials that were presented at the Conference. It turns out that only about 15% of the papers presented dealt specifically with safety management (by safety management, we mean hazard tracking, safety culture, management of change, safety review, etc.) or hazards assessment, whereas nearly 40% were technical. The tutorials showed what we would regard as a better proportion, with about half of them being concerned with organizational aspects of system safety.
There appears to be a rush to get through the hazards assessments so we can start using all that cool system safety software. And, once the analyst has gotten into the depths of the Markov diagram, there may be a reluctance to invest much time in the other end of the system safety process: hazards tracking and design/operational feedback. At least, that's what the relative proportions of the ISSC presentation categories seem to indicate. Certainly, the technical aspects of system safety are important, but undue emphasis on those can be problematic, as was pointed out in one of the tutorials. For example, when the software shows an event probability of 10-9, what it's really telling us is that something else is what's going to get us (as every system safety practitioner knows, or should know). Which brings us back to hazards assessment.
Hazards assessment is the foundation of any system safety activity. How to choose the best method, how to apply it correctly, and how to recognize one that hasn't been, should be given more visibility at our Conferences, in our opinion. Likewise, hazard tracking is critical. Many a good hazard assessment has been for naught because the hazard-control strategies didn't find their way into the final design and operational requirements of the system. Or, conversely, a control strategy has been made less effective by design changes made subsequent to the hazards assessment, unbeknownst to the analyst. These are both classic examples of organizational breakdowns. The organizational aspects of system safety, including examples of successful (and unsuccessful) hazard tracking, should also be given more emphasis at our Conferences, we think.
We suggest that the organizers of the 2007 ISSC consider using organizational management challenges of system safety as the theme for the Conference, or at least indicate their interest in papers addressing that aspect of system safety in the Call for Papers. We also suggest that the Executive Committee consider giving the management and organizational aspects of system safety more visibility in the Strategic Plan.
John Hinckley is the President and Larry Reising is a member of the Northwest Chapter of the System Safety Society.
|
