Categories
Mil-Std-882E Safety Analysis System Safety

Sub-System Hazard Analysis with Mil-Std-882E

In this video lesson, I look at Sub-System Hazard Analysis with Mil-Std-882E (SSHA, which is Task 204). I teach the mechanics of the task, but not just that. I’m using my long experience with this Standard to teach a pragmatic approach to getting the work done.

Task 204 is one of three tasks that integrate tightly in a Systems Engineering framework. (The others are System Hazard Analysis, Task 205, and System of Systems Hazard Analysis, Task 209.)

SSHA is designed to be used where a formal Sub-System Specification (SSS) has been created. However, an SSS is not essential to perform this Task. The need for SSHA is usually driven by the complexity of the system and/or that sub-system development is contracted out.

Together, we will explore Task 204’s aim, description, scope, and contracting requirements. There’s value-adding commentary, and I explain the issues with SSHA – how to do it well and avoid the pitfalls.

This is the seven-minute demo, the full video is 40-minutes’ long.

Topics: Sub-System Hazard Analysis

  • Preamble: Sub-system & System HA.
  • Task 204 Purpose:
    • Verify subsystem compliance;
    • Identify (new) hazards; and
    • Recommend necessary actions.
  • Task Description (six slides);
  • Reporting;
  • Contracting; and
  • Commentary.

Transcript: Sub-System Hazard Analysis

Introduction

Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial instruction on all things system safety. I’m Simon – I’m your host for today, as always and it’s the fourth of April 22. With everything that’s going on in the world, I hope that this video finds you safe and well.

Sub-System Hazard Analysis

Let’s move straight on to what we’re going to be doing. We’re going to be talking today about subsystem hazard analysis and this is task 204 under the military standard 882E. Previously we’ve done 201, which was preliminary hazard identification, 202, which is preliminary hazard analysis, and 203, which is safety requirements hazard analysis. And with task 204 and task 205, which is system has analysis, we’re now moving into getting stuck into particular systems that we’re thinking about, whether they be physical systems or intangible. We’re thinking about the system under consideration and I’m really getting into that analysis.

Topics for this Session

So, the topics that we’re going to cover today, I’ve got a little preamble to set things in perspective. We then get into the three purposes of task 204. First, to verify compliance. Secondly, to identify new hazards. And thirdly, to recommend necessary actions. That would be recommended control measures for hazards and risks. We’ve got six slides of task description, a couple of slides on reporting, one on contracting, and then a few slides on some commentary where I put in my tuppence worth and I’ll hopefully add some value to the basic bones of the standard.

It’s worth saying that you’ll notice that subsystem is highlighted in yellow and the reason for that is that the subsystem and system hazard analysis tasks are very, very similar. They’re identical except for certain passages and I’ve highlighted those in yellow. Normally I use a yellow highlighter to emphasize something I want to talk about. This time around, I’m using underlining for that and the yellow is showing you what these are different for subsystem analysis as opposed to system [hazard analysis]. And when you’ve watched both sessions on 204 and 205, I think you’ll see the significance of what I’ve done.

Preamble – Sub-system & System HA

Before we get started, we need to explain the system model that the 882 is assuming. If we look at the left-hand side of the hexagons, we’ve got our system in the center, which we’re considering. Maybe that interfaces with other systems. They work within the operating environment; hence we have the icon of the world, and the system and maybe other systems are there for a purpose. They’re performing some task; they’re doing some function and that’s indicated by the tools. We’re using the system to do something, whatever it might be.

Then as we move to the right-hand side, the system is itself broken down into subsystems. We’ve got a couple here. We’ve got sub-systems A and B and then A further broken down into A1 and A2, for example. There’s some sort of hierarchy of subsystems that are coming together and being integrated to form the overall system. That is the overall picture that I’d like to bear in mind while we’re talking about this. The assumption in the 882, is we’re going to be looking at this subsystem hierarchy bottom upwards, largely. We’ll come on to that.

Sub-System Hazard Analysis (T204)

The purpose of the task, as I’ve said before, it’s threefold. We must verify subsystem compliance with requirements. Requirements to deal with risk and hazards. We must identify previously unidentified hazards that may emerge as we’re working at a lower level now. And we must recommend actions as necessary. Those are further requirements to eliminate all hazards or mitigate associated risks. We’ll keep those three things in mind and that will keep coming up.

[Video continues…]

End: Sub-System Hazard Analysis

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

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

Categories
Mil-Std-882E Safety Analysis

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.

This is the seven-minute-long demo. The full video is 47 minutes long.

System Hazard Analysis: Topics

  • Task 205 Purpose [differences vs. 204];
    • 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.

Categories
Blog

FREE for FIVE DAYS ONLY

FREE for FIVE DAYS ONLY: All courses. Get $320 worth of courses for FREE.

Use these Links to make a (free) purchase of all courses within FIVE DAYS; once purchased, you can access them forever.

  1. PHI. https://www.udemy.com/course/how-to-preliminary-hazard-identification-mil-std-882e/?couponCode=3B647B2601765A24E3DF
  2. PHA. https://www.udemy.com/course/how-to-preliminary-hazard-analysis-mil-std-882e/?couponCode=D058185509903D726D56
  3. SRHA. https://www.udemy.com/course/how-system-requirements-hazard-analysis-with-mil-std-882e/?couponCode=75C1A9AD498E27B54297
  4. SSHA. https://www.udemy.com/course/how-to-sub-system-hazard-analysis-with-mil-std-882e/?couponCode=B4AC57607BD4D4CBEB7E
  5. SHA. https://www.udemy.com/course/system-hazard-analysis-with-mil-std-882e/?couponCode=4FDF41E4B2323B6B1656
  6. O&SHA. https://www.udemy.com/course/how-to-operating-support-hazard-analysis-mil-std-882e/?couponCode=EE860D71ADE8E63F7F73
  7. HHA. https://www.udemy.com/course/how-to-do-health-hazard-analysis-with-mil-std-882e/?couponCode=F737841C3E04393D94BC
  8. FHA. https://www.udemy.com/course/how-to-do-functional-hazard-analysis-with-mil-std-882e/?couponCode=1965EEBB198045B94788
  9. SoSHA. https://www.udemy.com/course/how-to-do-system-of-system-hazard-analysis-with-mil-std-882e/?couponCode=8BC6461BFE39AD45C419
  10. EHA. https://www.udemy.com/course/how-to-do-environmental-hazard-analysis-with-mil-std-882e/?couponCode=C307CCB7F61D0046F44F
  11. System Safety Process. https://www.udemy.com/course/system-safety-engineering-process/?couponCode=F8E483D24B3EF0535598
  12. SSRAP 1 & 2 (includes SATO). https://www.udemy.com/course/system-safety-risk-analysis-programs/?couponCode=786058D5B3479CF954A7

************************************************

This series of courses teaches the system safety analysis tasks from Mil-Std-882E. When combined, they allow us to assess a system’s safety in its given role and operating environment.

Design a Safety Risk Assessment Program for ANY system in ANY application. This course covers all ten analysis tasks from the defense system safety standard Mil-Std-882E.

Whatever it is, you will learn how to tailor your risk assessment, using the analyses you need. You will be able to meet your legal and regulatory requirements. Once you’ve learned how to do this, you can apply it to almost any system.  There are ten lessons.

I just posted these courses on Udemy, and they are on sale at unbeatable prices. Please use these links to access the courses; otherwise, Udemy takes 67% of my revenue!

Introduction to System / Product / Design Safety Concepts

NEW! Get the FREE introductory course here: https://www.udemy.com/course/introduction-to-system-product-design-safety-concepts/?referralCode=E173BDB0AD2525946E04

Preliminary Hazard Identification, Task 201

https://www.udemy.com/course/how-to-preliminary-hazard-identification-mil-std-882e/?referralCode=F681CF650D3BDDAD307B

Preliminary Hazard Analysis, Task 202

https://www.udemy.com/course/how-to-preliminary-hazard-analysis-mil-std-882e/?referralCode=1A153CA582E27235304D

System Requirements Hazard Analysis, Task 203

https://www.udemy.com/course/draft/6201059/?referralCode=919C1FCE9C325351BA24

Sub-System Hazard Analysis, Task 204

https://www.udemy.com/course/draft/6198979/?referralCode=D014CFEB810BD288A741

System Hazard Analysis, Task 205

https://www.udemy.com/course/draft/6213023/?referralCode=C586042AEC0B17DD4A0D

Operating & Support Hazard Analysis, Task 206

https://www.udemy.com/course/draft/6222279/?referralCode=52AC8A5582A67DE77BB0

Health Hazard Analysis, Task 207

https://www.udemy.com/course/draft/6222285/?referralCode=F589E3A00F2F19CACDD3

Functional Hazard Analysis, Task 208

https://www.udemy.com/course/draft/6238409/?referralCode=4253568A1CF2CD848BB8

System of Systems Hazard Analysis, Task 209

https://www.udemy.com/course/draft/6243643/?referralCode=AEE718911215D78E6D94

Environmental Hazard Analysis, Task 210

https://www.udemy.com/course/draft/6238409/?referralCode=4253568A1CF2CD848BB8

Meet the Author

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

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

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

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

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

•Presented on safety topics at several international conferences.

Categories
Blog Safety Management

Navigating the Safety Case

Navigating the Safety Case is Part 4 of a four-part series on safety cases. In it, we look at timing issues and typical content through the safety case lifecycle.

A Comprehensive Guide to Ensuring Project Safety

When embarking on any significant project, ensuring safety isn’t just a step in the process—it’s the foundation of success. A Safety Case is the bedrock of this commitment, systematically building the evidence needed to demonstrate that a system is safe for use throughout its lifecycle. Here’s a vibrant, step-by-step guide to understanding and implementing Safety Cases effectively.

Starting the Safety Journey: Initiation

The moment that Safety Management activity kicks off, the Safety Case begins to take shape. Think of it as an evolving tapestry where each thread represents a layer of safety assurance.

Milestone Checkpoints: Producing Safety Case Reports

Safety Case Reports should be produced at pivotal milestones to maintain accountability and ensure progress. These reports not only showcase progress but also serve as vital checkpoints to align all stakeholders. Common milestones include:

  1. Approval of the Outline Business Case
  2. Approval of the Full Business Case
  3. Authorization to begin demonstration trials
  4. Completion of major design phases
  5. Commitment to production
  6. Testing, acceptance, and user trials
  7. System introduction to service
  8. Design or material state updates (e.g., midlife refresh)
  9. Operational changes
  10. Disposal of the system

These reports should align with the Project Safety Management Plan, serving as contractual deliverables between the contractor and the project team.

Keeping it Alive: Periodic Reviews

Safety isn’t static. The Safety Case is a living document requiring ongoing updates, reviews, and configuration control. Regular reviews ensure it adapts to new challenges, emerging risks, and evolving system requirements.

Gathering Insights: Required Inputs

To build a robust Safety Case, a wealth of inputs is essential. These include data and outputs from key procedures such as hazard identification, risk estimation, risk reduction, and safety requirements. The journey is a collaborative effort where insights from all corners of the project feed into the evolving safety narrative.

The Safety Case and Safety Case Report require inputs from:

  1. Outputs from Procedure SMP01 – Safety Initiation;
  2. Outputs from Procedure SMP02 – Safety Committee;
  3. Outputs from Procedure SMP03 – Safety Planning;
  4. Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;
  5. Outputs from Procedure SMP05 – Hazard Identification and Analysis;
  6. Outputs from Procedure SMP06 – Risk Estimation;
  7. Outputs from Procedure SMP07 – Risk and ALARP Evaluation;
  1. Outputs from Procedure SMP08 – Risk Reduction;
  2. Outputs from Procedure SMP09 – Risk Acceptance;
  3. Outputs from Procedure SMP10 – Safety Requirements and Contracts;
  4. Outputs from Procedure SMP11 – Hazard Log.

Delivering Confidence: Required Outputs

At its core, the Safety Case outputs are more than just documents—they are the backbone of confidence for all stakeholders. The primary outputs include:

  • Controlled documentation supporting the safety of the system
  • Detailed Safety Case Reports tailored to each project phase
  • Evidence-backed arguments showcasing tolerable risk levels

Breaking It Down: Typical Safety Case Report Content

An effective Safety Case Report doesn’t just inform; it assures. Here’s what it typically includes:

  • Executive Summary: Assurance of safety progress and stakeholder alignment
  • System Description: Boundaries, scope, and interface clarity
  • Assumptions: Factors underpinning safety requirements
  • Progress Assessment: Updates on safety activities and milestones
  • Risk Management: Documentation of hazards, risks, and mitigation strategies
  • Emergency and Contingency Plans: Preparedness for unforeseen circumstances
  • Operational Guidance: Practical safety insights for operators

The Lifecycle Perspective: Safety Cases at Every Stage

Concept Stage

Here, safety begins with identifying risks early, crafting strategies, and ensuring feasibility. By the Outline Business Case, the safety vision should be clear, even if some areas remain undefined.

Assessment Phase

Building on the Concept Stage, this phase involves a deeper analysis of risks and strategies for mitigation, culminating in a Safety Case Report for the Full Business Case.

Demonstration & Trials

Safety during trials ensures a controlled environment for testing and evaluation. Detailed Safety Management Plans guide this phase, ensuring all involved parties understand their responsibilities.

Introduction to Service

At this stage, safety extends to operational readiness—ensuring support facilities, training, and logistic arrangements are in place.

Disposal

Disposal planning begins early, considering risks throughout the system’s life. Safety Cases for disposal ensure proper handling, whether through recycling, scrapping, or resale, minimizing liability and environmental impact.

Conclusion

The Safety Case is more than a procedural requirement—it’s a commitment to integrity, collaboration, and responsibility. By weaving together comprehensive safety practices at every stage, projects can achieve a level of confidence that benefits all stakeholders.

Are you ready to take your Safety Case to the next level? Share your thoughts and experiences in the comments below!

Meet the Author

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

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

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

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

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

•Presented on safety topics at several international conferences.

Categories
Blog Safety Management

The Lifelong Evolution of a Safety Case

Introduction

In The Lifelong Evolution of a Safety Case, we look at how to Review and revise a Safety Case and Re-Issue a Safety Case Report.

When it comes to ensuring safety throughout any Product, System, or Service lifecycle, reviewing and revising the Safety Case isn’t just a recommendation—it’s essential. The age or status of equipment isn’t simply about how old it is. Instead, it reflects an understanding of its condition, the effects of changes, and its performance in varying environments over time. Let’s dive into the key principles of maintaining and revising a Safety Case and the potential risks and strategies to avoid them.

Why Review the Safety Case?

Changes in operations, equipment condition, or organizational controls can disrupt the assumptions on which the original Safety Case was built. Recognizing when a review is needed ensures safety remains uncompromised.

Here are examples of scenarios that demand attention:

  • Structural Modifications: Repairs or upgrades impacting safety.
  • New Activities: Introduction of new tasks or uses for the equipment.
  • Environmental Changes: Shifts in operational environments or equipment roles.
  • Incident Data: Insights from accidents or maintenance inspections.
  • System Evolution: Decommissioning, extended use, or technological upgrades.

Figure: Relationship between the Safety Management System and Safety Case in terms of Age and Status

Relationship between the Safety Management System and Safety Case

Challenging Assumptions: The Foundation of Safety

A Safety Case is never static—it evolves as evidence and conditions change. It’s vital to challenge existing arguments continually. If new evidence undermines the validity of the Safety Case, steps like obtaining further proof, implementing corrective actions, or, in extreme cases, halting operations may be necessary.

Consider this: what was deemed safe at one time might become risky due to wear, updates, or new findings. Regular reviews ensure the Safety Case remains robust and relevant.

Ownership and Administration: Who’s in Charge?

The custodian of the Safety Case is the Project Safety Manager, the linchpin in ensuring safety throughout the lifecycle of the system. This individual must coordinate all safety activities, maintain the Safety Case, and oversee its interaction with the Safety Management System (SMS).

While contractors may handle the technical details, the responsibility for ensuring the integrity and adequacy of the Safety Case rests with the appointed safety delegation holder.

Records Matter: Documenting Safety

Every decision, from hazard mitigation to safety strategy adjustments, must be meticulously recorded. Key documents feeding into this process include:

  • System Requirements Document: Detailing specific safety needs.
  • Customer-Supplier Agreement: Outlining deliverables.
  • Through-Life Management Plan: Ensuring continuity in safety oversight.

A central part of this process is the Hazard Log, which serves as the repository of all identified risks and their management status. (see Procedure SMP11 – Hazard Log).

Avoiding Pitfalls: The Warnings

The warnings and project risks identified in all the other procedures, from SMP01 to SMP11 can manifest themselves through effects on the Safety Case, as it brings their outputs together. Also, there are other project risks specific to the Safety Case.

Neglecting regular reviews or documentation can lead to significant issues, including:

  1. Delays in Safety Approvals: Failure to engage approval authorities early can result in unmet safety requirements and service delays.
  2. Outdated Safety Cases: A mismatch between documentation and the system’s current state undermines credibility.
  3. Inadequate Risk Analysis: Improper techniques during safety assessments may yield an incomplete Safety Case.
  4. Lost Records: Poor documentation management can erode trust in the safety process.

Completing the Circle: The Role of Collaboration

Maintaining a credible and effective Safety Case is a collective effort. Contractors, safety committees, and stakeholders must work in concert to identify and mitigate hazards. Sharing data, especially during transitions between contractors, is crucial to avoiding gaps in safety oversight.

Wrapping Up

The Safety Case is more than a set of documents—it’s a dynamic framework ensuring that safety risks are continuously managed throughout the lifecycle of a system. With proper reviews, updates, and collaboration, it provides confidence that safety remains a top priority, no matter the changes a system undergoes.

This blog article is Part 3 of a series. It follows on from Part 2.

Meet the Author of ‘The Lifelong Evolution of a Safety Case’

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

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

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

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

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

•Presented on safety topics at several international conferences.

Categories
Blog

The 2024 Blog Digest – Q3/Q4

The 2024 Blog Digest – Q3/Q4 brings you all of The Safety Artisan’s blog posts from the first six months of this year. I hope that you find this a useful resource!

The 2024 Blog Digest – Q3/Q4: 18 Posts!

  • Sub-System Hazard Analysis with Mil-Std-882E
    In this video lesson, I look at Sub-System Hazard Analysis with Mil-Std-882E (SSHA, which is Task 204). I teach the mechanics of the task, but not just that. I’m using my long experience with this Standard to teach a pragmatic approach to getting the work done. Task 204 is one of three tasks that integrate… Read more: Sub-System Hazard Analysis with Mil-Std-882E
  • 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… Read more: System Hazard Analysis with Mil-Std-882E
  • FREE for FIVE DAYS ONLY
    FREE for FIVE DAYS ONLY: All courses. Get $320 worth of courses for FREE. Use these Links to make a (free) purchase of all courses within FIVE DAYS; once purchased, you can access them forever. ************************************************ This series of courses teaches the system safety analysis tasks from Mil-Std-882E. When combined, they allow us to assess… Read more: FREE for FIVE DAYS ONLY
  • Navigating the Safety Case
    Navigating the Safety Case is Part 4 of a four-part series on safety cases. In it, we look at timing issues and typical content through the safety case lifecycle. A Comprehensive Guide to Ensuring Project Safety When embarking on any significant project, ensuring safety isn’t just a step in the process—it’s the foundation of success.… Read more: Navigating the Safety Case
  • The Lifelong Evolution of a Safety Case
    Introduction In The Lifelong Evolution of a Safety Case, we look at how to Review and revise a Safety Case and Re-Issue a Safety Case Report. When it comes to ensuring safety throughout any Product, System, or Service lifecycle, reviewing and revising the Safety Case isn’t just a recommendation—it’s essential. The age or status of… Read more: The Lifelong Evolution of a Safety Case
  • The 2024 Blog Digest – Q3/Q4
    The 2024 Blog Digest – Q3/Q4 brings you all of The Safety Artisan’s blog posts from the first six months of this year. I hope that you find this a useful resource! The 2024 Blog Digest – Q3/Q4: 18 Posts! The 2024 Blog Digest – Q3/Q4 is it for this year – thanks, everyone! Meet… Read more: The 2024 Blog Digest – Q3/Q4
  • 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… Read more: Crafting a Safety Case and Safety Case Report – Part 2
  • 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 [Picture by Eric Bruton from Pexels.com] 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… Read more: Crafting a Safety Case and Safety Case Report
  • 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:… Read more: In-Service Safety Management System
  • Comprehensive Project Safety Management Plans: A Guide
    Comprehensive Project Safety Management Plans. Safety is a critical element in any large-scale project, especially in the context of defense and complex systems. One essential tool for managing safety is a Safety Management Plan (SMP). In this article, we’ll break down the process and structure of an effective SMP, highlighting its objectives, content, and how… Read more: Comprehensive Project Safety Management Plans: A Guide
  • Guide to Establishing and Running a Project Safety Committee (PSC)
    Our Second Safety Management Procedure is the Project Safety Committee. Okay, so committees are not the sexiest subject, but we need to get stakeholders together to make things happen! Project Safety Committee: Introduction In safety-critical industries such as defense, aerospace, and engineering, maintaining a robust safety management system (SMS) is paramount. A Project Safety Committee… Read more: Guide to Establishing and Running a Project Safety Committee (PSC)
  • Project Safety Initiation
    In ‘Project Safety Initiation’ we look at what you need to do to get your safety project or program started. Introduction Definitions A stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to… Read more: Project Safety Initiation
  • Members Get a Free Intro Course, 50% Off & Updates
    Members Get a Free Intro Course, 50% Off & Updates. I will send you the links and discount codes via email. So, tick the email box and check your junk mail to receive the offers. You will get an email series showcasing the free/paid resources. Also, regular updates on new articles: never miss another post!… Read more: Members Get a Free Intro Course, 50% Off & Updates
  • More Resources for Risk Assessment
    Welcome to Module Five, More Resources for Risk Assessment. We’re on the home straight now! This is the last of the five modules. I will let you know where to get more resources and help on these topics. Course Learning Objectives More Resources for Risk Assessment: Transcript Copyright/Source Statement “First, I want to point out… Read more: More Resources for Risk Assessment
  • Designing Your Risk Assessment Program
    Designing Your Risk Assessment Program. Which Ingredients should we use? In this post, I draw upon my 25+ years in system safety to give you some BOLD advice! I’m going to dare to suggest which analysis tasks are essential to every System Safety Program. I also suggest which tasks are optional depending on the system… Read more: Designing Your Risk Assessment Program
  • Understanding Your Risk Assessment Standard
    When Understanding Your Risk Assessment Standard, we need to know a few things. 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 will ask… Read more: Understanding Your Risk Assessment Standard
  • Risk Management 101
    Welcome to Risk Management 101, where we’re going to go through these basic concepts of risk management. We’re going to break it down into the constituent parts and then we’re going to build it up again and show you how it’s done. I’ve been involved in risk management, in project risk management, safety risk management,… Read more: Risk Management 101
  • System Safety Risk Analysis
    In this module, System Safety Risk Analysis, we’re going to look at how we deal with the complexity of the real world. We do a formal risk analysis because real-world scenarios are complex. The Analysis helps us to understand what we need to do to keep people safe. Usually, we have some moral and legal obligation to do it as well. We need to do it well to protect people and prevent harm to people.

The 2024 Blog Digest – Q3/Q4 is it for this year – thanks, everyone!

Meet the Author

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

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

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

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

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

•Presented on safety topics at several international conferences.

Categories
Safety Management

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:

  1. Agreeing on a Document
    To 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.
  2. Endorsing a Document
    To 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.
  3. Authorizing a Document
    The 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.
  4. Providing Assurance
    As 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 Order
The 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 Adjustments
Review 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) Risks
When 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 Reports
At 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 Endorsements
The 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.

Conclusion
Managing 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.

Categories
Safety Management

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

[Picture by Eric Bruton from Pexels.com]

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.

Definitions
To 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:

  1. Documenting Evidence
    A thorough record of all evidence ensures that the system meets established Safety Requirements and all identified risks are As Low As Reasonably Practicable (ALARP).
  2. Safe Execution of Activities
    For systems undergoing testing or trials, the Safety Case ensures these activities can proceed without jeopardizing safety.
  3. Justifying Safety of the System
    By clearly articulating the arguments and evidence, the Safety Case justifies the system’s safety through validated processes and assessments.
  4. Gaining Approval
    In 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.

  1. Incorporating Contractor and MOD Data
    The Safety Case combines all safety assessments and risk management activities, ensuring comprehensive and traceable safety information.
  2. Leveraging Diverse Evidence
    Safety evidence can vary, including historical, analytical, test, and expert judgment inputs. A structured approach ensures that all critical safety information is preserved and accessible.
  3. Compliance and Regulatory Approvals
    The 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:

  1. Role Assignments
    Designate a responsible individual to oversee the safety documentation process.
  2. Approval Protocols
    Define both internal and external approval workflows to streamline safety documentation reviews.
  3. Documentation for All Stages
    Ensure 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.

  1. System Development and Trials
    The Safety Case Report must evolve during development and trials, reflecting any updates to design or safety features.
  2. Project Milestones
    At each project milestone, the Safety Case Report should validate that safety standards are being met and provide support for decision-making regarding continued development.
  3. Variant Systems
    Safety 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:

  1. Clear Communication of Caveats
    Define the limitations and inform all relevant stakeholders, ensuring they understand any usage restrictions.
  2. Compliance Monitoring
    Enforce 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.

Categories
Safety Management

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:

  1. To recognize and uphold the safety requirements essential for equipment performance.
  2. 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:

  1. Safety Controls
    Essential 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.
  2. Safety Information Management
    Managing 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.
  3. Continuous Improvement and Safety Reviews
    Through 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.
  4. Configuration Management
    Maintaining 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.
  5. Risk Management
    As modifications and enhancements are made, risk management processes like Hazard Analysis and Risk Evaluation ensure new risks are assessed, managed, and documented.
  6. Lines of Development
    The 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:

  1. Outputs from Procedure SMP01 – Safety Initiation;
  2. Outputs from Procedure SMP02 – Safety Committee;
  3. Outputs from Procedure SMP03 – Safety Planning;
  4. Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;
  5. Outputs from Procedure SMP05 – Hazard Identification and Analysis;
  6. Outputs from Procedure SMP06 – Risk Estimation;
  7. Outputs from Procedure SMP07 – Risk and ALARP Evaluation;
  8. Outputs from Procedure SMP08 – Risk Reduction;
  9. Outputs from Procedure SMP09 – Risk Acceptance;
  10. Outputs from Procedure SMP10 – Safety Requirements and Contracts;
  11. Outputs from Procedure SMP11 – Hazard Log;
  12. 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:

  1. Through-Life Management Plan;
  2. Integrated Test, Evaluation and Acceptance Plan;
  3. Project Safety Management Plan including RACI (Responsible, Accountable, Consulted, Informed) chart;
  4. 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.);
  5. 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.

Categories
Blog Safety Management

Comprehensive Project Safety Management Plans: A Guide

Comprehensive Project Safety Management Plans. Safety is a critical element in any large-scale project, especially in the context of defense and complex systems. One essential tool for managing safety is a Safety Management Plan (SMP). In this article, we’ll break down the process and structure of an effective SMP, highlighting its objectives, content, and how to ensure its successful implementation.

Comprehensive Project Safety Management Plans: Introduction

Definitions

Safety Management Plan is defined as:

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

UK MoD Defence Standard 00-56

In other words, an SMP serves as a structured approach to managing safety across a project’s lifecycle, ensuring that all risks are identified, analyzed, and mitigated effectively.

Objectives

The core objectives of a Project Safety Management Plan are twofold:

  1. Ensuring Safety Performance: The plan guarantees that the system remains safe throughout its entire lifecycle.
  2. Maintaining Assurance: It provides the necessary information to demonstrate that safety objectives are being met continuously.
  3. Achieving these goals requires a coordinated, structured approach that integrates risk management and establishes clear safety requirements right from the start.

SMP in Practice: Contractor vs. Enterprise Project

Each organization involved in the project—whether it’s the Enterprise Project or a contractor—must produce a distinct SMP that outlines their safety activities. Though separate, these plans should align with each other and the overall project goals. This integration is crucial as safety activities span system development, trials, and any necessary safety approvals.

The SMP discussed here focuses specifically on the Enterprise Project’s plan, which acts as the guiding document for all safety management activities.

Procedure and Methodology

Establishing the Safety Management Framework

The SMP outlines the strategy for ensuring safety and documents the Safety Management System for a particular project. It’s more than just a checklist—it’s a comprehensive program that captures safety timescales, milestones, and other relevant data.

Key areas to be addressed in an SMP include:

  • General Equipment Safety: An overarching review of the equipment’s safety features.
  • System-Specific Requirements: For example, airworthiness or ship-specific hazards.
  • Occupational Safety: Encompassing manual handling, packaging, transport, and more.
  • Operational Safety: Ensuring safe procedures during the use phase.
  • Maintenance Safety: Guidelines for repair and maintenance activities.
  • Training and Disposal: Safety considerations for personnel training and end-of-life disposal of the system.

Creating a Tailored Safety Strategy

No two projects are identical, and neither should their SMPs be. Each plan must be custom-designed to fit the specific project requirements, ensuring a safety strategy that is practical and achievable.

Structuring the SMP: Essential Elements

An effective SMP should contain the following sections:

  1. Outline Description: Clearly defines the equipment, its purpose, operational environment, and expected capabilities.
  2. Safety Management System: Details the system’s objectives, managerial tasks, and responsible organizations.
  3. Responsibilities and Resources: Identifies key personnel and defines their roles through a RACI chart (Responsible, Accountable, Consulted, Informed).
  4. Audit Arrangements: Outlines internal and independent audit processes.
  5. Requirements and Acceptance Criteria: Defines safety requirements, targets, and the standards by which success will be measured.
  6. Safety Case Scope and Strategy: Lays out the assessment strategy and techniques to control hazards.
  7. Safety Programme: A comprehensive work plan linked to the Through Life Management Plan.

An example template for structuring your SMP can be found in Annex A. Refer to Annex B for a sample RACI chart to guide accountability and communication.

Warnings and Potential Project Risks

The SMP is the linchpin of project safety management. If not accurately maintained, the project may face unforeseen delays, increased costs, or compromised safety performance.

Common Pitfalls:

  • Inadequate Detail: Missing out on key safety activities can lead to delays and escalated costs.
  • Outdated Information: Failing to keep the SMP updated can result in misalignment with the actual safety activities.
  • Insufficient Review: Lack of endorsement by the Project Safety Committee (PSC) may mean the plan does not accurately reflect stakeholder responsibilities.

These risks underscore the importance of a thorough, continuously updated SMP.

Procedure Completion and Review

The Project Safety Committee (PSC) is responsible for drafting, endorsing, and reviewing the SMP, ensuring that safety requirements and acceptance criteria are clearly defined and agreed upon by all parties.

Timing:

  • Initial Production: Start as early as the Concept stage.
  • Ongoing Updates: Review and update the SMP regularly, especially during key project milestones.

The SMP should be a living document that evolves as new information arises or project requirements change.

Safety Planning: Required Inputs

This procedure for Safety Planning requires inputs from:

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

These inputs should be integrated with other management plans throughout the acquisition cycle.

Outputs:

The SMP’s outputs should feed into several project documents, including:

  • System Requirements Document: Capture specific safety needs.
  • Customer Supplier Agreement: Document mutual agreements on safety deliverables.
  • Through Life Management Plan: Align with long-term safety management.
  • Business Case Submissions: Support safety-related elements in decision-making processes.

All meeting minutes should reflect decisions made regarding the SMP’s development and up-issue.

Conclusion

The Safety Management Plan is the cornerstone of safety assurance in complex projects. Properly implemented, it serves as a robust framework to manage safety risks, ensure compliance, and maintain confidence in the system’s safety performance throughout its lifecycle.

By following the structure and content outlined in this guide, project teams can create a comprehensive, effective SMP that aligns with the highest standards of safety management.d up-issue.

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

TITLE

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

DESCRIPTION

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

INVOLVEMENT OF SPECIALIST SAFETY ADVISORS

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

PROJECT SAFETY MANAGEMENT SYSTEM

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

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

SAFETY REQUIREMENTS

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

PROGRAMME OF WORK

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

SAFETY CASE STRATEGY

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

APPROVAL

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

DISTRIBUTION

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

Annex B – RACI Chart example

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

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

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

Acknowledgment of Copyright

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

Comprehensive Project Safety Management Plans: What are Your Questions?

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.