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.

There is surprisingly little guidance out there on what the ADC terms mean or how they are to be used. The definitions provided below are the ones that I use, but always check your client doesn’t have their own definitions that they have mandated in the contract. I will provide more context on how they are to be used later in the article:

Causes are the things that happen in our system, or to our system, that can lead to an unplanned event occurring. They can generally be categorised into one or more of the following categories:

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

My very first job out of university over 25 years ago was as a hazard workshop secretary where I spent five weeks in Seoul, followed by a further two weeks in Kuwait, recording a Hazard Log for a new oil refinery. Over the years since then I have created, managed, reviewed, and accepted hundreds of Hazard Logs. These have covered chemical plants, nuclear facilities, helicopters, satellite signalling, new trains, station upgrades, new timetables, new buses, and a whole range of other operations and infrastructure.

There is an ongoing debate in some circles of the Australian rail industry about whether the terms So Far As Is Reasonably Practicable (SFAIRP) and As Low As Reasonably Practicable (ALARP) mean the same thing or not. I am not sure where this idea came from, but there is some wording in the ONRSR guidance (which I will discuss below) and some now withdrawn guidance from TfNSW that may be the cause of this.