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
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:
Approval of the Outline Business Case
Approval of the Full Business Case
Authorization to begin demonstration trials
Completion of major design phases
Commitment to production
Testing, acceptance, and user trials
System introduction to service
Design or material state updates (e.g., midlife refresh)
Operational changes
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:
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
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.
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.
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:
Delays in Safety Approvals: Failure to engage approval authorities early can result in unmet safety requirements and service delays.
Outdated Safety Cases: A mismatch between documentation and the system’s current state undermines credibility.
Inadequate Risk Analysis: Improper techniques during safety assessments may yield an incomplete Safety Case.
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.
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!
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 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
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 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
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: 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: 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. 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
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)
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. 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
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. 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
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
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
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.
TL;DR Updating Legal Presumptions for Computer Reliability must happen if we are to have justice! Background The ‘Horizon’ Scandal in the UK was a major miscarriage of justice: Between 1999 and 2015, over 900 sub postmasters were convicted of theft, fraud and false accounting based on faulty Horizon data, with about 700 of these prosecutions… Read more: Updating Legal Presumptions for Computer Reliability
What are the Hazard and Risk basics? So, what is this risk analysis stuff all about? What is ‘risk’? How do you define or describe it? How do you measure it? When? Why? Who…? In this free session, I explain the basic terms and show how they link together, and how we can break them… Read more: Hazard and Risk Basics
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.
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.
“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:
Ensuring Safety Performance: The plan guarantees that the system remains safe throughout its entire lifecycle.
Maintaining Assurance: It provides the necessary information to demonstrate that safety objectives are being met continuously.
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:
Outline Description: Clearly defines the equipment, its purpose, operational environment, and expected capabilities.
Safety Management System: Details the system’s objectives, managerial tasks, and responsible organizations.
Responsibilities and Resources: Identifies key personnel and defines their roles through a RACI chart (Responsible, Accountable, Consulted, Informed).
Audit Arrangements: Outlines internal and independent audit processes.
Requirements and Acceptance Criteria: Defines safety requirements, targets, and the standards by which success will be measured.
Safety Case Scope and Strategy: Lays out the assessment strategy and techniques to control hazards.
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:
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:
The aims and objectives of the safety management system;
Technical tasks to be undertaken and organization responsible for implementing them;
Identification of project staff with responsibility for carrying out safety tasks. Include those who are to be issued with letters of delegation;
Cross-refer to any relevant project safety documents or reports;
A regime for internal or independent audits of the safety management system;
Details of the project safety panel;
Responsibilities, resources, and interfaces with Enterprise, contractor, and specialist advisors;
Safety reviews, feedback, and reporting procedures;
Transfer arrangements;
Design changes;
Contractor’s trials.
SAFETY REQUIREMENTS
Safety requirements arising from legislation;
Enterprise Certification requirements;
Acceptance criteria;
Safety requirements from the Requirement or;
Safety targets;
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:
Activity
Safety Delegation Holder
Project Safety Manager
Independent Safety Auditor
Contractor Project Safety Engineer
Equipment User
Safety Case Preparation
A
R
I
R
I
Safety Case Endorsement
A
I
R
I
I
Hazard Log Administration
A
I
–
R
–
Safety Requirements Preparation
A
R
–
R
C
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.
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 (PSC) plays a vital role in overseeing, coordinating, and ensuring safety compliance throughout the lifecycle of equipment and systems. This guide will explore the role, objectives, and procedures of a PSC, as defined in UK Def Stan 00-56, and provide insights on how to structure and run a PSC effectively.
What is a Project Safety Committee (PSC)?
A Safety Committee is defined as:
A group of stakeholders that exercises, oversees, reviews and endorses safety management and safety engineering activities.
Def Stan 00-56
Simply put, the PSC is a formal body composed of experts and decision-makers from various disciplines, convened to ensure that safety-related decisions are well-founded, thoroughly vetted, and correctly implemented.
Objectives of a PSC
The key objectives of a PSC are to ensure effective coordination, agreement, and proper response from those with safety responsibilities. Specifically, the PSC achieves the following:
Coordination of Safety Issues: The PSC acts as a platform where all stakeholders responsible for safety management can ensure coordination on safety issues, eliminating silos.
Access to Knowledge: It provides decision-makers with access to relevant knowledge and expertise across different domains, including engineering, maintenance, user experience, and risk management.
Oversight of the Safety Case: The PSC ensures competent oversight of the safety case throughout its development and maintenance.
Audit Trail: keep detailed meeting records, and establish an audit trail showing that advice was sought and safety decisions were grounded in expertise.
The PSC should facilitate smaller working groups or sub-committees to address specific safety issues when necessary, ensuring that no aspect of the safety management process is overlooked.
In Australia, it is a legal requirement for those with safety responsibilities (Duty Holders) to consult, coordinate and cooperate with others. Other countries may use different terms for similar requirements. The bottom line is that it’s a good idea!
Top Tip
Project Safety Committee: Procedure
Membership of the PSC
The effectiveness of a PSC largely depends on its membership, which should include representatives with specific roles and expertise, as appropriate to the project. Typical members might include:
Delivery Team Representatives (e.g., Project Safety Manager)
Logistics Support Teams
Equipment Support Teams
Customer and User Representatives
Prime Contractors and Subcontractors
Design Organization
Independent Safety Auditor
Specialist Advisors
Regulator / Safety Authority
Safety and Environmental Protection Group
Moreover, it may also include contractors, consultants, and subject matter experts from other government departments or foreign defense bodies.
However, don’t invite anybody and everybody ‘just in case’, as this devalues the PSC and its work.
Top Tip
More information on PSC membership has been provided in Annex A – example Terms of Reference for a PSC.
Chair and Quorum
A critical element of any PSC is competent leadership. The PSC Chair must be a safety-competent individual holding formally-delegated authority for the program’s safety tasks, typically defined in a Letter of Delegation. This document outlines the chairperson’s responsibilities and authority.
For a PSC to conduct its business, it must be quorate, meaning a minimum number of key members must be present. This quorum usually consists of:
Delivery Team safety delegation holder
Project Safety Manager
Design organization representative
Customer representative
Safety Case author
If a quorum is not achieved, the meeting can still proceed, but decisions will only be implemented after receiving approval from the absent quorum members..
Quorum
In order for a PSC to make decisions concerning the safety of a capability or equipment, it should be declared quorate at the beginning of the meeting. In order for a PSC to be declared quorate, the following SQEP and authorized members should be in attendance:
Delivery Team safety delegation holder
Project Safety Manager
Design organization
Customer representative (Project Sponsor)
Safety Case author
The quorate for a PSC can be expanded depending on the nature of the project. Details should be provided in the Project Safety Management Plan (SMP) or Terms of Reference.
If a quorum is not achieved, the meeting can still proceed, but decisions will only be implemented after receiving approval from the absent quorum members.
This is a good point. PSCs don’t always meet frequently, and getting some members to attend can be challenging. Nevertheless, it is important to keep moving forwards.
Top Tip
Meeting Frequency and Structure
PSC meetings should be scheduled regularly, though the frequency will depend on the project’s complexity and phase. Typically, meetings occur more frequently during the early design and review stages, and less frequently once the system is in service.
For smaller projects, PSC activities can be integrated into broader project meetings, ensuring safety remains a specific agenda item. Larger or more complex projects may require dedicated PSC meetings with support from Working Groups to assess hazards or system integrity.
Working Level Support
Depending on the complexity of the project, one or more working groups may be established that support the PSC by assessing hazards or reviewing the integrity of specific systems. Integrity working groups could consider structure, propulsion or other electrical or mechanical systems, reporting significant issues to the PSC.
Role of the Safety Management Committee (SMC)
For large-scale projects or portfolios, a Safety Management Committee (SMC) may be established to manage multiple PSCs across similar systems. This ensures consistency in safety management policy and strategy across projects. The SMC will oversee the activities of individual PSCs, ensuring adherence to safety management plans (SMPs).
Figure 2.1 shows an example of a Safety Committee structure, together with the management documents that sit at the relevant committee level.
Figure 2.1 – Safety Committee Structure
Safety Committee Structure
Figure 2.1 represents an example of a Safety Committee structure, with supporting working groups and hazard reviews in place. Teams can modify the structure of the Safety Committees to suit the specific organization of the program. The emphasis should be on establishing a Safety Committee with suitable chairmanship and Terms of Reference.
The structure shown in Figure 2.1 would be suitable for a large Program managing several important projects. However, it is probably overkill for most projects. With committees, less is sometimes more.
Top Tip
Project Safety Committee Authority and Competence
The chairman of the PSC should hold a Letter of Delegation detailing the authority for carrying out the safety management tasks on that program.
The PSC exists to provide information and specialist advice to those who have specific responsibility for safety management on an acquisition project so that they can reach informed decisions. The Project safety delegation holder should seek and consider relevant advice through the PSC but remain the decision-maker.
While not all members of the PSC need to have specific competence and experience in Safety Management, some committee members must have this competence and are consulted. In addition to the safety delegation holder, whose competence must be established before their delegation being issued, other members of the PSC who must be safety competent would typically include the Project Safety Manager and the Independent Safety Auditor (if appointed).
As a minimum, the Project Safety Manager should have system safety competence at the practitioner level. Competence requirements for the safety delegation holder will be defined in a relevant Assignment Specification.
The level of competence needed is driven by many factors – size, complexity, novelty – and this will be discussed under a post on ‘Proportionality’ (TBD).
Top Tip
Where beneficial, combine committees for safety and environmental management activities. Align programs as far as possible and share data where relevant.
Where there are separate safety and environmental committees, these could meet consecutively over the morning and afternoon. Members and specialists should attend as appropriate to each.
The PSC covers groups of similar projects within a Delivery Team where common activities are required. Separate committees are better for very large, high risk or diverse projects within a Delivery Team.
The PSC meets regularly as a body, or its work is included as a permanent item in another forum (in this instance care should be taken that all relevant parties are included), or simply through written communications. This last option is less desirable because there is no opportunity for direct interaction.
Record-Keeping and Documentation
Accurate record-keeping is vital to ensure transparency, accountability, and auditability. PSC meeting minutes should document:
Attendees
Key discussions
Advice and recommendations
Decisions made
Agreed actions
These records often feed into larger project documentation, such as the System Requirements Document, Through Life Management Plan, and Safety Management System (SMS).
Review and Agreement of Safety Documents
A key PSC function is reviewing safety documents and advising the safety delegation holder on their suitability. Agreement can be recorded formally via document sign-offs or recommendations in PSC minutes. This process ensures that all safety documentation, including the Safety Case, meets the required standards before formal approval and implementation.
Risks and Pitfalls
Failure to establish or effectively run a PSC can lead to significant risks for a project, including:
Incomplete stakeholder engagement, leading to safety requirements not being adequately defined.
Inappropriate safety activities, if the PSC does not review and approve the SMP.
Infrequent meetings, potentially delaying issue identification, risking project time and cost.
Lack of clear authority, causing confusion between Enterprise and contractor responsibilities, which could shift accountability from the designers to the PSC.
By mitigating these risks through clear terms of reference, structured meetings, and well-defined roles, the PSC can ensure project safety management remains robust and reliable.
Beware of the PSC delving into detail and doing what is expedient, rather than was is needed. Set appropriate TORs and agendas and stick to them.
Tip Top
If the PSC does not meet with sufficient frequency, then they may not identify in a timely manner, any issues with the safety program. This could result in impacts on project time and cost.
If the PSC attempts to control the detailed design solutions, rather than relying on the contractor’s Safety Committee and design function, then Enterprise will take responsibility from the designer. Enterprise staff will be represented on the contractor’s Safety Committee and shall exercise influence at that forum and through setting appropriate requirements.
Project Safety Committee: Timing
Formation
Establish the PSC during the Concept phase of a project by the Customer, or Requirements Manager, through the Capability Working Group, in conjunction with the relevant Project Director, to set out the safety requirements for the equipment.
The PSC has an important role to play in influencing safety requirements. This is not mentioned in ‘PSC: Required Outputs’, below, but is possibly the PSC’s most important contribution.
Top Tip
Meetings
The required frequency of the PSC meetings depends on various factors including the stage of the project, the complexity of the system, and whether the PSC is supported by Working Groups or has complete responsibility. Hold meetings at greater frequency during periods of significant review and decision-making, typically when project milestones are approaching.
PSC meetings may occur less frequently during periods of stability, such as during the in-service phase, when fewer safety decisions are necessary. However, the PSC still has an important duty to provide oversight of the Safety Case and ensure that it remains valid and monitoring safety performance. Consider whether the system or its usage is changing and seeking counter-evidence that shows the predicted level of safety performance is not being achieved in practice.
Project Safety Committee: Required Inputs
The procedure may use the following reference inputs, as available:
Other Safety Audit Plans (e.g. self or Peer audit);
Safety Audit Report;
Hazard Log Report;
Safety Requirements;
Safety Assessment Report;
Safety Case Report.
Acquisition System Guidance Functional Competencies for System Safety Management;
Records of previous meetings of the Safety Committee.
Project Safety Committee: Required Outputs
The outputs of the procedure will comprise:
Established Safety Committee membership;
Defined Terms of Reference for the Safety Committee (see Further Guidance – Examples Terms of Reference for Project Safety Committee);
Records of Safety Committee meetings, including advice given and the actions, agreed;
The advice given by members of the Safety Committee should include recommendations on whether a reviewed document (e.g. Safety Management Plan or Safety Case Report) should be authorized by the Project Director. If authorization is not recommended, then the reasons should be recorded.
Conclusion
The establishment and management of a Project Safety Committee (PSC) are critical to the safe delivery of defense and engineering projects. Through clear objectives, expert membership, and rigorous oversight, the PSC ensures that safety remains at the forefront of project decision-making, thereby protecting both people and assets.
By following this comprehensive guide, organizations can structure their PSCs effectively, aligning with safety standards and regulatory requirements. The PSC is not just a procedural necessity; it is a cornerstone of responsible project management in safety-critical environments.
Annex A
Example Terms of Reference for Project Safety Committee
Terms of Reference for – Project XXXX
Purpose:
To provide a forum for monitoring and coordinating all safety management and risk reduction activities associated with the project to ensure effective levels of safety and provide an appraisal of the Safety Case. The Project Safety Committee reports to the Project Director or in a larger Delivery Team to the Safety Management Committee.
Tasks:
Set and keep under review the project’s safety policy and strategy;
Set and keep under review the project’s safety targets and objectives;
Define the system boundaries for safety responsibility;
Advise the Chairperson of the Safety Committee on the safety responsibilities of each authority associated with the project;
Advise the Chairperson of the Safety Committee on the standards, statutory regulations, and any restrictions with which the projects should comply;
Review, monitor, classify and allocate new equipment hazards as they are identified;
Carry out reviews of the project’s Safety Case and progress on achieving safety targets, to a predetermined program, issuing the results to the Delegated Authority;
Agree on any control measures necessary to reduce identified risks to ALARP;
Ensure proper and timely availability of training and issue of documentation;
Carry out actions from ISA, regulatory or internal audit findings;
Operate a system for reviewing and monitoring safety performance and maintain the Safety Case.
Membership:
Delivery Team responsible for the procurement aspects of the project;
Customer representative (Capability or Equipment Customer);
Safety Officer (if appointed);
Design organization;
Delivery Team responsible for the support aspects of the project;
Equipment User;
Training Authority;
Maintainer;
Maintenance Authority;
Specialist Advisors (as required):
Defense Safety Regulators;
Defense Ordnance Safety Group;
Land Accident Prevention and Investigation Team;
Military Aviation Accident Investigation Team;
Serious Equipment Failure Investigation Team;
Independent Safety Auditor;
Interfacing Delivery Teams;
Technical Specialists.
Acknowledgment of Copyright
In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.
Project Safety Committee: Who Would You Include?
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.
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 the ultimate acceptance of the project.
We will look at the RACI chart of stakeholders under a later SMP.
Top Tip
Project Safety Initiation: Objectives
This procedure describes the start-up of safety management activities on a project. It identifies safety stakeholders and legislative and other standards that need to be satisfied. The procedure also creates the key elements of the safety management organization for the project.
In normal circumstances, this procedure would be applied at the outset of a project, early in the Concept phase. However, it can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process on an existing system. The procedure may also be re-applied at significant points in the life cycle (e.g. after Full Business Case approval), to review and update the project safety arrangements and ensure that they continue to be appropriate.
Remember that a Project delivers on a specific: a) Outcome, result or benefits, e.g. meeting requirements; b) Schedule; and c) Quality criteria, e.g. needed to realise benefits.
Top Tip
Comprehensive Guide to Safety Management Procedure Initiation
Safety management is critical to any project, especially those involving complex systems with safety and environmental implications. This procedure outlines the early-stage safety processes that should be followed, assuming that the Program Director has already been appointed and safety responsibilities have been delegated to a competent team member within the delivery team. The goal of safety initiation is to ensure that safety management starts on a firm basis, identifying crucial stakeholders, regulatory authorities, and internal teams responsible for safety and environmental protection.
In this article, we will provide an in-depth understanding of the safety initiation process, stakeholder identification, project safety organization creation, compliance considerations, and necessary documentation.
Purpose of Safety Initiation
The primary objective of safety initiation is to commence the safety management process by:
Identifying stakeholders, regulators, and approval authorities.
Appointing a Project Safety Manager (PSM) and, if required, an Independent Safety Auditor (ISA).
Forming the Project Safety Committee (PSC).
Ensuring compliance with safety and environmental regulations and creating a responsible, accountable, consulted, informed (RACI) chart.
This procedure helps mitigate risks to project timelines, cost, and overall safety by ensuring safety requirements are identified and met early in the project lifecycle.
All applicable factors need to be lined up to ensure the success of a safety project or program.
Top Tip
Project Safety Initiation: How It’s Done
1. Stakeholder Identification in Safety Initiation
The identification of stakeholders is crucial. Stakeholders include any individuals or groups impacted by the project’s development or operation, as well as those responsible for the project’s approval and compliance. This may include industry professionals, regulatory bodies, and environmental authorities. Here’s how to systematically identify and involve relevant stakeholders:
Who Are the Stakeholders?
A stakeholder is defined as anyone affected by the system or involved in its acceptance, including:
Individuals who are responsible for safety at any stage of the project.
Groups or individuals with safety information or requirements relevant to the project.
Subject Matter Experts (SMEs) with specialized knowledge critical to project safety.
Consulting Key Stakeholders
At a minimum, the following must be consulted:
Project Sponsor (e.g., Director of the End Users’ Business Unit).
Equipment Users who will be directly affected.
Director Technical responsible for the technical aspects of the project.
Safety & Environmental Protection Group tasked with compliance.
Other Delivery Teams involved with subsystems or associated projects.
After identifying stakeholders, record their involvement and details in Form SMP01/F/02 – Register of Stakeholder Requirements and Information. External stakeholders such as other government departments or industry experts should also be logged into the communication plan. For complex projects, develop a communication plan outlining stakeholder contact details, responsibilities, and relevant security considerations.
It may be helpful to rename the project communication plan the Project Stakeholder Management Plan – what do you need from stakeholders for your Project to succeed?
Top Tip
2. Ensuring Compliance with Safety Regulations
Compliance with safety and environmental regulations is a critical responsibility of the Delivery Team. The following methods ensure compliance across various safety aspects:
Key Compliance Strategies:
System Specifications: Delivery Teams develop specifications to meet user requirements, ensuring safety and environmental standards are incorporated.
Through Life Management Plan (TLMP): This plan outlines the long-term impact of safety and environmental legislation on equipment.
Enterprise Guidance: Use internal guidelines when creating contracts to include safety and environmental performance targets.
Sources for Regulatory and Legislative Information:
To maintain compliance with safety and environmental legislation, teams can access a wide range of resources, including:
Legislative registers held by the program teams.
Defense Regulator intranet pages.
Health & Safety Executive publications and other professional societies.
Suppliers, contractors, and consultants with expertise in safety and environmental law.
The Delivery Team must identify applicable legislation at the start of the project and continuously update a legislative register as part of the Safety Case.
For more information on this vital task, see the post on System Requirements Hazard Analysis here.
Top Tip
3. Creating a Project Safety Organization
Establishing a robust safety management structure is essential to ensure compliance with safety standards and regulations. The Safety Management Plan (SMP) will eventually document the project’s entire safety organization, but before that, some key safety roles need to be defined.
Steps to Set Up Project Safety Organization:
Develop a Project Safety RACI Chart: This chart defines who is Responsible, Accountable, Consulted, and Informed at different stages of the safety process.
Appoint a Competent Project Safety Manager (PSM): This individual is responsible for overseeing safety management throughout the project.
Appoint an Independent Safety Auditor (ISA): For complex or high-risk projects, appointing an ISA is advisable. The ISA ensures that safety audits are conducted independently.
Form a Project Safety Committee (PSC): This group will be responsible for monitoring and governing safety issues within the project.
3. Ensuring Compliance with Safety Regulations
Compliance with safety and environmental regulations is a critical responsibility of the Delivery Team. The following methods ensure compliance across various safety aspects:
Key Compliance Strategies:
System Specifications: Delivery Teams develop specifications to meet user requirements, ensuring safety and environmental standards are incorporated.
Through Life Management Plan (TLMP): This plan outlines the long-term impact of safety and environmental legislation on equipment.
Enterprise Guidance: Use internal guidelines when creating contracts to include safety and environmental performance targets.
Sources for Regulatory and Legislative Information:
To maintain compliance with safety and environmental legislation, teams can access a wide range of resources, including:
Legislative registers held by the program teams.
Defense Regulator intranet pages.
Health & Safety Executive publications and other professional societies.
Suppliers, contractors, and consultants with expertise in safety and environmental law.
The Delivery Team must identify applicable legislation at the start of the project and continuously update a legislative register as part of the Safety Case.
4. Safety Documentation and Records
Documenting safety processes ensures accountability and maintains a clear safety management trail. These records feed into critical project documentation, including:
System Specification: Defines specific safety requirements.
Customer-Supplier Agreement: Documents agreements on safety information.
Through Life Management Plan (TLMP): Outlines the ongoing safety and environmental impact.
Safety Elements in Business Case Submissions: Ensures all safety-related information is considered in formal project submissions.
Proper documentation supports future audits, stakeholder engagement, and compliance efforts. Competent to perform the required responsibilities.
5. Importance of Competence in Safety Management
Competence in safety management is key to project success. The competence of the PSM and ISA must be demonstrated and documented to assure that they can effectively discharge their safety responsibilities.
Consequences of Incompetence or Delays:
Failure to appoint competent individuals or delay the initiation of safety management procedures can lead to:
Increased risk to project timelines and costs.
Delayed engagement with stakeholders.
Overlooked safety and environmental requirements.
Conclusion: Importance of Early Safety Management Initiation
Initiating a structured safety management process at the early stages of a project is crucial for ensuring compliance with safety and environmental standards. By identifying stakeholders, setting up a robust safety organization, ensuring compliance, and maintaining accurate documentation, the project minimizes risks, avoids delays, and maintains clear communication with all involved parties.
Project Safety Initiation: Timing
Initial Application
In an acquisition program, the procedure should be carried out early in the Concept phase. Stakeholders, system boundaries, supporting systems/arrangements, and acceptance authorities need to be identified as early as possible to support the subsequent Preliminary Hazard Identification activity (Procedure SMP04 – Preliminary Hazard Identification) and the preparation of the SMP.
The procedure can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process.
Review
The registers of stakeholders and requirements should be reviewed and updated after the Outline Business Case and Full Business Case as part of the review and update of the SMP.
New Safety Managers could also use this as a take-over checklist, to make sure all necessary decisions have been made and clearly documented.
Top Tip
Acknowledgment of Copyright
In this article, I have used some material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.
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.
More Resources for Risk Assessment Programs Course
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
Describe fundamental risk concepts;
Explain what a system safety approach is and does;
Define what a risk analysis program is;
List the hazard analysis tasks that make up a program;
Select tasks to meet your needs;
Design a tailored risk analysis program for any application; and
Know how to get more information and resources.
More Resources for Risk Assessment: Transcript
Copyright/Source Statement
“First, I want to point out that I’ve been referring to a standard; Military Standard 882E, a copyright-free publication. It’s a US standard and is available to download for free at many different locations. One of them is the US Defence Acquisition University. As far as I can tell, this is the official home of it now. You can search for ‘DAU’ or ‘Defence Acquisition University’ [to find it]. And when you go there, this is a search function, which is very good. You’ll find 882E very easily. But here’s the link for reference now.
So that is copyright-free. This presentation, of course, is copyright The Safety Artisan of this year (2021). But it’s also worth saying that there’s a lot more out there. There’s more help you can get than the standard by itself. The Defence Acquisition University for some reason doesn’t seem to publish much on 882E, either in the way of guidance or help on how to use this standard.
For More…
If you want more information, please feel free to go to The Safety Artisan channel on YouTube; subscribe to the channel and click on the bell symbol to get informed whenever a new video comes out. There are lots of free videos on The Safety Artisan channel. And also short free demo versions of the paid videos. So, if you want to look at a video to see whether you think it’s worth buying, there will be a free version on there. Either a two-minute thing with subtitles or, for a lot of the lessons, there’s a full seven minutes. It’s the first seven minutes of the lesson. So you can get a flavor of what’s there.
And then for more videos and resources, you can visit this site, www.safetyartisan.com. That’s got all the information there. It’s a secure site. Here you can sign up for regular emails from The Safety Artisan. And that will get you a free Course Triple Bundle. Please feel free to help yourself and look at the free goodies!
Mil-Std-882E Analysis Tasks
But also, there are ‘paid lessons’ on each one of the 10 [Mil-Std-882E] Tasks. Lessons on average are about – most of the lessons are about forty-five minutes. Some are a little bit shorter at thirty-five minutes. And the Environmental one is an hour. As is, the Health Hazard Analysis one. That’s because those are very complex tasks. So they vary from about 35 to 60 minutes in length each.
What and Why?
And for each of those old video training sessions, you will get some in-depth training on each task. Your training video will include a full description of the task, plus a commentary that I provide. You will get a full written transcript of the video as well. And if you go there, the page will tell you the benefits of each task. What it’s designed to do and how to apply it. Its pros and cons. And my expert tips from long and sometimes bitter experience on how to get the most out of these tasks. Also, pitfalls to avoid.
In Conclusion – Learning Objectives
Let’s recap, for this entire course, the five modules. You should now be able to describe your fundamental research concepts from Module One. From Module Two, you should be able to explain what a system safety approach is and does. You should be able to define what a risk analysis program is. You should be able to list the Hazard Analysis Tasks that make up a Safety Program. Or a Risk Analysis Program.
Critically, you should be able to select which tasks you need to meet your needs. And by doing that repeatedly, you should then be able to design a tailored Risk Analysis Program. And you should be able to do this for pretty much any application. And in the final module, you will have learned how to get more information. And where to find more in-depth resources on each of those 10 tasks. That’s in case you should need to go to the next level.
So, that’s what we’ve covered in this session.
End
And it just remains for me to say thanks very much for buying this [course] video and supporting the work of The Safety Artisan. I’m Simon and I would like to say a personal thanks very much to you. Goodbye and hope to see you again soon.”
This is Module 5 of SSRAP
This is Module 5 from the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application.
The full course comprises 15 lessons and 1.5 hours of video content, plus resources. It’s on sale now, so check out all the free preview videos here!
Meet the Author
Learn safety engineering with me, an industry professional with 25 years of experience, I have:
•Worked on aircraft, ships, submarines, ATMS, trains, and software;
•Tiny programs to some of the biggest (Eurofighter, Future Submarine);
•In the UK and Australia, on US and European programs;
•Taught safety to hundreds of people in the classroom, and thousands online;
•Presented on safety topics at several international conferences.
The Ten Viewpoints of Mil-Std-882E Hazard Analyses
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 that you are analyzing.
Which Ingredients should we use?
Everything – high novelty, challenging requirements, bespoke development and massive scrutiny);
The Bare Essentials;
New Designs and Integrations;
The Human Element;
Electronics, Software and Data;
Combining existing Systems; and
Environmental Protection.
Video Highlights
Designing Your Safety Program – Highlights (SSRAP M4)
Topics
Designing Your Risk Assessment Program: Transcript
We’re onto Module Four – Designing Your Program.
This module aims to show you how to design a systematic, effective strategy for Risk Analysis. An effective program for Risk Analysis that isn’t wasteful. This module is a little bit longer than the others but bear with me! This is the real meat of what I promised you. So, let’s get started.
Multiple Points of View
As I said in a previous slide, we will deal with multiple points of view. We will use multiple points of view to look at the system from many different angles.
Ten different angles, in this case, one for each task. Each of those tasks brings a different perspective. So, each task has a different purpose. What they have in common is they are all there to bring out a different aspect of the system. They are different kinds of analysis, but they all have the same aim. To identify hazards and analyze hazards.
From that, we can then identify what we need to do to control those hazards. And that, in turn, gives us safety requirements. Sometimes they’re called ‘derived safety requirements’. They need to be met for the system to be safe. That’s the whole point of what we’re doing, as mentioned before.
Which Ingredients?
But if you’ve got everything then you only need all those 10 tasks if everything is in the red. Perhaps you’ve got a very novel system. You’ve got challenging performance requirements. You’ve got lots of bespoke development. And you’ve got a very critical system that’s going to get a lot of scrutiny. So, you need all 10 only if you’ve got a development from hell. Where you’ve got a very challenging development and you need all the tools you can get.
Now, that’s fine. That’s what the standard’s designed for. But very rarely are we going to work on a program where we’re pulling out all the stops. More often, we’re going to be working on something where there are some challenging areas and some less so. And we don’t need the entire program. We don’t need all 10 tasks to achieve success. And it’s OK to tailor your safety analysis to deliver value for money. In fact, this approach is better.
So, we’ve got some options here. I’m going to take you through the bare essentials. Those are what you need to do for every safety program. The work that we would do to address new designs and new integrations. Work that we would do to address the human element. This includes both parts of human factors. That’s the human contribution to safety and the impact that the system might have on human health. So, there’s a bit of back and forth in there in the two tasks there.
Then if our system has got programmable electronic software, we might need to look at that. Or if it has data that is being developed or modified, we need to look at that too. We need to assess the safety implications of the modifications/development. We might consider combining existing systems into a system of systems. And then finally, we might have to do environmental protection. So, the bare essentials plus those five optional elements are the ones that we will look at.
The Essentials #1
Let’s start with the essentials. I’m going to say it’s axiomatic – that every program needs these three tasks. It needs Preliminary Hazard Identification. It needs Preliminary Hazard Analysis. And it needs System Requirements Hazard Analysis. The last one is about identifying safety requirements for the system.
Now, that’s a very bold statement, is it for me to say you must have these elements in every safety program? Let me justify that, first of all, before I explain it a little bit in the next slide.
The first thing to note is that you can do these tasks early on. They are quick and cheap tasks if you do them early enough. If you do them early enough, it’s low granularity. So, it can be a quick and simple analysis. And because of that, it’s cheap. But don’t let that fool you! Getting in early and thinking about Risk early gives us valuable insight. Insight that we can then take action on. So we get actionable results early enough in the program to do something about it if we do it.
The second point to note with these three is that every other task depends on their outputs. Indeed, if you’re going to successfully tailor a safety program, you need the output from these tasks. They will help you focus on what’s important and what’s less important.
Thirdly, from experience, almost every program suffers from not doing these three tasks. Whether that be well enough, early enough, or both. I’ve never been on a program where we said, ‘We did too much Preliminary Hazard Identification Analysis!’. Nor ‘We did too much identification of safety requirements!’. That has never, ever happened in more than 20 years of experience working on safety programs.
It’s always been the opposite. We wish we’d done more. We wish we’d gone in earlier with these tasks. Then we would have known something that would have helped us to make sensible decisions. Ultimately, it would have saved a lot of time and money too! Think of these essentials as an investment, because that’s what they are…
This is Module 4 of SSRAP
This is Module 4 of the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application.
The full course comprises 15 lessons and 1.5 hours of video content, plus resources. It’s on pre-sale at HALF PRICE until September 1st, 2024. Check out all the free preview videos hereand order using the coupon “Pre-order-Half-Price-SSRAP”. But don’t leave it too long because there are only 100 half-price courses available!
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.
The Ten Viewpoints of Mil-Std-882E Hazard Analyses
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 ‘Are we doing the right thing?’ And ‘Are we doing it right?’
So, what will we do and why are we doing it? First, the use of safety standards is very common for many 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’.
We can also use it to help us achieve a compromise. That can be a compromise across different stakeholders or different organizations. 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 an 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 it’s 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.
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, and why it came into existence. And who brought it into existence. To do what for who – who’s the ultimate customer here?
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. This standard was first developed several decades ago. It 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 pushes the limits of what you can achieve in performance.
That’s a lot of complexity. Lots of critical weapon systems, and so forth. So 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 in 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 of 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…
This is Module 3 of SSRAP
‘Understanding Your Risk Assessment Standard’ is Module 3 of the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application.
The full course comprises 15 lessons and 1.5 hours of video content, plus resources. It’s on pre-sale at HALF PRICE until September 1st, 2024. Check out all the free preview videos hereand order using the coupon “Pre-order-Half-Price-SSRAP”. But don’t leave it too long because there are only 100 half-price courses available!
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.
