Crafting a Safety Case and Safety Case Report - Part 2
In Crafting a Safety Case and Safety Case Report - Part 2, we move on to review and sign off on the artifacts.

Introduction In any high-stakes environment—whether it's defense, engineering, or aviation—Safety Case Reports play an essential role in validating the safety of a system. A meticulous review and sign-off process ensures that these reports meet every necessary standard before they are officially issued. Let’s dive into the distinct types of approvals in the Safety Case Report review process, what they signify, and how they work together to ensure comprehensive safety oversight.

Understanding Review and Sign-Off Terminology

When dealing with complex Safety Case Reports, different stages of review carry unique responsibilities. Below are the key terms that guide the process of approving a Safety Case Report:

- Agreeing on a DocumentTo agree on a document means that the reviewer acknowledges it accurately represents the current situation. This doesn’t imply full approval but rather confirms that the document is aligned with the reviewer’s knowledge and understanding of the current state.

- Endorsing a DocumentTo endorse a document, the reviewer confirms that the report complies with all necessary policies, procedures, and best practices. Endorsement reflects a broader scope of confidence, going beyond mere factual accuracy to affirm that the report aligns with the organization’s or industry’s standards.

- Authorizing a DocumentThe authorization step is significant: it implies that the document may be issued and the reviewer personally accepts responsibility for its contents. At this point, the Safety Case Report is ready for dissemination, pending any final checks, and represents the highest level of accountability within the review process.

- Providing AssuranceAs outlined in Def Stan 00-56, assurance represents the overarching confidence that the Safety Case Report satisfies all safety requirements. Assurance is based on evidence from the review process, ensuring that the system in question meets both internal and external safety expectations.

This diagram is sourced from ASEMS.

Key Players in Safety Case Report Review

Independent Safety Auditors (ISA)In most fields, endorsement by Independent Safety Auditors is required as set forth in domain-specific JSPs (Joint Service Publications). These auditors bring an impartial perspective, helping ensure the project aligns with regulatory and safety standards. Non-regulatory authorities are only involved when their policies directly impact the project, providing relevant insights without imposing extra requirements.

Stakeholders in Review OrderThe review order by Independent Safety Auditors, stakeholders, and team members can vary, and in some cases, reviews may happen in parallel. This flexibility helps streamline approvals as projects progress, while still meeting all mandated review steps shown by bold, solid-bordered boxes in each approval cycle.

Lifecycle-Based Review AdjustmentsReview processes should adapt across different stages of the project lifecycle, reflecting the evolving nature of safety assessments. In the early stages, the Safety Authority may serve as a Subject Matter Expert (SME) to guide project leaders, especially if they have formally delegated safety responsibilities. Early involvement of Safety Regulators is essential in confirming that the Safety Case approach aligns with regulatory expectations, paving the way for approval at later stages.

Authority of the Defence Safety Authority (DSA)With its role as a Regulator, the Defence Safety Authority (DSA) has several tools for managing enforcement actions. From issuing Corrective Action Reports to, in severe cases, withdrawing authorizations or approvals to operate equipment, the DSA’s regulatory reach is extensive.

Safety Case Report Terminology Clarification

Understanding specific terminology is crucial, as terms like “endorsement” may be used differently across documents. For instance, the endorsement of Safety Case Reports by the Duty Holder has a unique context within MOD Shipping Regulations (DSA02-DMR). Importantly, it’s the Safety Case Report itself, not the underlying Safety Case body of evidence, that is subjected to this approval process.

Key Milestones in Safety Case Reporting

Safety Case Reports are vital at specific points throughout a project. The Project Safety Management Plan establishes these delivery points, typically at stages such as:

- Outline Business Case: Initial project approval

- Full Business Case: Final project approval

- Demonstration Trials: Clearance to begin testing

- Design Completion: Design baseline is agreed

- Production Commitment: Readiness for manufacturing

- User Trials: Clearance for testing by end-users

- Service Introduction: Official product release

- Major Updates: Mid-life upgrades or significant changes

- Usage Changes: Shifts in operational use

- Disposal: Safe decommissioning and disposal

These milestones help projects track safety progress, ensuring risks are managed at each critical juncture.

ALARP (As Low As Reasonably Practicable) RisksWhen risks cannot be mitigated to ALARP standards, they must be documented as unresolved actions in the Hazard Log. These are then incorporated into both the Project Safety Plan and the Safety Case Report to enable corrective action in the next project phase.

Authorization and Accountability in the Safety Case Process

Within the Project

Authorization by the Project's safety-responsible member signifies their endorsement of the project’s safety progression. Prior to this, unresolved issues from the Project Safety Committee or Independent Safety Auditor should be addressed to ensure all feedback has been incorporated.

Outside the Project

The Duty Holder, usually from the Front Line Command, represents the interests of users and front-line operations. Their acceptance of risk reflects the project’s readiness to meet frontline demands and their willingness to accept the outlined safety measures.

Land Systems and Duty Holder Collaboration

For land systems, the Duty Holder’s acceptance is crucial for documenting the shared responsibility of operational safety. The Duty Holder and project safety manager jointly sign the Part 3 Safety Case, symbolizing a mutual commitment to safety oversight. Any updates in the Safety Case Report require similar signatures to reflect updated safety responsibilities.

Endorsement by Regulatory Authorities

When a project falls under formal regulatory requirements, the Safety Case must include all supporting evidence necessary for regulatory review. Approval certificates and certification notices serve as proof that the system meets specific safety criteria, while any safety-specific conditions are also documented in the Safety Case.

Approval Process for Safety Case ReportsAt each milestone, the Project Safety Committee—often including the Independent Safety Auditor—reviews the Safety Case Report for accuracy. Observations and recommendations are compiled, contributing to the final report presented to the project’s safety-responsible member for authorization.

Regulator and Certification Authority EndorsementsThe Project Safety Management Plan outlines the required safety approvals and responsible authorities, such as the Ordnance, Munitions & Explosives Safety Review Panel, Naval Authorities, or Military Laser Safety Committee. It’s essential for the project team to distinguish between advisory authorities and those directly responsible for regulatory compliance.

ConclusionManaging safety within complex projects requires a thorough, structured approach to Safety Case Report review, approval, and endorsement. From early planning to final authorization, engaging with Independent Safety Auditors, Duty Holders, and regulatory authorities ensures the project meets all necessary safety standards. By adhering to this process, projects can confidently progress, knowing they are aligned with industry best practices and regulatory requirements.

That was 'Crafting a Safety Case and Safety Case Report - Part 2'. Part 1 of this series is here. Part 3 is coming soon!

Meet the Author of Crafting a Safety Case and Safety Case Report - Part 2

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.
#ALARPStandards #DefStan00056Compliance #DefenseSafetyAuthorityDSA #HazardLogandSafetyPlan #IndependentSafetyAuditorEndorsement #ProjectLifecycleSafetyCase #RegulatorySafetyCompliance #SafetyAssurance #SafetyCaseReportProcess #SafetyCaseReportReview #SafetyCaseSignOffProcess #SafetyReportAuthorization
Simon Di Nucci https://www.safetyartisan.com/?p=4141

Crafting a Safety Case and Safety Case Report - Part 2
In Crafting a Safety Case and Safety Case Report - Part 2, we move on to review and sign off on the artifacts.

Introduction In any high-stakes environment—whether it's defense, engineering, or aviation—Safety Case Reports play an essential role in validating the safety of a system. A meticulous review and sign-off process ensures that these reports meet every necessary standard before they are officially issued. Let’s dive into the distinct types of approvals in the Safety Case Report review process, what they signify, and how they work together to ensure comprehensive safety oversight.

Understanding Review and Sign-Off Terminology

When dealing with complex Safety Case Reports, different stages of review carry unique responsibilities. Below are the key terms that guide the process of approving a Safety Case Report:

- Agreeing on a DocumentTo agree on a document means that the reviewer acknowledges it accurately represents the current situation. This doesn’t imply full approval but rather confirms that the document is aligned with the reviewer’s knowledge and understanding of the current state.

- Endorsing a DocumentTo endorse a document, the reviewer confirms that the report complies with all necessary policies, procedures, and best practices. Endorsement reflects a broader scope of confidence, going beyond mere factual accuracy to affirm that the report aligns with the organization’s or industry’s standards.

- Authorizing a DocumentThe authorization step is significant: it implies that the document may be issued and the reviewer personally accepts responsibility for its contents. At this point, the Safety Case Report is ready for dissemination, pending any final checks, and represents the highest level of accountability within the review process.

- Providing AssuranceAs outlined in Def Stan 00-56, assurance represents the overarching confidence that the Safety Case Report satisfies all safety requirements. Assurance is based on evidence from the review process, ensuring that the system in question meets both internal and external safety expectations.

This diagram is sourced from ASEMS.

Key Players in Safety Case Report Review

Independent Safety Auditors (ISA)In most fields, endorsement by Independent Safety Auditors is required as set forth in domain-specific JSPs (Joint Service Publications). These auditors bring an impartial perspective, helping ensure the project aligns with regulatory and safety standards. Non-regulatory authorities are only involved when their policies directly impact the project, providing relevant insights without imposing extra requirements.

Stakeholders in Review OrderThe review order by Independent Safety Auditors, stakeholders, and team members can vary, and in some cases, reviews may happen in parallel. This flexibility helps streamline approvals as projects progress, while still meeting all mandated review steps shown by bold, solid-bordered boxes in each approval cycle.

Lifecycle-Based Review AdjustmentsReview processes should adapt across different stages of the project lifecycle, reflecting the evolving nature of safety assessments. In the early stages, the Safety Authority may serve as a Subject Matter Expert (SME) to guide project leaders, especially if they have formally delegated safety responsibilities. Early involvement of Safety Regulators is essential in confirming that the Safety Case approach aligns with regulatory expectations, paving the way for approval at later stages.

Authority of the Defence Safety Authority (DSA)With its role as a Regulator, the Defence Safety Authority (DSA) has several tools for managing enforcement actions. From issuing Corrective Action Reports to, in severe cases, withdrawing authorizations or approvals to operate equipment, the DSA’s regulatory reach is extensive.

Safety Case Report Terminology Clarification

Understanding specific terminology is crucial, as terms like “endorsement” may be used differently across documents. For instance, the endorsement of Safety Case Reports by the Duty Holder has a unique context within MOD Shipping Regulations (DSA02-DMR). Importantly, it’s the Safety Case Report itself, not the underlying Safety Case body of evidence, that is subjected to this approval process.

Key Milestones in Safety Case Reporting

Safety Case Reports are vital at specific points throughout a project. The Project Safety Management Plan establishes these delivery points, typically at stages such as:

- Outline Business Case: Initial project approval

- Full Business Case: Final project approval

- Demonstration Trials: Clearance to begin testing

- Design Completion: Design baseline is agreed

- Production Commitment: Readiness for manufacturing

- User Trials: Clearance for testing by end-users

- Service Introduction: Official product release

- Major Updates: Mid-life upgrades or significant changes

- Usage Changes: Shifts in operational use

- Disposal: Safe decommissioning and disposal

These milestones help projects track safety progress, ensuring risks are managed at each critical juncture.

ALARP (As Low As Reasonably Practicable) RisksWhen risks cannot be mitigated to ALARP standards, they must be documented as unresolved actions in the Hazard Log. These are then incorporated into both the Project Safety Plan and the Safety Case Report to enable corrective action in the next project phase.

Authorization and Accountability in the Safety Case Process

Within the Project

Authorization by the Project's safety-responsible member signifies their endorsement of the project’s safety progression. Prior to this, unresolved issues from the Project Safety Committee or Independent Safety Auditor should be addressed to ensure all feedback has been incorporated.

Outside the Project

The Duty Holder, usually from the Front Line Command, represents the interests of users and front-line operations. Their acceptance of risk reflects the project’s readiness to meet frontline demands and their willingness to accept the outlined safety measures.

Land Systems and Duty Holder Collaboration

For land systems, the Duty Holder’s acceptance is crucial for documenting the shared responsibility of operational safety. The Duty Holder and project safety manager jointly sign the Part 3 Safety Case, symbolizing a mutual commitment to safety oversight. Any updates in the Safety Case Report require similar signatures to reflect updated safety responsibilities.

Endorsement by Regulatory Authorities

When a project falls under formal regulatory requirements, the Safety Case must include all supporting evidence necessary for regulatory review. Approval certificates and certification notices serve as proof that the system meets specific safety criteria, while any safety-specific conditions are also documented in the Safety Case.

Approval Process for Safety Case ReportsAt each milestone, the Project Safety Committee—often including the Independent Safety Auditor—reviews the Safety Case Report for accuracy. Observations and recommendations are compiled, contributing to the final report presented to the project’s safety-responsible member for authorization.

Regulator and Certification Authority EndorsementsThe Project Safety Management Plan outlines the required safety approvals and responsible authorities, such as the Ordnance, Munitions & Explosives Safety Review Panel, Naval Authorities, or Military Laser Safety Committee. It’s essential for the project team to distinguish between advisory authorities and those directly responsible for regulatory compliance.

ConclusionManaging safety within complex projects requires a thorough, structured approach to Safety Case Report review, approval, and endorsement. From early planning to final authorization, engaging with Independent Safety Auditors, Duty Holders, and regulatory authorities ensures the project meets all necessary safety standards. By adhering to this process, projects can confidently progress, knowing they are aligned with industry best practices and regulatory requirements.

That was 'Crafting a Safety Case and Safety Case Report - Part 2'. Part 1 of this series is here. Part 3 is coming soon!

Meet the Author of Crafting a Safety Case and Safety Case Report - Part 2

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.
#ALARPStandards #DefStan00056Compliance #DefenseSafetyAuthorityDSA #HazardLogandSafetyPlan #IndependentSafetyAuditorEndorsement #ProjectLifecycleSafetyCase #RegulatorySafetyCompliance #SafetyAssurance #SafetyCaseReportProcess #SafetyCaseReportReview #SafetyCaseSignOffProcess #SafetyReportAuthorization
Simon Di Nucci https://www.safetyartisan.com/?p=4141

How to Understand Safety Standards

Learn How to Understand Safety Standards with this FREE session from The Safety Artisan.



In this module, Understanding Your Standard, we’re going to ask the question: Am I Doing the Right Thing, and am I Doing it Right? Standards are commonly used for many reasons. We need to understand our chosen system safety engineering standard, in order to know: the concepts, upon which it is based; what it was designed to do, why and for whom; which kinds of risk it addresses; what kinds of evidence it produces; and it’s advantages and disadvantages.



Understand Safety Standards : You'll Learn to



- List the hazard analysis tasks that make up a program; and



- Describe the key attributes of Mil-Std-882E. 



https://youtu.be/JTcBax2nNvE

Understanding Your Standard



Topics:  Understand Safety Standards



Aim: Am I Doing the Right Thing, and am I Doing it Right?



- Standards: What and Why?



- System Safety Engineering pedigree;



- Advantages – systematic, comprehensive, etc:



- Disadvantages – cost/schedule, complexity & quantity not quality.



Transcript: Understand Safety Standards



Click here for the Transcript on Understanding Safety Standards

In Module Three, we're going to understand our Standard. The standard is the thing that we're going to use to achieve things - the tool. And that's important because tools designed to do certain things usually perform well. But they don’t always perform well on other things. So we're going to ask ‘Are we doing the right thing?’ And ‘Are we doing it right?’



What and Why?



So, what are we going to do, and why are we doing it? First of all, the use of standards in safety is very common for lots of reasons. It helps us to have confidence that what we're doing is good enough. We've met a standard of performance in the absolute sense. It helps us to say, ‘We've achieved standardization or commonality in what we're doing’. And we can also use it to help us achieve a compromise. That can be a compromise across different stakeholders or across different organizations. And standardization gives us some of the other benefits as well. If we're all doing the same thing rather than we're all doing different things, it makes it easier to train staff. This is one example of how a standard helps.



However, we need to understand this tool that we're going to use. What it does, what it's designed to do, and what it is not designed to do. That's important for any standard or any tool. In safety, it's particularly important because safety is in many respects intangible. This is because we're always looking to prevent a future problem from occurring. In the present, it's a little bit abstract. It's a bit intangible. So, we need to make sure that in concept what we're doing makes sense and is coherent. That it works together. If we look at those five bullet points there, we need to understand the concept of each standard. We need to understand the basis of each one.



And they’re not all based on the same concept. Thus some of them are contradictory or incompatible. We need to understand the design of the standard. What the standard does, what the aim of the standard is, why it came into existence. And who brought it into existence. To do what for who - who's the ultimate customer here?



And for risk analysis standards, we need to understand what kind of risks it addresses. Because the way you treat a financial risk might be very different from a safety risk. In the world of finance, you might have a portfolio of products, like loans. These products might have some risks associated with them. One or two loans might go bad and you might lose money on those. But as long as the whole portfolio is making money that might be acceptable to you. You might say, ‘I'm not worried about that 10% of my loans have gone south and all gone wrong. I'm still making plenty of profit out of the other 90%’. It doesn't work that way with safety. You can't say ‘It's OK that I've killed a few people over here because all this a lot over here are still alive!’. It doesn't work like that!



Also, what kind of evidence does the standard produce? Because in safety, we are very often working in a legal framework that requires us to do certain things. It requires us to achieve a certain level of safety and prove that we have done so. So, we need certain kinds of evidence. In different jurisdictions and different industries, some evidence is acceptable. Some are not. You need to know which is for your area.



And then finally, let's think about the pros and cons of the standard, what does it do well? And what does it do not so well?



System Safety Pedigree



We're going to look at a standard called Military Standard 882E. Many decades ago, this standard developed was created by the US government and military to help them bring into service complex-cutting edge military equipment. Equipment that was always on the cutting edge. That pushed the limits of what you could achieve in performance.



That’s a lot of complexity. Lots of critical weapon systems, and so forth. And they needed something that could cope with all that complexity. It's a system safety engineering standard. It's used by engineers, but also by many other specialists. As I said, it's got a background from military systems. These days you find these principles used pretty much everywhere. So, all the approaches to System Safety that 882 introduced are in other standards. They are also in other countries.



It addresses risks to people, equipment, and the environment, as we heard earlier. And because it's an American standard, it's about system safety. It's very much about identifying requirements. What do we need to happen to get safety? To do that, it produces lots of requirements. It performs analyses in all those requirements and generates further requirements. And it produces requirements for test evidence. We then need to fulfill these requirements. It's got several important advantages and disadvantages. We're going to discuss these in the next few slides.



Comprehensive Analysis



Before we get to that, we need to look at the key feature of this standard. The strengths and weaknesses of this standard come from its comprehensive analysis. And the chart (see the slide) is meant to show how we are looking at the system from lots of different perspectives. (It’s not meant to be some arcane religious symbol!) So, we're looking at a system from 10 different perspectives, in 10 different ways.



Going around clockwise, we've got these ten different hazard analysis tasks. First of all, we start off with preliminary hazard identification. Then preliminary hazard analysis. We do some system requirements hazard analysis. So, we identify the safety requirements that the system is going to meet so that we are safe. We look at subsystem and system hazard analysis. At operating and support hazard analysis - people working with the system. Number seven, we look at health hazard analysis - Can the system cause health problems for people? Functional hazard analysis, which is all about what it does. We're thinking of sort of source software and data-driven functionality. Maybe there's no physical system, but it does stuff. It delivers benefits or risks. System of systems hazard analysis – we could have lots of different and/or complex systems interacting. And then finally, the tenth one - environmental hazard analysis.



If we use all these perspectives to examine the system, we get a comprehensive analysis of the system. From this analysis, we should be confident that we have identified everything we need to. All the hazards and all the safety requirements that we need to identify. Then we can confidently deliver an appropriate safe system. We can do this even if the system is extremely complex. The standard is designed to deal with big, complex cutting-edge systems.



Advantages #1



In fact, as we move on to advantages, that's the number one advantage of this standard. If we use it and we use all 10 of those tasks, we can cope with the largest and the most demanding programs. I spent much of my career working on the Eurofighter Typhoon. It was a multi-billion-dollar program. It cost hundreds of billions of dollars, four different nations worked together on it. We used a derivative of Mil. Standard 882 to look at safety and analyze it. And it coped. It was powerful enough to deal with that gigantic program. I spent 13 years of my life on and off on that program so I'd like to think that I know my stuff when we're talking about this.



As we've already said, it's a systematic approach to safety. Systems, safety, engineering. And we can start very early. We can start with early requirements - discovery. We don't even need a design - we know that we have a need. So we can think about those needs and analyze them.



And it can cover us right through until final disposal. And it covers all kinds of elements that you might find in a system. Remember our definition of ‘system’? It’s something that consists of hardware, software, data, human beings, etc. The standard can cope with all the elements of a system. In fact, it’s designed into the standard. It was specifically designed to look at all those different elements. Then to get different insights from those elements. It’s designed to get that comprehensive coverage. It’s really good at what it does. And it involves, not just engineers, but people from all kinds of other disciplines. Including operators, maintainers, etc, etc.



I came from a maintenance background. I was either directly or indirectly supporting operators. I was responsible for trying to help them get the best out of their system. Again, that's a very familiar world to me. And rigorous standards like this can help us to think rigorously about what we're doing. And so get results even in the presence of great complexity, which is not always a given, I must say.



So, we can be confident by applying the standard. We know that we're going to get a comprehensive and thorough analysis. This assures us that what we're doing is good.



Advantages #2



So, there's another set of advantages. I've already mentioned that we get assurance. Assurance is ‘justified confidence’. So we can have high confidence that all reasonably foreseeable hazards will be identified and analyzed. And if you're in a legal jurisdiction where you are required to hit a target, this is going to help you hit that target.



The standard was also designed for use in contracts. It’s designed to be applied to big programs. We’d define that as where we are doing the development of complex high-performance systems. So, there are a lot of risks. It's designed to cope with those risks.



Finally, the standard also includes requirements for contracting, for interfaces with other systems, for interfaces with systems engineering. This is very important for a variety of disciplines. It’s important for other engineering and technical disciplines. It’s important for non-technical disciplines and for analysis and recordkeeping. Again, all these things are important, whether it is for legal reasons or not. We need to do recordkeeping. We need to liaise with other people and consult with them. There are legal requirements for that in many countries. This standard is going to help us do all those things.



But, of course, in a standard everything has pros and cons and Mil. Standard 882 is no exception. So, let's look at some of the disadvantages.



Disadvantages #1



First of all, a full system safety program might be overkill for the system that you want to use, or that you want to analyze.  The Cold War, thank goodness, is over; generally speaking, we're not in the business of developing cutting-edge high-performance killing machines that cost billions and billions of dollars and are very, very risky. These days, we tend to reduce program risk and cost by using off-the-shelf stuff and modifying it. Whether that be for military systems, infrastructure in the chemical industry, transportation, whatever it might be. Very much these days we have a family of products and we reuse them in different ways. We mix and match to get the results that we want.



And of course, all this comprehensive analysis is not cheap and it's not quick. It may be that you've got a program that is schedule-constrained. Or you want to constrain the cost and you cannot afford the time and money to throw a full 882 program at it. So, that's a disadvantage.



The second family of problems is that these kinds of safety standards have often been applied prescriptively. The customer would often say, ‘Go away and go and do this. I'm going to tell you what to do based on what I think reduces my risk’. Or at least it covers their backside. So, contractors got used to being told to do certain things by purchasers and customers. The customers didn't understand the standards that they were applying and insisting upon. So, the customers did not understand how to tailor a safety standard to get the result that they wanted. So they asked for dumb things or things that didn't add value. And the contractors got used to working in that kind of environment. They got used to being told what to do and doing it because they wouldn't get paid if they didn't. So, you can't really blame them.



But that's not great, OK? That can result in poor behaviors. You can waste a lot of time and money doing stuff that doesn't actually add value. And everybody recognizes that it doesn't add value. So you end up bringing the whole safety program into disrepute and people treat it cynically. They treat it as a box-ticking exercise. They don't apply creativity and imagination to it. Much less determination and persistence. And that's what you need for a good effective system safety program. You need creativity. You need imagination. You need people to be persistent and dedicated to doing a good job. You need that rigor so that you can have the confidence that you're doing a good job because it's intangible.



Disadvantages #2



Let's move onto the second kind of family of disadvantages. And this is the one that I've seen the most, actually, in the real world. If you do all 10 tasks and even if you don't do all 10, you can create too many hazards. If you recall the graphic from earlier, we have 10 tasks. Each task looks at the system from a different angle. What you can get is lots and lots of duplication in hazard identification. You can have essentially the same hazards identified over and over again in each task. And there's a problem with that, in two ways.



First of all, quality suffers. We end up with a fragmented picture of hazards. We end up with lots and lots of hazards in the hazard log, but not only that. We get fragments of hazards rather than the real thing. Remember I said those tests for what a hazard really is? Very often you can get causes masquerading as hazards. Or other things that that exacerbating factors that make things worse. They're not a hazard in their own right, but they get recorded as hazards. And that problem results in people being unable to see the big picture of risk. So that undermines what we're trying to do. And as I say, we get lots of things misidentified and thrown into the pot. This also distracts people. You end up putting effort into managing things that don't make a difference to safety. They don't need to be managed. Those are the quality problems.



And then there are quantity problems. And from personal experience, having too many hazards is a problem in itself.  I've worked on large programs where we were managing 250 hazards or thereabouts. That is challenging even with a sizable, dedicated team. That is a lot of work in trying to manage that number of hazards effectively. And there's always the danger that it will slide into becoming a box-ticking exercise. Superficial at best.



I've also seen projects that have two and a half thousand hazards or even 4000 hazards in the hazard log. Now, once you get up to that level, that is completely unmanageable. People who have thousands of hazards in a hazard log and they think they're managing safety are kidding themselves. They don't understand what safety is if they think that's going to work. So, you end up with all these items in your hazard log, which become a massive administrative burden. So people end up taking shortcuts and the real hazards are lost. The real issues that you want to focus on are lost in the sea of detail that nobody will ever understand. You won’t be able to control them.



Unfortunately, Mil. Standard 882 is good at generating these grotesque numbers of hazards. If you don't know how to use the standard and don't actively manage this issue, it gets to this stage. It can go and does go, badly wrong. This is particularly true on very big programs. And you really need clarity on big projects.



Summary of Module



Let's summarize what we've done with this module. The aim was to help us understand whether we're doing the right thing and whether we've done it right. And standards are terrific for helping us to do that. They help us to ensure we're doing the right thing. That we're looking at the right things. And they help us to ensure that we're doing it rigorously and repeatedly. All the good quality things that we want. And Mil. Standard 882E that we're looking at is a system safety engineering standard. So it's designed to deal with complexity and high-performance and high-risk. And it's got a great pedigree. It's been around for a long time.



Now that gives advantages. So, we have a system safety program with this standard that helps us to deal with complexity. That can cope with big programs, with lots of risks. That's great.



The disadvantages of this standard are that if we don't know how to tailor or manage it properly, it can cost a lot of money. It can take a lot of time to give results which can cause problems for the program. And ultimately, you can accidentally ignore safety if you don't deliver on time. And it can generate complexity. And it can generate a quantity of data that is so great that it actually undermines the quality of the data. It undermines what we're trying to achieve. In that, we get a fragmented picture in which we can't see the true risks. And so we can’t manage them effectively. If we get it wrong with this standard, we can get it really wrong. And that brings us to the end of this module.



This is Module 3 of SSRAP



This is Module 3 from the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application. You can access the full course here.



You can find more introductory lessons at Start Here.

#coursesafetyengineering #engineersafety #ineedsafety #knowledgeofsafety #learnsafety #MilStd882E #needforsafety #riskassessment #safetyblog #safetydo #safetyengineer #safetyengineerskills #safetyengineertraining #safetyengineeringcourse #safetyprinciples #safetystandard #softwaresafety #systemsafety #theneedforsafety #understandsafetystandards #whatarethesafetystandards

Simon Di Nucci https://www.safetyartisan.com/2021/04/16/ssrap-3-understanding-your-standard/

Crafting a Safety Case and Safety Case Report
Crafting a Safety Case and Safety Case Report: A Comprehensive Guide for Project Safety Assurance - PART 1

Introduction

Building a robust Safety Case and Safety Case Report is essential to ensuring the safety and regulatory compliance of complex systems within the Ministry of Defence (MOD) and similarly regulated industries. From risk management and regulatory compliance to stakeholder approval, these documents play a pivotal role in documenting and demonstrating that a system meets safety requirements throughout its lifecycle.

DefinitionsTo understand the scope and purpose of these documents, we’ll start with definitions.

What is a Safety Case?Defined in Def Stan 00-056, a Safety Case is:

“A structured argument, supported by a body of evidence that provides a compelling, comprehensible, and valid case that a system is safe for a given application in a given environment.”

What is a Safety Case Report?Also defined in Def Stan 00-056, a Safety Case Report is:

“A report that summarises the arguments and evidence of the Safety Case, and documents progress against the Safety Programme.”

Objectives of the Safety Case

A well-prepared Safety Case achieves several key objectives:

- Documenting EvidenceA thorough record of all evidence ensures that the system meets established Safety Requirements and all identified risks are As Low As Reasonably Practicable (ALARP).

- Safe Execution of ActivitiesFor systems undergoing testing or trials, the Safety Case ensures these activities can proceed without jeopardizing safety.

- Justifying Safety of the SystemBy clearly articulating the arguments and evidence, the Safety Case justifies the system's safety through validated processes and assessments.

- Gaining ApprovalIn cases where safety approvals are required beyond the project level, the Safety Case serves as the official documentation submitted to regulators or higher authorities for review.

Procedure for Developing a Safety Case

The creation of a Safety Case within the MOD follows a well-structured, iterative approach, evolving alongside the project from concept through to service.

Step-by-Step Process

The Safety Case is generated in stages, starting with conceptual safety requirements and progressing through assessment, development, and manufacturing stages. The document consolidates safety data and insights from contractors, MOD procedures, and risk assessments, providing a holistic picture of safety efforts and compliance.

- Incorporating Contractor and MOD DataThe Safety Case combines all safety assessments and risk management activities, ensuring comprehensive and traceable safety information.

- Leveraging Diverse EvidenceSafety evidence can vary, including historical, analytical, test, and expert judgment inputs. A structured approach ensures that all critical safety information is preserved and accessible.

- Compliance and Regulatory ApprovalsThe Safety Case facilitates submissions to MOD safety authorities for approvals, such as safety certificates or internal safety audits.

Why the Safety Case Concept is Good Practice

Several key factors make the Safety Case framework essential in high-risk industries, including defense and manufacturing:

- Prioritization of Safety Efforts: Risk assessments at the core of the Safety Case help allocate resources effectively.

- Adherence to Legal Standards: The written evidence in a Safety Case aligns with common law requirements, ensuring robust legal compliance.

- Efficient Knowledge Transfer: Documented safety records reduce risks associated with high staff turnover.

- Cost-Efficiency and Safety Culture: Implementing a structured safety management system reduces accidents, boosts morale, and supports a proactive safety culture.

Producing the Safety Case Documentation

An effective Project Safety Management Plan is critical to the organization of the Safety Case documentation. It should include:

- Role AssignmentsDesignate a responsible individual to oversee the safety documentation process.

- Approval ProtocolsDefine both internal and external approval workflows to streamline safety documentation reviews.

- Documentation for All StagesEnsure that documentation covers the design, construction, manufacture, and operational phases, aligning with the safety significance of each stage.

Safety Case Documentation Lifecycle

The Safety Case is dynamic and should adapt throughout the project lifecycle to maintain relevance as the system evolves.

- System Development and TrialsThe Safety Case Report must evolve during development and trials, reflecting any updates to design or safety features.

- Project MilestonesAt each project milestone, the Safety Case Report should validate that safety standards are being met and provide support for decision-making regarding continued development.

- Variant SystemsSafety Cases can be structured to accommodate system variations by creating a single report with variant-specific appendices or compatibility matrices.

Handling Safety Case Caveats

Projects may occasionally need to progress with certain “caveats” or limitations due to incomplete safety information. When this occurs, the following should be considered:

- Clear Communication of CaveatsDefine the limitations and inform all relevant stakeholders, ensuring they understand any usage restrictions.

- Compliance MonitoringEnforce caveat compliance and evaluate whether limitations may introduce additional risks.

Long-Term Safety Documentation Retention

MOD mandates stringent retention periods for safety documentation based on potential risks and exposure, ranging from 2 to 50 years depending on the nature of the hazard. Retention policies are essential for maintaining comprehensive records for the MOD and assisting in post-project reviews or incident investigations.

Transparency in Safety Information Disclosure

While certain MOD establishments may restrict the disclosure of sensitive information under the Public Interests Disclosure Act, unclassified safety documentation should remain accessible to relevant parties and stakeholders, supporting transparency in public safety efforts.

By following the guidance outlined above, project teams can ensure that their Safety Cases not only meet MOD requirements but also foster a culture of safety excellence, accountability, and continuous improvement.

Crafting a Safety Case and Safety Case Report Part 2 is coming soon!

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.
#ALARPSafetyStandards #DefStan00056SafetyCase #MODSafetyRegulations #ProjectSafetyMilestones #SafetyCaseReport #SafetyManagementSystem
Simon Di Nucci https://www.safetyartisan.com/?p=4139

Crafting a Safety Case and Safety Case Report
Crafting a Safety Case and Safety Case Report: A Comprehensive Guide for Project Safety Assurance - PART 1

Introduction

Building a robust Safety Case and Safety Case Report is essential to ensuring the safety and regulatory compliance of complex systems within the Ministry of Defence (MOD) and similarly regulated industries. From risk management and regulatory compliance to stakeholder approval, these documents play a pivotal role in documenting and demonstrating that a system meets safety requirements throughout its lifecycle.

DefinitionsTo understand the scope and purpose of these documents, we’ll start with definitions.

What is a Safety Case?Defined in Def Stan 00-056, a Safety Case is:

“A structured argument, supported by a body of evidence that provides a compelling, comprehensible, and valid case that a system is safe for a given application in a given environment.”

What is a Safety Case Report?Also defined in Def Stan 00-056, a Safety Case Report is:

“A report that summarises the arguments and evidence of the Safety Case, and documents progress against the Safety Programme.”

Objectives of the Safety Case

A well-prepared Safety Case achieves several key objectives:

- Documenting EvidenceA thorough record of all evidence ensures that the system meets established Safety Requirements and all identified risks are As Low As Reasonably Practicable (ALARP).

- Safe Execution of ActivitiesFor systems undergoing testing or trials, the Safety Case ensures these activities can proceed without jeopardizing safety.

- Justifying Safety of the SystemBy clearly articulating the arguments and evidence, the Safety Case justifies the system's safety through validated processes and assessments.

- Gaining ApprovalIn cases where safety approvals are required beyond the project level, the Safety Case serves as the official documentation submitted to regulators or higher authorities for review.

Procedure for Developing a Safety Case

The creation of a Safety Case within the MOD follows a well-structured, iterative approach, evolving alongside the project from concept through to service.

Step-by-Step Process

The Safety Case is generated in stages, starting with conceptual safety requirements and progressing through assessment, development, and manufacturing stages. The document consolidates safety data and insights from contractors, MOD procedures, and risk assessments, providing a holistic picture of safety efforts and compliance.

- Incorporating Contractor and MOD DataThe Safety Case combines all safety assessments and risk management activities, ensuring comprehensive and traceable safety information.

- Leveraging Diverse EvidenceSafety evidence can vary, including historical, analytical, test, and expert judgment inputs. A structured approach ensures that all critical safety information is preserved and accessible.

- Compliance and Regulatory ApprovalsThe Safety Case facilitates submissions to MOD safety authorities for approvals, such as safety certificates or internal safety audits.

Why the Safety Case Concept is Good Practice

Several key factors make the Safety Case framework essential in high-risk industries, including defense and manufacturing:

- Prioritization of Safety Efforts: Risk assessments at the core of the Safety Case help allocate resources effectively.

- Adherence to Legal Standards: The written evidence in a Safety Case aligns with common law requirements, ensuring robust legal compliance.

- Efficient Knowledge Transfer: Documented safety records reduce risks associated with high staff turnover.

- Cost-Efficiency and Safety Culture: Implementing a structured safety management system reduces accidents, boosts morale, and supports a proactive safety culture.

Producing the Safety Case Documentation

An effective Project Safety Management Plan is critical to the organization of the Safety Case documentation. It should include:

- Role AssignmentsDesignate a responsible individual to oversee the safety documentation process.

- Approval ProtocolsDefine both internal and external approval workflows to streamline safety documentation reviews.

- Documentation for All StagesEnsure that documentation covers the design, construction, manufacture, and operational phases, aligning with the safety significance of each stage.

Safety Case Documentation Lifecycle

The Safety Case is dynamic and should adapt throughout the project lifecycle to maintain relevance as the system evolves.

- System Development and TrialsThe Safety Case Report must evolve during development and trials, reflecting any updates to design or safety features.

- Project MilestonesAt each project milestone, the Safety Case Report should validate that safety standards are being met and provide support for decision-making regarding continued development.

- Variant SystemsSafety Cases can be structured to accommodate system variations by creating a single report with variant-specific appendices or compatibility matrices.

Handling Safety Case Caveats

Projects may occasionally need to progress with certain “caveats” or limitations due to incomplete safety information. When this occurs, the following should be considered:

- Clear Communication of CaveatsDefine the limitations and inform all relevant stakeholders, ensuring they understand any usage restrictions.

- Compliance MonitoringEnforce caveat compliance and evaluate whether limitations may introduce additional risks.

Long-Term Safety Documentation Retention

MOD mandates stringent retention periods for safety documentation based on potential risks and exposure, ranging from 2 to 50 years depending on the nature of the hazard. Retention policies are essential for maintaining comprehensive records for the MOD and assisting in post-project reviews or incident investigations.

Transparency in Safety Information Disclosure

While certain MOD establishments may restrict the disclosure of sensitive information under the Public Interests Disclosure Act, unclassified safety documentation should remain accessible to relevant parties and stakeholders, supporting transparency in public safety efforts.

By following the guidance outlined above, project teams can ensure that their Safety Cases not only meet MOD requirements but also foster a culture of safety excellence, accountability, and continuous improvement.

Crafting a Safety Case and Safety Case Report Part 2 is coming soon!

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.
#ALARPSafetyStandards #DefStan00056SafetyCase #MODSafetyRegulations #ProjectSafetyMilestones #SafetyCaseReport #SafetyManagementSystem
Simon Di Nucci https://www.safetyartisan.com/?p=4139

Why Call it The Safety 'Artisan'?

Why did I call my business The Safety 'Artisan'?



artisan/ˈɑːtɪzan,ɑːtɪˈzan/Learn to pronounce noun



A worker in a skilled trade, especially one that involves making things by hand. "street markets where local artisans display handwoven textiles, painted ceramics, and leather goods"



https://youtu.be/-qOAP0AxDHM

Why Call it The Safety 'Artisan'?



Why The Safety 'Artisan'?



Hi, everyone. When I was choosing a name for my business, I thought of quite a lot of alternatives, but I settled on The Safety Artisan for three reasons. First, I liked the meaning of the word, the idea of an individual person pursuing their craft and trying to do it to the very best of their abilities.



Second, I liked the application because I've worked on a lot of very large, even multi-billion-dollar projects; but we're still knowledge workers. We're still individuals who have to be competent at what we do in order to deliver a safe result for people.



And third, I liked the idea, the image of the cottage industry, the artisan working at home as I am now, and delivering goods and services that other people can use wherever they are. And indeed, you might be home or you might be on your mobile phone listening to this.



So I liked all three of those things. I thought, yes, that's what I'm about. That's what I believe in and want to do. And if that sounds good to you, too, then please check out The Safety Artisan, where I provide #safety #engineering #training.



Learn more about me here.

#coursesafetyengineering #engineersafety #ineedsafety #knowledgeofsafety #learnsafety #needforsafety #safetyartisan #safetyblog #safetydo #safetyengineer #safetyengineerskills #safetyengineertraining #safetyengineering #safetyengineeringcourse #safetyprinciples #safetytraining #softwaresafety #theneedforsafety

Simon Di Nucci https://www.safetyartisan.com/2021/03/26/why-call-it-the-safety-artisan/

In-Service Safety Management System
In-Service Safety Management System: Ensuring Long-Term Safety for Military Equipment

Safety is paramount when it comes to military operations, especially for in-service equipment relied upon by personnel daily. This article delves into the intricacies of maintaining an In-Service Safety Management System, offering insight into how safety practices are implemented, monitored, and evolved over time.

Introduction: Why In-Service Safety Matters

When military equipment enters service, the journey of ensuring its safe use doesn’t end there. An effective In-Service Safety Management System (SMS) oversees all safety-related aspects of equipment throughout its operational life. From day-to-day safety practices to long-term risk management, the SMS is vital for sustained safety performance. It also provides a roadmap for identifying, documenting, and addressing safety requirements as equipment evolves over time.

Key Definitions

A Safety Management System, according to Def Stan 00-056, is defined as:

“The organisational structure, processes, procedures, and methodologies that enable the direction and control of the activities necessary to meet safety requirements and safety policy objectives.”

This structure ensures every team member understands the standards and processes needed to maintain operational safety.

Objectives: What an In-Service SMS Aims to Achieve

The primary objectives of an in-service SMS are twofold:

- To recognize and uphold the safety requirements essential for equipment performance.

- To continuously document these processes, forming an auditable Safety Case to maintain accountability.

An effective SMS aligns with various support areas, referred to as "Lines of Development." These encompass personnel, training, sustainability, infrastructure, and facilities, ensuring that each line functions in sync for safe operations from the equipment's inception to its eventual decommissioning.

The SMS also involves continuous Risk Management, adjusting to changes such as equipment enhancements or new usage contexts. This proactive monitoring ensures that safety assurance is consistently updated and accurate.

Procedure for Sustaining Safety Performance

The SMS structure is implemented through the following methods:

- Safety ControlsEssential safety controls cover every phase, from operation to disposal, to reduce risks associated with the equipment. This includes operational limitations, maintenance, emergency preparedness, training, storage, transportation, and waste disposal.

- Safety Information ManagementManaging information effectively is vital. Safety data, incident reports, and safety improvement suggestions should be systematically documented, archived, and shared with relevant stakeholders. Maintaining a Hazard Log and a Safety Case as part of the Safety Management Plan ensures all safety data is up-to-date and readily accessible.

- Continuous Improvement and Safety ReviewsThrough regular audits, inspections, and incident reporting, the SMS can continually improve by identifying and addressing weaknesses. This proactive monitoring helps ensure that safety risks remain controlled over time.

- Configuration ManagementMaintaining a consistent standard for the equipment, including hardware, software, and documentation, is integral to the SMS. Regular reviews address potential issues like obsolescence or outdated manuals to ensure sustained safety performance.

- Risk ManagementAs modifications and enhancements are made, risk management processes like Hazard Analysis and Risk Evaluation ensure new risks are assessed, managed, and documented.

- Lines of DevelopmentThe SMS covers various developmental lines, from training and sustainability to equipment upgrades. Each line contributes to the system’s overall safety, focusing on creating an infrastructure that is both resilient and adaptable.

Safety Records and Documentation: A Foundation for Accountability

The in-service SMS relies on a foundation of well-maintained records. Documents such as the System Requirements Document, Through Life Management Plan, and Project Safety Management Plan with RACI (Responsible, Accountable, Consulted, Informed) charts support clear communication and accountability among stakeholders. Comprehensive documentation is essential for tracking compliance, reviewing safety measures, and justifying safety performance in the event of an audit.

Potential Risks and Warnings

It’s crucial to establish the SMS requirements early in the project lifecycle. Without these, the project may face delays or even safety risks during operation. Other potential risks include gaps in safety roles or inadequate documentation. An outdated or insufficiently maintained SMS may allow lapses in safety that could result in operational hazards or accidents.

Ongoing Review and Development

The SMS must remain dynamic to handle evolving requirements. Major changes, such as equipment modifications or regulatory updates, require a thorough review of the SMS. This adaptive approach helps ensure that safety protocols evolve alongside the equipment, preventing oversights or outdated practices.

Timing for Effective SMS Implementation

An SMS should ideally be drafted early and continually updated as the project progresses. By staying aligned with project developments, it ensures a seamless transition to the in-service phase. A Responsible, Accountable, Consulted, Informed (RACI) chart outlines the responsibilities of every stakeholder, creating a structured approach to safety management. Regular updates also ensure that each stage of the project reflects current safety standards.

Conclusion

For military equipment, safety isn’t a one-time effort but an ongoing commitment. An In-Service Safety Management System provides a comprehensive framework that maintains, monitors, and evolves safety practices, ensuring the safety of both the equipment and the personnel who rely on it.

Required Inputs

This procedure for the Safety Case and Safety Case Report requires inputs from:

- Outputs from Procedure SMP01 – Safety Initiation;

- Outputs from Procedure SMP02 – Safety Committee;

- Outputs from Procedure SMP03 – Safety Planning;

- Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;

- Outputs from Procedure SMP05 – Hazard Identification and Analysis;

- Outputs from Procedure SMP06 – Risk Estimation;

- Outputs from Procedure SMP07 – Risk and ALARP Evaluation;

- Outputs from Procedure SMP08 – Risk Reduction;

- Outputs from Procedure SMP09 – Risk Acceptance;

- Outputs from Procedure SMP10 – Safety Requirements and Contracts;

- Outputs from Procedure SMP11 – Hazard Log;

- Outputs from Procedure SMP12 - Safety Case and Safety Case Report.

This procedure should draw on information in the following documents, and it should also define changes that should be made to their content:

- Through-Life Management Plan;

- Integrated Test, Evaluation and Acceptance Plan;

- Project Safety Management Plan including RACI (Responsible, Accountable, Consulted, Informed) chart;

- Safety Management System Manuals of stakeholders (e.g. Delivery Teams, Delivery Teams providing sub-systems, Users, authorities responsible for safe storage, transportation, disposal, inspection, audit, incident investigation etc.);

- Customer/Supplier Agreements (or similar) defining interfaces and responsibilities for certain Safety Management activities.

Required Outputs

Safety Management System Documentation

The In-Service Safety Management System arrangements should be recorded in various places because of the many authorities involved. For instance, the Safety Management System manuals of different Delivery Teams, user authorities, contractors and support authorities should contain relevant information as well as other documents recording arrangements for Incident and Accident reporting and investigation.

The principal means of bringing together this information should be through the Safety Management Plan and its RACI chart, defining the involvement of the different authorities.

The Project Safety Case should contain a description of the In-Service Safety Management System in operation to ensure that the safety performance of the equipment is achieved and sustained through life.

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.
#DefStanSafetyManagementSystem #EquipmentLifecycleSafety #InServiceSafetyManagement #MilitarySafetyProtocols #RiskManagementinService #SafetyCaseDocumentation #SafetyControlsMilitaryEquipment
Simon Di Nucci https://www.safetyartisan.com/?p=4133