Hazard Logs #6 - Managing Hazards to Closure

This article was written by Andy Petrie , Director Systems & Safety Assurance

Throughout this series of articles, I have continued to emphasise that a Hazard Log is a management tool and as a record of decisions.? If you stick to this basic premise, then closing hazards becomes a relatively straightforward task.??

What often happens is that Hazard Logs sometimes morph into something different, either intentionally or by accident, and that simple process becomes an overly complex nightmare.

When Hazard Logs are set up as part of a complex set of interlinked processes you can find yourself trying to close out interdependent actions or even circular arguments. ?As I explain below the best Hazard Logs are simple Hazard Logs, where you use a process to close hazards out progressively, so that you do not find yourself in a Gordian knot at the end of a project.

Another common issue I see with Hazard Logs, is that some people view them as the de-facto project safety case that must include comprehensive details of every safety issue and every decision made.? This approach makes it very difficult to close hazards out but adds no value to a properly structured assurance argument.

There is ultimately no right or wrong way of doing this, the way you decide to set things up should be best for your project, provided that it achieves the outcome of demonstrating that safety has been managed.? The guidance in this article is my preferred approach and presents a simple way of doing things that will achieve that goal.?

How a Hazard Log supports the Safety Case

A Hazard Log on its own is not the Safety Case, but it is one of the many pieces of evidence that forms the Safety Case.?

Most projects require multiple processes in place for the management of the assurance activities, and these all need to be presented together as key parts of the Safety Case.

A Safety Case brings together all of the relevant information from a project that is needed to support the primary safety argument that the asset and/or operation will be safe.?

They can be called many things (e.g. Assurance Report, Assurance Statement, Assurance Case, Case for Safety, etc.), but all achieve the same intent.? A project can have many Safety Cases at different stages, for example it is common to have a Safety Case at Final Design and one at Completion.

The example below is not exhaustive, but provided for context only.? In this project we have decided to manage our primary assurance processes in four separate management tools.

1. Safety Risks are managed in the Hazard Log
2. Assumptions Dependencies and Constraints are managed in the ADC Register
3. Human Factors is managed in the HF Issues Register (HFIR); and
4. Requirements are managed in the Requirements Verification and Traceability Matrix (RVTM).?????

Together these make up the assurance evidence for the Safety Case as shown in the diagram below.?

For this example Safety Case to be valid, all these supporting artefacts must be closed.? At the point that this Safety Case is written, it does not matter in which of the four registers the issue has been recorded as managed, provided that it has been managed in one of them and that can be demonstrated.

When I say that you only need to manage an issue in one place and do not need to trace it through multiple registers, this is why.?? At the point the Safety Case is written the issue must be closed, so where it has been closed is not relevant.

One of the counter arguments I hear a lot, relates to what to do if an issue is not closed when writing the Safety Case? This is a valid point, and it does happen, for example with a Safety Case requesting conditional approval pending final closure of some items, where we need to know what the safety risk of those open items is.?

The answer however is very simple, in the Safety Case you simply highlight the open items and identify the hazards that it relates to.? Instead of having an ongoing administrative burden throughout the project, managing issues in multiple places, you simply trace any open issues by exception at the Safety Case stage when there should only be a small number, if any, to deal with.?

If you set up your processes properly at the start of a project, use either a relationship database or simple cross referencing in Excel, then at the Safety Case stage you are simply running a report on any open issues and providing all the linked items that are relevant.

Like all my articles, the trick here is to keep it simple, there is no need to make things complicated. Spend some time up front and it will pay dividends throughout delivery.

Hazard closure means the hazard is managed

When you mark a hazard as Closed in the Hazard Log, the hazard does not go away, it simply means that the relevant actions are managed, and the hazard is therefore managed. ??

A hazard can be marked as closed in the Hazard Log provided the action can be traced to another register where it is being actively managed.? ??As noted above, there is no benefit from keeping issues open in multiple registers, all this does is increase the administrative burden.?

I have seen situations where staff are trying to manage hundreds of interrelated issues in multiple registers, this can result in a negative safety impact as key issues get lost in the sheer number of items and circular arguments can get missed.?

The Hazard Log is there to ensure that issues that need to be actively managed are being actively managed.? Once an issue requiring active management has been addressed, there is no need to spend further time and effort on it and it should be closed.? ?

A closed hazard still exists in the Hazard Log and can be re-opened if the issue does not get addressed, but do this only when needed, don’t set up a burdensome process based on managing exceptions.

Set your framework and processes up correctly and this can be a simple task.? If you get challenged by a Client or ISA stating ‘I expect everything should be in the Hazard Log!’ you have a simple response of ‘your personal opinion is noted, but we are following our approved processes’.

The Hazard Log is a record of activities

The Hazard Log is a record of activities, not the activities themselves.? When we note that an item is Closed in the Hazard Log, we are actually saying one of two things:

1. That the specific action has been undertaken (i.e. the design has been changed, the control has been added, etc.) and providing a reference to the evidence that this has been done; or
2. The specific action has been transferred to a more appropriate management register and providing a reference as to where it can be found.

In the second case we are not saying here that an individual action has necessarily been closed, but that it is now under active management elsewhere in a more appropriate place and that the evidence will be provided in the Safety Case. As noted above, an issue does not need to be actively managed in two places and it should be closed in the Hazard Log.

Examples

Options for managing an issue

You don’t actually manage any issues in a Hazard Log.? The Hazard Log is a record that issues have been managed. ??

Take an example where we have identified a human factor issue to close a hazard, you can either:

1. Record the management of the issue directly it the Hazard Log, in which case you document the issues as closed once the evidence has been provided that it is done or agreed; or
2. You manage it in a Human Factors Issues Register.? In this case you can provide a reference, or link, to the HFIR and mark it as closed in the Hazard Log.

In the second case the HFIR must form part of the Safety Case.

Closing a Hazard

A hazard in the Hazard Log may well have a few specific management activities associated with it.? Once those activities are managed, the hazard can be closed:

In this example a hazard has three issues that need to be managed to support the introduction of a new alarm, these are options of how they could be closed:

1. Implement new alarm – Closed, this has been included in the design [Design Report Ref.] and included in the RVTM [Requirement Ref.]
2. Control Interface to be updated to prioritise alarm – Closed, this has been transferred to the HFIR [Issue Ref.]
3. O&M to train their staff on alarm prioritisation – Closed, this has been transferred to the ADC register [Dependency Ref.]

In this example, all three issues are adequately managed, and a reference is provided to where the evidence will be found in the Safety Case.? This hazard should now be Closed in the Hazard Log.

Closing Controls

The best way to close a potential control is by implementing it, providing a reference to where it can be found in the design documentation, and then how it’s implementation can be tracked using the requirements and V&V process.

Sometimes a potential control is identified but is not yet agreed, this should be recorded in the Hazard Log.? Upon further review, the control may not be implemented, in this case an explanation would need to be provided as to why the control was determined not to be reasonably practicable to implement.? The record in the Hazard Log could be:

1. A short explanation providing a clarification, (e.g. Reference to a Standard)
2. A reference to a meeting or specific decision that is on the record, or
3. A reference to a specific risk assessment document.

It is crucial to the safety assurance argument that where a potential control has been rejected, that there is a record of the decision and the reason.

At the end of a project stage all hazards should be closed

A Hazard Log is generally created to manage a change.? Once the change is finished, all hazards in the Hazard Log should be closed.? This does not mean that the hazards have gone away, just that they are managed.? These hazards then transfer with the asset or operation to the next stage in the lifecycle.? The next Duty Holder may maintain the Hazard Log as an ongoing risk register if they so choose, but that is a decision for them.

As noted earlier, there may still be some outstanding issues at the end of the project stage, for example some of the specific issues regarding operation and maintenance may not yet be finalised as the asset is handed over.?

The best place to manage these issues is in the ADC Register, so the hazard in the Hazard Log could still be shown as closed (i.e. managed) but the safety case would identify the open ADCs and reference the associated hazard(s). ??

The ultimate Client may request that this is presented differently but it is a relatively simple task to manage these by exception at the Final Safety Case stage.

Takeaways

So here are my five takeaways, get these right and you won’t be far off the mark when it comes to managing a Hazard log to closure:

1. The Hazard Log is a management tool that forms part of the Safety Case.
2. The Hazard Log can refer out to other artefacts that form part of the Safety Case, it does not need to include everything.
3. Issues aren’t actually managed in the Hazard Log, the Hazard Log is a record of how they are managed.
4. Close hazards progressively when they are adequately managed.
5. All hazards should be closed at the end of the project.? By exception, any hazard or issue that is still open should be reported in the Safety Case.

A Hazard Log is a tool for you to use to record the process, it should not be dictating the process. Once it has done it’s job, close it.

#ARCHArtifex #Assurance #HazardLog

This is part #6 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 (This Article)

Hazard Log #7 – General Guidance

Hazard Log #8 - Running an effective Hazard Identification Workshop

#ARCHArtifex #ARCHSESA #Assurance #HazardLog