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.
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, etc., for a long, long time. I hope that I can put my experience to good use, helping you in whatever you want to do with this information.
Maybe you’re getting an interview. Maybe you want to learn some basics and decide whether you want to know more about risk management or not. Whatever it might be, I think you’ll find this short session really useful. I hope you enjoy it and thanks for watching.
Welcome to Risk Management 101, where we’re going to…
Hi everyone and welcome to Risk Management 101. We’re going to go through these basic concepts of risk management. We’re going to break it down into the constituent parts. Then we’re going to build it up again and show you how it’s done.
My name is Simon Di Nucci and I have a lot of experience working in risk management, project risk management, safety risk management, etc. I’m hoping that I can put my experience to good use, helping you in whatever you want to do with this information. Whether you’re going for an interview or you want to learn some basics. You can watch this video and decide if you want to know more about risk management or if you don’t need to. Whatever it might be, you’ll find this short session useful. I hope you enjoy it and thanks for watching.
Topics For This Session
Risk Management 101. So what does it all mean? We’re going to break risk management down into we’ve got six constituent parts. I’m using a particular standard that breaks it down this way. Other standards will do this in different ways. We’ll talk about that later. Here we’ve got risk management broken down into; hazard identification, hazard analysis, risk estimation, risk evaluation (and ALARP), risk reduction, and risk acceptance.
Risk Management
Let’s get right on to that. Risk management – what is it? It’s defined as “the systematic application of management policies, procedures, and practices to the tasks of hazard identification, hazard analysis, risk estimation, risk and ALARP evaluation, risk reduction, and risk acceptance”.
There are a couple of things to note here. We’re talking about management policies, procedures, and practices. The ‘how’ we do it. Whether it’s a high-level policy or low-level common practice. E.g. how things are done in our organization vs how the day-to-day tasks are done? And it’s also worth saying that when we talk about ‘hazards’, that’s a safety ‘ism’. If we were doing security risk management, we could be talking about ‘threats’. We can also be talking about ‘causes’ in day-to-day language. So, we can be talking about something causing a risk or leading to a risk. More on that later, but that’s an overview of what risk management is.
Part 1
Let’s look at it in a different way. For those of you who like a visual representation, here is a graph of the hierarchical breakdown. They need to happen in order, more or less, left to right. And as you can see, there’s a link between risk evaluation and risk reduction. We’ll come on to that. So, it’s not ‘or’ it’s a serial ‘this is what you have to do’. Sometimes they’re linked together more intimately.
Hazard Identification
First of all, hazard identification. So, this is the process where we identify and list hazards and accidents associated with the system. You may notice that some words here are in bold. Where a word is in bold, we are going to give the definition of what it is later.
These hazards could lead to an accident but are only associated with the system. That’s the scope. If we were talking about a system that was an airplane, a ship, or a computer, we would have a very different scope. There would also be a different way that maybe accidents would happen.
On a more practical level, how do we do hazard identification? I’m not going to go into any depth here, but there are certain classic ones. We can consult with our workers and inspect the workplace where they’re operating. In some countries, that’s a legal requirement (Including in Australia where I live). Another option is looking at historical data. And indeed, in some countries and in some industries, that’s a requirement. A requirement means we have to do that. And we can use special analysis techniques. Now, I’m not going to talk about any of those analysis techniques today. You can watch some other sessions on The Safety Artisan to see that.
Hazard Analysis
Having done hazard identification, we’ve asked ourselves ‘What could go wrong?’. We can put some more detail on and ask, ‘How could it go wrong? And how often?’. That kind of stuff. So, we want to go into more detail about the hazards and accidents associated with this particular system. And that will help us to define some accident sequences. We can start with something that creates a hazard and then the hazard may lead to an accident. And that’s what we’re talking about. Later, we will show that using graphics can be helpful.
But again, more on terminology. In different industries, we call it different things. We tend to say ‘accident’ in the UK and Australia. In the U.S., they might call it a ‘mishap’, which is trying to get away from the idea that something was accidental. Nobody meant it to happen. Mishap is a more generic term that avoids that implication. We also talk about ‘losses’ or we talk about ‘breaches’ in the security world. We have some issues where somebody has been able to get in somewhere that they should not. And we can talk about accident sequences. Or, in a more common language, we call it a sequence of events. That’s all it is.
Risk Estimation
Now we’re talking about the risk estimation. We’ve thought about our hazards and accidents and how they might progress from one to another. Let’s think about, ‘How big is the risk of this actually happening?’. Again, we’ll unpack this further later at the next level. But for now, we’re going to talk about the systematic use of available information. Systematic- so, ordered. We’re following a process. This isn’t somebody on their own taking a subjective view ‘Look, I think it’s not that’. It’s a process that is repeatable. We want to do something systematic. It’s thorough, it’s repeatable, and so it’s defendable. We can justify the conclusions that we’ve come to because we’ve done it with some rigour. We’ve done it in a systematic way. That’s important. Particularly if we’re talking about harm coming to people or big losses.
Risk and ALARP / SFARP Evaluation
Now, risk evaluation is just taking that estimated risk just now and comparing it to something and saying, “How serious is this risk?”. Is it something that is very low? If it’s very insignificant then we’re not bothered about it. We can live with it. We can accept it. Or is it bigger than that? Do we need to do something more about it? Again, we want to be systematic. We want to determine whether risk reduction is necessary. Is this acceptable as it is or is it too high and we need to reduce it? That’s the core of risk evaluation.
Tolerability
In this UK-based standard – we’re using terminology is found in different forms around the world. But in the UK, they talk about ‘tolerability’. We’re talking about the absolute level of risk. There probably is an upper limit that’s allowed in the law or in our industry. And there’s a lower limit that we’re aiming for. In an ideal world, we’d like all our risks to be low-level risks. That would be terrific.
So, that’s ‘tolerability’. And you might hear it called different things. And then within the UK system, there are three classes of ‘tolerability’ at risk. We could say it’s either ‘broadly acceptable’- it’s very low. It’s down in the target region where we like to get all our risks. It’s ‘tolerable’- we can expose people to this risk or we can live with this risk, but only if we’ve met certain other criteria. And then there’s the risk that it’s so big. It’s so far up there, that we can’t do that. We can’t have that under any circumstances. It’s unacceptable. You can imagine a traffic light system where we have categorized our risk.
ALARP / SFARP
And then there’s the test of whether our risk can be accepted in the UK. It’s called ALARP. We reduce the risk As Low As Reasonably Practicable. And in other places, you’ll see SFARP. We’ve eliminated or minimized the risk So Far As Is Reasonably Practicable. In the nuclear industry, they talk about ALARA: As Low As Reasonably Achievable. And then different laws use different tests. Whichever one you use, there’s a test that we have to say, “Can we accept the risk?” “Have we done enough risk reduction?”. And whatever you’ve put in those square brackets, that’s the test that you’re using. And that will vary from jurisdiction to jurisdiction. The basic concept of risk evaluation is estimating the level of risk. Then compare it to some standard or some regulation. Whatever it might be, that’s what we do. That’s risk evaluation.
Risk Reduction
We’ve asked, “Do we need to reduce risk further?”. And if we do, we need to do some risk reduction. Again, we’re being systematic. This is not some subjective thing where we go “I have done some stuff, it’ll be alright. That’s enough.”. We’re being a bit more rigorous than that. We’ve got a systematic process for reducing risk. And in many parts of the world, we’re directed to do things in a certain way.
Elimination
This is an illustration from an Australian regulation. In this regulation, we’re aiming to eliminate risk. We want to start with the most effective risk reduction measures. Elimination is “We’ve reduced the risk to zero”. That would be lovely if we could do that but we can’t always do that.
Substitution
What’s the next level? We could get rid of this risk by substituting something less risky. Imagine we’ve got a combustion engine powering something. The combustion engine needs flammable fuel and it produces toxic fumes. It could release carbon monoxide and CO2 and other things that we don’t want. We ask, “Can we get rid of that?”. Could we have an electric motor and have a battery instead? That might be a lot safer than the combustion engine. That is a substitution. There are still risks with electricity. But by doing this we’ve substituted something risky for something less risky.
Isolation
Or we could isolate the hazard. Let’s use the combustion engine as an example again. We can say, “I’ll put that in the fuel and the exhaust somewhere, a long way from people”. Then it’ll be a long way from where it can do harm or cause a loss.” And that’s another way of dealing with it.
Engineering Controls
Or we could say, “I’m going to reduce the risks through engineering controls”. We could put in something engineered. For example, we can put in a smoke detector. A very simple, therefore highly reliable, device. It’s certainly more reliable than a human. You can install one that can detect some noxious gases. It’s also good if it’s a carbon monoxide detector. Humans cannot detect carbon monoxide at all. (Except if you’ve got carbon monoxide poisoning, you’ll know about it. Carbon monoxide poisoning gives you terrible headaches and other symptoms.) But of course, that’s not a good way to detect that you’re breathing in poisonous gas. We do not want to do it that way.
So, we can have an engineering control to protect people. Or we can use an interlock. We can isolate things in a building or behind a wall or whatever. And if somebody opens the door, then that forces the thing to cut out so it’s no longer dangerous. There are different things for engineering controls that we can introduce. They do not rely on people. They work regardless of what any person does.
Administrative / Procedural Controls
Next on the list, we could reduce exposure to the hazard by using administrative controls. That’s giving somebody some rules to follow a procedure. “Do this. Don’t do that.” Now, that’s all good. We can give people warning signs and warn people not to approach something. But, of course, sometimes people break the rules for good reasons. Maybe they don’t understand. Or, maybe they don’t know the danger. Perhaps they’ve got to do something or maybe the procedure that we’ve given them doesn’t work very well. It’s too difficult to get the job done, so people cut corners. So, procedural protection can be weak. And a bit hit-and-miss sometimes.
Personal Protective Equipment
Finally, we can give people personal protective equipment. We can give them some eye protection. I’m wearing glasses because I’m short-sighted. But you can get some goggles to protect your eyes from damage. Damage like splashes, flying fragments, sparks, etc. We can have a hard hat so that if we’re on a building site and something drops from above on us that protects the old brain box.
It won’t stop the accident from happening, but it will help reduce the severity of the accident. That’s the least effective. We’re doing nothing to prevent the accident from happening. We’re reducing the severity in certain circumstances. For example, if you drop a ton of bricks on me, it doesn’t matter whether I’m wearing a hard hat or not. I’m still going to get crushed. But with one brick, I should be able to survive that if I’m wearing a hard hat.
Risk Acceptance
Let’s move on to risk acceptance. At some stage, if we have reduced the risk to a point where we can accept it. That is, we can live with it and we’ve decided that we’re going to need to do whatever it is that is exposing us to the risk. We need to use the system. For example, we want to get in our car to enable us to go from A to B quickly and independently. So, we’re going to accept the risk of driving in our car. We’ve decided we’re going to do that. We make risk-acceptance decisions every day, often without thinking about it. We get in a car every day on average and we don’t worry about the risk, but it’s always there. We’ve just decided to accept it.
But in this example, it’s not an individual deciding to do something on the spur of the moment. Nor is it based on personal experience. We’ve got a systematic process where a bunch of people come together. The relevant stakeholders agree that a risk has been assessed or has been estimated and has been evaluated. They agree that the risk reduction is good enough and that we will accept that risk. There’s a bit more to it than you and I saying “That’ll be alright.”
Part 2
Let’s summarise where we’ve got to. We’ve talked about these six components of risk management. That’s terrific. And as you can see, they all go together. Risk evaluation and risk reduction are more tightly coupled. That’s because when we do some risk reduction, we then re-evaluate the risk. We ask ‘Can we accept it?’. If the answer is ‘No.’ we need to do some more work. Then we do some more risk reduction. So those tend to be a bit more coupled together at the end. That’s the level we’ve got to. We’re now going to go to the next level.
So, we’re going to explain these things. We’ve talked about hazard identification and hazard analysis, but what is a hazard? And what is an accident? And what is an accident sequence? We’re going to unpack that a bit more. We’re going to take it to the next level. And throughout this, we’re talking about risk over and over again. Well, what is ‘risk’? We’re going to unpack that to the next level as well.
This is a safety standard. We’re talking about harm to people. How likely is that harm and how severe might it be? But it might be something else. It might be a loss or a security breach. Or a financial loss, a negative result for our project. We might find ourselves running late. Or we’re running over budget. We might be failing to meet quality requirements. Or we’re failing to deliver the full functionality that we said we would. Whatever it might be.
Hazard
So, let’s unpack this at the next level. A hazard is a term that we use, particularly in safety. As I say, we call it other things in different realms. But in the safety world, it’s a physical situation or it’s a state of a system.
As it says, it often follows from some initiating event that we may call a ‘cause’. The hazard may lead to an accident. However, the key thing to remember is once a hazard exists, an accident is possible, but it’s not certain. You can imagine the sort of cartoon banana skin on the pavement gag. Well, the banana skin is the hazard. In the cartoon, the cartoon character always steps on the banana skin. They always fall over the comic effect. But in the real world, nobody may tread on the banana skin and slip over. There could be nobody there to slip over all the banana skin. Or even if somebody does, they could catch themselves. Or they fall, but it’s on a soft surface and they don’t hurt themselves so there’s no harm.
So, the accident isn’t certain. And in fact, we can have what we call ‘non-accident’ outcomes. We can have harmless consequences. A hazard is an important midway step. I heard it called an accident waiting to happen, which is a helpful definition. An accident waiting to happen, but it doesn’t mean that the accident is inevitable.
Accident
But accidents can happen. Again, the ‘accident’, ‘mishap’, or ‘unintended event’. Something we did not want or a sequence of events that caused harm. And in this case, we’re talking about harm to people. And as I say, it might be a security breach. It might be a financial loss or reputational damage. Something might happen that is very embarrassing for an organization or an individual. Or again, we could have a hiccup with our project.
Harm
But in this case, we’re talking about harm. With this kind of standard, we’re using what you might call a body count approach to the harm. We’re talking about actual death, physical injury, or damage to the health of people.
This standard also considers the damage to property and the environment. Now, very often we are legally required to protect people and the environment from harm. Property less so. However, there will be financial implications of losses of property or damage to the systems. We don’t want that. But it’s not always criminally illegal to do that. Whereas usually, hurting people and damaging the environment is. So, this is ‘harm’. We do not want this thing to happen. We do not want this impact.
Safety is a much tougher business in this instance. If we have a problem with our project, it’s embarrassing but we could recover it. It’s more difficult to do that when we hurt somebody.
Risk
And always in these terms, we’re talking about ‘risk’. What is ‘risk’? Risk is a combination of two things. It’s a combination of the likelihood of harm or loss and the severity of that harm or loss. It’s those two things together. And we’ve got a very simple illustration here, a little table. And they’re often known as a risk matrix but don’t worry about that too much. Whatever you want to call it. We’ve got a little two by two table here and we’ve got likelihood in the white text and severity in the black.
Low Risk
We can imagine where there’s a risk where we have a low likelihood of a ‘low harm’ or a ‘low impact’ accident or outcome. We say, ‘That’s unlikely to happen, and even if it does not much is going to happen.’ It’s going to be a very small impact. So, we’d say that that’s a low risk.
Then at the other end of the spectrum, we can imagine something that has a high likelihood of happening. And that likelihood also has a high impact. Things that happen that we definitely do not want to happen. And we say, ‘That’s a high risk and that’s something that we are very, very concerned about.’
Medium Risk
And then in the middle, we could have a combination of an outcome that is quite likely, but it’s of low severity. Or it’s of high severity, but it’s unlikely to happen. And we say, ‘That’s a medium risk’.
Now, this is a very simplified matrix for teaching purposes only. In the real world, you will see matrices that are four by four, five by five, or even six by six, or combinations thereof. And in security where they talk about threat and vulnerability and the outcomes. Here, you might see multiple matrices used. They use multiple matrices to progressively build up a picture of the risk. They use matrices as building blocks. So, it may not be only one matrix used in a more complex thing you’ve got to model. But here we’ve got a nice, simple example. This illustrates what risk is. It’s a combination of severity and likelihood of harm or loss. And that’s what risk is, fundamentally. And if we have a firm grasp of these fundamentals, it’ll help us to reason and deal with almost anything. With enough application.
Accident Sequence
Now, let’s move on and talk about accident sequences. We’re talking about a progression in this case. We’re imagining a left-to-right path. A progression of events that results in an accident. This diagram, which looks like a bow tie, is meant to represent the idea that we can have one hazard. There might be many causes that lead to this hazard. There might be many different things that could create the hazard or initiate the hazard. And the hazard may have many different consequences.
Consequences
As I’ve said before, nothing at all may happen. That might be the consequence of the hazard. Most of the time that’s what’s going to happen. But there may be a variety of consequences. Somebody might get a minor injury or there might be a more serious accident where one or more people are killed. A good example of this is fire. So, the hazard is the fire. The causes might be various. We could be dealing with flammable chemicals, or a lightning strike, or an electricity arc flash. Or we could be dealing with very high temperatures where things spontaneously burst into flames. Or we could have a chemical in the presence of pure oxygen. Some things will spontaneously burst into flames in the presence of pure oxygen. So there’re a variety of causes that lead to the fire.
An Example
And the fire might be very small and burn itself out. It causes very little damage and nobody gets hurt. Or it might lead to a much bigger fire that, in theory, could kill lots of people. So, there’s a huge range of consequences potentially from one hazard. But the accident sequence is how we would describe and capture this progression. From initiating events to the hazard to the possible consequences. And by modeling the accident sequence, of course, we can think about how we could interrupt it.
Part 3
We’ve broken risk management down into those six constituent parts. We’ve gone to the next level, in that we’ve sort of gone down to the concepts that underpin these things. These hazards, the accidents, and the accident sequence. We’ve talked about risk itself and what we don’t want to happen. The harm, the loss, the financial loss, the embarrassment, the failed or late or budget project, a security breach, the undesired event, etc. We had an objective which was to do something safely or to complete a project and the risk is that that won’t happen. That there’ll be an impact on what we were trying to do that is negative. That is undesirable.
There are just only more concepts that we need to look at to complete the pattern, as you can see. We’ve been talking about the system. And we’ve been talking about doing things systematically. Then a system works in an operating environment. So, let’s unpack that.
System
First of all, we have a system. The system is going to be a combination of things. I wouldn’t call a pen or a pencil a system. It’s only got a couple of components. You could pull it apart. But it’s too simple to be worth calling it a system. We wouldn’t call it a pen system, would we? So, a system is something more complex. It’s a combination of things and we need to define the boundary. I’ll come back to that.
But within this boundary, we’ve got some different elements in the system that work together. Or they’re used together within a defined operating environment. So, we’re going to expose this system to a range of conditions in which it is designed to work. The intention is the system is going to do whatever it does to perform a given task. It can do one defined task or achieve a specific purpose.
I talked before about getting in our car. A car is complex enough to be called a system. We get in our car and we drive it on the roads. Or if we’ve got a four-wheel drive, we can drive Off-Road. Or we can use it in a more demanding operating environment to achieve a specific purpose. We want to transport ourselves, and sometimes some stuff, from A to B. That’s what we’re trying to do with the system.
Within the System
And within that system, we may have personnel/people, we may have procedures. A bunch of rules about how you drive a car legally in different countries. We’ve got materials and physical things – what the car is made of. We could have tools to repair it, and change wheels. We’ve got some other equipment, like a satnav. We’ve got facilities. We need to take a car somewhere to fill up with fuel or to recharge it. We’ve got services like garages, repairs, servicing, etc. And there could be some software in there as well. Of course, these days in the car, there’s software everywhere in most complex devices.
So, our system is a combination of lots of different things. These things are working together to achieve some kind of goal or some kind of result. There’s somewhere we want to get to. And it’s designed to work in a particular operating environment. Cars work on roads really well. Off-road cars can work on tracks. Put them in deep water, they tend not to work so well. So, let’s talk about that operating environment.
Operating Environment
What we’ve got here, is the total set of all external, natural, and induced conditions. (That’s external to the system, so outside the boundary.) So, it might be these conditions-. It might be natural or it might be generated by something else, which a system is exposed to at any given moment. We need to get a good understanding of the system, the operating environment, and what we want it to do.
If we have a good understanding of those three things, then we will be well on the way to being able to understand the risks associated with that system. That’s one of the key things with risk management. If you’ve got those three things, that’s crucial. You will not be able to do effective risk management if you don’t have a grasp of those things. And if you do have a thorough grasp of those things, it’s going to help you do effective risk management.
Conclusion
So, we’ve talked about risk management. We’ve broken it down into some big sections. Those six sections; the hazard identification; analysis; risk estimation; evaluation; reduction; and acceptance. We’ve seen how those things depend on only a few concepts. We’ve got the concepts of ‘hazards’, ‘risks’, and ‘accidents’. As well as the undesirable consequences that the risk might result in. The risk is measured based on the likelihood and severity of that harm or loss occurring.
When we’re dealing with a more complex system, we need to understand that system and the environment in which it operates. Of course, we’ve put it in that environment for a purpose. And that unpacking has allowed us to break down quite a big concept, risk management. A lot of people, like myself, spend years and years learning how to do this. It takes time to gain experience because it’s a complex thing. But if we break it down, we can understand what we’re doing. We can work our way down the fundamentals. And then if we’ve got a good grasp of the fundamentals, that supports getting the more complex stuff right. So, that’s what risk management is all about. That’s your risk management 101 and I hope that you find that helpful.
Copyright Statement
I just need to say briefly that those quotations from the standard. I can do that under a Creative Commons license. The CC4.0. That allows me to do that within limits that I am careful to observe. But this video presentation is copyrighted by the Safety Artisan.
For More…
And you can see more like these at the Safety Artisan website. That’s www.safetyartisan.com. And as you can see, it’s a secure site so you can visit without fear of a security breach. So, do head over there. Subscribe to the monthly newsletter to get discounts on paid videos and regular updates of what’s coming up. both paid and free.
So, it just remains for me to say thanks very much for watching and I look forward to catching up with you again very soon.
In this post ‘Full Function Hazard Logs: A Deep Dive into Relational Databases’, I explore some things we can do with a hazard log built upon a database.
In my 25-year career in safety engineering, I’ve seen many hazard logs and hazard tracking systems. Most of them were hosted in Microsoft Excel, but there were also commercial tools and bespoke databases. Let’s explore well beyond mere spreadsheets…
The Accident Sequence Illustrated.
In the realm of hazard management, navigating through the complexities of hazard logs, hazard tracking systems, and risk registers is crucial for ensuring safety and compliance. To shed light on this intricate process, we embark on a journey to explore the nuances of full-function hazard logs and their utilization within relational databases. Join us as we unravel the intricacies of hazard identification, risk assessment, and control measures within the realm of safety engineering.
Unveiling the Essence of Full Function Hazard Logs
Entities and Links in an Example Full-function Hazard Log
In our quest to decipher the essence of full-function hazard logs, we delve into the core components of relational databases. Our mission is clear: to unravel the labyrinth of entities within a hazard log, understand their interconnections, and discern the rationale behind data recording. By comprehending the diverse facets of hazard logs, we equip ourselves with the knowledge to tailor hazard log features to meet specific needs, ensuring efficiency and efficacy in hazard management processes.
Illustrating with Cassandra: A Glimpse into Hazard Log Tools
As we embark on this journey, we look closely at Cassandra, an exemplar of hazard log tools. While our focus remains steadfast on elucidating hazard management principles, Cassandra serves as a tangible illustration, offering a practical lens through which to explore complex concepts.
The Cassandra Hazard Log Logo
Through this illustrative example, we navigate the intricacies of accident causal control, dissecting the underlying hazard model that underpins our hazard management endeavors.
Deciphering Hazard Log Screens: A Comprehensive Overview
Venturing further into the realm of hazard log management, we dissect the various screens encapsulated within the hazard log interface.
A Screen with Accident-related Data and Links.
From the overview screen, where we gain a holistic view of accidents, hazards, causes, and controls, to the core screen, where we delve into the specifics of causal analysis, each screen offers a unique perspective on hazard management. By scrutinizing leading particulars, probability, severity, and post-control statuses, we unravel the intricacies of hazard identification and risk mitigation.
Unveiling the Power of Relational Databases
Central to our exploration is the underlying power of relational databases, where entities are intricately linked through many-to-many relationships. As we navigate through the database landscape, we witness the seamless integration of accidents, hazards, causes, and controls, each playing a pivotal role in shaping hazard management strategies. By harnessing the full potential of relational databases, we unlock a myriad of benefits, empowering us to make informed decisions and uphold safety standards with unwavering diligence.
Accessing Additional Resources: Empowering Your Hazard Management Journey
As we conclude our exploration of full-function hazard logs within relational databases, we extend an invitation to delve deeper into the realm of hazard management.
Through free email subscriptions and access to courses on safety engineering, we provide a gateway to further enrich your hazard management knowledge. Join our community of safety enthusiasts, engage in insightful discussions, and embark on a transformative journey toward bolstering safety practices within your organization.
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.
“What Have Hazard Logs Ever Done for Us? Well, there’s the aqueduct…” Monty Python’s Flying Circus may not be an obvious connection to hazard management, but it works! Hazard Logs – or Hazard Tracking Systems (HTS), which is a better term – are underappreciated but vital tools.
In this webinar on hazard logs, one of the topics that I will be covering is what a ‘full-function’ HTS can do. By that, I mean a purpose-built database, rather than just a spreadsheet. So here is a taster of the benefits, derived from my 25+ years of experience on system safety programs, large and small.
Key Elements of a Hazard Log
An HTS pulls together key safety data about:
Accidents: ‘An unintended event, or sequence of events, that causes harm’;
Accident Sequences: ‘The progression of events that results in an accident’;
Causes: that may lead to a hazard;
Controls (or mitigations): ‘A measure that, when implemented, reduces risk.’; and, of course
Hazards: ‘A physical situation or state of a system, often following from some initiating event, that may lead to an accident’.
Accident Sequence
Understanding how causes lead to hazards, and hazards lead to consequences, which may include (harmful) accidents, is fundamental to understanding accident sequences. This in turn helps us to understand the mechanisms that lead to harm – and defeat them.
Managing Many-to-Many Connections
A Hazard Log doesn’t just store data elements, it links those data together meaningfully to make information. A relational database does this by allowing us to make many-to-many connections between different classes of data.
Hazard Log Connections
This allows us to do a lot of useful things. We’ve already mentioned understanding the mechanisms behind accident sequences. This allows us to design or select effective controls to interrupt the accident sequences and prevent harm.
Discovering Pathways to Harm
Understanding these links also enables us to see connections, for example between causes and accidents, which we had not seen before. This is important, as many severe accidents arise from unanticipated pathways to harm, perhaps in very specific circumstances. (For example, not shutting the bow doors of a ferry properly led to the flooding and capsizing of the Herald of Free Enterprise, killing 193 people.)
Change Impact Analysis
Understanding these connections also allows us to perform safety change impact analysis (‘the analysis of changes within a deployed product or application and their potential consequences’). In many programs I worked on, in-use incidents revealed that:
Designs were not working as intended;
Hazard controls were not as effective as thought;
Work done was not as designed; or that
The actual use of a system was not as foreseen.
If we know the links to something that has changed – what it affects / what affects it – then we can begin to estimate the impact. From experience, this occupies a lot of our time in in-service safety management.
Recovery and Improvement
In the real world things rarely stand still. There are usually many different stimuli for change (we’ve already mentioned our incidents/accidents). Our enterprise might have to raise its game for several reasons:
The Regulator demanding change or improvement;
Customers asking for more performance or more assurance;
The public reaction to incidents elsewhere in the market;
New technology or new competitors in our industry; or
Our commitment to continuous improvement.
Pareto analysis tells us that a minority of causes tend to dominate the effect. Thus, a small number of causes or initiating events drive the occurrence of hazards. Similarly, a minority of hazards will dominate incident and/or accident statistics.
We may know this from experience or analysis of our specific system, or we may have only generic data. It doesn’t matter.
Using these insights, we can use the linkages in the HTS to target particular causes, events, conditions, scenarios, hazards, etc. We identify the set that (should) make the biggest impact, the biggest difference. We can then rank the contributors in order of importance and tackle them.
Again, long and sometimes bitter experience tells me that safety practitioners will spend a lot of time doing this. Reacting to stimuli is a big part of safety management.
The Tool Supports the Process
Of course, we should be using tools to support the process. (The process is designed to produce the results or outcomes that we need). One example of such is the Risk Assessment process from ISO 31000, below.
The Risk Assessment Process
We want our HTS to support this process, storing the data that we get from the risk identification, analysis, and evaluation activities. We also want our Hazard Log to provide information that enables communication and consultation as well as monitoring and review (perhaps using a risk matrix).
Other Functions
Hazard Logs and HTS also perform many other functions. These may appear mundane, but when they go wrong they suddenly become very exciting! What Have Hazard Logs Ever Done for Us? They help us avoid these unwanted excitements, by providing:
Data discipline (e.g. drop-down selections rather than free text fields).
Questions? Comments? Send me your feedback in the comments, below.
My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!
In ‘Optimizing Safety: Active Hazard Management with Hazard Logs’ we look at how to unleash the power of this underrated tool!
Introduction
A Hazard Log is more than just a record; it’s a dynamic tool for actively managing safety risks associated with systems. This continually updated log encapsulates Hazards, Accident Sequences, and Accidents, ensuring a structured approach to risk management. Dive into the world of Hazard Logs to discover their application, advantages, and best practices for effective use.
Active Management with Hazard Logs
Overview
A Hazard Log serves as an ongoing record, meticulously updated to capture Hazards, Accident Sequences, and Accidents linked to a system. It acts as a comprehensive repository, providing insights into risk management decisions for each Hazard and Accident.
The Hazard Log is a structured method of keeping and referring to Safety Risk Evaluations and other information pertaining to a piece of equipment or system. It is the primary means of monitoring the status of all identified hazards, choices made, and risk-reduction actions done, and should be utilised to assist supervision by the Project Safety Committee and other stakeholders.
Hazards, Accident Sequences, and Accidents noted are those that could potentially occur as well as those that have already occurred. The title Hazard Log may be deceptive because the information saved relates to the overall Safety Programme and includes Accidents, Controls, Risk Evaluation, ALARP/SFARP rationale, and Hazard data.
Utilization and Administration
Administered by a dedicated Hazard Log Administrator, primary access is granted to add, edit, or close data records. All other personnel have read-only access, ensuring visibility of Hazards while maintaining control. Records are tracked using a status field, indicating stages such as opening, awaiting mitigation confirmation, or ALARP/SFARP justification.
Recording Hazards
Considered best practice, each Hazard is recorded as “open,” with ALARP/SFARP arguments treated provisionally until mitigation actions are confirmed. Hazards are not deleted but closed with appropriate justifications, reflecting changes in relevance.
As an example, suppose the mitigation is contingent on the development of an operational procedure. This may not be developed until far after the Hazard has been discovered in the early stages of design or construction.
Hazards should not be erased from the Hazard Log, but rather closed and labeled “out of scope” or “not considered credible” with adequate justification. If such Hazards are no longer thought to be relevant to the system, the Log entry should be modified to reflect this.
Application in Systems
The Hazard Log should focus on a specified system, detailing its scope and safety requirements. It records the evaluation of Hazards, residual risk assessments, and recommendations for mitigation or formal acceptance with ALARP/SFARP justification.
Because a Hazard Log is an organised method of collecting and referencing data and records on Hazards, as well as documenting the Risk Evaluation and other information relevant to an equipment or system, unambiguous cross-referencing to supporting documentation is critical. The supporting documentation can be directly incorporated in the Hazard Log or cross-referenced.
Establishing a Hazard Log: Why and When
Traceability
A Hazard Log is crucial for projects, offering traceability in the decision-making process, and justifying the assessed Safety Risk. Initiated at the program’s earliest stage, it remains a live document throughout the system life cycle.
As modifications are implemented in the system, the Hazard Log should be updated to reflect the current design standard by including new or changed Hazards and the associated residual risks. The Hazard Log must be checked frequently to verify that hazards are being managed effectively and that compelling safety arguments in the Safety Case can be created.
Advantages & Disadvantages
Advantages
The Hazard Log is a traceable record of the Project’s Hazard Management process and thus:
Ensures that the Project Safety Programme uses a consistent set of Safety information;
Facilitates oversight by the Safety Panel and other stakeholders of the current status of the Safety activities; and
Supports the effective management of possible Hazards and Accidents so that the associated Risks are brought up to and maintained at a tolerable level;
Disadvantages
The Hazard Log could include information about the relationship between hazards, accidents, and their control through the establishment and fulfilment of Safety Requirements. However, if it is not robust or well-structured, this may obscure the identification and clearance of Hazards.
If Hazards are not well defined when they are entered into the Hazard Log, the rigour enforced by the need for a clear audit trail of changes made may make it very difficult to maintain the Hazard and Accident records most effectively. Before beginning data entry, an appropriate structure should be created and agreed upon.
Choosing the Right Format: Electronic vs. Paper-Based
Electronic Format
While a Hazard Log can be produced in any format, an electronic format, often in databases like Microsoft Access or SQL Server, ensures quick cross-referencing and traceability. Proprietary tools like Cassandra or spreadsheet packages like Microsoft Excel offer flexibility.
Bespoke vs. Proprietary
Choosing between a bespoke database and a proprietary tool involves considerations of customizability and standardization. A bespoke system may be simple to administer, while a proprietary tool ensures consistency across programs.
In conclusion, Hazard Logs, when actively managed, emerge as indispensable tools for maintaining safety standards and facilitating informed decision-making. Understanding their application and choosing the right format ensures efficient risk management throughout a system’s life cycle.
We will explore more active hazard management in our upcoming blog post using Cassandra as a case study.
That was ‘Optimizing Safety: Active Hazard Management with Hazard Logs’. See another article of my articles on hazard logs here. I hope that you find them useful: leave a comment, below!
My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!
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.
