System Hazard Analysis with Mil-Std-882E
In this 45-minute session, I look at System Hazard Analysis with Mil-Std-882E. SHA is Task 205 in the Standard. I explore Task 205's aim, description, scope, and contracting requirements.

I also provide commentary, based on working with this Standard since 1996, which explains SHA. How to use it to complement Sub-System Hazard Analysis (SSHA, Task 204). How to get the maximum benefits from your System Safety Program.

Using Task 205 effectively is not just a matter of applying it in number order with the other Tasks. We need to use it within the Systems Engineering framework. That means using it top-down, to set requirements, and bottom-up to verify that they are met.

https://youtu.be/F70fhSGsyLk
This is the seven-minute-long demo. The full video is 47 minutes long.

get the course 'system hazard analysis': click here

System Hazard Analysis: Topics

- Task 205 Purpose ;

- Verify subsystem compliance;

- ID hazards (subsystem interfaces and faults);

- ID hazards (integrated system design); and

- Recommend necessary actions.

- Task Description (five slides);

- Reporting;

- Contracting; and

- Commentary.

Transcript: System Hazard Analysis with Mil-Std-882E

Introduction

Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial safety training resources and videos. I’m Simon, your host, and I’m recording this on the 13th of April 2020. And given the circumstances when I record this, I hope this finds you all well.

System Hazard Analysis Task 205

Let's get on to our topic for today, which is System Hazard Analysis. Now, system hazard analysis is, as you may know, Task 205 in the Mil-Std-882E system safety standard.

Topics for this Session

What we're going to cover in this session is purpose, task description, reporting, contracting, and some commentary – although I'll be making commentary all the way through. Going back to the top, the yellow highlighting with this (and with Task 204), I'm using the yellow highlighting to indicate differences between 205 and 204 because they are superficially quite similar. And then I'm using underlining to emphasize those things that I want to bring to your attention and emphasize.

Within Task 205, Purpose. We've got four purpose slides for this one. Verify subsistent compliance and recommend necessary actions – fourth one there. And then in the middle of the sandwich, we've got the identification of hazards, both between the subsystem interfaces and faults from the subsystem propagating upwards to the overall system and identifying hazards in the integrated system design. So, quite a different emphasis to 204, which was thinking about subsystems in isolation. We’ve got five slides of task description, a couple on reporting, one on contracting – nothing new there – and several commentaries.

System Requirements Hazard Analysis (T205)

Let's get straight on with it. The purpose, as we've already said, there is a three-fold purpose here; Verify system compliance, hazard identification, and recommended actions, and then, as we can see in the yellow, the identifying previously unidentified hazards is split into two. Looking at subsystem interfaces and faults and the integration of the overall system design. And you can see the yellow bit, that's different from 204 where we are taking this much higher-level view, taking an inter-subsystem view and then an integrated view.

Task Description (T205) #1

On to the task description. The contract has got to do it and document, as usual, looking at hazards and mitigations, or controls, in the integrated system design, including software and human interface. We must come onto that later.

All the usual stuff about we've got to include COTS, GOTS, GFE, and NDI. So, even if stuff is not being developed, if we're putting together a jigsaw system from existing pieces, we've still got to look at the overall thing. And as with 204, we go down to the underlined text at the bottom of the slide, areas to consider. Think about performance, and degradation of performance, functional failures, timing and design errors, defects, inadvertent functioning – that classic functional failure analysis that we've seen before.

Again, while conducting this analysis, we’ve got to include human beings as an integral component of the system, receiving inputs, and initiating outputs.  Human factors were included in this standard from long ago...

The End

You can find a free pdf of the System Safety Engineering Standard, Mil-Std-882E, here.

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.
#Milstd882Technique #Milstd882Training #Milstd882tutorial #Milstd882Video #MilStd882E #Milstd882eTechnique #Milstd882eTraining #Milstd882etutorial #Milstd882eVideo #SafetystandardTechnique #SafetystandardTraining #Safetystandardtutorial #SafetystandardVideo #SHA #systemhazardanalysis #systemhazardanalysisTechnique #systemhazardanalysisTraining #systemhazardanalysistutorial #systemhazardanalysisVideo #SystemsafetyengineeringTechnique #systemsafetyengineeringtraining #Systemsafetyengineeringtutorial #SystemsafetyengineeringVideo #Task205
Simon Di Nucci https://www.safetyartisan.com/?p=480

System Safety Principles

In this 45-minute video, I discuss System Safety Principles, as set out by the US Federal Aviation Authority in their System Safety Handbook. Although this was published in 2000, the principles still hold good (mostly) and are worth discussing. I comment on those topics where the modern practice has moved on, and those jurisdictions where the US approach does not sit well.



https://youtu.be/sG7D2Am5crg

This is the ten-minute preview of the full, 45-minute video.



Get the full lesson as part of the FREE Learning Triple Bundle.



System Safety Principles: Topics



- Foundational statement



- Planning



- Management Authority



- Safety Precedence



- Safety Requirements



- System Analyses Assumptions & Criteria



- Emphasis & Results



- MA Responsibilities



- Software hazard analysis



- An Effective System Safety Program



System Safety Principles: Transcript



Hello and welcome to The Safety Artisan where you will find professional pragmatic and impartial educational products. I’m Simon and it’s the 3rd of November 2019. Tonight I’m going to be looking at a short introduction to System Safety Principles.



Introduction



On to system safety principles; in the full video we look at all principles from the U.S. Federal Aviation Authority’s System Safety Handbook but in this little four- or five-minute video – whatever it turns out to be – we’ll take a quick look just to let you know what it’s about.



Topics for this Session



These are the subjects in the full session. Really a fundamental statement; we talk about planning; talk about the management authority (which is the body that is responsible for bringing into existence -in this case- some kind of aircraft or air traffic control system, something like that, something that the FAA would be the regulator for in the US).



We talk about safety precedents. In other words, what’s the most effective safety control to use. Safety requirements; system analyses – which are highlighted because that’s just the sample I’m going to talk about, tonight; assumptions and safety criteria; emphasis and results – which is really about how much work you put in where and why; management authority responsibilities; a little aside of a specialist area – software hazard analysis; And finally, what you need for an effective System Safety Program.



Now, it’s worth mentioning that this is not an uncritical look at the FAA handbook. It is 19 years old now so the principles are still good, but some of it’s a bit long in the tooth. And there are some areas where, particularly on software, things have moved on. And there are some areas where the FAA approach to system safety is very much predicated on an American approach to how these things are done.  



Systems Analysis



So, without further ado, let’s talk about system analysis. There are two points that the Handbook makes. First of all, these analyses are basic tools for systematically developing design specifications. Let’s unpack that statement. So, the analyses are tools- they’re just tools. You’ve still got to manage safety. You’ve still got to estimate risk and make decisions- that’s absolutely key. The system analyses are tools to help you do that. They won’t make decisions for you. They won’t exercise authority for you or manage things for you. They’re just tools.



Secondly, the whole point is to apply them systematically. So, coverage is important here- making sure that we’ve covered the entire system. And also doing things in a thorough and orderly fashion. That’s the systematic bit about it.



And then finally, it’s about developing design specifications. Now, this is where the American emphasis comes in. But before we talk about that, it’s fundamental to note that really we need to work out what our safety requirements are.



What are we Trying to Achieve?



What are we trying to achieve here with safety? And why? These are really important concepts because if you don’t know what you’re trying to achieve then it will be very difficult to get there and to demonstrate that you’ve got there - which is kind of the point of safety. Putting effort into getting the requirements right is very important because without doing that first step all your other work could be invalid. In my experience of 20-plus years in the business, if you don’t have a precise grasp of what you’re trying to achieve then you’re going to waste a lot of time and money, probably.



So, onto the second bullet point. Now the handbook says that the ultimate measure of safety is not the scope of analysis but in satisfying requirements. So, the first part – very good. We’re not doing analysis for the sake of it. That’s not the measure of safety – that we’ve analyzed something to death or that we’ve expended vast amounts of dollars on doing this work but that we’ve worked out the requirements and the analysis has helped us to meet them. That is the key point.



Safety in Different Jurisdictions



This is where it can go slightly pear-shaped in that this emphasis on requirements (almost to the exclusion of anything else) is a very U.S.-centric way of doing things. So, very much in the US, the emphasis is you meet the spec, you certify that you’ve met spec and therefore we’re safe. But of course what if the spec is wrong? Or what if it’s just plain inappropriate for a new use of an existing system or whatever it might be?



In other jurisdictions, notably the U.K. (and as you can tell from my accent that’s where I’m from, I’ve got a lot of experience doing safety work in the U.K. but also Australia where I now live and work) it’s not about meeting requirements. Well, it is but let me explain. In the UK and Australia, English law works on the idea of intent.



So, we aim to make something safe: not whether it has that it’s necessarily met requirements or not, that doesn’t really matter so much, but is the risk actually reduced to an acceptable level? There are tests for deciding what is acceptable. Have you complied with the law? The law outside the US can take a very different approach to “it’s all about the specification”.



Not Just the Specification



Of course, those legal requirements and that requirement to reduce risk to an acceptable level, are, in themselves, requirements. But in Australian or British legal jurisdiction, you need to think about those legal requirements as well. They must be part of your requirements set.



So, just having a specification for a technical piece of cake that ignores the requirements of the law, which include not only design requirements but the thing is actually safe in service and can be safely introduced, used, disposed of, etc. If you don’t take those things into account you may not meet all your obligations under that system of law.



So, there’s an important point to understanding and using American standards and an American approach to system safety out of the assumed context. And that’s true of all standards and all approaches but it’s a point I bring out in the main video quite forcefully because it’s very important to understand.



Get the full lesson as part of the FREE Learning Triple Bundle.



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.

#coursesafetyengineering #engineersafety #FederalAviationAdministration #ineedsafety #knowledgeofsafety #learnsafety #needforsafety #safetyblog #safetydo #safetyengineer #safetyengineerskills #safetyengineertraining #safetyengineeringcourse #safetyprinciples #softwaresafety #systemsafety #systemsafetyengineering #systemsafetyhandbook #systemsafetyprinciples #theneedforsafety

Simon Di Nucci https://www.safetyartisan.com/2022/08/17/in-full-system-safety-principles/

Safety Concepts Part 2

In this 33-minute session, Safety Concepts Part 2, The Safety Artisan equips you with more Safety Concepts. I look at the basic concepts of safety, risk, and hazard in order to understand how to assess and manage them.



Exploring these fundamental topics provides the foundations for all other safety topics, but it doesn't have to be complex. The basics are simple, but they need to be thoroughly understood and practiced consistently to achieve success. This video explains the issues and discusses how to achieve that success.



https://youtu.be/TBaS32cWsRg

Highlights of Safety Concepts, Part 2 video.



Get the full-length Lesson as part of the FREE Triple Learning Bundle.



Safety Concepts Part 2: Topics



- Risk & Harm;



- Accident & Accident Sequence;



- (Cause), Hazard, Consequence & Mitigation;



- Requirements / Essence of System Safety;



- Hazard Identification & Analysis;



- Risk Reduction / Estimation;



- Risk Evaluation & Acceptance;



- Risk Management & Safety Management; and



- Safety Case & Report.



Safety Concepts Part 2: Transcript



Click Here for the Transcript

Hi everyone, and welcome to the safety artisan where you will find professional, pragmatic, and impartial advice on safety. I’m Simon, and welcome to the show today, which is recorded on the 23rd of September 2019. Today we’re going to talk about system safety concepts. A couple of days ago I recorded a short presentation (Part 1) on this, which is also on YouTube.  Today we are going to talk about the same concepts but in much more depth.



In the short session, we took some time picking apart the definition of ‘safe’. I’m not going to duplicate that here, so please feel free to go have a look. We said that to demonstrate that something was safe, we had to show that risk had been reduced to a level that is acceptable in whatever jurisdiction we’re working in.



And in this definition, there are a couple of tests that are appropriate that the U.K., but perhaps not elsewhere. We also must meet safety requirements. And we must define the Scope and bound the system that we’re talking about a Physical system or an intangible system like a computer program. We must define what we’re doing with it and what it’s being used for. And within which operating environment within which context is being used.  And if we could do all those things, then we can objectively say - or claim - that the system is safe.



Topics



We’re going to talk about a lot more Topics. We’re going to talk about risk accidents. The cause has a consequence sequence. They talk about requirements and. Spoiler alert. What I consider to be the essence of system safety. And then we’ll get into talking about the process. Of demonstrating safety, hazard identification, and analysis.



Risk Reduction and estimation. Risk Evaluation. And acceptance. And then pulling it all together. Risk management safety management. And finally, reporting, making an argument that the system is safe supporting with evidence. And summarizing all of that in a written report. This is what we do, albeit in different ways and calling it different things.



Risk



Onto the first topic. Risk and harm.  Our concept of risk. It’s a combination of the likelihood and severity of harm. Generally, we’re talking about harm. To people. Death. Injury. Damage to help. Now we might also choose to consider any damage to property in the environment. That’s all good. But I’m going to concentrate on harm to people. Because usually, that’s what we’re required to do. By the law. And there are other laws covering the environment and property sometimes. That. We’re not going to talk.  just to illustrate this point. This risk is a combination of Severity and likelihood.



We’ve got a very crude. Risk table here. With a likelihood along the top. And severity. Downside. And we might. See that by looking at the table if we have a high likelihood and high severity. Well, that’s a high risk. Whereas if we have Low Likelihood and low severity. We might say that’s a low risk. And then. In between, a combination of high and low we might say that’s medium. Now, this is a very crude and simple example. Deliberately.



You will see risk matrices like this. In. Loads of different standards. And you may be required to define your own for a specific system, there are lots of variations on this but they’re all basically. Doing this thing and we’re illustrating. How do we determine the level of risk. By that combination of severity. And likely, I think a picture is worth a thousand words. Moving online to the accident. We’re talking about (in this standard) an unintended event that causes harm.



Accidents, Sequences and Consequences



Not all jurisdictions just consider accidental events, some consider deliberate harm as well. We’ll leave that out. A good example of that is work health and safety in Australia but no doubt we’ll get to that in another video sometime. And the accident sequences the progression of events. That results in an accident that leads to an. Now we’re going to illustrate the accident sequence in a moment but before we get there. We need to think about cousins.  here we’ve got a hazardous physical situation or state of a system. Often following some initiating event that may lead to an accident, a thing that may cause harm.



And then allied with that we have the idea of consequences. Of outcomes or an outcome. Resulting from. An. Event. Now that all sounds a bit woolly doesn’t it, let’s illustrate that. Hopefully, this will make it a lot clearer. Now. I’ve got a sequence here. We have. Causes. That might lead to a hazard. And the hazard might lead to different consequences. And that’s the accident. See. Now in this standard, they didn’t explicitly define causes.



Cause, Hazard, and Consequence



They’re just called events. But most mostly we will deal with causes and consequences in system safety. And it’s probably just easier to implement it. Whether or not you choose to explicitly address every cause. That’s often an optional step. But this is the accident Sequence that we’re looking at. These sorts of funnels are meant to illustrate the fact that they may be many causes for one hazard. And one has it may lead to many consequences on some of those consequences. Maybe. No harm at all.



We may not actually have an accident. We may get away with it. We may have a. Hazard. And. Know no harm may befall a human. And if we take all of this together that’s the accident sequence. Now it’s worth reiterating that just because a hazard exists, it does not necessarily lead to harm. But to get to harm, we must have a hazard; a hazard is both necessary and sufficient. To lead to harmful consequences. OK.



Hazards: an Example



And you can think of a hazard as an accident waiting to happen. You can think of it in lots of different ways, let’s think about an example, the hazard might be. Somebody slips. Okay well while walking and all. That slip might be caused by many things it might be a wet surface. Let’s say it’s been raining, and the pavement is slippery, or it might be icy. It might be a spillage of oil on a surface, or you’d imagine something slippery like ball bearings on a surface.



So, there’s something that’s caused the surface to become slippery. A person slips – that’s the hazard. Now the person may catch themselves; they may not fall over. They may suffer no injury at all. Or they might fall and suffer a slight injury; and, very occasionally, they might suffer a severe injury. It depends on many different factors. You can imagine if you slipped while going downstairs, you’re much more likely to be injured.



And younger, healthy, fit people are more likely to get over a fall without being injured, whereas if they’re very elderly and frail, a fall can quite often result in a broken bone. If an elderly person breaks a bone in a fall the chances of them dying within the next 12 months are quite high. They’re about one in three.



So, the level of risk is sensitive to a lot of different factors. To get an accurate picture, an accurate estimate of risk, we’re going to need to factor in all those things. But before we get to that, we’ve already said that hazards need not lead to harm. In this standard, we call it an incident, where a hazard has occurred; it could have progressed to an accident but didn’t, we call this an incident. A near miss.



We got away with it. We were lucky. Whatever you want to call it. We’ve had an incident but no he’s been hurt. Hopefully, that incident is being reported, which will help us to prevent an actual accident in the future.  That’s another very useful concept that reminds us that not all hazards result in harm. Sometimes there will be no accident. There will be no harm simply because we were lucky, or because someone present took some action to prevent harm to themselves or others.



Mitigation Strategies (Controls)



But we would really like to deliberately design out or avoid Hazards if we can. What we need is a mitigation strategy, we need a measure or measures that, when we put them into practice, reduce that risk. Normally, we call these things controls. Again, now we’ve illustrated this; we’ve added to the funnels. We’ve added some mitigation strategies and they are the dark blue dashed lines.



And they are meant to represent Barriers that prevent the accident sequence from progressing towards harm. And they have dashed lines because very few controls are perfect, you know everything’s got holes in it. And we might have several of them. But usually, no control will cover all possible causes, and very few controls will deal with all possible consequences.  That’s what those barriers are meant to illustrate.



That idea that picture will be very useful to us later. When we are thinking about how we’re going to estimate and evaluate risk overall and what risk reduction we have achieved. And how we talk about justifying what we’ve done is good. That’s a very powerful illustration. Well, let’s move on to safety requirements.



Safety Requirements



Now. I guess it’s no great surprise to say that requirements, once met, can contribute directly to the safety of the system. Maybe we’ve got a safety requirement that says all cars will be fitted with seatbelts. Let’s say we’ll be required to wear a seatbelt.  That makes the system safer.



Or the requirement might be saying we need to provide evidence of the safety of the system. And, the requirement might refer to a process that we’ve got to go through or a set kind of evidence that we’ve got to provide. Safety requirements can cover either or both of these.



The Essence of System Safety



Requirements. Covering. Safety of the system or demonstrating that the system is safe. Should give us assurance, which is adequate confidence or justified confidence. Supported with evidence by following a process. And we’ll talk more about the process. We meet safety requirements. We get assurance that we’ve done the right thing. And this really brings us to the essence of what system safety is, we’ve got all these requirements – everything is a requirement really – including the requirement. To demonstrate risk reduction.



And those requirements may apply to the system itself, the product. Or they may provide, or they may apply to the process that generates the evidence or the evidence. Putting all those things together in an organized and orderly way really is the essence of system safety, this is where we are addressing safety in a systematic way, in an orderly way. In an organized way. (Those words will keep coming back). That’s the essence of system safety, as opposed to the day-to-day task of keeping a workplace safe.



Maybe by mopping up spills and providing handrails, so people don’t slip over. Things like that. We’re talking about a more sophisticated level of safety. Because we have a more complex problem a more challenging problem to deal with. That’s system safety. We will start on the process now, and we begin with hazard identification and analysis; first, we need to identify and list the hazards, the Hazards and accidents associated with the system.



We’ve got a system, physical or not. What could go wrong? We need to think about all the possibilities. And then having identified some hazards we need to start doing some analysis, we follow a process. That helps us to delve into the detail of those hazards and accidents. And to define and understand the accident sequences that could result. In fact, in doing the analysis we will very often identify some more hazards that we hadn’t thought of before, it’s not a straight-through process it tends to be an iterative process.



Risk Reduction



And ultimately what we’re trying to do is reduce risk, we want a systematic process, which is what we’re describing now. A systematic process of reducing risk. And at some point, we must estimate the risk that we’re left with. Before and after all these controls, these mitigations, are applied. That’s risk estimation.  Again, there’s that systematic word, we’re going to use all the available information to estimate the level of risk that we’ve got left. Recalling that risk is a combination of severity and likelihood.



Now as we get towards the end of the process, we need to evaluate risk against set criteria. And those criteria vary depending on which country you’re operating in or which industry we’re in: what regulations apply and what good practice is relevant. All those things can be a factor. Now, in this case, this is a U.K. standard, so we’ve got two tests for evaluating risk. It’s a systematic determination using all the available evidence. And it should be an objective evaluation as far as we can make it.



Risk Evaluation



We should use certain criteria on whether a risk can be accepted or not. And in the U.K. there are two tests for this. As we’ve said before, there is ALARP, the ‘As Low As is Reasonably Practicable’ test, which says: Have we put into practice all reasonably practicable controls? (To reduce risk, this is a risk reduction target). And then there’s an absolute level of risk to consider as well. Because even if we’ve taken all practical measures, the risk remaining might still be so high as to be unacceptable to the law.



Now that test is specific to the U.K, so we don’t have to worry too much about it. The point is there are objective criteria, which we must test ourselves or measure ourselves against. An evaluation that will pop out the decision, as to whether a further risk reduction is necessary if the risk level is still too high. We might conclude that are still reasonably practicable measures that we could take. Then we’ve got to do it.



We have an objective decision-making process to say: have we done enough to reduce risk? And if not, we need to do some more until we get to the point where we can apply the test again and say yes, we’ve done enough. Right, that’s rather a long-winded way of explaining that. I apologize, but it is a key issue and it does trip up a lot of people.



Risk Acceptance



Now, once we’ve concluded that we’ve done enough to reduce risk and no further risk reduction is necessary, somebody should be in a position to accept that risk.  Again, it’s a systematic process, by which relevant stakeholders agree that risks may be accepted. In other words, somebody with the right authority has said yes, we’re going to go ahead with the system and put it into practice, implement it. The resulting risks to people are acceptable, providing we apply the controls.



And we accept that responsibility.  Those people who are signing off on those risks are exposing themselves and/or other people to risk. Usually, they are employees, but sometimes members of the public as well, or customers. If you’re going to put customers in an airliner you’re saying yes there is a level of risk to passengers, but that the regulator, or whoever, has deemed to be acceptable. It’s a formal process to get those risks accepted and say yes, we can proceed. But again, that varies greatly between different countries, between different industries. Depending on what regulations and laws and practices apply. (We’ll talk about different applications in another section.)



Risk Management



Now putting all this together we call this risk management.  Again, that wonderful systematic word: a systematic application of policies, procedures, and practices to these tasks. We have hazard identification, analysis, risk estimation, risk evaluation, risk reduction & risk acceptance. It’s helpful to demonstrate that we’ve got a process here, where we go through these things in order. Now, this is a simplified picture because it kind of implies that you just go through the process once.



With a complex system, you go through the process at least once. We may identify further hazards when we get into Hazard Analysis and estimating risk. In the process of trying to do those things, even as late as applying controls and getting to risk acceptance. We may discover that we need to do additional work. We may try and apply controls and discover the controls that we thought were going to be effective are not effective.



Our evaluation of the level of risk and its acceptability is wrong because it was based on the premise that controls would be effective, and we’ve discovered that they’re not, so we must go back and redo some work. Maybe as we go through, we even discover Hazards that we hadn’t anticipated before. This can and does happen, it’s not necessarily a straight-through process. We can iterate through this process. Perhaps several times, while we are moving forward.



Safety Management



OK, Safety Management. We’ve gone to a higher level really than risk because we’re thinking about requirements as well as risk. We’re going to apply organization, we’re going to apply management principles to achieve safety with high confidence. For the first time, we’ve introduced this idea of confidence in what we’re doing. Well, I say the first time, this is insurance isn’t it? Assurance, having justified confidence, or appropriate confidence because we’ve got the evidence. And that might be product evidence too we might have tested the product to show that it’s safe.



We might have analyzed it. We might have said well we’ve shown that we follow the process that gives us confidence that our evidence is good. And we’ve done all the right things and identified all the risks.  That’s safety management. We need to put that in a safety management system, we’ve got a defined organizational structure, and we have defined processes, procedures, and methods. That gives us direction and control of all the activities that we need to put together in combination to effectively meet safety requirements and safety policy.



And our safety tests, whatever they might be. More and more now we’re thinking about top-level organization and planning to achieve the outcomes we need. With a complex system, a complex operating environment, and a complex application.



Safety Planning



Now I’ll just mention planning. Okay, we need a safety management plan that defines the strategy: how we’re going to get there, how are we going to address safety. We need to document that safety management system for a specific project. Planning is very important for effective safety. Safety is very vulnerable to poor planning. If a project is badly planned or not planned at all, it becomes very difficult to Do safety effectively, because we are dependent on the process, on following a rigorous process to give us confidence that all results are correct.  If you’ve got a project that is a bit haphazard, that’s not going to help you achieve the objectives.



Planning is important. Now the bit of that safety plan that deals with timescales, milestones, and other date-related information. We might refer to it as a safety program. Now being a UK Definition, British English has two spellings of program. The double-m-e-version of programme.

#10basicprinciplesofsafety #5digitalsafetyrules #basicprinciplesofsafety #defstan0056 #defencestandard0056 #differencebetweensafeandsafety #Safetyconcept #safetyconcepts #safetydefinitioninenglish #safetydefinitioninnebosh #safetyengineering #safetyofprincipaldefinition #safetyprinciple #safetyprinciplesandpractices #systemsafetyconcepts #systemsafetytraining #whatarethe3principlesofsafety

Simon Di Nucci https://www.safetyartisan.com/2022/08/03/system-safety-concepts-full-version/

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!

#hazardcontrollog #hazardlogexample #hazardlogform #hazardmonitoringsystem #hazardtracking #hazardtrackinglog #hazardtrackingsystemtemplate #howmanyhazardcategoriesarethere #riskmanagementtrackingtools #risktrackingandreporting #risktrackinginprojectmanagement #risktrackingprocess #risktrackingsoftware #whatisahazardlog

Simon Di Nucci https://www.safetyartisan.com/2022/07/20/hazard-logs-a-brief-summary/

Australian WHS Course

In this Australian WHS Course, we show you how to practically and pragmatically implement the essential elements of Australian Work Health and Safety Legislation. In particular, we look at the so-called 'upstream' WHS duties. These are the elements you need to safely introduce systems and services into the Australian market.



Lessons in This Course



A Guide to the Australian WHS Act



Image by Wendy Van Zyl, from Pexels



This Guide to the WHS Act covers many topics of interest to system safety and design safety specialists, this full-length video covers key sections (§) of the Act:



- § 3, Object ;



- § 4-8, Definitions;



- § 12A, Exclusions;



- § 18, Reasonably Practicable;



- § 19, Primary Duty of Care;



- § 22-26, Duties of Designers, Manufacturers, Importers, Suppliers & those who Install/Construct/Commission;



- § 27, Officers & Due Diligence;



- § 46-49, Consult, Cooperate & Coordinate;



- § 152, Function of the Regulator; and



- § 274-276, WHS Regulations and CoP.



The Consultation, Cooperation & Coordination Code of Practice



Photo by August de Richelieu from Pexels.com



In this 30-minute session, we look at the Consultation, Cooperation & Coordination Code of Practice (CC&C CoP). We cover the Commonwealth and Model versions of the CoP, appendices & a summary of detailed requirements; and further commentary. This CoP is one of the two that are generally applicable.



Topics:



- CC&C in the Federal or Commonwealth CoP;



- Extra CC&C in the Model CoP;



- (Watch out for Jurisdiction);



- Further commentary; and



- Where to get more information.



The Risk Management CoP



Photo by Marta Branco from Pexels



In this 40-minute session, we look at the Risk Management Code of Practice (CoP). We cover: who has WHS duties; the four-step process; keeping records, appendices & a summary of detailed requirements; and further commentary. This CoP is the other one of the two that are generally applicable.



Topics:



- Who has WHS duties;



- The four-step process;



- Keeping records, appendices & summary of detailed requirements;



- Further commentary; and



- Where to get more information.



Safe Design



Karolina Grabowska STAFFAGE from Pexels



Want some good guidance on Safe Design? In this 52-minute video from the Safety Artisan, you will find it. We take the official guidance from Safe Work Australia and provide a value-added commentary on it. The guidance integrates seamlessly with Australian law and regulations, but it is genuinely useful in any jurisdiction.



Topics:



- A safe design approach;



- Five principles of safe design;



- Ergonomics and good work design;



- Responsibility for safe design;



- Product lifecycle;



- Benefits of safe design;



- Legal obligations; and



- Our national approach.



How to Demonstrate SFARP



Photo by Sondre Dahl from Pexels.com



So our learning objectives for this session at the end of this session, you should understand the SFARP concept: what it’s all about. You should understand the variety of techniques that are available to you. Most importantly, you will be able to apply these techniques in the correct order, because that’s important in the real world.



Topics



- Introduction – Reasonably Practicable;



- How to SFARP with:



- Codes, Standards & Regulations; and



- Controls, or groups of controls.



- Some practical hints on good practice;



- Examples; and



- Source information.



These lessons sell for $45 USD each, but you can get a 20% discount here. (You can get a bigger discount by subscribing to our mailing list!)

#demonstrateSFARP #reasonablypracticable #reasonablypracticablecaselaw #reasonablypracticabledefinition #reasonablypracticablehealthandsafety #reasonablypracticablemeaning #reasonablypracticablewhs #sfairp #sfairphealthandsafety #SFARP #sfarpsafety #showSFARP #whatdoesreasonablypracticablemean #whatisthebesthealthandsafetycoursetodo #whatisthepurposeofwhs #whsclasses #Whscourse #whscourseonline #whscourses #whstrainingformanagers

Simon Di Nucci https://www.safetyartisan.com/2022/07/06/australian-whs-course/

Career Change

Career change: in my lecture to the System Engineering Industry Program at the University of Adelaide, I reflect on my career changes. What can you learn from my experiences? (Hint: a lot, I hope!)



I want to talk about career changes because all of you - everyone listening - have already started to make them. You've already made the 'career change' from being a school student to coming here. You're going to graduate – hopefully - and then move on into industry or academia or whatever you choose to do. And there are a lot of things to take in. Some of them are directly relevant to safety. But a lot of these things are relevant to whatever you're doing.



I'm a High-School Student: How Can I Plan My Career Path?



When I was a student at school, I knew what I wanted to do. I guess I was quite lucky in that respect. I wanted to be a pilot in the Air Force. But then I flunked my first eye test at 14, and I knew that was the end of that dream. So I had to choose something else. And I ended up becoming an engineer in the Air Force.



The relevance of that is that I joined the Air Force before I went to university, and they paid me some money. They paid my fees (Well, there weren't fees at the time.) I know it's a strange concept these days, but University was free back in the day. But far fewer people went to university, so it’s swings and roundabouts.



But I'd gone from school, where I was in the top three of everything in every class.  Then I started doing my engineering course at university. I found myself in the bottom quarter of the class in terms of performance. So that was a bit of a shock, I have to say. I suddenly realized that I was now a small fish in a much bigger bowl. I suppose if you never leave Adelaide, you never have to experience that.



But if those of you do move on and move out of the Goldfish Bowl is ‘Adle’-brain, you'll discover there's a big world out there. One with lots of competition. And it's a very exciting world, but it can be a little bit frightening sometimes. But anyway, I got through it. Most of us got through the course. I was doing an aerospace systems engineering course, and we had a wash-out rate of about 10% in the first year. But if you survived your first year, it got easier.



I’ve got these questions - I lifted these questions, actually, from an essay education website. It's a bit tongue in cheek saying, ‘How can I plan my career path?’. Because when you're at school, you don't really have any idea about what work is all about. Unless maybe you've got a part-time job. Or your family owns a business or whatever, and you've worked in it, and you have a more realistic idea of what work is. But work is very different from school, as I'm sure you know, and University is very different from school.



I'm a Graduate: What Do I Do Next?



And then when I graduate, I think, ‘Well, I had a career path mapped out for me’, which was ‘Join the Air Force’. But I had some second thoughts. University opened my eyes and widened my horizons. And I thought about doing other things. ‘Should I stick with the Air Force?’. Although, there was always the issue that I’d have to pay them back lots of money, which I didn't have. So, I decided to stay.



And so, you're thinking as a graduate, ‘Well, what do I do next?’. There're opportunities in the public sector, working for the government. There're opportunities in the private sector. Do I go for a small or medium or work for a large firm? Do I stay in academia and do some research? What do I do? (Do you all go straight to a master's on your course? Or is it a bachelor's?) So maybe you think, ‘Well, do I stay and do a master's?’ ‘Do I stay and do a Ph.D.?’ My results weren't good enough to do a Ph.D. so that was a decision I didn't have to make.



There are lots of choices. And there are pros and cons of working for large firms and small firms or the public sector. I have to say the public sector is probably better at training you and investing in you. This is because they typically employ large numbers of people. And certainly, the Air Force was very enlightened about the way it did education.



And a lot of people in the Air Force studying - even the troops who had maybe joined the Air Force early, those who left school at 16 with very few qualifications. Lots of people were doing a part-time study with the Open University. A lot of people I worked with did that. Part of my job was to help them get through trying to do a master's degree in software engineering or safety part-time and support them. Which was a great privilege and I really enjoy doing that. So, you've got lots of choices.



So, there're lots of opportunities out there for you. Do go out and look at what's out there. And as I say, some firms will have a formal graduate development scheme. Others will not. It'll be an informal scheme, but make your mind up about which way you want to go. And what you want. Always bearing in mind, of course, that, as you'll have seen, I ended up making a series of big career changes. I had no idea I was going to do those things. I got into software by accident. I got into safety by accident. Sorry, but no cheesy pun intended.



I'm a Veteran: How Can I Make the Career Change into Industry?



And then when I left the Air Force after 20 years, I had to make a career change from Air Force into ‘Civvy Street’, as it was known. And fortunately for me, the Air Force - in fact, all the armed forces in the UK - had a really good career change scheme. A scheme where you're entitled to go back to the classroom and you could do courses. There were some basic courses everybody had to do.



Specifically, one where you were taught how to deal with grief, surprisingly. Because if you've been institutionalized in a large employer for a long, long time and you only know one way of doing things, then it’s difficult to leave. Then when you leave that and you've got to go out and make your own decisions and stuff, and that's really challenging.



And the forces introduced this career change scheme based on - I think it was at a New York Police Department experience. The New York police discovered that a lot of their veterans who left the police force were dying after only a few years of retirement. And they thought ‘This is weird. They've done this dangerous job all their lives, and then they leave and then they all die’.



Of natural causes, I should say, and suicide. And the New York police said, ‘We're not preparing our people to leave the stresses and strains of the police and get used to a completely different way of life.’. Fortunately, the force has introduced this career change training to help you do that. To learn practical skills. I did my project management training, et cetera.



So, that was helpful. And often I would say, if you're going to make a career change, retraining is often a big part of that. Whether it's the cause or the effect of the career change.



I'm Looking for A Career Change: What Are My Options?



In all of these things - as I say, I've done a lot of changes in my career. Some of my career was planned, but a great deal of it was not. And that's okay. Sometimes choices are made for you by personal circumstances or whatever. I decided I had to leave the Air Force because our daughter was about to go to secondary school. We couldn't afford to move around anymore and disrupt her education. So, the choice was made for me.



But also you might be tracking along quite nicely in your job and an opportunity comes up. And you think, ‘Well, I'd never thought about doing that, but actually, this is interesting. I've just got to try this.’ And I would encourage you to do that.



I’m An Employer: How Can I Ensure I Have the Workforce I Need?



One of the things I do nowadays – what I have done for a long time - is interview people. Whether it be for Frazer-Nash, QinetiQ before, or even in the Air Force. Because some of the jobs I was in were specialists and we had the right to interview. We could choose people. We could choose volunteers. So, I've interviewed hundreds and hundreds of people over many years. And potential employers are looking for the right people to employ. You're looking for a good employer. How do I perform an interview and get that job? Or that career that I want?



And it's not a secret, but when I'm interviewing people, if you rock up at the office, I'm going to find out what you do. What you've been doing academically. What you do outside of work. Because obviously – it’s not ‘obviously’, sorry. Often some of the most interesting things about people are what they do in their spare time. And you can learn a lot about somebody. People have got interests, particularly those who serve in different ways. Whether you volunteer for anything or sport or something like that. Because you often find that high achievers in life tend to be high achievers in everything.



And I've interviewed one or two people and they've gone out the door and I've looked at the other interviewer. And I’d say, ‘Well if we hire her, we're all going to have to raise our game, aren't we? Because she's going to make us look bad.’. Which is a wonderful problem to have, by the way. You think ‘Great. We can get this person on the team who's going to allow us to do something we've never done before.’. So, we're looking for people that we can utilize. That we can deploy. What have you done? What tools and techniques are you able to use?



Consultancy is a bit unusual. Most of you will probably not start in consultancy. You probably won't start in safety. In safety, most of us tend to have done another job first and then got into it for whatever reason. So, we've made that 'career change' as a graduate or an ex-graduate early in your career. I guess we'll be looking mainly at your potential.



It's not the technical skills so much that we're looking for. Technical skills can be taught. If I want somebody who can do fault tree analysis, we can teach you how to do fault tree analysis. We can send you on a course. What I can't or what is not so easy to teach is attitude and the way you approach work. And are you a team player and all those kinds of things? So, that's often much more important.



I’m An Educator: How Can I Inspire or Educate?



I suppose this is what I'm trying to do today. In my spare time, I also run my own business called The Safety Artisan so please check it out. You can go to www.safetyartisan.com. And there're lots of lessons on there about safety. About Australian WHS and system safety. Some of it is free and some of it you have to pay me some money for which I will be very grateful. Thank you very much. The only problem is you have to listen to me talking, but never mind. You can't have everything.



There're a lot of opportunities out there, and I think the Australian jobs market is very dynamic. And it works both ways. Big firms will hire hundreds of people to do a project. And then some of them will then fire you just like that when the project is over. Not all firms are like that. Many are looking for people with transferable skills. If one door shuts, usually another door opens. So, we're looking for people who can be flexible and adaptable. This is why I find myself doing cybersecurity these days as well as safety.



Reflections On a Career in Safety



I'll move on to some quick reflections. It says ‘Reflections on a career in safety’ but you could apply this to almost anything. At University, I learned – and in training courses throughout my career – I've learned a theoretical framework. Whether it be engineering. Whether it be marketing. Marketing is a science and an art and a very complex one, for example.



So, whether it's engineering or not, there're lots of things to learn during your career. And you'll get to learn on a course, or an institution like this - You'll get to learn some theory. A framework to plug things into. But actually, it's the practical experience where you sort of put the flesh on the bones, and the two go together.



And then the second point I'd just like to make on reflection. To a degree, I would say go with the flow because opportunities will come up that you hadn't planned for. That you hadn't thought of. But give it a go. If you've got an opportunity, try it. Particularly as I found, if the alternative is doing something you really don't want to do. That makes the choice a lot easier. But go for it.



Also, you've got to remember to stick to your principles. So, you've got to decide what's important to you and hold on to those values. Otherwise, you could end up doing something you're not happy with. In fact, somebody much cleverer than me once said that the secret or the art of progress is to "preserve change amidst order and preserve order amidst change". And those are very wise words. So, decide what's really important to you. What you will not change. What you will not compromise on under any circumstances. But other than that, go for it.



And finally, in safety and in many other things, I've seen people tend to overcomplicate things. I think Einstein said, if you can't explain something in simple terms, you don't really understand it. And that's a very challenging quote but it's very true. So, there's a lot of complexity out there. And that's the whole point of systems engineering, isn't it? To deal with complexity. So, big programs, are complex things and difficult to understand. But it's all about boiling it down to something simple. And then, understanding what those core principles are and holding fast onto them while dealing with the complexity. So, a little plug for systems engineering.



I’m very happy to talk about systems engineering, it's so important to safety.



Do You have any Career Change Questions? Leave a Comment, below.

#canichangecareerat30 #canyouchangecareerat30 #careerchange #careerchangeafter10years #careerchangeat40australia #careerchangedon'tknowwhattodo #careerchangeforover50s #careerchangewithoutexperience #careerpath #howcaniplanmycareerpath #objectiveforcareerchange #tochangecareerpath #whataremyoptions #whatdoidonext #whentochangecareer #whentochangecareerpaths #wheretostartcareerchange #whycareerchangereason #whychangecareerinterviewquestions

Simon Di Nucci https://www.safetyartisan.com/2022/06/08/career-change/

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:



- Business Units shall audit their Delivery (Project) Teams, or equivalents, safety, and environmental management systems.

- Delivery (Project) Teams or equivalents shall audit the safety and environmental management systems of their projects.

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

#health&safetypolicylegalrequirements #howlongisasafetygoodfor #safety&healthpolicystatement #safetyisthebestpolicy #safetypolicyandobjectives #safetypolicyinindustry #safetypolicystatementofintent #safetytrainingpolicystatement #whatissafetypolicystatement #whenshouldhealthandsafetypolicybereviewed #whyhealthandsafetypolicyisimportant

Simon Di Nucci https://www.safetyartisan.com/2022/05/25/safety-management-policy/