Hazard Logs #7 - Stop Transferring Hazards

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

I did not intend to write this as a standalone topic, however there is enough content here to warrant its own article, especially as I see the use of ‘Hazard Transfers’ seems to be permeating throughout the industry.? ?For me, the very principle of ‘Hazard Transfers’ not only goes against the fundamentals of safety legislation, but it also introduces unnecessary risks to effective project delivery.

If you haven’t yet read my article on Duty Holders I would recommend that you do that first, as a lot of the concepts I discuss in this article are explained there.? In this article I also use the term Asset in the broader meaning of something that provides value to the business (e.g. a timetable), not just physical assets.

Hazards are always associated with an Asset

Hazards aren’t real things; they don’t physically exist.? A Hazard is just a potential failure mode of an Asset, or in the use of the Asset.? A Hazard is therefore a property of the Asset itself and we only consider it in relation to the Asset.?

Assets are real things, as such there is always a party with responsibility for the Assets.? The responsible party can change, usually with a change in the lifecycle stage (i.e. plan, design, build, O&M, dispose), or through a change to contracted scope within a lifecycle stage. ?Under legislation, the party responsible for the Asset at any given stage is known as the Duty Holder.?

Within the legislation Duty Holders with responsibility for a lifecycle stage, or an activity within that stage, have a duty to ensure safety So Far As Is Reasonably Practicable (SFAIRP).?

As Hazards are always associated with an Asset, therefore the Duty Holder that has responsibility for the Asset also has responsibility for the associated Hazards.

Why you can’t transfer Hazards within a Lifecycle Stage

A Hazard will always be associated with an Asset, and there will always be a party responsible for that Asset (i.e. the Duty Holder).

The Duty Holder responsible for the Asset is therefore responsible for the Hazard.? You cannot transfer a Hazard that you are responsible for, and if it was not your Hazard in the first place then you cannot transfer it.

The only exception to this is if there is a change in a Duty Holder’s contracted scope when the responsibility for the Asset transfers to another Duty Holder.? The relevant Hazards would be provided as part of the Asset Information that accompanies the Asset transfer.? The transfer of Asset Information becomes a simple matter of fact and would not need a ‘Hazard Transfer’.

Interface Hazards

Interface hazards do exist where there can be a shared accountability (e.g. Wheel Rail Interface, Platform Train Interface, etc.) but the respective contribution to these Hazards remains with the relevant Duty Holder but they both have an additional duty to cooperate in managing the Hazard. These are generally managed as Interface Hazards, but this is not a ‘Hazard Transfer’.

How did we get here?

I think that this problem has emanated from people trying to be genuinely helpful and wanting to make sure other parties are aware of their respective Hazards.? But it has evolved into yet another bureaucratic nightmare that people can’t seem to wake from.

We get situations where during the Hazard Identification workshop, a party has identified a Hazard that is not in their scope.? They then enter them in their Hazard Log and find that they can’t manage them, so then they go through a process of trying to transfer them to another Duty Holder.? All this is doing is creating paperwork.? There is no obligation for a second Duty Holder to accept a ‘Hazard Transfer’, and they often don’t. You’re then stuck in the situation of having orphan hazards in you Hazard Log with no way of managing them to closure.

So what should I be doing?

The best way to manage this is at the Hazard Identification workshop where the discussion about the Hazard is recorded in the minutes, but simply noted as out of scope. ??The workshop minutes are available to all participants as a source of information for their own Hazard Logs.

If the issue is something new and novel, or you think the appropriate Duty Holder may have missed it in their Hazard Identification process, then feel free to advise them of the potential Hazard for their consideration.? But that is all you are doing, providing advice.? They have no duty to acknowledge or respond to your communication, and you should certainly not build this into your process.

If a Hazard does inadvertently find its way into a Hazard Log and it’s found to be outside of the Duty Holder’s scope, then it should be deleted, with a record in the journal of the decision and the reason why. Again, feel free to advise the other party, but you are under no obligation to do so.

Even if some of your current project scope is removed from your deliverables and given to another party, all you would do is handover that relevant part of the Hazard Log for their information. What the other Duty Holder does with those hazards is up to them.??

Why you shouldn’t transfer Hazards at the end of a Lifecycle Stage

At the end of a lifecycle stage there is often the need to transfer the responsibility for an Asset between Duty Holders; but remember that the Hazards are just properties of the Asset and form part of the Asset Information for the transferred Asset.

The Duties for the earlier lifecycle stage remain with the first Duty Holder, the duties do not transfer with the Asset.? For example, the duty to ensure an Asset is designed safe SFAIRP does not get transferred to the party building the Asset, they have their own new duty to ensure that the Asset is built safe SFAIRP.? The same applies to the transition between the Builder and the Operator and/or Maintainer.

The next Duty Holder has no obligation to adopt the previous Hazard Log or manage the Hazards in the same way as the previous party.

Requiring the next Duty Holder to formally accept a Hazard is therefore irrelevant, as those Hazards remain a property of the Asset regardless of whether they are accepted or not. ?While adding no practical value to the assurance process, it does add significant paperwork, extra bureaucracy, and does introduce two significant risks.

Blurring of duties

The duty in legislation to ensure that safety is managed SFAIRP relates to the specific Duty Holder, but by requiring the next Duty Holder to formally accept Hazards, they are also formally accepting the risk assessment and SFAIRP claim, and in doing so taking on some of the liabilities on behalf of the first Duty Holder.

This is a great outcome for the first Duty Holder as they are in effect getting a formal acceptance of their safe SFAIRP claim by the next Duty Holder.? This may sound like semantics, but in a court case it would carry a lot of weight for a Designer to state the risk assessment and SFAIRP claim for a Hazard had been formally accepted by the Builder and/or the O&M.

Project Delays

Another consideration here is to recognise the role of the Client in the management of the contracts.? Take an example where the party building the Asset and the party operating the Asset are both under contract to the Client organisation, as such there is no contractual relationship between the Builder and the Operator.?

At the end of the lifecycle stage the Assets are actually being handed back from the Builder to the Client under the terms of the contract, the Client then transfers the Assets on to the Operator.? ?This may be nothing more than a signature on a piece of paper, but it is the Client who receives the Assets from the Builder.

As the Operator has no contractual relationship with the Builder, they therefore have no obligation to accept Hazards.? They can then use this to demand changes to the Assets before they will accept the ‘Hazard Transfers’.? This will usually occur at the end of a project and can result in delays and additional cost as the Builder cannot complete their works until the Operator is happy.

So what should I be doing?

While you should not be transferring Hazards, you do have a duty to consult with your stakeholders, including any future Duty Holders.? Make sure you have shared the Hazard Log for information and allowed plenty of opportunities for feedback and discussion.

As a Duty Holder you are responsible for ensuring safety SFAIRP and you are under no obligation to act on feedback from the next Duty Holder.? If you choose not to act on feedback, then always keep a record as to why you made this decision.?

There will be occasions where there may be a disagreement such that a future Duty Holder wants a control that you do not consider to be reasonably practicable.? These issues should be escalated to the Client at the earliest opportunity for resolution through the contract, not managed through the Hazard Log.

Why you should never accept a ‘transferred’ Hazard

As described above, as a Duty Holder you have no requirement to ‘Accept’ a Hazard from another party.?

For their records it would be good practice to provide an acknowledgement, but I would strongly recommend that you never formally accept a Hazard from another Duty Holder, or formally approve any risk assessment for that matter.

By ‘Accepting a Hazard’ you are in effect approving another duty holders safe SFAIRP argument and accepting some of the risk liability if something goes wrong.?? Anything that is passed from another party should be treat as advisory only and used to inform your process.

No, you can’t transfer Controls Either

Formal transfer of Controls seems to have become a thing too, and it does not make any sense for the same reasons as described above.? As a Duty Holder you are either responsible for a Control or you’re not, it’s black and white.

As a Duty Holder you may identify what you consider to be a reasonably practicable Control that needs to be implemented by another party.? If this is the case, then you need to agree that Control with the other party.? This may sound like a trivial difference, but there is an important legal distinction here. ??

Often this is quite simple and can refer to an existing procedure or acknowledge that Control will be implemented and provide a record that they have agreed to it, for example in the workshop minutes or the Hazard Log journal.?

Where you cannot get an immediate agreement and a specific management activity needs to be undertaken to agree a Control then the best place to manage this is usually in the Assumptions, Dependencies, and Constraints (ADC) Register.? This becomes very important when the designer believes that a critical O&M Control is required, but the O&M provider does not agree to it, and that may need the design to be changed or the Client to intervene.

Alternatively, if you are getting to the end of the project and preparing the Safety Case when a Control that has been agreed in principle, but is not yet implemented, then you can also manage this in the ADC Register.

Remember that Controls are the responsibility of the relevant Duty holder.? To transfer something, you must own it first.? A Designer cannot own O&M Controls and can only agree them with the O&M Duty Holder or manage them in an ADC register until an O&M Duty Holder is appointed.

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. Hazards are properties of the Asset, the responsibility for the Hazard is therefore with the Duty Holder responsible for the Asset.
2. Assets can transfer between Duty Holders, the associated Hazards form part of the transfer of the Asset Information.? You cannot transfer a Hazard without a transfer of the Asset.
3. Formally accepting a Transferred Hazard at a change in a lifecycle stage means that you have implicitly accepted the risk assessment and SFAIRP claim from the previous Duty Holder, along with part of the liabilities for their duty.
4. You can’t transfer controls between Duty Holders, you need to agree the controls with the other parties.
5. Remember the Hazard Log is a formal record of decisions and may be used as evidence in a formal investigation.

Responsibility for Hazards and Controls lies with the respective Duty Holder and can not be transferred. I know a lot of projects use this process so I would highly recommend that you review it ASAP.

?#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

Hazard Log #7 – Stop Transferring Hazards (This Article)

Hazard Log #8 - General Guidance

Hazard Log #9 - Running an effective Hazard Identification Workshop

#ARCHArtifex #ARCHSESA #Assurance #HazardLog