In my series of articles on Hazard Logs I have covered a range of topics relating to the most important aspects of managing hazards and identified some of the frequent mistakes I see people making.

In this article there are some final tips and some updates based on the great feedback I have received.

As with any set of guidance or rules there will always be an exception which needs to be managed differently, but if you follow the principles in this series of articles you won’t go far wrong for the vast majority of applications.

A good Hazard Log should be a simple, efficient, and effective way for managing hazards as part of a safety case for a project and/or change.

Let’s get back to doing it properly.

Apply the ‘So What?' test

I spoke about the ‘So What?’ test in an earlier article, but it’s a really important principle that you should apply across all aspects of hazard management, especially where you find yourself in a situation where you’re not sure how to proceed with an issue.

This could occur where you have inherited the management of a Hazard Log from someone else and you don’t feel confident changing things.  First of all, go through the guidance provided in this series and make as many changes as you feel comfortable with (always recording the decision in the Journal).

If there are any items left, then simply ask ‘so what’ questions.  Start from the basis that if it doesn’t serve a purpose in line with this guidance, then it should be closed or deleted.  Then if you still have things open ask ‘so what’ am I expecting someone to do with this information?  If there’s a genuine reason to have it there, then make sure there is a specific action to manage it.  If not, then close or delete it.

For example: you’ve identified a hazard of an earth fault resulting in an electric shock.  As part of the hazard process, it was identified that additional earthing and bonding be installed.  This has been agreed by the designer and a requirement has been created to verify it has been implemented.  This hazard can be closed; however, some people may want to leave it open and transfer it to the Operator.  Ask the question ‘so what’ am I expecting the operator to do with this information? The answer is nothing, it is managed.  The earthing and bonding will be installed, identified on the drawings and the asset information will be handed over to the operator.  There’s no specific action for the operator, so there’s no point leaving this open.

Another type of Assumption – The Basis of Safety Claim

In Hazard Log article #5 I talked about Assumptions, Dependencies, and Constraints (ADCs) and some of the feedback I received is that there is another type of assumption that I did not cover.  These types of assumptions are different from those I referred to in the article and relate to assumptions about the organisational context, the current state of technology, or society.

These are effectively statements that are accurate now, but may change in the future, and if they do change may require the safety argument to be revisited.

The term I’ve used for these in the past is a Basis of Safety claim, they don’t need to be in your ADC register as they don’t need managing, but it’s good to record them in the safety reports and/or design reports.

For example: The onboard control system for a new train has been future proofed on the basis that the network owner’s strategy is for the current conventional signalling to be upgraded to CBTC in the life of the asset.  If the network owner decides to upgrade to ECTS instead of CBTC, then that basis of safety claim is no longer valid and the safety case for the onboard control systems would have to be revisited as part of any upgrades to support ETCS.

Write it so that someone else can read it

When writing a Hazard Log, always bear in mind that someone else may need to come along at a later date and be able to take over the management.  To do this they need to be able to read and make sense of the entries.  I have spent way too much time over my career trying to make sense of hazards that someone else has written, wasting time and effort managing something that probably didn’t need to be there.

Use the guidance in this series of articles, keep whatever you write concise and clear, and delete things that are no longer needed.  Keep a journal of when things were added, deleted, or changed and why.

A Hazard Log is a formal record of decisions made to manage safety.  It should always be written in such a way that it can be used as evidence in an investigation should an accident happen.

I do know of investigations into fatal incidents where the coroner, police, and regulators have gone through Hazard Logs looking for evidence of decisions that have been made.  The inability to find the record of a safety decision being made in a Hazard Log or other associated artefact will likely be taken as the absence of evidence of a reasonable decision being made and may be used to prosecute a duty holder for negligence resulting in fines, or even a prison custodial sentence.

Creating an Operational Risk Register

One of the questions I get asked is what to do with a Hazard Log at the end of a project.  A copy definitely needs to be retained as part of the asset information and this information needs to be kept such that it can be made available at a later point in time to view any decisions that were made in the project or ultimately as it may provide evidence in a court case.

Some projects may choose to retain the Hazard Log as a living document, this is often the case for rolling stock, or other assets, where very strict configuration control is required through the operational life of the asset.

Another option is to transform the contents of the Hazard Log into an Operational Risk Register that can be used to inform safety decision making throughout the operation and maintenance phase of the asset life cycle. Detailed Hazard Logs do not always readily transfer into an Operational Risk Register particularly where lots of ‘sub-hazards’ have been created that are in fact causes consequences or failures of controls.

There are many ways of creating an Operational Risk Register, for example by using a top-event approach, or by aligning risks to specific assets or operations. While the Hazard Log remains a project change specific document it is often useful to understand what the eventual operator and maintainer will use the information for, and it can sometimes be built into the hazard management process to make the final transfer much easier.  For example, by having clear asset categories assigned to the hazards in the Hazard Log, or by linking them to top events that will be used by the O&M.

There is no right or wrong way of doing this, and it is always best to consult as early as possible with the final operator and maintainer to work out what you can do to help them.

Keep it Simple

As my final thought, it’s very easy to create a poor-quality Hazard Log with hundreds of entries and more data than you can ever need.  But these aren’t efficient and end up having a massive burden on the project over the delivery lifecycle.

It takes a lot of up-front time and effort to create a simple and efficient Hazard Log that is fit for purpose and actually allows you to manage safety better than the poor-quality one.

A true master of their craft knows how to keep things simple, so please use the information in these articles to ensure that you, your team, and your organisation, are developing and using efficient and effective Hazard Logs.

Let’s get back to doing it properly.

Takeaways

So here are my final five takeaways, get these right and you won’t be far off the mark when it comes to managing a simple, efficient, and effective hazard log.

1. When working in the Hazard Log always ask ‘So What’ am I expecting someone else to do with this information.  If you can’t answer it, leave it out.
2. Basis of Safety claims should be recorded in your safety case and/or design reports.
3. Write the Hazard Log so that someone else can pick it up and manage it when you’re gone.
4. A Hazard Log can become an Operational Risk Register but needs to evolve. Ask you client if you can make it easier for them.
5. It's easy to create a large Hazard Log that is full of data.  It takes real skill to prepare a short and efficient Hazard Log with only the key information.

Hopefully this series of articles can help you understand the purpose of a Hazard Log, how to make the most of it and more importantly what not to do.

This is part #8 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 a message.

Hazard Log #1 – Back to Basics

Hazard Log #2 – The Well Written Hazard

Hazard Log #3 – Causes and Consequences

Hazard Log #4 – The Importance of Effective Controls

Hazard Log #5 – Assumptions, Dependencies, & Constraints

Hazard Log #6 – Managing Hazards to Closure

Hazard Log #7 – Stop Transferring Hazards

Hazard Log #8 - General Guidance (This Article)

Hazard Log #9 - Running an effective Hazard Identification Workshop