Blog Safety Management

What Have Hazard Logs Ever Done for Us?

“What Have Hazard Logs Ever Done for Us? Well, there’s the aqueduct…” Monty Python’s Flying Circus may not be an obvious connection to hazard management, but it works! Hazard Logs – or Hazard Tracking Systems (HTS), which is a better term – are underappreciated but vital tools.

In this webinar on hazard logs, one of the topics that I will be covering is what a ‘full-function’ HTS can do. By that, I mean a purpose-built database, rather than just a spreadsheet. So here is a taster of the benefits, derived from my 25+ years of experience on system safety programs, large and small.

Key Elements of a Hazard Log

An HTS pulls together key safety data about:

  • Accidents: ‘An unintended event, or sequence of events, that causes harm’;
  • Accident Sequences: ‘The progression of events that results in an accident’;
  • Causes: that may lead to a hazard;
  • Controls (or mitigations): ‘A measure that, when implemented, reduces risk.’; and, of course
  • Hazards: ‘A physical situation or state of a system, often following from some initiating event, that may lead to an accident’.
Accident Sequence
Accident Sequence

Understanding how causes lead to hazards, and hazards lead to consequences, which may include (harmful) accidents, is fundamental to understanding accident sequences. This in turn helps us to understand the mechanisms that lead to harm – and defeat them.

Managing Many-to-Many Connections

A Hazard Log doesn’t just store data elements, it links those data together meaningfully to make information. A relational database does this by allowing us to make many-to-many connections between different classes of data.

Humorous illustration of linkages between data types in a Hazard Log or HTS
Hazard Log Connections

This allows us to do a lot of useful things. We’ve already mentioned understanding the mechanisms behind accident sequences. This allows us to design or select effective controls to interrupt the accident sequences and prevent harm.

Discovering Pathways to Harm

Understanding these links also enables us to see connections, for example between causes and accidents, which we had not seen before. This is important, as many severe accidents arise from unanticipated pathways to harm, perhaps in very specific circumstances. (For example, not shutting the bow doors of a ferry properly led to the flooding and capsizing of the Herald of Free Enterprise, killing 193 people.)

Change Impact Analysis

Understanding these connections also allows us to perform safety change impact analysis (‘the analysis of changes within a deployed product or application and their potential consequences’). In many programs I worked on, in-use incidents revealed that:

  • Designs were not working as intended;
  • Hazard controls were not as effective as thought;
  • Work done was not as designed; or that
  • The actual use of a system was not as foreseen.

If we know the links to something that has changed – what it affects / what affects it – then we can begin to estimate the impact. From experience, this occupies a lot of our time in in-service safety management.

Recovery and Improvement

In the real world things rarely stand still. There are usually many different stimuli for change (we’ve already mentioned our incidents/accidents). Our enterprise might have to raise its game for several reasons:

  • The Regulator demanding change or improvement;
  • Customers asking for more performance or more assurance;
  • The public reaction to incidents elsewhere in the market;
  • New technology or new competitors in our industry; or
  • Our commitment to continuous improvement.

Pareto analysis tells us that a minority of causes tend to dominate the effect. Thus, a small number of causes or initiating events drive the occurrence of hazards. Similarly, a minority of hazards will dominate incident and/or accident statistics.

We may know this from experience or analysis of our specific system, or we may have only generic data. It doesn’t matter.

Using these insights, we can use the linkages in the HTS to target particular causes, events, conditions, scenarios, hazards, etc. We identify the set that (should) make the biggest impact, the biggest difference. We can then rank the contributors in order of importance and tackle them.

Again, long and sometimes bitter experience tells me that safety practitioners will spend a lot of time doing this. Reacting to stimuli is a big part of safety management.

The Tool Supports the Process

Of course, we should be using tools to support the process. (The process is designed to produce the results or outcomes that we need). One example of such is the Risk Assessment process from ISO 31000, below.

Shows the elements, progression and cycle of the Risk Assessment Process from ISO 31000
The Risk Assessment Process

We want our HTS to support this process, storing the data that we get from the risk identification, analysis, and evaluation activities. We also want our Hazard Log to provide information that enables communication and consultation as well as monitoring and review (perhaps using a risk matrix).

Other Functions

Hazard Logs and HTS also perform many other functions. These may appear mundane, but when they go wrong they suddenly become very exciting! What Have Hazard Logs Ever Done for Us? They help us avoid these unwanted excitements, by providing:

Questions? Comments? Send me your feedback in the comments, below.

My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

Leave a Reply

Your email address will not be published. Required fields are marked *