Categories
Blog Safety Management

Risk Management 101

Welcome to Risk Management 101, where we’re going to go through these basic concepts of risk management. We’re going to break it down into the constituent parts and then we’re going to build it up again and show you how it’s done. I’ve been involved in risk management, in project risk management, safety risk management, etc., for a long, long time.  I hope that I can put my experience to good use, helping you in whatever you want to do with this information.

Maybe you’re getting an interview. Maybe you want to learn some basics and decide whether you want to know more about risk management or not.  Whatever it might be, I think you’ll find this short session really useful. I hope you enjoy it and thanks for watching.

Welcome to Risk Management 101, where we’re going to…

You can get the RM101 Course as part of the FREE Triple Learning Bundle.

Risk Management 101, Topics

  • Hazard Identification;
  • Hazard Analysis;
  • Risk Estimation;
  • Risk [and ALARP] Evaluation;
  • Risk Reduction; and
  • Risk Acceptance.

Risk Management 101, Transcript

Introduction

Hi everyone and welcome to Risk Management 101. We’re going to go through these basic concepts of risk management. We’re going to break it down into the constituent parts. Then we’re going to build it up again and show you how it’s done.

My name is Simon Di Nucci and I have a lot of experience working in risk management, project risk management, safety risk management, etc.  I’m hoping that I can put my experience to good use, helping you in whatever you want to do with this information. Whether you’re going for an interview or you want to learn some basics. You can watch this video and decide if you want to know more about risk management or if you don’t need to.  Whatever it might be, you’ll find this short session useful. I hope you enjoy it and thanks for watching.

Topics For This Session

Risk Management 101. So what does it all mean? We’re going to break risk management down into we’ve got six constituent parts. I’m using a particular standard that breaks it down this way. Other standards will do this in different ways. We’ll talk about that later. Here we’ve got risk management broken down into; hazard identification, hazard analysis, risk estimation, risk evaluation (and ALARP), risk reduction, and risk acceptance.

Risk Management

Let’s get right on to that. Risk management – what is it? It’s defined as “the systematic application of management policies, procedures, and practices to the tasks of hazard identification, hazard analysis, risk estimation, risk and ALARP evaluation, risk reduction, and risk acceptance”.

There are a couple of things to note here. We’re talking about management policies, procedures, and practices. The ‘how’ we do it. Whether it’s a high-level policy or low-level common practice. E.g. how things are done in our organization vs how the day-to-day tasks are done? And it’s also worth saying that when we talk about ‘hazards’, that’s a safety ‘ism’. If we were doing security risk management, we could be talking about ‘threats’. We can also be talking about ‘causes’ in day-to-day language. So, we can be talking about something causing a risk or leading to a risk. More on that later, but that’s an overview of what risk management is.

Part 1

Let’s look at it in a different way. For those of you who like a visual representation, here is a graph of the hierarchical breakdown. They need to happen in order, more or less, left to right. And as you can see, there’s a link between risk evaluation and risk reduction. We’ll come on to that. So, it’s not ‘or’ it’s a serial ‘this is what you have to do’. Sometimes they’re linked together more intimately.

Hazard Identification

First of all, hazard identification. So, this is the process where we identify and list hazards and accidents associated with the system. You may notice that some words here are in bold. Where a word is in bold, we are going to give the definition of what it is later.

These hazards could lead to an accident but are only associated with the system. That’s the scope. If we were talking about a system that was an airplane, a ship, or a computer, we would have a very different scope. There would also be a different way that maybe accidents would happen.

On a more practical level, how do we do hazard identification? I’m not going to go into any depth here, but there are certain classic ones. We can consult with our workers and inspect the workplace where they’re operating. In some countries, that’s a legal requirement (Including in Australia where I live). Another option is looking at historical data. And indeed, in some countries and in some industries, that’s a requirement. A requirement means we have to do that. And we can use special analysis techniques. Now, I’m not going to talk about any of those analysis techniques today. You can watch some other sessions on The Safety Artisan to see that.

Hazard Analysis

Having done hazard identification, we’ve asked ourselves ‘What could go wrong?’. We can put some more detail on and ask, ‘How could it go wrong? And how often?’. That kind of stuff. So, we want to go into more detail about the hazards and accidents associated with this particular system. And that will help us to define some accident sequences. We can start with something that creates a hazard and then the hazard may lead to an accident. And that’s what we’re talking about. Later, we will show that using graphics can be helpful.

But again, more on terminology. In different industries, we call it different things. We tend to say ‘accident’ in the UK and Australia. In the U.S., they might call it a ‘mishap’, which is trying to get away from the idea that something was accidental. Nobody meant it to happen. Mishap is a more generic term that avoids that implication. We also talk about ‘losses’ or we talk about ‘breaches’ in the security world. We have some issues where somebody has been able to get in somewhere that they should not. And we can talk about accident sequences. Or, in a more common language, we call it a sequence of events. That’s all it is.

Risk Estimation

Now we’re talking about the risk estimation. We’ve thought about our hazards and accidents and how they might progress from one to another. Let’s think about, ‘How big is the risk of this actually happening?’. Again, we’ll unpack this further later at the next level. But for now, we’re going to talk about the systematic use of available information. Systematic- so, ordered. We’re following a process. This isn’t somebody on their own taking a subjective view ‘Look, I think it’s not that’. It’s a process that is repeatable. We want to do something systematic. It’s thorough, it’s repeatable, and so it’s defendable. We can justify the conclusions that we’ve come to because we’ve done it with some rigour. We’ve done it in a systematic way. That’s important. Particularly if we’re talking about harm coming to people or big losses.

Risk and ALARP / SFARP Evaluation

Now, risk evaluation is just taking that estimated risk just now and comparing it to something and saying, “How serious is this risk?”. Is it something that is very low? If it’s very insignificant then we’re not bothered about it. We can live with it. We can accept it. Or is it bigger than that? Do we need to do something more about it? Again, we want to be systematic. We want to determine whether risk reduction is necessary. Is this acceptable as it is or is it too high and we need to reduce it? That’s the core of risk evaluation.

Tolerability

In this UK-based standard – we’re using terminology is found in different forms around the world. But in the UK, they talk about ‘tolerability’. We’re talking about the absolute level of risk. There probably is an upper limit that’s allowed in the law or in our industry. And there’s a lower limit that we’re aiming for. In an ideal world, we’d like all our risks to be low-level risks. That would be terrific.

So, that’s ‘tolerability’. And you might hear it called different things. And then within the UK system, there are three classes of ‘tolerability’ at risk. We could say it’s either ‘broadly acceptable’- it’s very low. It’s down in the target region where we like to get all our risks. It’s ‘tolerable’- we can expose people to this risk or we can live with this risk, but only if we’ve met certain other criteria. And then there’s the risk that it’s so big. It’s so far up there, that we can’t do that. We can’t have that under any circumstances. It’s unacceptable. You can imagine a traffic light system where we have categorized our risk.

ALARP / SFARP

And then there’s the test of whether our risk can be accepted in the UK. It’s called ALARP. We reduce the risk As Low As Reasonably Practicable. And in other places, you’ll see SFARP. We’ve eliminated or minimized the risk So Far As Is Reasonably Practicable. In the nuclear industry, they talk about ALARA: As Low As Reasonably Achievable. And then different laws use different tests. Whichever one you use, there’s a test that we have to say, “Can we accept the risk?” “Have we done enough risk reduction?”. And whatever you’ve put in those square brackets, that’s the test that you’re using. And that will vary from jurisdiction to jurisdiction. The basic concept of risk evaluation is estimating the level of risk. Then compare it to some standard or some regulation. Whatever it might be, that’s what we do. That’s risk evaluation.

Risk Reduction

We’ve asked, “Do we need to reduce risk further?”. And if we do, we need to do some risk reduction. Again, we’re being systematic. This is not some subjective thing where we go “I have done some stuff, it’ll be alright. That’s enough.”. We’re being a bit more rigorous than that. We’ve got a systematic process for reducing risk. And in many parts of the world, we’re directed to do things in a certain way.

Elimination

This is an illustration from an Australian regulation. In this regulation, we’re aiming to eliminate risk. We want to start with the most effective risk reduction measures. Elimination is “We’ve reduced the risk to zero”. That would be lovely if we could do that but we can’t always do that.

Substitution

What’s the next level? We could get rid of this risk by substituting something less risky. Imagine we’ve got a combustion engine powering something. The combustion engine needs flammable fuel and it produces toxic fumes. It could release carbon monoxide and CO2 and other things that we don’t want. We ask, “Can we get rid of that?”. Could we have an electric motor and have a battery instead? That might be a lot safer than the combustion engine. That is a substitution. There are still risks with electricity. But by doing this we’ve substituted something risky for something less risky.

Isolation

Or we could isolate the hazard. Let’s use the combustion engine as an example again. We can say, “I’ll put that in the fuel and the exhaust somewhere, a long way from people”. Then it’ll be a long way from where it can do harm or cause a loss.” And that’s another way of dealing with it.

Engineering Controls

Or we could say, “I’m going to reduce the risks through engineering controls”. We could put in something engineered. For example, we can put in a smoke detector. A very simple, therefore highly reliable, device. It’s certainly more reliable than a human. You can install one that can detect some noxious gases. It’s also good if it’s a carbon monoxide detector. Humans cannot detect carbon monoxide at all. (Except if you’ve got carbon monoxide poisoning, you’ll know about it. Carbon monoxide poisoning gives you terrible headaches and other symptoms.) But of course, that’s not a good way to detect that you’re breathing in poisonous gas. We do not want to do it that way.

So, we can have an engineering control to protect people. Or we can use an interlock. We can isolate things in a building or behind a wall or whatever. And if somebody opens the door, then that forces the thing to cut out so it’s no longer dangerous. There are different things for engineering controls that we can introduce. They do not rely on people. They work regardless of what any person does.

Administrative / Procedural Controls

Next on the list, we could reduce exposure to the hazard by using administrative controls. That’s giving somebody some rules to follow a procedure. “Do this. Don’t do that.” Now, that’s all good. We can give people warning signs and warn people not to approach something. But, of course, sometimes people break the rules for good reasons. Maybe they don’t understand. Or, maybe they don’t know the danger. Perhaps they’ve got to do something or maybe the procedure that we’ve given them doesn’t work very well. It’s too difficult to get the job done, so people cut corners. So, procedural protection can be weak. And a bit hit-and-miss sometimes.

Personal Protective Equipment

Finally, we can give people personal protective equipment. We can give them some eye protection. I’m wearing glasses because I’m short-sighted. But you can get some goggles to protect your eyes from damage. Damage like splashes, flying fragments, sparks, etc. We can have a hard hat so that if we’re on a building site and something drops from above on us that protects the old brain box.

It won’t stop the accident from happening, but it will help reduce the severity of the accident. That’s the least effective. We’re doing nothing to prevent the accident from happening. We’re reducing the severity in certain circumstances. For example, if you drop a ton of bricks on me, it doesn’t matter whether I’m wearing a hard hat or not. I’m still going to get crushed. But with one brick, I should be able to survive that if I’m wearing a hard hat.

Risk Acceptance

Let’s move on to risk acceptance. At some stage, if we have reduced the risk to a point where we can accept it. That is, we can live with it and we’ve decided that we’re going to need to do whatever it is that is exposing us to the risk. We need to use the system. For example, we want to get in our car to enable us to go from A to B quickly and independently. So, we’re going to accept the risk of driving in our car. We’ve decided we’re going to do that. We make risk-acceptance decisions every day, often without thinking about it. We get in a car every day on average and we don’t worry about the risk, but it’s always there. We’ve just decided to accept it.

But in this example, it’s not an individual deciding to do something on the spur of the moment. Nor is it based on personal experience. We’ve got a systematic process where a bunch of people come together. The relevant stakeholders agree that a risk has been assessed or has been estimated and has been evaluated. They agree that the risk reduction is good enough and that we will accept that risk. There’s a bit more to it than you and I saying “That’ll be alright.”

Part 2

Let’s summarise where we’ve got to. We’ve talked about these six components of risk management. That’s terrific. And as you can see, they all go together. Risk evaluation and risk reduction are more tightly coupled. That’s because when we do some risk reduction, we then re-evaluate the risk. We ask ‘Can we accept it?’. If the answer is ‘No.’ we need to do some more work. Then we do some more risk reduction. So those tend to be a bit more coupled together at the end. That’s the level we’ve got to. We’re now going to go to the next level.

So, we’re going to explain these things. We’ve talked about hazard identification and hazard analysis, but what is a hazard? And what is an accident? And what is an accident sequence? We’re going to unpack that a bit more. We’re going to take it to the next level. And throughout this, we’re talking about risk over and over again. Well, what is ‘risk’? We’re going to unpack that to the next level as well.

This is a safety standard. We’re talking about harm to people. How likely is that harm and how severe might it be? But it might be something else. It might be a loss or a security breach. Or a financial loss, a negative result for our project. We might find ourselves running late. Or we’re running over budget. We might be failing to meet quality requirements. Or we’re failing to deliver the full functionality that we said we would. Whatever it might be.

Hazard

So, let’s unpack this at the next level. A hazard is a term that we use, particularly in safety. As I say, we call it other things in different realms. But in the safety world, it’s a physical situation or it’s a state of a system.

As it says, it often follows from some initiating event that we may call a ‘cause’. The hazard may lead to an accident. However, the key thing to remember is once a hazard exists, an accident is possible, but it’s not certain. You can imagine the sort of cartoon banana skin on the pavement gag. Well, the banana skin is the hazard. In the cartoon, the cartoon character always steps on the banana skin. They always fall over the comic effect. But in the real world, nobody may tread on the banana skin and slip over. There could be nobody there to slip over all the banana skin. Or even if somebody does, they could catch themselves. Or they fall, but it’s on a soft surface and they don’t hurt themselves so there’s no harm.

So, the accident isn’t certain. And in fact, we can have what we call ‘non-accident’ outcomes. We can have harmless consequences. A hazard is an important midway step. I heard it called an accident waiting to happen, which is a helpful definition. An accident waiting to happen, but it doesn’t mean that the accident is inevitable.

Accident

But accidents can happen. Again, the ‘accident’, ‘mishap’, or ‘unintended event’. Something we did not want or a sequence of events that caused harm. And in this case, we’re talking about harm to people. And as I say, it might be a security breach. It might be a financial loss or reputational damage. Something might happen that is very embarrassing for an organization or an individual. Or again, we could have a hiccup with our project.

Harm

But in this case, we’re talking about harm. With this kind of standard, we’re using what you might call a body count approach to the harm. We’re talking about actual death, physical injury, or damage to the health of people.

This standard also considers the damage to property and the environment. Now, very often we are legally required to protect people and the environment from harm. Property less so. However, there will be financial implications of losses of property or damage to the systems. We don’t want that. But it’s not always criminally illegal to do that. Whereas usually, hurting people and damaging the environment is. So, this is ‘harm’. We do not want this thing to happen. We do not want this impact.

Safety is a much tougher business in this instance. If we have a problem with our project, it’s embarrassing but we could recover it. It’s more difficult to do that when we hurt somebody.

Risk

And always in these terms, we’re talking about ‘risk’. What is ‘risk’? Risk is a combination of two things. It’s a combination of the likelihood of harm or loss and the severity of that harm or loss. It’s those two things together. And we’ve got a very simple illustration here, a little table. And they’re often known as a risk matrix but don’t worry about that too much. Whatever you want to call it. We’ve got a little two by two table here and we’ve got likelihood in the white text and severity in the black.

Low Risk

We can imagine where there’s a risk where we have a low likelihood of a ‘low harm’ or a ‘low impact’ accident or outcome. We say, ‘That’s unlikely to happen, and even if it does not much is going to happen.’ It’s going to be a very small impact. So, we’d say that that’s a low risk.

Then at the other end of the spectrum, we can imagine something that has a high likelihood of happening. And that likelihood also has a high impact. Things that happen that we definitely do not want to happen. And we say, ‘That’s a high risk and that’s something that we are very, very concerned about.’

Medium Risk

And then in the middle, we could have a combination of an outcome that is quite likely, but it’s of low severity. Or it’s of high severity, but it’s unlikely to happen. And we say, ‘That’s a medium risk’.

Now, this is a very simplified matrix for teaching purposes only. In the real world, you will see matrices that are four by four, five by five, or even six by six, or combinations thereof. And in security where they talk about threat and vulnerability and the outcomes. Here, you might see multiple matrices used. They use multiple matrices to progressively build up a picture of the risk. They use matrices as building blocks. So, it may not be only one matrix used in a more complex thing you’ve got to model. But here we’ve got a nice, simple example. This illustrates what risk is. It’s a combination of severity and likelihood of harm or loss. And that’s what risk is, fundamentally. And if we have a firm grasp of these fundamentals, it’ll help us to reason and deal with almost anything. With enough application.

Accident Sequence

Now, let’s move on and talk about accident sequences. We’re talking about a progression in this case. We’re imagining a left-to-right path. A progression of events that results in an accident. This diagram, which looks like a bow tie, is meant to represent the idea that we can have one hazard. There might be many causes that lead to this hazard. There might be many different things that could create the hazard or initiate the hazard. And the hazard may have many different consequences.

Consequences

As I’ve said before, nothing at all may happen. That might be the consequence of the hazard. Most of the time that’s what’s going to happen. But there may be a variety of consequences. Somebody might get a minor injury or there might be a more serious accident where one or more people are killed. A good example of this is fire. So, the hazard is the fire. The causes might be various. We could be dealing with flammable chemicals, or a lightning strike, or an electricity arc flash. Or we could be dealing with very high temperatures where things spontaneously burst into flames. Or we could have a chemical in the presence of pure oxygen. Some things will spontaneously burst into flames in the presence of pure oxygen. So there’re a variety of causes that lead to the fire.

An Example

And the fire might be very small and burn itself out. It causes very little damage and nobody gets hurt. Or it might lead to a much bigger fire that, in theory, could kill lots of people. So, there’s a huge range of consequences potentially from one hazard. But the accident sequence is how we would describe and capture this progression. From initiating events to the hazard to the possible consequences. And by modeling the accident sequence, of course, we can think about how we could interrupt it.

Part 3

We’ve broken risk management down into those six constituent parts. We’ve gone to the next level, in that we’ve sort of gone down to the concepts that underpin these things. These hazards, the accidents, and the accident sequence. We’ve talked about risk itself and what we don’t want to happen. The harm, the loss, the financial loss, the embarrassment, the failed or late or budget project, a security breach, the undesired event, etc. We had an objective which was to do something safely or to complete a project and the risk is that that won’t happen. That there’ll be an impact on what we were trying to do that is negative. That is undesirable.

There are just only more concepts that we need to look at to complete the pattern, as you can see. We’ve been talking about the system. And we’ve been talking about doing things systematically. Then a system works in an operating environment. So, let’s unpack that.

System

First of all, we have a system. The system is going to be a combination of things. I wouldn’t call a pen or a pencil a system. It’s only got a couple of components. You could pull it apart. But it’s too simple to be worth calling it a system. We wouldn’t call it a pen system, would we? So, a system is something more complex. It’s a combination of things and we need to define the boundary. I’ll come back to that.

But within this boundary, we’ve got some different elements in the system that work together. Or they’re used together within a defined operating environment. So, we’re going to expose this system to a range of conditions in which it is designed to work. The intention is the system is going to do whatever it does to perform a given task. It can do one defined task or achieve a specific purpose.

I talked before about getting in our car. A car is complex enough to be called a system. We get in our car and we drive it on the roads. Or if we’ve got a four-wheel drive, we can drive Off-Road. Or we can use it in a more demanding operating environment to achieve a specific purpose. We want to transport ourselves, and sometimes some stuff, from A to B. That’s what we’re trying to do with the system.

Within the System

And within that system, we may have personnel/people, we may have procedures. A bunch of rules about how you drive a car legally in different countries. We’ve got materials and physical things – what the car is made of. We could have tools to repair it, and change wheels. We’ve got some other equipment, like a satnav. We’ve got facilities. We need to take a car somewhere to fill up with fuel or to recharge it. We’ve got services like garages, repairs, servicing, etc. And there could be some software in there as well. Of course, these days in the car, there’s software everywhere in most complex devices.

So, our system is a combination of lots of different things. These things are working together to achieve some kind of goal or some kind of result. There’s somewhere we want to get to. And it’s designed to work in a particular operating environment. Cars work on roads really well. Off-road cars can work on tracks. Put them in deep water, they tend not to work so well. So, let’s talk about that operating environment.

Operating Environment

What we’ve got here, is the total set of all external, natural, and induced conditions. (That’s external to the system, so outside the boundary.) So, it might be these conditions-. It might be natural or it might be generated by something else, which a system is exposed to at any given moment. We need to get a good understanding of the system, the operating environment, and what we want it to do.

If we have a good understanding of those three things, then we will be well on the way to being able to understand the risks associated with that system. That’s one of the key things with risk management. If you’ve got those three things, that’s crucial. You will not be able to do effective risk management if you don’t have a grasp of those things. And if you do have a thorough grasp of those things, it’s going to help you do effective risk management.

Conclusion

So, we’ve talked about risk management. We’ve broken it down into some big sections. Those six sections; the hazard identification; analysis; risk estimation; evaluation; reduction; and acceptance. We’ve seen how those things depend on only a few concepts. We’ve got the concepts of ‘hazards’, ‘risks’, and ‘accidents’. As well as the undesirable consequences that the risk might result in. The risk is measured based on the likelihood and severity of that harm or loss occurring.

When we’re dealing with a more complex system, we need to understand that system and the environment in which it operates. Of course, we’ve put it in that environment for a purpose. And that unpacking has allowed us to break down quite a big concept, risk management. A lot of people, like myself, spend years and years learning how to do this. It takes time to gain experience because it’s a complex thing. But if we break it down, we can understand what we’re doing. We can work our way down the fundamentals. And then if we’ve got a good grasp of the fundamentals, that supports getting the more complex stuff right. So, that’s what risk management is all about. That’s your risk management 101 and I hope that you find that helpful.

Copyright Statement

I just need to say briefly that those quotations from the standard. I can do that under a Creative Commons license. The CC4.0. That allows me to do that within limits that I am careful to observe. But this video presentation is copyrighted by the Safety Artisan.

For More…

And you can see more like these at the Safety Artisan website. That’s www.safetyartisan.com. And as you can see, it’s a secure site so you can visit without fear of a security breach. So, do head over there. Subscribe to the monthly newsletter to get discounts on paid videos and regular updates of what’s coming up. both paid and free.

So, it just remains for me to say thanks very much for watching and I look forward to catching up with you again very soon.

End of Risk Management 101

You can get the RM101 Course as part of the FREE Triple Learning Bundle. For more introductory sessions on this site start here.

Meet the Author

Learn safety engineering with me, an industry professional with 25 years of experience, I have:

•Worked on aircraft, ships, submarines, ATMS, trains, and software;

•Tiny programs to some of the biggest (Eurofighter, Future Submarine);

•In the UK and Australia, on US and European programs;

•Taught safety to hundreds of people in the classroom, and thousands online;

•Presented on safety topics at several international conferences.

Categories
Blog Safety Management Tools & Techniques

Full Function Hazard Logs: A Deep Dive into Relational Databases

In this post ‘Full Function Hazard Logs: A Deep Dive into Relational Databases’, I explore some things we can do with a hazard log built upon a database.

In my 25-year career in safety engineering, I’ve seen many hazard logs and hazard tracking systems. Most of them were hosted in Microsoft Excel, but there were also commercial tools and bespoke databases. Let’s explore well beyond mere spreadsheets…

The Accident Sequence Illustrated.

In the realm of hazard management, navigating through the complexities of hazard logs, hazard tracking systems, and risk registers is crucial for ensuring safety and compliance. To shed light on this intricate process, we embark on a journey to explore the nuances of full-function hazard logs and their utilization within relational databases. Join us as we unravel the intricacies of hazard identification, risk assessment, and control measures within the realm of safety engineering.

Unveiling the Essence of Full Function Hazard Logs

Entities and Links in an Example Full-function Hazard Log

In our quest to decipher the essence of full-function hazard logs, we delve into the core components of relational databases. Our mission is clear: to unravel the labyrinth of entities within a hazard log, understand their interconnections, and discern the rationale behind data recording. By comprehending the diverse facets of hazard logs, we equip ourselves with the knowledge to tailor hazard log features to meet specific needs, ensuring efficiency and efficacy in hazard management processes.

Illustrating with Cassandra: A Glimpse into Hazard Log Tools

As we embark on this journey, we look closely at Cassandra, an exemplar of hazard log tools. While our focus remains steadfast on elucidating hazard management principles, Cassandra serves as a tangible illustration, offering a practical lens through which to explore complex concepts.

The Cassandra Hazard Log Logo
The Cassandra Hazard Log Logo

Through this illustrative example, we navigate the intricacies of accident causal control, dissecting the underlying hazard model that underpins our hazard management endeavors.

Deciphering Hazard Log Screens: A Comprehensive Overview

Venturing further into the realm of hazard log management, we dissect the various screens encapsulated within the hazard log interface.

A Screen with Accident-related Data and Links.

From the overview screen, where we gain a holistic view of accidents, hazards, causes, and controls, to the core screen, where we delve into the specifics of causal analysis, each screen offers a unique perspective on hazard management. By scrutinizing leading particulars, probability, severity, and post-control statuses, we unravel the intricacies of hazard identification and risk mitigation.

Unveiling the Power of Relational Databases

Central to our exploration is the underlying power of relational databases, where entities are intricately linked through many-to-many relationships. As we navigate through the database landscape, we witness the seamless integration of accidents, hazards, causes, and controls, each playing a pivotal role in shaping hazard management strategies. By harnessing the full potential of relational databases, we unlock a myriad of benefits, empowering us to make informed decisions and uphold safety standards with unwavering diligence.

Accessing Additional Resources: Empowering Your Hazard Management Journey

As we conclude our exploration of full-function hazard logs within relational databases, we extend an invitation to delve deeper into the realm of hazard management.

Through free email subscriptions and access to courses on safety engineering, we provide a gateway to further enrich your hazard management knowledge. Join our community of safety enthusiasts, engage in insightful discussions, and embark on a transformative journey toward bolstering safety practices within your organization.

Learn safety engineering with me, an industry professional with 25 years of experience, I have:

•Worked on aircraft, ships, submarines, ATMS, trains, and software;

•Tiny programs to some of the biggest (Eurofighter, Future Submarine);

•In the UK and Australia, on US and European programs;

•Taught safety to hundreds of people in the classroom, and thousands online;

•Presented on safety topics at several international conferences.

Categories
Blog Safety Management

What Have Hazard Logs Ever Done for Us?

“What Have Hazard Logs Ever Done for Us? Well, there’s the aqueduct…” Monty Python’s Flying Circus may not be an obvious connection to hazard management, but it works! Hazard Logs – or Hazard Tracking Systems (HTS), which is a better term – are underappreciated but vital tools.

In this webinar on hazard logs, one of the topics that I will be covering is what a ‘full-function’ HTS can do. By that, I mean a purpose-built database, rather than just a spreadsheet. So here is a taster of the benefits, derived from my 25+ years of experience on system safety programs, large and small.

Key Elements of a Hazard Log

An HTS pulls together key safety data about:

  • Accidents: ‘An unintended event, or sequence of events, that causes harm’;
  • Accident Sequences: ‘The progression of events that results in an accident’;
  • Causes: that may lead to a hazard;
  • Controls (or mitigations): ‘A measure that, when implemented, reduces risk.’; and, of course
  • Hazards: ‘A physical situation or state of a system, often following from some initiating event, that may lead to an accident’.
Accident Sequence
Accident Sequence

Understanding how causes lead to hazards, and hazards lead to consequences, which may include (harmful) accidents, is fundamental to understanding accident sequences. This in turn helps us to understand the mechanisms that lead to harm – and defeat them.

Managing Many-to-Many Connections

A Hazard Log doesn’t just store data elements, it links those data together meaningfully to make information. A relational database does this by allowing us to make many-to-many connections between different classes of data.

Humorous illustration of linkages between data types in a Hazard Log or HTS
Hazard Log Connections

This allows us to do a lot of useful things. We’ve already mentioned understanding the mechanisms behind accident sequences. This allows us to design or select effective controls to interrupt the accident sequences and prevent harm.

Discovering Pathways to Harm

Understanding these links also enables us to see connections, for example between causes and accidents, which we had not seen before. This is important, as many severe accidents arise from unanticipated pathways to harm, perhaps in very specific circumstances. (For example, not shutting the bow doors of a ferry properly led to the flooding and capsizing of the Herald of Free Enterprise, killing 193 people.)

Change Impact Analysis

Understanding these connections also allows us to perform safety change impact analysis (‘the analysis of changes within a deployed product or application and their potential consequences’). In many programs I worked on, in-use incidents revealed that:

  • Designs were not working as intended;
  • Hazard controls were not as effective as thought;
  • Work done was not as designed; or that
  • The actual use of a system was not as foreseen.

If we know the links to something that has changed – what it affects / what affects it – then we can begin to estimate the impact. From experience, this occupies a lot of our time in in-service safety management.

Recovery and Improvement

In the real world things rarely stand still. There are usually many different stimuli for change (we’ve already mentioned our incidents/accidents). Our enterprise might have to raise its game for several reasons:

  • The Regulator demanding change or improvement;
  • Customers asking for more performance or more assurance;
  • The public reaction to incidents elsewhere in the market;
  • New technology or new competitors in our industry; or
  • Our commitment to continuous improvement.

Pareto analysis tells us that a minority of causes tend to dominate the effect. Thus, a small number of causes or initiating events drive the occurrence of hazards. Similarly, a minority of hazards will dominate incident and/or accident statistics.

We may know this from experience or analysis of our specific system, or we may have only generic data. It doesn’t matter.

Using these insights, we can use the linkages in the HTS to target particular causes, events, conditions, scenarios, hazards, etc. We identify the set that (should) make the biggest impact, the biggest difference. We can then rank the contributors in order of importance and tackle them.

Again, long and sometimes bitter experience tells me that safety practitioners will spend a lot of time doing this. Reacting to stimuli is a big part of safety management.

The Tool Supports the Process

Of course, we should be using tools to support the process. (The process is designed to produce the results or outcomes that we need). One example of such is the Risk Assessment process from ISO 31000, below.

Shows the elements, progression and cycle of the Risk Assessment Process from ISO 31000
The Risk Assessment Process

We want our HTS to support this process, storing the data that we get from the risk identification, analysis, and evaluation activities. We also want our Hazard Log to provide information that enables communication and consultation as well as monitoring and review (perhaps using a risk matrix).

Other Functions

Hazard Logs and HTS also perform many other functions. These may appear mundane, but when they go wrong they suddenly become very exciting! What Have Hazard Logs Ever Done for Us? They help us avoid these unwanted excitements, by providing:

Questions? Comments? Send me your feedback in the comments, below.

My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

Categories
Blog Safety Management

Optimizing Safety: Active Hazard Management with Hazard Logs

In ‘Optimizing Safety: Active Hazard Management with Hazard Logs’ we look at how to unleash the power of this underrated tool!

Introduction

A Hazard Log is more than just a record; it’s a dynamic tool for actively managing safety risks associated with systems. This continually updated log encapsulates Hazards, Accident Sequences, and Accidents, ensuring a structured approach to risk management. Dive into the world of Hazard Logs to discover their application, advantages, and best practices for effective use.

Active Management with Hazard Logs

Overview

A Hazard Log serves as an ongoing record, meticulously updated to capture Hazards, Accident Sequences, and Accidents linked to a system. It acts as a comprehensive repository, providing insights into risk management decisions for each Hazard and Accident.

The Hazard Log is a structured method of keeping and referring to Safety Risk Evaluations and other information pertaining to a piece of equipment or system. It is the primary means of monitoring the status of all identified hazards, choices made, and risk-reduction actions done, and should be utilised to assist supervision by the Project Safety Committee and other stakeholders.

Hazards, Accident Sequences, and Accidents noted are those that could potentially occur as well as those that have already occurred. The title Hazard Log may be deceptive because the information saved relates to the overall Safety Programme and includes Accidents, Controls, Risk Evaluation, ALARP/SFARP rationale, and Hazard data.

Utilization and Administration

Administered by a dedicated Hazard Log Administrator, primary access is granted to add, edit, or close data records. All other personnel have read-only access, ensuring visibility of Hazards while maintaining control. Records are tracked using a status field, indicating stages such as opening, awaiting mitigation confirmation, or ALARP/SFARP justification.

Recording Hazards

Considered best practice, each Hazard is recorded as “open,” with ALARP/SFARP arguments treated provisionally until mitigation actions are confirmed. Hazards are not deleted but closed with appropriate justifications, reflecting changes in relevance.

As an example, suppose the mitigation is contingent on the development of an operational procedure. This may not be developed until far after the Hazard has been discovered in the early stages of design or construction.

Hazards should not be erased from the Hazard Log, but rather closed and labeled “out of scope” or “not considered credible” with adequate justification. If such Hazards are no longer thought to be relevant to the system, the Log entry should be modified to reflect this.

Application in Systems

The Hazard Log should focus on a specified system, detailing its scope and safety requirements. It records the evaluation of Hazards, residual risk assessments, and recommendations for mitigation or formal acceptance with ALARP/SFARP justification.

Because a Hazard Log is an organised method of collecting and referencing data and records on Hazards, as well as documenting the Risk Evaluation and other information relevant to an equipment or system, unambiguous cross-referencing to supporting documentation is critical. The supporting documentation can be directly incorporated in the Hazard Log or cross-referenced.

Establishing a Hazard Log: Why and When

Traceability

A Hazard Log is crucial for projects, offering traceability in the decision-making process, and justifying the assessed Safety Risk. Initiated at the program’s earliest stage, it remains a live document throughout the system life cycle.

As modifications are implemented in the system, the Hazard Log should be updated to reflect the current design standard by including new or changed Hazards and the associated residual risks. The Hazard Log must be checked frequently to verify that hazards are being managed effectively and that compelling safety arguments in the Safety Case can be created.

Advantages & Disadvantages

Advantages

The Hazard Log is a traceable record of the Project’s Hazard Management process and thus:

  • Ensures that the Project Safety Programme uses a consistent set of Safety information;
  • Facilitates oversight by the Safety Panel and other stakeholders of the current status of the Safety activities; and
  • Supports the effective management of possible Hazards and Accidents so that the associated Risks are brought up to and maintained at a tolerable level;

Disadvantages

  • The Hazard Log could include information about the relationship between hazards, accidents, and their control through the establishment and fulfilment of Safety Requirements. However, if it is not robust or well-structured, this may obscure the identification and clearance of Hazards.
  • If Hazards are not well defined when they are entered into the Hazard Log, the rigour enforced by the need for a clear audit trail of changes made may make it very difficult to maintain the Hazard and Accident records most effectively. Before beginning data entry, an appropriate structure should be created and agreed upon.

Choosing the Right Format: Electronic vs. Paper-Based

Electronic Format

While a Hazard Log can be produced in any format, an electronic format, often in databases like Microsoft Access or SQL Server, ensures quick cross-referencing and traceability. Proprietary tools like Cassandra or spreadsheet packages like Microsoft Excel offer flexibility.

Bespoke vs. Proprietary

Choosing between a bespoke database and a proprietary tool involves considerations of customizability and standardization. A bespoke system may be simple to administer, while a proprietary tool ensures consistency across programs.

In conclusion, Hazard Logs, when actively managed, emerge as indispensable tools for maintaining safety standards and facilitating informed decision-making. Understanding their application and choosing the right format ensures efficient risk management throughout a system’s life cycle.

We will explore more active hazard management in our upcoming blog post using Cassandra as a case study.

That was ‘Optimizing Safety: Active Hazard Management with Hazard Logs’. See another article of my articles on hazard logs here. I hope that you find them useful: leave a comment, below!

My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

Categories
Blog Safety Management

Hazard Logs and Hazard Tracking Systems

In this blog post and video ‘Hazard Logs and Hazard Tracking Systems’, I’m going to tell you about their benefits and features.

In many industries, we are required to create a hazard log: perhaps by a regulator, a customer, or a prime contractor. Or maybe it’s “just the way we do it round here”. Whatever the reason, many junior staff will be given responsibility for entering data into a hazard log.

Hazard Logs enable us to manage large amounts of safety data and references, but only if they are implemented properly. Unfortunately, it seems that there are an infinite number of ways of not doing them well. In my 25+ years in System Safety, I’ve seen many bad hazard logs, so I created this lesson to help you get the basics right.

Topics | Transcript | Questions

This is the trailer for the full, 35-minute lesson.

Topics

I’m going to be covering these topics, which are the most commonly asked questions:

  • What is a hazard log? (What is it what do we do with it?)
  • The key elements of a hazard log (what needs to be in it to make it work)?
  • Hazard Log management (what we need to do)?
  • What about hazard log tools? (What can we use to create a hazard log)?
  • What’s the difference between a hazard log and a risk assessment?
  • What’s the difference between a hazard log and a risk register?

Transcript

Hi everyone, and welcome to the Safety Artisan.

I’m Simon and today we’re going to be talking about Hazard logs and hazard tracking systems.

As I said, we’re going to look at hazard logs and hazard tracking systems and we’re going to be answering the most popular questions.

The most often asked questions about Hazard logs and Hazard Tracking Systems that you will find on the internet. So that’s what we’re going to answer.

And this is going to be the first of three sessions on this subject.

Side: Topics

Topics for this session. Right now commonly asked questions are:

  • What is a hazard log? What is it what do we do with it?
  • The key elements of a hazard log: What needs to be in it to make it work?
  • Hazard Log of management: What do we need to do?
  • What about hazard log tools? What can we use to create a hazard log?

Effectively now we’ll be looking at that in much more detail in sessions two and three. But we’ll just go over the basics today and then also, some very common questions:

  • What’s the difference between a hazard log versus a risk assessment? and
  • What’s the difference between a hazard log and a risk register?

And when I say Hazard Log, you can substitute [the phrase] hazard tracking system at all times. They’re really one and the same thing, which we will talk about.

[End of Trailer.]

See also a 10% free sample of the full video.

Related Articles

See also this info-post on Hazard Logs and there is another post to come on how a relational database can deliver a ‘Full Function’ Hazard Log.

My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

Questions about HLs & HTS?

Ask me in the comments.

Categories
Blog Safety Management

Proportionality

Proportionality is about committing resources to the Safety Program that are adequate – in both quality and quantity – for the required tasks.

Introduction to Proportionality

Proportionality is a concept that should be applied to determine the allocation of resource and effort to a safety and environmental argument based on its risk.  It is a difficult concept to attempt to distil into a process as each Product, System or Service will have different risks, objectives, priorities and interfaces that make a ‘one size fits all’ approach impossible.

This section describes an approach that may be used to assist in applying the concept of proportionality; it seeks to guide you in understanding where a proportionate amount of effort can be directed, while at the same time maintaining the overriding principle that Risk to Life must be managed.  Regulators require that a proportional approach is used and there are many methods that try to achieve this.  Some focus on the amount of evidence needed to justify a safety argument; some provide more emphasis on the application of activities that are required to make a safety argument and some consider that fulfilling certain criteria can lead to an assessment of risk, but one requirement that is at the centre of any proportional approach is that safety risks are acceptable. 

A fundamental consideration of a proportional approach is considering compliance against assessment criteria.  The Health and Safety Executive’s view is that there should be some proportionality between the magnitude of the risk and the measures taken to control the risk. The phrase “all measures necessary” should be interpreted with this principle in mind. Both the likelihood of accidents occurring and the severity of the worst possible accident determine proportionality.  Application of proportionality should highlight the hazardous activities for which the Duty Holder should provide the most detailed arguments to support the demonstration [that risk is acceptable].

The following considerations may affect proportionality, in a defence context:

  1. Type of consequence;
  2. Severity;
  3. The stage in the Life cycle;
  4. Intended use (CON OPS/Design Intent);
  5. Material state (degradation);
  6. Historical performance;
  7. Cost of safety;
  8. Cost of realising risk;
  9. Public Relations;
  10. Persons at Risk:
    1. 1st,2nd,3rd Party;
    1. Military
    1. Civilian;
    1. Civil Servants;
    1. Contractors;
    1. General public;
    1. VIPs;
    1. Youths;
  11. Volume;
  12. Geographical spread/transboundary.

Some important points that should be noted regarding safety and environmental proportionality approach are that:

  1. Proportionality is inherent to safety and environmental risk assessment (i.e. use of ALARP, BPEO, etc.);
  2. Proportionality is explicitly linked to risk;
  3. Multiple factors need to be considered when deciding a proportional approach;
  4. ASEMS is the mandated safety and environmental framework; therefore, the framework should be applied; it is not possible to develop a proportional approach that negates any part of ASEMS.

Waterfall Approach Process

The model that should be used to consider a proportional approach is intended to provide guidance and should only be used by competent safety and environmental practitioners.  A degree of judgement should be used when answering questions, particularly where a Product, System or Service may easily be classified in more than one category; this is why the use of competent safety and environmental practioners is required.

The waterfall approach model categorises Product, System or Service risk in accordance with factual questions, presented on the left of the diagram below, which are asked about the intended function and operation.  Each question should be used to define the cumulative potential risk, which may be presented by the Product, System or Service.  The Product, System or Service is categorised into one of three risk bands, which align to those defined in the Tolerability triangle, presented in the right of of the diagram.

During the process two initial questions are asked, where an answer of “yes” will automatically result in a categorisation of high risk, regardless of the answer to subsequent questions.  Further refinement is required for lower risk systems to ensure that the system risk is categorised appropriately.

Figure 1, Proportionality Waterfall Approach Model

The diagram above depicts the proportionality waterfall approach model used for the application of ASEMS.

Adherence to ASEMS is mandatory for DE&S.  As such, it is not possible to develop a proportional approach that negates any individual part of ASEMS and so the procedures described in ASEMS Part 2 – Instructions, Procedures and Support should be followed;  where proportionality may be applied is within each General Management Procedure, Safety Management Procedure or Environmental Management Procedure for the allocation of resource, time or effort.

Once the risk category has been established guidance is defined which prescribes the rigour which should be applied to the safety assessment process in terms of Process, Effort, Competence, Output, Assurance (PECOA):

  1. Process – the amount of dedicated/specific process, level of intervention in the organisational structure the Safety and Environmental Management System are established;
  2. Effort – How much time is afforded to the management of risk;
  3. Competence – the level of competence that is required to conducted appropriate assessment and management of safety and environmental;
  4. Output – The detail of evidence and reporting is cognisant to the level of risk;
  5. Assurance – The level of assurance required which shall be applied to the process.

Guidance for the application of PECOA is provided in the table below.  It should be noted that this is indicative guidance for illustrative purposes only. It is a fundamental requirement of ASEMS safety management principles that all safety decisions made should be reviewed, assessed and endorsed by a Safety and Environmental Management Committee to ensure that the Products, Systems and Services categorisation is correct. The diagram below shows the process that may be applied:

Proportionality Process

It should be remembered that using this low/medium and high categorisation could be misleading as the model takes no account of the population or rate of occurrence of the harm. A simple system that can only cause minor injury could still have a high degree of risk if there are lots of people exposed to the risk and the accident rate was high.  Moreover, acceptance of such a situation could lead to the development of an ineffective safety culture or the bypassing of safety mitigation procedures in order to avoid a high accident/minor injury position.  This is where the application of competent safety and environmental advice is essential to ensure that any proportionality model is not slavishly followed at the expense of proper rigour.   Where this model is useful is assisting those safety and environmental professionals to perform a preliminary assessment regarding what Products, Systems or Services are a priority for the allocation of resource, time or effort.

Stage One – System type and Life Cycle Phase

The first question is used to indicate, at a high level, the likely degree of risk for a project.  It should be noted that this is not a definitive assessment and that Products, Systems or Services could move within the model as the safety or environmental evidence is assessed.  There will be a degree of pre-existing assessment which accompanies a Product, System or Service and this may be used to assist with this initial question. 

The safety and environmental assessment process should be closely aligned with the Product, System or Service development process for newly developed Product, System or Services.  Where Products, Systems or Services are in the Concept, Assessment, Development or Manufacture phase of the CADMID/T cycle, they should be accompanied by a safety and environmental assessment process which utilises quantitative assessment techniques.

Where a Product, System or Service sits in the CADMID/T cycle should not influence the rigour of any safety or environmental argument; this model is provided to assist with any determination of the resource, time or effort that may be applied to the evidence to support the argument.  All Risk to Life should be ALARP, with no exception; what changes is the allocation of resources, time and effort to reach that judgement.

Those Products, Systems or Services where the expected worst credible consequence results in, at worst, a single minor injury should automatically be categorised as LOW risk and a qualitative approach may be adopted.

Commercial Off The Shelf or Military Off The Shelf systems should be accompanied by evidence which may be used in the safety and environmental assessment to demonstrate that they are acceptably safe and environmentally compliant, particularly where these are manufactured for use in the EU, where each Product, System or Service should demonstrate compliance with the applicable EU standards.  That the Product, System or Service is Commercial Off The Shelf or Military Off The Shelf is not, in itself, evidence.

Such evidence should include test evidence, trials evidence or a certificate of conformance.  Where a Commercial Off The Shelf or Military Off the Shelf system is already in the in-service phase and it is established that there is sufficient evidence to form a compelling safety argument that the Risk to Life is ALARP, then the system should be categorised as MEDIUM-LOW.  Where the system is also non-complex then it may be categorised as LOW.

Such Commercial Off The Shelf or Military Off the Shelf evidence should only be relied upon where it is established that this evidence is sufficient to demonstrate that the system is acceptably safe and environmentally compliant and already in existence.  The degree and appropriateness of evidence should be established by a Safety and Environmental Management Committee, with particular emphasis upon the quality of the evidence for high-risk systems.  This approach should be undertaken if the Product, System or Service in its entirety is categorised as Commercial Off The Shelf or Military Off the Shelf.  Where only sub-systems or components are Commercial Off The Shelf or Military Off the Shelf, the Product, System or Service should be categorised as bespoke and assessed accordingly.

Stage Two – Risk estimation and System Complexity

Any estimation of the risk that a Product, System or Service is likely to present should be used to further refine its categorisation.  If the worst credible consequence of a Product, System or Service is multiple fatalities then that Product, System or Service should automatically be categorised as HIGH risk.

If the worst credible consequence is a single fatality or multiple severe injuries then the system complexity should be considered further to refine and inform the categorisation.  Complex or novel system designs should have a higher degree of Suitably Qualified Experienced Personnel to conduct the safety and environmental assessment.  Accordingly, those Products Systems or Services which are complex and novel should also be categorised as HIGH whereas those exhibiting a lower degree of complexity might be categorised as MEDIUM.

Notwithstanding this, those Products, Systems or Services thatare in the Concept, Assessment, Development or Manufacture/Termination phase of the CADMID/T cycle should still be supported by a quantitative safety and environmental process.  The only exceptions are those Products, Systems or Services where the worst credible consequence is a single minor injury.  These should be categorised as LOW risk and may be supported by a qualitative safety and/or environmental process.

LOW risk Products, Systems or Services were the worst credible consequence is at worst a single minor injury should be categorised as LOW-MEDIUM risk where the design is complex or novel, those exhibiting a lower degree of complexity should be categorised as LOW risk.

Once the risk category has been established the rigour which should be applied to the safety assessment process in terms of Process, Effort, Competence, Output, Assurance (PECOA) should be defined.  This is summarised below:

Program ScaleLifecycle Stage
Small scale or no Critical FunctionCADMID/TCADMID/TCADMID/T
Large Scale Capital,

Critical Function or bespoke
CADMID/TCADMID/TCADMID/T
AssessmentHighMediumLow
ProcessA rigorous quantitative safety and environmental assessment process should be applied.Consideration should be given to the application of a qualitative safety and environmental assessment process.  Functional safety/environmental assessment may be required, if identified as a risk control measure.A qualitative safety and environmental assessment process should be appropriate for low risk, low complexity systems.
EffortSignificant effort should be expended developing the safety and environmental case.A medium level of effort should apportioned to development of the safety and environmental case, increasing for newly developed systems.A medium level of effort should be apportioned to development of the safety and environmental case.
CompetenceThe safety and environmental assessment and assurance programme should be led by individuals who are experts.  Remaining personnel should be at least Practitioners who should be provided with oversight where appropriate.Personnel engaged in the safety and environmental assessment and approval should be at least practitioners.Personnel engaged in the safety and environmental assessment and approval should be at least supervised practitioners who should be provided with oversight where appropriate.
OutputA safety and environmental case should be developed which includes a safety argument.  The safety assessment process should be substantiated by quantitative evidence.A safety and environmental case should be developed, which should include a safety and environmental argument for all by simplex low risk systems.  The safety assessment process should be substantiated by quantitative evidence for newly developed systems.A safety and environmental statement may be considered for systems, which are low risk and complexity.
AssuranceThe safety and environmental assessment should be independently assured.Independent assurance should be considered and applied to those projects which are considered to be novel or complex.  Assurance may be conducted at Committee level. Independent assurance is not required.
ASEMS GuidanceSafety and Environmental   Dedicated tailored and full implementation of all Clauses, articulated through adherence to all GMPs, SMPs and EMPs.Safety and Environmental   Apply full implementation of all Clauses, in line with guidance provided for the Functional safety/environmental assessment, as required, if identified as a risk control measure and application of GMPs, SMPs and EMPs.Where Project Teams have an overarching Safety and Environmental Management Systems in place:   Safety Gather sufficient evidence to support safety argument and document in a Safety Case/Assessment in accordance with SMP 04050609 and 12     Environmental Gather sufficient information in order to produce Environmental Impact Statement in accordance with EMP 07 – Environmental Reporting.

Process

The type of safety and environmental process which should be applied is dependent both upon the Product System or Service categorisation and the phase of the CADMID/T cycle that the project is in.  Newly developed MEDIUM-LOW to HIGH category Products, Systems or Services which are in the Concept, Assessment, Development or Manufacture phase of the cycle should have a quantitative safety and environmental assessment process applied, the depth and rigour of the assessment should be proportionate to its classification.  LOW risk Products, Systems or Services where the worst credible consequence is anticipated to be no greater than one minor injury may be assessed qualitatively.

A qualitative safety and environmental assessment process should be applied to Products, Systems or Services, which are in the In-Service, Disposal/Termination phase where it is deemed that there is sufficient evidence already in existence to demonstrate that it is acceptably safe.  In these circumstances a qualitative safety and environmental process should be applied to assess the in-service risks.

The approach uses a systematic and logical approach to categorise the resource, time and effort required to support any argument that a Product, System or Service is acceeptably safe or provides no significant damage to teh environment.  It also advocates the application of ASEMS in its entirety, prescribing the level of rigour, which should be applied in terms of process, effort, competence, output and assurance.

Effort

The effort apportioned to the safety and environmental process should be proportionate to the classification of the system.  A significant amount of rigour should be applied to those projects requiring quantitative assessment processes, particularly those with the highest degree of risk and complexity.

If a Product System or Service is assessed to be in a particularly low category and is simple it may not be necessary to undertake the full scope of risk management procedures.  In these circumstances a certificate of conformance may be sufficient, which may be supported by statement to that effect from the Safety and Environmental Management Committee.

All decisions made regarding the evidence required to justify a safety argument (regardless of risk) should be endorsed by a Safety and Environmental Management Committee.  If this is decision is delegated further for those Products, Systems or Services that are low risk is for the Duty Holder to determine as all decisions regarding to Risk to Life are made on their behalf.

Competence

The safety and environmental lead should be an expert for HIGH category projects or for MEDIUM category projects where the Product System or Service is particularly complex or a novel design.  The remaining personnel engaged on such projects should be at least practitioner level.  A competency assessment should be undertaken which should be endorsed by a Safety and Environmental Management Committee.

The safety and environmental lead for MEDIUM category projects should be at least practitioner level.  The remaining personnel engaged on such projects should be practitioner or supervised practitioner where appropriate supervision is in place.  A competency assessment should be undertaken which should be endorsed by a Safety and Environmental Management Committee.

The safety and environmental lead for LOW category projects should be at least practitioner level or a supervised practitioner with appropriate supervision in place.

Competency requirements relating to specific safety and environmental processes defined in ASEMS should be applied where those processes are undertaken.

Output

A safety and environmental case should be developed for HIGH category projects which includes a safety and environmental argument, developed using Claims Arguments Evidence (CAE) or Goal Structuring Notation (GSN).  The argument should be substantiated by quantitative evidence such as reliability data or the output from quantitative safety assessment processes.

A safety and environmental case should be developed for MEDIUM category projects which includes a CAE or GSN safety argument.  The quality and depth of evidence required to substantiate the safety and environmental argument should be proportionate to the classification of the Product System or Service.   Products, Systems or Services with increased complexity or higher degrees of risk should be substantiated by quantitative evidence

A Safety and environmental case should be developed for MEDIUM-LOW category Products, Systems or Services.  A safety and environmental argument should be included for those Products, Systems or Services which are particularly complex or novel or those which exhibit an increased degree of risk

A Safety and environmental case should be developed for MEDIUM-LOW category Products, Systems or Services.  A safety and environmental argument should be included for those Products, Systems or Services which are particularly complex or novel or those which exhibit an increased degree of risk.

A safety and environmental case or Safety and environmental statement should be developed for LOW category Products, Systems or Services.  A certificate of conformance may be adequate for the lowest risk simple Products, Systems or Services

All decisions made regarding the evidence required to justify a safety argument (regardless of risk) should be endorsed by a Safety and Environmental Management Committee.  If this is decision is delegated further for those Products, Systems or Services that are considered to fall in the low category, then it is for the Duty Holder to determine (as all decisions regarding to Risk to Life are made on their behalf) whether to acept the risks or not.

Assurance

HIGH and MEDIUM category projects should be independently reviewed by a Safety and Environmental Auditor.  The degree of Independent Safety and Environmental Auditor engagement should be proportionate to the project categorisation.

MEDIUM-LOW category projects should be independently reviewed by a Safety and Environmental Auditor where the safety and assessment processes applied are novel or complex.  Justification should be provided where an Independent Safety and Environmental Auditor is not appointed.

It is not necessary for projects categorised LOW to be independently reviewed.

It should be remembered that it is not prudent to take any form of autocratic system or approach without sufficient validation, verification and endorsement by competent and duly authorised individuals, who are considered Suitably Qualified and Experienced Personnel for the role.  Endorsement of decisions should be made by a competent panel or committee, as part of the overall hazard analysis and risk assessment and any variation in opinion from that presented by any proportionality model should be managed by such a panel.

If you found this post on Proportionality helpful, please leave a review.

If this post is missing something you wanted, please let me know!

Categories
Blog Safety Management

Hazard Logs – a Brief Summary

In Hazard Logs – a Brief Summary, we will give you an overview of this important safety management tool. This post serves as an introduction to longer posts and videos (e.g. Hazard Logs & Hazard Tracking Systems), which will provide you with much more content.

Hazard Logs – a Brief Summary

Description of Hazard Log

A Hazard Log is a continually updated record of the Hazards, Accident Sequences, and Accidents associated with a system. It includes information documenting risk management for each Hazard and Accident.

The Hazard Log is a structured means of storing and referencing Safety Risk Evaluations and other information relating to a piece of equipment or system. It is the principal means of tracking the status of all identified Hazards, decisions made and actions undertaken to reduce risks. It should be used to facilitate oversight by the Project Safety Committee and other stakeholders.

The Hazards, Accident Sequences, and Accidents recorded are those which could conceivably occur, as well as those which have already been experienced. The term Hazard Log may be seen as misleading since the information stored relates to the entire Safety Programme and covers Accidents, Controls, Risk Evaluation, and ALARP/SFARP justification, as well as data on Hazards.

Operation

The Hazard Log is maintained by a Hazard Log Administrator, who is responsible to the Project Safety Engineer/Manager. The Hazard Log Administrator has primary access to the Hazard Log allowing him/her to add, edit or close data records. All other personnel requiring access to the Hazard Log are normally allowed read-only access. This allows for visibility of Hazards to all but limits the control/administration of data records to the Hazard Log Administrator.

Records can be tracked by the use of a status field. This, for example, identifies whether the record has just been opened, is awaiting confirmation of mitigation actions, or is ALARP/SFARP.

It is best practice for the Hazard Log to record each Hazard as “open” and for ALARP/SFARP arguments to be provisional until all mitigation actions are confirmed to be satisfactorily completed. An example is where the mitigation depends upon the production of an operational procedure that may not be written until well after the Hazard is first identified in the early stages of design or construction.

Hazards should not be deleted from the Hazard Log, but closed and marked as “out of scope” or “not considered credible”, together with appropriate justification. Where such Hazards are no longer considered relevant to the system, the Log entry should be updated to reflect this.

Application

In general, the Hazard Log should relate to a specified system and record its scope of use, together with the safety requirements. When Hazards are identified, the Hazard Log should show how these Hazards were evaluated and note the resulting residual risk assessment; the Hazard Log should then record any recommendations for further action to mitigate the Hazards, or formally document acceptance of the Hazards and any ALARP/SFARP justification.

Since a Hazard Log is a structured way of storing and referencing data and records on Hazards, documenting the Risk Evaluation and other information relating to a piece of equipment or system, clear cross-referencing to supporting documentation is essential. The supporting documentation can be either directly embedded or cross-referenced within the Hazard Log.

When it Might be Used

A Hazard Log should be established for all projects. This will allow full traceability of the formal decision process which would justify the assessed level of Safety Risk.

The Hazard Log is established at the earliest stage of the program and should be maintained throughout the system life cycle as a “live” document or database. As changes are integrated into the system, the Hazard Log should be updated to incorporate added or modified Hazards and the associated residual risks noted to reflect the current design standard.

It is essential that the Hazard Log is reviewed at regular intervals, to ensure that Hazards are being managed appropriately and enable robust safety arguments in the Safety Case to be established.

Advantages, Disadvantages, and Limitations

Advantages 

The Hazard Log contains the traceable record of the Hazard Management process for the Project and therefore:

  • Ensures that the Project Safety Programme uses a consistent set of Safety information;
  • Facilitates oversight by the Safety Panel and other stakeholders of the current status of the Safety activities;
  • Supports the effective management of possible Hazards and Accidents so that the associated Risks are brought up to and maintained at a tolerable level;
  • Provides traceability of Safety decisions made.

Disadvantages 

  • The relationship between Hazards, Accidents, and their management through setting and meeting Safety Requirements could be included within the Hazard Log. However, if it is not sufficiently robust or well-structured, this may obscure the identification and clearance of Hazards;
  • If Hazards are not well defined when they are entered into the Hazard Log, then the rigor enforced by the need for a clear audit trail of changes made may make it very difficult to maintain the Hazard and Accident records in the most effective way. An appropriate structure should therefore be designed and agreed upon before data entry starts.

Comments

A Hazard Log can be produced in any format, but an electronic format is the most common, as this tends to provide the quickest means of cross-referring and providing traceability through the Hazard Log. A paper-based Hazard Log would have limitations for most defense Systems as it would become large, staff-intensive, and cumbersome as the System developed. This in turn introduces a significant maintenance overhead for a project.

The electronic form of the Hazard Log can be developed using Database development tools like Microsoft Access or SQL Server. Alternatively, you can use an existing application such as DOORS. Alternatively, it can be completed in a simple spreadsheet package such as Microsoft Excel. The UK Ministry of Defence’s preferred Hazard Log tool was Cassandra, a proprietary Database based upon Microsoft Access.  (We will use Cassandra as an example in another blog post.)

A bespoke Database enables the originator to custom define fields appropriate to the System. Conversely, a proprietary tool allows for a consistent and standardized approach across a range of programs. A bespoke system may be relatively simple to administer and manipulate, whereas a proprietary tool may require external training. Widespread use of different bespoke solutions may become unmanageable.

Sources of Additional Information

Additional guidance on the Hazard Log can be found within the following references: MoD’s Project-Oriented Safety Management System – procedure SMP11 – Hazard Log.  An example Hazard Log structure is also presented there.

Copyright Acknowledgement

In this article, I have used material from a UK Ministry of Defence guide. It is reproduced under the terms of the UK’s Open Government Licence.

Hazard Logs – a Brief Summary: Ask Me Anything!

Categories
Blog Safety Management

Safety Management Policy

In this post on Safety Management Policy, we’re going to look at the policy requirements of a typical project management safety standard. This is the Acquisition Safety & Environmental System (ASEMS).

The Ministry of Defence is the biggest acquirer of manufactured goods in the UK, and it uses ASEMS to guide hundreds of acquisition projects. They will range from the development of large, complex systems to buying simpler off-the-shelf items.

(You may be aware that the UK Ministry of Defence has a terrible record of project failure. I have personal experience of working on both sides of contracts – for buyer and seller. I can tell you that they would have done better if they had followed ASEMS more carefully. The standard is good, but no standard can help if you don’t use it!)

The policy clauses listed here are typical of many found around the world. There is a lot to be learned by studying them.

Safety Management Policy – Overview

ASEMS Part 1 – Policy comprises a series of policy statements grouped in six loosely related sections as follows:

Part 1 – General Clauses

These clauses represent those overarching general requirements that shall be used in all instances. If the clause is self-explanatory, there may not be explicit Instructions in ASEMS – Part 2 Instructions, Guidance, and Support to support them but where these are provided, the Instructions and Guidance will provide a best practice method for compliance.

Clause 1.1 Conform to Secretary of State for Defence’s Policy

Those holding safety and environmental protection delegations shall ensure that in the procuring or supporting Products, Systems, or Services, they conform to the Secretary of State’s Health, Safety, and Environmental Protection Policy Statement.

Clause 1.2 Instructions

The instructions defined in ASEMS – Part 2 Instructions, Guidance, and Support shall be used to manage safety and environmental impact within the Enterprise.

Clause 1.3 Duty Holders

Duty Holders shall be appointed and Letters of Delegation issued in accordance with the Enterprise Chief Executive Officer’s Organisation and Arrangements.

Clause 1.4 Interfaces

Interfaces between organizations shall be identified so that risks across them can be appropriately managed and effectively communicated.

Clause 1.5 Data and Record Format

Data shall be maintained in a format, which satisfies the reporting requirements of senior management within the Enterprise. Auditable records shall be made and kept under review in accordance with relevant legislation.

Clause 1.6 Significant Occurrences and Fault Reporting

All Delivery (Project) Teams shall record and report significant Product, System, or Service faults, accidents, incidents, and near misses to the Enterprise Safety, Health & Environment Committee through the Quality, Safety, and Environmental Protection Team.

Clause 1.7 Learning From Experience

Business Units, Delivery (Project) Teams, or equivalents shall ensure accidents and incidents are investigated to identify opportunities to reduce the likelihood and impact of recurrence. Lessons learned shall be shared amongst all relevant stakeholders to maximize benefit.

Clause 1.8 Training

Enterprise-sponsored courses for system safety and environmental protection shall be the recognized route for achieving suitable and sufficient competence throughout the Enterprise.

Part 2 – Management Responsibilities

Management responsibilities for safety and environmental protection permeate through every Clause, and are the heart of any successful safety and environmental management system; however, these Clauses confer specific requirements upon management and make compliance easier to measure.

Clause 2.1 Organisation and Arrangements

Business Unit Directors or equivalent shall document their Organisation and Arrangements that shall communicate their commitment to the Secretary of State for Defence’s policy statement, continual improvement, positive safety and environmental culture, to minimize adverse effects on the environment, and comply with legal and other appropriate requirements.

Clause 2.2 Communication

Business Units, Delivery (Project) Teams, or equivalents shall ensure that communication procedures are implemented that provide an effective flow of safety and environmental protection information upwards, downwards, and across their organization.

Clause 2.3 Organisational Change Management

Business Unit Directors or equivalent shall identify any increased safety risk associated with organizational change and manage it appropriately.

Part 3 – Safety and Environmental Management System

These Clauses place specific requirements upon organizations and individuals and represent the minimum requirements for a safety and environmental management system. They include the requirement to plan for safety and environmental protection, to enact that plan, check that the plan is working, and to make changes where necessary to improve the system

Clause 3.1 Safety and Environmental Management System

Business Units, Delivery (Project) Teams, or equivalents shall operate in compliance with established Safety and Environmental Management Systems.

Clause 3.2 Safety and Environmental Management Plan

Business Units or equivalent shall ensure that all Products, Systems, or Services have a suitable and sufficient through-life safety and environmental management plan.

Clause 3.3 Stakeholder Agreements

Agreements between Stakeholders shall define and document system safety and environmental protection responsibilities.

Clause 3.4 Availability of Resources

Business Units, Delivery (Project) Teams or equivalents shall ensure the availability of resources necessary to establish, implement and maintain the safety and environmental management system and detail these in a through-life safety and environmental management plan.

Clause 3.5 Core Element Documentation

Business Units, Delivery (Project) Teams or equivalents shall establish, maintain and retain suitable and sufficient information that describes the core elements of the safety and environmental management system(s), their interaction, and any related documentation.

Clause 3.6 Accountability

Individuals deployed to assignments that require the formal delegation of safety and environmental responsibilities, accountabilities, and authority shall be mapped against, and comply with, the requirements of the Enterprise Acquisition Safety taxonomy.   

Clause 3.7 Monitoring

Business Units, Delivery (Project) Teams or equivalents shall establish, implement and maintain a suitable and sufficient procedure to monitor and measure safety and environmental performance of their safety and environmental management system on a regular basis.

Clause 3.8 Audit Frequency

Compliance with the documented safety and environmental management system shall be verified via audit at planned intervals according to a published schedule, and as required.

Clause 3.9 Internal Audit

At planned intervals commensurate with the risk:

  1. Business Units shall audit their Delivery (Project) Teams, or equivalents, safety, and environmental management systems.
  2. Delivery (Project) Teams or equivalents shall audit the safety and environmental management systems of their projects.
  3. The Enterprise Quality, Safety, and Environmental Protection Team or their representative, shall audit the safety and environmental management systems of Business Units and Delivery (Project) Teams.

Policy Clause 3.10 Review

Business Units, Delivery (Project) Teams, or equivalents shall review their safety and environmental management systems, at planned intervals commensurate with the risk, to ensure their continuing suitability, adequacy, and effectiveness.

Part 4 – Safety and Environmental Cases/Assessments

These Clauses contain the requirements that each safety and environmental case/assessment shall contain. Defense Regulators may require further, additional, requirements to what is contained in these clauses. Adherence to these Clauses will ensure safety and environmental cases/assessments contain the minimum evidence necessary to support safety and environmental arguments that Products, Systems, and Services are safe to use.

Clause 4.1 Safety Cases

Delivery (Project) Teams or equivalents shall establish and maintain through-life safety cases that provide a compelling, comprehensible, and valid argument that a Product, System, or Service is safe for a given application in a given operating environment.

Clause 4.2 Environmental Cases

Delivery (Project) Teams or equivalents shall establish and maintain through-life environmental cases that provide a compelling, comprehensible, and valid argument that the environmental impact of a Product, System or Service is reduced, or Best Practicable Environmental Option (BPEO) is applied.

Clause 4.3 Identification of Legislation and other Requirements

Business Units or equivalent shall establish and maintain a procedure for identifying and accessing the relevant safety and environmental legislative and other requirements that are applicable to their projects.

Clause 4.4 Legislation Compliance and other Requirements

Delivery (Project) Teams or equivalents shall establish, and demonstrate compliance with, relevant legislation and other requirements.

Clause 4.5 Environmental Impact Identification

Business Units, Delivery (Project) Teams or equivalent shall establish, implement and maintain a procedure for the on-going proactive identification of environmental impacts.

Clause 4.6 Safety Hazard Identification

Business Units, Delivery (Project) Teams or equivalent shall establish, implement and maintain a procedure for the on-going proactive identification of safety hazards.

Clause 4.7 Safety and Environmental Objectives and Targets

Business Units, Delivery (Project) Teams or equivalents shall establish and maintain relevant safety and environmental objectives with a resourced programme to achieve targets.

Clause 4.8 Accident and Incident Records

Business Units, Delivery (Project) Teams or equivalent shall monitor and record accidents, incidents and near misses, where the performance of their Product, Systems or Services results in harm to individuals or damage to the environment and use this information to keep their risk assessments valid.

Clause 4.9 Assessment Approval

Safety and environmental case reports shall be personally approved by the individual with formally delegated authority to confirm their acceptance with the progress of the safety case/assessment and of the risks associated with the project.

Clause 4.10 Independent Assurance

Independent review of the Safety and Environmental Management System shall be ensured, as appropriate and commensurate to the risk, by the individual with formally delegated authority for safety and environmental protection.

Part 5 – Risk management

Risk Management is an essential function of safety and environmental protection and these Clauses reflect that importance. They set both general safety and environmental protection standards and specific the Enterprise requirements that support the need for assurance and performance monitoring to the Defence Board. The requirement to refer risks through Line management is included here.

Clause 5.1 Risk and Impact Assessment

All foreseeable Safety Risks and Environmental impacts shall be identified, assessed, prioritised and managed.

Clause 5.2 Change Management

Business Units, Delivery (Project) Teams or equivalents are to ensure that all new or increased safety risks arising from changes to Products, Systems or Services or to their operating environment are managed appropriately

Clause 5.3 Hierarchy of Controls

Business Units, Delivery (Project) Teams, or equivalent shall adopt a recognized hierarchical approach for achieving a reduction in safety risk and environmental impact.

Clause 5.4 Consultation

Business Units, Delivery (Project) Teams, or equivalent shall ensure that all stakeholders are identified and consulted so that their views and responsibilities are considered when managing safety and environmental risks.

Clause 5.5 Safety Risk

Products, Systems or Services shall not have safety risks that have not been formally assessed, justified and declared to be Tolerable and As Low As Reasonably Practicable (ALARP), unless communicated and accepted by a Duty Holder (DH).

Clause 5.6 Environmental Impact

Significant environmental impacts shall be minimised utilising BPEO.

Clause 5.7 Non-compliance Reporting

In circumstances where the ability of the Delegation Holder to achieve compliance with the requirements of ASEMS may have been compromised, Business Units, Delivery (Project) Teams or equivalents shall take immediate steps to correct the situation. Actions required could include improving the clarity of the authority, instructions or responsibilities provided, increasing resources or correcting deficiencies in practices or procedures. Where resolution of the problem lies outside the control of the Delegation Holder, the issue is to be referred through the line management chain. This requirement is to be applied to any further levels of delegation as necessary.

Clause 5.8 Referral Requirements

Where risks cannot be managed within an individual’s delegated responsibility, the risk shall be formally referred using the Enterprise Risk Referral procedure.

Part 6 – Competence

It is necessary that those involved in safety and environmental protection are suitably qualified and experienced in order for them to perform their roles. These Clauses detail the way that competence is to be captured and assessed.

Clause 6.1 Roles and Responsibilities

Business Units, Delivery (Project) Teams or equivalents shall demonstrate that competence requirements have been established for all roles in accordance with appropriate standards including the Enterprise System Safety & Environmental Protection Competency Maps, Assignment Specifications, and Success Profiles.

Clause 6.2 Suitably Qualified and Experienced Personnel

Business Units, Delivery (Project) Teams or equivalents shall ensure that those engaged in safety and environmental protection are suitably qualified and experienced to discharge their safety and environmental responsibilities.

Clause 6.3 Competence

The competence of all staff with system safety and environmental responsibilities shall be regularly assessed, monitored, and recorded.  Staff with formally delegated system safety and environmental responsibilities shall demonstrate their competence to receive the delegation prior to deployment, and their competence shall be regularly monitored and recorded. 

Safety Management Policy: which clauses will you use?

Categories
Blog Safety Management

SMP03 Safety Planning

Safety Planning: if you fail to plan, you are planning to fail. In my experience, good safety plans don’t always result in successful safety programs; however, bad safety plans never lead to success.

Safety Planning: Introduction

Definitions

Safety Management Plan is defined as:

“A document that defines the strategy for addressing safety and documents the Safety Management System for a specific project.”

UK MoD Defence Standard 00-56

Objectives

The objectives of a Project Safety Management Plan (SMP) are twofold:

  1. To ensure that the safety performance of the system is acceptable throughout its life;
  2. To provide and maintain adequate assurance information that this is being achieved.

These objectives can only be realised by following a coordinated and structured approach to safety throughout the system lifecycle. This encompasses setting appropriate requirements as well as conducting risk management as an integral part of system development.

Separate project SMPs are to be produced both by the Enterprise Project and by the contractor. Each SMP defines the safety activities to be conducted by that organisation, so they are closely related to each other. The programmes that they contain will also be linked to activities of system development, trials and any Safety approvals required. Similarly, the Independent Safety Auditor’s Audit Plan will also be linked to these activities.

This procedure is concerned with the SMP for the Enterprise Project rather than plans produced by the contractor or Independent Safety Auditor.

The SMP details the Enterprise’s Safety Management Activities for the Project and therefore:

  1. Ensures that safety responsibilities are recognised and properly allocated;
  2. Defines the safety programme timescales and so supports the timely completion of tasks and identification of any slippage.

The Enterprise Project SMP forms an essential element of the Through Life Management Plan. Each project requires an SMP describing the measures that will be enacted to demonstrate that the system will be tolerably safe throughout its life.

The publication and agreement of the arrangements detailed in the SMP should be the mechanism through which the Enterprise through-life safety management of the equipment is established. The SMP is the formal record of the way the Enterprise manages safety for a project.

Safety Planning: Procedure

Method

The SMP defines the strategy for addressing safety and interprets the Safety Management System for a specific project. It also contains the safety programme which documents safety timescales, milestones and other date-related information.

The SMP will consider all aspects of equipment safety including, but not restricted to;

  1. General equipment safety;
  2. System specific requirements i.e. Airworthiness, Ship Key Hazards etc.;
  3. Occupational Safety i.e. Manual Handling, Packaging, Transport and Storage, Control of Substances Hazardous to Health etc.;
  4. Safety of operation;
  5. Infrastructure interfaces;
  6. Maintenance;
  7. Training;
  8. Disposal.

The SMP may be based on the template in Annex A. It should not be confused with the requirement of Defence Standard 00-56 for the contractor to produce a Safety Plan.

The SMP should be detailed for the current stage of the acquisition cycle but should also define a workable safety strategy for all the remaining stages, including Disposal. This safety strategy covers both the Enterprise’s input to safety engineering and safety assurance aspects, including Safety Case development and safety approvals.

Devising a general plan is not practical: each plan must be tailored to its project and goals.

See Annex B for an example of a RACI (Responsible, Accountable, Consulted, Informed) Chart which might be used as part of a Project SMP to define the responsibilities and accountabilities of the authorities involved in the implementation of the Enterprise  Project safety programme.

The SMP may cover groups of similar projects within a Delivery Team where common activities are required, although separate committees are envisaged for very large, high risk or diverse projects within a Delivery Team.

Content

The Project SMP should contain the following information: –

  1. Outline description. Description of the equipment, clearly defining the purpose and capability expected (and eventually achieved) of the project. Clearly identify the range, or variants, of the equipment covered, its purpose, operating cycle and environment and defining interfaces with other equipment and levels of competence expected of the operator(s);
  2. Safety Management System. Details of the Safety Management System including its aims and objectives, the managerial and technical tasks to be undertaken and the organisation responsible for implementing them;
  3. Responsibilities and resources. The management structure, responsibilities, resources and interfaces with contractors that are necessary for the implementation of the safety programme. This should include the roles and details of all personnel involved throughout the life of the project. It should include the Team Leader, the individual within the team with formally-delegated safety responsibilities, the Project Safety Manager, Equipment Capability Customer, Maintainers, Users and the Project Safety Committee. The reporting chain should be identified within the plan. A RACI (Responsible, Accountable, Consulted, Informed) Chart should be used to define the responsibilities and accountabilities of the authorities involved in the implementation of the Enterprise Project Safety Programme;
  4. Audit. Details of the audit arrangements for the project, including internal and independent audits;
  5. Requirements, objectives, targets and acceptance. A definition of the safety requirements, objectives, targets, regulation, licensing and certification requirements and acceptance criteria for the project. Details of statutory safety standards, legislation and regulations, and any restrictions or exemptions that may apply. The means and criteria by which the requirements are to be demonstrated and accepted are to be clearly defined (these elements will form part of the technical requirement for the project and will become deliverables under the contract);
  6. Scope of the Safety Case. Clearly identify the range and variants, of the equipment covered, its purpose, operating cycle and environment to be covered e.g. the operating envelope;
  7. Safety Case strategy. The definition of the strategy to be followed for the safety assessment. This should give a full breakdown of all the techniques to be used to identify, analyse, assess and control hazards;
  8. Safety Programme. The programme of work that identifies and schedules the tasks contained in the previous paragraphs. This programme should be linked to key stages in the Through Life Management Plan.

An outline of Project SMP has been provided in Annex A. Additional advice is available from domain-specific safety regulations.

Warnings and Potential Project Risks

The SMP is the principal mechanism for managing project risks associated with safety activities. If the plan is not accurate or is not kept up to date, then the effects of delays in the safety activities or changing project timescales may not be recognised and managed.

If the SMP is not sufficiently detailed, then required safety activities may not be identified and planned into the programme. This may have adverse effects on the project time and cost once the missing activities are recognised and performed. If the requisite activities are not undertaken at all, then either the safety performance may not be adequate, or the necessary safety assurance evidence may not be generated. The former would lead to avoidable accidents and the latter to an inadequate Safety Case that might prevent the system from being accepted into service.

If the SMP is not reviewed and endorsed by the Project Safety Committee (PSC), then it is possible that the Project Safety Management System described in the plan may not be an accurate reflection of the safety responsibilities as understood by other parties. The programme of activities contained in the SMP might not be achievable if the resources required are not available at the times assumed.

Procedure Completion

The PSC is responsible for drafting and endorsing the SMP and agreeing on the safety targets, requirements and acceptance criteria.  It is important that all organisations with safety responsibilities described in the SMP should review the SMP described and agree that it is accurate.

The SMP endorsed by the PSC shall be accepted formally by the Enterprise’s delegated authorities for procurement, support and operation. 

Safety Planning: Timing

Initial Production

The SMP should be produced at the earliest stage of the project, e.g. at the beginning of the Concept stage and be updated as the project progresses through the acquisition stages.

Review, Development and Acceptance

It is recommended that the SMP should be reviewed to a predetermined project programme, particularly if there are major changes to the programme.  It must accurately record arrangements and should be reviewed at each meeting of the PSC, or at least annually.

The SMP endorsed by the PSC shall be accepted formally by the Enterprise-delegated authorities for procurement, support and operation.  When any of the signatories change, the SMP shall be re-issued and formally accepted again by the delegated authorities.

The SMP evolves as the project matures and additional information becomes available or decisions are made.  Early iterations will only outline broad strategies and goals; later iterations will become more definitive.  This will enable important safety management tasks to be carried out during the subsequent acquisition stages.

Safety Planning: Required Inputs

This procedure for Safety Planning requires inputs from:

  1. Outputs from procedure SMP01 – Safety Initiation;
  2. Outputs from procedure SMP02 – Safety Committee.

The SMP must be integrated with other management plans produced by the Project throughout the acquisition cycle to ensure its effectiveness. It shall also be of sufficient detail to stand alone for all safety planning activities.

The development of the SMP will be based on the following:

  1. Overall project programme;
  2. User Requirements Document and System Requirements Document;
  3. Through Life Management Plan;
  4. Existing descriptions of the safety management arrangements for organisations involved in the project (e.g. Delivery Team Safety Management System descriptions).

Safety Planning: Required Outputs

Where relevant, the outputs from this procedure should feed into the following:

  1. System Requirements Document – for any specific Safety requirements;
  2. Customer Supplier Agreement – to document agreements on Safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Outline Business Case and Full Business Case submissions.

PSC meeting minutes should record the review of the SMP and any decisions made regarding its amendment and up-issue.

Safety Planning: Annex A – Template for a Safety Management Plan

TITLE

Title of equipment or system to be procured with Requirement reference number.

DESCRIPTION

A brief description of the project including its purpose and the environment it is to operate in. The scope of the project and interfaces with other equipment are also to be identified.

INVOLVEMENT OF SPECIALIST SAFETY ADVISORS

List any specialist advisors who need to be involved in the programme and send them a copy of this plan where required. Such advisers should include the internal advisors or external regulators or statutory bodies that provide advice.

PROJECT SAFETY MANAGEMENT SYSTEM

A description of the Safety Management System within the Enterprise delivery team to include:

  1. The aims and objectives of the safety management system;
  2. Technical tasks to be undertaken and organisation responsible for implementing them;
  3. Identification of project staff with responsibility for carrying out safety tasks. Include those who are to be issued with letters of delegation;
  4. Cross refer to any relevant project safety documents or reports;
  5. A regime for internal or independent audits of the safety management system;
  6. Details of the project safety panel;
  7. Responsibilities, resources and interfaces with Enterprise, contractor and specialist advisors;
  8. Safety reviews, feedback and reporting procedures;
  9. Transfer arrangements;
  10. Design changes;
  11. Contractor’s trials.

SAFETY REQUIREMENTS

  1. Safety requirements arising from legislation;
  2. Enterprise Certification requirements;
  3. Acceptance criteria;
  4. Safety requirements from the Requirement or;
  5. Safety targets;
  6. Safety-related standards to be applied e.g. British Standards, Defence Standards, International Standards or overseas standards.

PROGRAMME OF WORK

Identify the tasks that will enable the safety requirements to be met and develop this into a schedule of work on a Gantt or PERT chart, link to key stages in the Through Life Management Plan.

SAFETY CASE STRATEGY

This strategy should support the programme of work above. It will give consideration to the types of analyses and testing to be carried out. It will define the scope of work of the safety case and the interfaces with associated equipment safety cases.

APPROVAL

This plan will be approved by a person with delegated authority.

DISTRIBUTION

Plan to be distributed to the management area with responsibility for in-service support. The plan will also be distributed to teams procuring equipment with which the project interfaces and or interacts.

Annex B – RACI Chart example

The SMP should contain a RACI Chart to define which authority is Responsible, Accountable, Consulted or Informed for each of the activities in the Safety Programme. A simple example is given below:

ActivitySafety Delegation HolderProject Safety ManagerIndependent Safety AuditorContractor Project Safety EngineerEquipment User
Safety Case PreparationARIRI
Safety Case EndorsementAIRII
Hazard Log AdministrationAIR
Safety Requirements PreparationARRC

Key: R – Responsible; A – Accountable; C – Consulted; I – Informed

Acknowledgement of Copyright

In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.

Safety Planning: What are Your Questions?

Categories
Blog Safety Management

SMP02 Project Safety Committee

Our Second Safety Management Procedure is the Project Safety Committee. Okay, so committees are not the sexiest subject, but we need to get stakeholders together to make things happen!

Project Safety Committee: Introduction

Definitions

Safety Committee is defined as:

A group of stakeholders that exercises, oversees, reviews and endorses safety management and safety engineering activities.

Def Stan 00-56

Objectives

The key elements for the effective management and delivery of safety are coordination, agreement, and proper response by those authorities with responsibilities for the equipment. 

The PSC brings together those with safety management responsibilities and other stakeholders with relevant specific knowledge, authority, or Subject Matter Expertise. It, therefore:

  1. Provides a forum through which all those with safety responsibilities can ensure effective co-ordination on safety issues;
  2. Provides access for decision-makers to all those with relevant knowledge;
  3. Provides competent oversight of the Safety Case during its development and upkeep;
  4. Provides, through records of its meetings, an audit trail showing that suitable advice has been sought and that safety management decisions were well-founded.

The Enterprise PSC may be supported by Panels, Sub-Committees, or Working Groups with the appropriate level of Subject Matter Expertise and defined Terms of Reference to address specific safety issues.

Although contractors will be members of the Enterprise PSC, they may also need to form and chair their own Safety Committee. Typically this might be necessary on more complex projects where there are multiple sub-contractors. Enterprise will be represented on the Contractor’s Safety Committee to ensure that there is an adequate understanding of the in-service environment and the user’s needs. If there are both Enterprise and Contractor Safety Committees, then they must each have clear Terms of Reference, and their inter-relationship must be well defined.

In Australia, it is a legal requirement for those with safety responsibilities (Duty Holders) to consult, coordinate and cooperate with others. Other countries may use different terms for similar requirements. The bottom line is that it’s a good idea!

Top Tip

Project Safety Committee: Procedure

Membership

The PSC should include representatives, as appropriate, from the following areas:

  1. The Delivery Team (including the Project Safety Manager, and other technical, contracts, and finance officers as required);
  2. Integrated Logistics Support teams;
  3. Equipment support teams;
  4. Customer representatives (project sponsor);
  5. User representatives (Equipment End User);
  6. Trials team;
  7. Maintenance specialists;
  8. Training Authorities;
  9. Prime contractor;
  10. Design organization;
  11. Independent Safety Auditor (if appointed);
  12. Specialist advisors (e.g. from Enterprise, certification authority, or industry safety consultants);
  13. Enterprise Safety Authority; and
  14. Enterprise Safety and Environmental Protection Group.

Other representatives that may be required to participate should include contractors, consultants, subject matter experts, safety sustainable development & continuity, operators, users, and maintainers of the equipment. These should also include reliability and quality managers, (other government departments or representatives of other nation-states governments or departments – for public sector projects.)

However, don’t invite anybody and everybody ‘just in case’, as this devalues the PSC and its work.

Top Tip

More information on PSC membership has been provided at Annex A – example Terms of Reference for a PSC. Further advice is available from QSEP.

Chair

The Committee(s) should be chaired by the safety-competent individual holding formally-delegated responsibility for safety within the Project.  A Letter of Delegation may detail the scope of the delegation holders’ responsibility and authority to carry out the safety management tasks on that program.

Quorum

In order for a PSC to make decisions concerning the safety of a capability or equipment, it should be declared quorate at the beginning of the meeting. In order for a PSC to be declared quorate, the following SQEP and authorized members should be in attendance:

  • Delivery Team safety delegation holder
  • Project Safety Manager
  • Design organization
  • Customer representative (Project Sponsor)
  • Safety Case author

The quorate for a PSC can be expanded depending on the nature of the project. Details should be provided in the Project Safety Management Plan (SMP) or Terms of Reference.

If there are insufficient attendees for the PSC to be declared quorate, the meeting can still proceed with decisions being noted and only implemented once an agreement has been received from the quorum ex-committee. 

This is a good point. PSCs don’t always meet frequently, and getting some members to attend can be challenging. Nevertheless, it is important to keep moving forwards.

Top Tip

Meeting Frequency and Mechanisms

The PSC may meet regularly as a body, or its work may be included as a permanent item in another forum (in this instance care should be taken that all relevant parties are included), or simply through written communications. The key principles are to ensure that all relevant authorities are consulted, actions are agreed upon and properly allocated, and a record is kept of proceedings. A PSC can either be established for a single type of equipment, or a family of variants of equipment.

Smaller projects may choose to integrate the PSC activities with other meetings. As a minimum, the discussion of safety issues should remain a unique item on meeting agendas.

Working Level Support

Depending on the complexity of the project, one or more working groups may be established that support the PSC by assessing hazards or reviewing the integrity of specific systems. Integrity working groups could consider structure, propulsion or other electrical or mechanical systems, reporting significant issues to the PSC.

Safety Management Committee

Where a number of similar equipment are managed in a single Delivery Team, consideration should be given to establishing a top-level Safety Management Committee (SMC) to set out and agree on the safety management policy and strategy for those projects. The strategy would detail the formation of PSCs for individual equipment, or groups of similar equipment e.g. radio systems, or support vehicles rather than a type of radio or vehicle.

The SMC will monitor and control the activities of the individual PSCs, which will operate in accordance with their own SMPs. Structures can be tailored to suit individual circumstances. Terms of Reference, including membership, for an SMC, should be similar to that of a PSC. The safety management policy and strategy for those projects will be recorded in a Safety Management System document, similar to an SMP. Figure 2.1 shows an example of a Safety Committee structure, together with the management documents that sit at the relevant committee level.

Figure 2.1 – Safety Committee Structure

Safety Committee Structure

Figure 2.1 represents an example of a Safety Committee structure, with supporting working groups and hazard reviews in place. Teams can modify the structure of the Safety Committees to suit the specific organization of the program. The emphasis should be on establishing a Safety Committee with suitable chairmanship and Terms of Reference.

The structure shown in Figure 2.1 would be suitable for a large Program managing several important projects. However, it is probably overkill for most projects. With committees, less is sometimes more.

Top Tip

Project Safety Committee Authority and Competence

The chairman of the PSC should hold a Letter of Delegation detailing the authority for carrying out the safety management tasks on that program.

The PSC exists to provide information and specialist advice to those who have specific responsibility for safety management on an acquisition project so that they can reach informed decisions. The Project safety delegation holder is required to seek and consider relevant advice through the PSC but remains the decision-maker.

Whilst not all members of the PSC need to have specific competence and experience in Safety Management, it is essential that some committee members do have this competence and are consulted.  In addition to the safety delegation holder, whose competence must be established prior to their delegation being issued, other members of the PSC who must be safety competent would typically include the Project Safety Manager and the Independent Safety Auditor (if appointed).

As a minimum, the Project Safety Manager should have system safety competence at the practitioner level.  Competence requirements for the safety delegation holder will be defined in a relevant Assignment Specification.

The level of competence needed is driven by many factors – size, complexity, novelty – and this will be discussed under a post on ‘Proportionality’ (TBD).

Top Tip

Where it is considered beneficial, a combined committee may be established for the safety and environmental management activities. It should be ensured that the programs are aligned as far as possible and that data is shared where relevant.

It is suggested that where there are separate safety and environmental committees, these meet consecutively over the morning and afternoon – with membership and specialists attending as appropriate to each.

The PSC may cover groups of similar projects within a Delivery Team where common activities are required, although separate committees are envisaged for very large, high risk or diverse projects within a Delivery Team.

The PSC may meet regularly as a body, or its work may be included as a permanent item in another forum (in this instance care should be taken that all relevant parties are included), or simply through written communications. This last option is less desirable because there is no opportunity for direct interaction.

Records and Project Documentation

The records from this procedure will consist of PSC meeting minutes which should record the following:

  1. Those present;
  2. The discussions;
  3. Advice given;
  4. Decisions made;
  5. Recommendations to those with delegated authority for safety management; and
  6. Actions agreed.

Where relevant, the outputs from this procedure will feed into the following:

  1. System Requirements Document – for any specific safety requirements;
  2. Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Outline Business Case and Full Business Case submissions.

Review and Agreement of Safety Documents

The role of the PSC includes reviewing safety documents and advising the safety delegation holder on their suitability. The agreement that the document is suitable can be signified in various ways and the Project Director should define, which is required. Methods for recording the review and its findings could include:

  1. Formal sign off of the document by all members of the PSC;
  2. A recommendation, recorded in PSC minutes, that the document is satisfactory and can be authorized for release by the agreed signatory.

Warnings and Potential Project Risks

If the PSC is not established early in the acquisition life cycle, then some of the stakeholders involved may not be identified and their needs may not be addressed adequately in the development of the safety requirements or the production of the SMP. This could also occur if the PSC is established with an incomplete membership.

If the PSC does not review and approve the safety tasks described in the SMP, then the activities may be inappropriate to deliver the required levels of safety performance and safety assurance.

If the PSC does not review and approve the Safety Management System described in the SMP, then they may not identify areas of disagreement concerning responsibilities for safety.

Beware of the PSC delving into detail and doing what is expedient, rather than was is needed. Set appropriate TORs and agendas and stick to them.

Tip Top

If the PSC does not meet with sufficient frequency, then they may not identify in a timely manner, any issues with the safety program. This could result in impacts on project time and cost.

If the PSC attempts to control the detailed design solutions, rather than relying on the contractor’s Safety Committee and design function, then Enterprise will take responsibility from the designer. Enterprise staff will be represented on the contractor’s Safety Committee and shall exercise influence at that forum and through setting appropriate requirements.

Procedure Completion

Delivery Teams will complete the procedure, in conjunction with advice and information from members of the PSC.

Project Safety Committee: Timing

Formation

The PSC should be established during the Concept phase of a project by the Customer, or Requirements Manager, through the Capability Working Group, in conjunction with the relevant Project Director, to set out the safety requirements for the equipment.

The PSC has an important role to play in influencing safety requirements. This is not mentioned in ‘PSC: Required Outputs’, below, but is possibly the PSC’s most important contribution.

Top Tip

Meetings

The required frequency of the PSC meetings depends on various factors including the stage of the project, the complexity of the system, and whether the PSC is supported by Working Groups or has complete responsibility.  Meetings will be required at greater frequency during periods of significant review and decision making, typically when project milestones are approaching.

PSC meetings may occur less frequently during periods of stability, such as during the in-service phase, when fewer safety decisions are necessary.  However, the PSC still has an important duty to provide oversight of the Safety Case and ensure that it remains valid and monitoring safety performance.  This will include considering whether the system or its usage is changing and seeking counter-evidence that shows the predicted level of safety performance is not being achieved in practice.

Project Safety Committee: Required Inputs

The procedure may use the following reference inputs, as available:

  1. Outputs from procedure SMP01 – Safety Initiation;
  2. Documents to be reviewed such as:
    1. Project Safety Management Plan;
    2. Independent Safety Auditor Audit Plan (if appointed);
    3. Independent Safety Auditor Audit Report (if appointed);
    4. Other Safety Audit Plans (e.g. self or Peer audit);
    5. Safety Audit Report;
    6. Hazard Log Report;
    7. Safety Requirements;
    8. Safety Assessment Report;
    9. Safety Case Report.
  3. Acquisition System Guidance Functional Competencies for System Safety Management;
  4. Records of previous meetings of the Safety Committee.

Project Safety Committee: Required Outputs

The outputs of the procedure will comprise:

  1. Established Safety Committee membership;
  2. Defined Terms of Reference for the Safety Committee (see Further Guidance – Examples Terms of Reference for Project Safety Committee);
  3. Records of Safety Committee meetings, including advice given and the actions, agreed;
  4. The advice given by members of the Safety Committee should include recommendations on whether a reviewed document (e.g. Safety Management Plan or Safety Case Report) should be authorized by the Project Director. If authorization is not recommended, then the reasons should be recorded.

Annex A

Example Terms of Reference for Project Safety Committee

Terms of Reference for – Project XXXX

Purpose:

To provide a forum for monitoring and coordinating all safety management and risk reduction activities associated with the project to ensure effective levels of safety and provide an appraisal of the Safety Case. The Project Safety Committee reports to the Project Director or in a larger Delivery Team to the Safety Management Committee.

Tasks:

  1. To set and keep under review the project’s safety policy and strategy;
  2. To set and keep under review the project’s safety targets and objectives;
  3. To define the system boundaries for safety responsibility;
  4. To advise the Chairperson of the Safety Committee on the safety responsibilities of each authority associated with the project;
  5. To advise the Chairperson of the Safety Committee on the standards, statutory regulations, and any restrictions with which the projects should comply;
  6. To review, monitor, classify and allocate new equipment hazards as they are identified;
  7. To carry out reviews of the project’s Safety Case and progress on achieving safety targets, to a predetermined program, issuing the results to the Delegated Authority;
  8. To agree on any control measures that are deemed necessary to reduce identified risks to ALARP;
  9. To ensure proper and timely availability of training and issue of documentation;
  10. To carry out actions from ISA, regulatory or internal audit findings;
  11. To operate a system for reviewing and monitoring safety performance and maintain the Safety Case.

Membership:

  1. Delivery Team responsible for the procurement aspects of the project;
  2. Customer representative (Capability or Equipment Customer);
  3. Safety Officer (if appointed);
  4. Design organization;
  5. Delivery Team responsible for the support aspects of the project;
  6. Equipment User;
  7. Training Authority;
  8. Maintainer;
  9. Maintenance Authority;
  10. Specialist Advisors (as required):
    1. Defense Safety Regulators;
    2. Defense Ordnance Safety Group;
    3. Land Accident Prevention and Investigation Team;
    4. Military Aviation Accident Investigation Team;
    5. Serious Equipment Failure Investigation Team;
    6. Independent Safety Auditor;
    7. Interfacing Delivery Teams;
    8. Technical Specialists.

Acknowledgment of Copyright

In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.

Project Safety Committee: Who would You Include?