In Crafting a Safety Case and Safety Case Report – Part 2, we move on to review and sign off on the artifacts.
Introduction In any high-stakes environment—whether it’s defense, engineering, or aviation—Safety Case Reports play an essential role in validating the safety of a system. A meticulous review and sign-off process ensures that these reports meet every necessary standard before they are officially issued. Let’s dive into the distinct types of approvals in the Safety Case Report review process, what they signify, and how they work together to ensure comprehensive safety oversight.
Understanding Review and Sign-Off Terminology
When dealing with complex Safety Case Reports, different stages of review carry unique responsibilities. Below are the key terms that guide the process of approving a Safety Case Report:
Agreeing on a 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.
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.
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.
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.
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:
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).
Safe Execution of Activities For systems undergoing testing or trials, the Safety Case ensures these activities can proceed without jeopardizing safety.
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.
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.
Incorporating Contractor and MOD Data The Safety Case combines all safety assessments and risk management activities, ensuring comprehensive and traceable safety information.
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.
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:
Role Assignments Designate a responsible individual to oversee the safety documentation process.
Approval Protocols Define both internal and external approval workflows to streamline safety documentation reviews.
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.
System Development and Trials The Safety Case Report must evolve during development and trials, reflecting any updates to design or safety features.
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.
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:
Clear Communication of Caveats Define the limitations and inform all relevant stakeholders, ensuring they understand any usage restrictions.
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.
In-Service Safety Management System: Ensuring Long-Term Safety for Military Equipment
Safety is paramount when it comes to military operations, especially for in-service equipment relied upon by personnel daily. This article delves into the intricacies of maintaining an In-Service Safety Management System, offering insight into how safety practices are implemented, monitored, and evolved over time.
Introduction: Why In-Service Safety Matters
When military equipment enters service, the journey of ensuring its safe use doesn’t end there. An effective In-Service Safety Management System (SMS) oversees all safety-related aspects of equipment throughout its operational life. From day-to-day safety practices to long-term risk management, the SMS is vital for sustained safety performance. It also provides a roadmap for identifying, documenting, and addressing safety requirements as equipment evolves over time.
Key Definitions
A Safety Management System, according to Def Stan 00-056, is defined as:
“The organisational structure, processes, procedures, and methodologies that enable the direction and control of the activities necessary to meet safety requirements and safety policy objectives.”
This structure ensures every team member understands the standards and processes needed to maintain operational safety.
Objectives: What an In-Service SMS Aims to Achieve
The primary objectives of an in-service SMS are twofold:
To recognize and uphold the safety requirements essential for equipment performance.
To continuously document these processes, forming an auditable Safety Case to maintain accountability.
An effective SMS aligns with various support areas, referred to as “Lines of Development.” These encompass personnel, training, sustainability, infrastructure, and facilities, ensuring that each line functions in sync for safe operations from the equipment’s inception to its eventual decommissioning.
The SMS also involves continuous Risk Management, adjusting to changes such as equipment enhancements or new usage contexts. This proactive monitoring ensures that safety assurance is consistently updated and accurate.
Procedure for Sustaining Safety Performance
The SMS structure is implemented through the following methods:
Safety 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.
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.
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.
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.
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.
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:
This procedure should draw on information in the following documents, and it should also define changes that should be made to their content:
Through-Life Management Plan;
Integrated Test, Evaluation and Acceptance Plan;
Project Safety Management Plan including RACI (Responsible, Accountable, Consulted, Informed) chart;
Safety Management System Manuals of stakeholders (e.g. Delivery Teams, Delivery Teams providing sub-systems, Users, authorities responsible for safe storage, transportation, disposal, inspection, audit, incident investigation etc.);
Customer/Supplier Agreements (or similar) defining interfaces and responsibilities for certain Safety Management activities.
Required Outputs
Safety Management System Documentation
The In-Service Safety Management System arrangements should be recorded in various places because of the many authorities involved. For instance, the Safety Management System manuals of different Delivery Teams, user authorities, contractors and support authorities should contain relevant information as well as other documents recording arrangements for Incident and Accident reporting and investigation.
The principal means of bringing together this information should be through the Safety Management Plan and its RACI chart, defining the involvement of the different authorities.
The Project Safety Case should contain a description of the In-Service Safety Management System in operation to ensure that the safety performance of the equipment is achieved and sustained through life.
Meet the Author
Learn safety engineering with me, an industry professional with 25 years of experience, I have:
•Worked on aircraft, ships, submarines, ATMS, trains, and software;
•Tiny programs to some of the biggest (Eurofighter, Future Submarine);
•In the UK and Australia, on US and European programs;
•Taught safety to hundreds of people in the classroom, and thousands online;
•Presented on safety topics at several international conferences.
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.
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!
Video Introduction
Introduction from the Beginning – the Key Things Haven’t Changed!
Introduction to the Safety Artisan
Hi everyone, and welcome to the safety artisan, a series of instructional videos on safety. I’m Simon and I’m a safety engineer and consultant with over 20 years of experience (now 25+) working in systems safety, safety engineering, safety in design and a whole bunch of related disciplines including software safety. I’ve got a lot of background in this area, and I hope that you’ll be able to support this enterprise. The tagline for the business is professional pragmatic and impartial. But what does that really mean? Well, in my time as a safety engineer and consultant, I’ve worked with lots of clients…
… doing many different things:
Aerospace, air traffic management, software, ships and submarines, other transport systems, etc. I often find that clients are making two kinds of mistake. They’re either not doing enough work to meet their obligations, or they’re doing too much work. The first one is perhaps obvious, as safety standards and safety legislation are very demanding. People aren’t always aware of what their obligations are, and therefore they’re not always meeting them. But when you’re a consultant and, it must be said, demanding a lot of money from clients to do this work, I think the suspicion is sometimes that the consultant is just asking to do more work to get more money.
Now, that’s not actually what ethical consultants do, but I’m sure not everyone believes that. So, here, I hope to get away from that paradigm, and we can actually share information just because it’s factual. Accepting what I say doesn’t mean that I’ll take any more money off you and you can check out what you see and decide whether you like it. The other issue is perhaps less obvious: people do too much work. But the reality is there are people all over the place doing safety work that just doesn’t make a difference – i.e. it doesn’t demonstrate that you’ve met requirements or that risk is managed.
And that’s also a difficult sell…
…because questioning what the tribe is doing, questioning the culture of the organization is difficult and frankly risky for individuals. So they don’t want to do it. So again, here in the privacy of a video, it’s just you and me. I can tell you stuff, you can give me feedback on the website or at Patreon.com. You can ask questions and hopefully we can get to a better understanding of the facts, without worrying about sums of money changing hands or convincing your peers that change is necessary.
So I hope you find this helpful and I hope you’re able to support me… [I’m not on Patreon anymore!] … You can always look me up on LinkedIn and check out my experience and qualifications. Thanks very much for listening and I look forward to talking to you again.
Remember: Members Get a Free Intro Course, 50% Off & Updates!
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.
Our website uses cookies to provide you with the best experience. By continuing to use our website, you agree to our use of cookies. For more information, read our Privacy Policy on the "About" Page.
