In Part 1 of this series of articles I mentioned that Hazard Logs have a tendency to become overpopulated with items that do not need to be there, or are recorded incorrectly.

One of the main causes for this is that a lot of people get confused when writing a hazard for a Hazard Log.  They're not sure what to put in, so they put everything in to be on the safe side. There’s a lot of guidance online but there no definitive requirement on how to do it, but this is approach I prefer to use.

Let me introduce the concept of a well-written hazard for a Hazard Log, which when done properly should always be a simple statement containing two parts.

Well-written hazard: An unplanned event that results in an unwanted outcome.

An unplanned event

What do I mean by this? Well, it’s probably easier to describe what a planned event is. As part of your design or construction process, you are already planning for a number of possible events.  We don’t need to repeat all of these requirements and design considerations in a Hazard Log.

If as part of a hazard identification workshop a failure mode is discussed, but the Duty Holders are satisfied that the risk is already planned for and is being appropriately managed (i.e. part of a documented process that will form part of the evidence for the final safety case), then that discussion should be recorded in the workshop minutes, but there’s no value duplicating the process by creating a hazard in the Hazard Log.

Example: We are running a Hazard Identification workshop on a Viaduct structure.  One of the guidewords is ‘earthquake’.  In the workshop the relevant designer confirms that the structure is being built to the relevant national standard as specified by Client.  This is therefore planned for and being appropriately managed, there is a competent engineer doing the design, and it will be documented in the design report.  This discussion should be recorded in the workshop minutes, but it does not make it into the Hazard Log as it is not an unplanned event.

An unplanned event could be something like a tree falling onto a road or railway line.  This isn’t planned for, we don’t design cars or trains to hit trees, but it does happen. This could be a valid entry in a Hazard Log as an unplanned event when it leads to a collision, we can then consider appropriate controls in the hazard review.

Exceeding a planned event

You can qualify a hazard to consider what would happen if an event went beyond the planned-for scope.  For example, in a tunnel we may have a hazard ‘significant fire that exceeds the design capacity of the ventilation system’.  In this case we have planned and designed for a fire event, but there may be a chance that the sheer scale of the fire or smoke exceeds the design capacity of the ventilation system.  You should only do this if there was a reasonably foreseeable cause of the large fire event.

An unwanted outcome

This is a Hazard Log, so the unwanted outcome would typically be a direct safety incident, or an operational incident that could have indirect safety impacts.  It may be appropriate to include environmental consequences or other types of harm if that is part of the agreed process.

The Hazard Log should not be used for risks that do not result in a safety incident or other agreed type of harm.  It should never be used for financial risks, program risk, or contractual disputes.

Things that aren't Hazards

Sometimes a good way of trying to build understanding of what something should be, is by giving examples of what it is not.  These next few examples are based on some common mistakes that I see regularly in Hazard Logs.  I will talk more about Causes and Consequences in Part #3 and Controls in Part #4.

Causes are not hazards

Is “strong winds” a Hazard? No.  It has the potential to be an unplanned event but it is not a hazard for the Hazard Log.

A well-written hazard would need to include an unwanted outcome e.g. “Strong winds while installing temporary structures leads to a collapse”

I think a lot of confusion here comes from the WHS approach to hazards, which are generally considered as unsafe conditions with potential for an incident to occur.  For example, a loose floor tile may be identified as a hazard in a workplace safety inspection, but when we’re talking hazard logs the loose floor tile would be the unplanned event which would lead to the unwanted outcome of someone tripping on it.

Consequences are not hazards

Is “fall from height” a hazard? No. It has the potential to be an unwanted outcome, but it is not a hazard for the Hazard Log.

A well-written hazard would need to include an unplanned event e.g. “Maintenance work near an unprotected edge results in a fall from height”.

Failed controls are not hazards

Is “Fire detection does not detect a fire” a hazard? No. It’s a failure of a specific control to mitigate a hazardous event (i.e. the fire) that has already occurred.

If fire is a genuine safety risk, then it should be included in the Hazard Log with appropriate fire detection identified as a critical control.  It is then up to the fire engineers to demonstrate that detection would be an effective control in their design reports. This does not make it a hazard though.

Telling professionals how to do their job is not a hazard

Is “Designer does not design properly” a hazard? No. It could be considered a potential cause in some circumstances, but generally it is one that is known and planned for, so it does not need to be in the Hazard Log.

We should have competent designers who know how to do their job following their organisation’s design processes. There will be additional checks and design approvals in place, but this is not a hazard.

Still not sure if it’s a Hazard?

Here are a couple of tests you can apply to help you decide if something is a hazard for your Hazard Log.

The ‘Transfer of Energy’ test

Hazards in a Hazard Log should always be potential events.  Every event can be considered in the context of a transfer of energy between one state to another. Here are some examples of what I mean:

• Worker falls from height – Potential energy becomes kinetic energy when the fall occurs
• Contact with live equipment – Electrical Energy transfers from a system to a person
• Exposure to hazardous substance – Chemical potential that could react with the human body
• Train derailment – Kinetic Energy changes direction from the planned path

If you can’t describe a transfer of energy between two states, then it probably isn’t a hazard

The ‘So what?’ test

If you are unsure whether a potential hazard needs to be included in the Hazard Log apply the ‘So What?’ test.

Ask yourself questions like: ‘So what’ am I expecting someone to do with this hazard?  Or: ‘So what’ would be done differently if this wasn’t in the Hazard Log.

Ask why the project is expending resources in writing this hazard and then the ongoing administration to manage it to closure.  If the answer does not relate to a hazard that needs to be actively managed via the Hazard Log to support the overall safety argument, then it probably shouldn’t be in there.

If the answer to your ‘So what?’ question is something like this, then it probably shouldn’t be in the Hazard Log.

• Let’s just put it there so we can keep track of it.
• There’s no-where else to put it.
• The Client wanted it in there.
• They won’t let me put it in the project risk register.

Sometimes It can be difficult to push back on Clients or Project Managers requests, but use these rules to help you manage an efficient Hazard Log.

Complex hazards should be analysed outside the Hazard Log

The rules above should cover most of the issues I see in poor quality Hazard Logs, but in some cases, there are very complex hazard scenarios with multiple and interrelated causes and different accident scenarios.

If you have one of these scenarios, don’t try and manage it in the Hazard Log. There are other specialist tools such a Fault & Event Tree Analysis, Bow-Tie Analysis, QRA, etc. that can be used for a detailed hazard analysis.

You can still refer to the top-level events in the Hazard Log, but instead of trying to overpopulate the data, refer to the detailed analysis and just record a summary of the outputs in the Log.

There’s always an exception

While this approach will apply to the vast majority of hazard logs, there are some specific cases where a different approach is needed.  These will tend to be highly complex systems such as software development for an advanced rail signalling system, in these cases the Hazard Log will likely take the form of an issues register to support the software and technology development process.  This is OK provided it is done intentionally, however the well-written hazard principles can still apply.

Takeaways

So here are my five takeaways, get these right and you won’t be far off the mark when it comes to writing hazards for the Hazard Log:

1. Only use well-written hazards: An unplanned event that results in an unwanted outcome.
2. Don’t include project risks that just relate to costs, delays, or contractual deliverables.
3. Don’t include hazards that are causes, consequences, or failed controls; and don’t create hazards to tell competent professionals how to do their job.
4. Analyse complex hazards using an appropriate tool.  Provide a summary only in the hazard log referencing the analysis and safety claim.
5. If you're still not sure, apply the 'Transfer of Energy Test' and the 'So What?' test.

Hazards should be well written and focused to make the Hazard Log an effective change management tool.

#ARCHArtifex #Assurance #HazardLog

This is part #2 of a series of articles in this series, so some of your questions will be answered in more detail later.  If you have any questions, you’d like answered in these then send me message.

Hazard Log #1 – Back to Basics

Hazard Log #2 – The Well Written Hazard (This Article)

Hazard Log #3 – Causes and Consequences

Hazard Log #4 – The Importance of Effective Controls

Hazard Log #5 – Managing Closure

Hazard Log #6 – Assumptions, Dependencies, & Constraints

Hazard Log #7 – General Guidance