SMP03 Safety Planning

Safety Planning: if you fail to plan, you are planning to fail. In my experience, good safety plans don't always result in successful safety programs; however, bad safety plans never lead to success.



Safety Planning: Introduction



Definitions



A Safety Management Plan is defined as:



“A document that defines the strategy for addressing safety and documents the Safety Management System for a specific project.”UK MoD Defence Standard 00-56



Objectives



The objectives of a Project Safety Management Plan (SMP) are twofold:



- To ensure that the safety performance of the system is acceptable throughout its life;

- To provide and maintain adequate assurance information that this is being achieved.



These objectives can only be realised by following a coordinated and structured approach to safety throughout the system lifecycle. This encompasses setting appropriate requirements as well as conducting risk management as an integral part of system development.



Separate project SMPs are to be produced both by the Enterprise Project and by the contractor. Each SMP defines the safety activities to be conducted by that organisation, so they are closely related to each other. The programmes that they contain will also be linked to activities of system development, trials and any Safety approvals required. Similarly, the Independent Safety Auditor’s Audit Plan will also be linked to these activities.



This procedure is concerned with the SMP for the Enterprise Project rather than plans produced by the contractor or Independent Safety Auditor.



The SMP details the Enterprise’s Safety Management Activities for the Project and therefore:



- Ensures that safety responsibilities are recognised and properly allocated;

- Defines the safety programme timescales and so supports the timely completion of tasks and identification of any slippage.



The Enterprise Project SMP forms an essential element of the Through Life Management Plan. Each project requires an SMP describing the measures that will be enacted to demonstrate that the system will be tolerably safe throughout its life.



The publication and agreement of the arrangements detailed in the SMP should be the mechanism through which the Enterprise through-life safety management of the equipment is established. The SMP is the formal record of the way the Enterprise manages safety for a project.



Safety Planning: Procedure



Method



The SMP defines the strategy for addressing safety and interprets the Safety Management System for a specific project. It also contains the safety programme which documents safety timescales, milestones and other date-related information.



The SMP will consider all aspects of equipment safety including, but not restricted to;



- General equipment safety;

- System specific requirements i.e. Airworthiness, Ship Key Hazards etc.;

- Occupational Safety i.e. Manual Handling, Packaging, Transport and Storage, Control of Substances Hazardous to Health etc.;

- Safety of operation;

- Infrastructure interfaces;

- Maintenance;

- Training;

- Disposal.



The SMP may be based on the template in Annex A. It should not be confused with the requirement of Defence Standard 00-56 for the contractor to produce a Safety Plan.



The SMP should be detailed for the current stage of the acquisition cycle but should also define a workable safety strategy for all the remaining stages, including Disposal. This safety strategy covers both the Enterprise’s input to safety engineering and safety assurance aspects, including Safety Case development and safety approvals.



Devising a general plan is not practical: each plan must be tailored to its project and goals.



See Annex B for an example of a RACI (Responsible, Accountable, Consulted, Informed) Chart which might be used as part of a Project SMP to define the responsibilities and accountabilities of the authorities involved in the implementation of the Enterprise  Project safety programme.



The SMP may cover groups of similar projects within a Delivery Team where common activities are required, although separate committees are envisaged for very large, high risk or diverse projects within a Delivery Team.



Content



The Project SMP should contain the following information: -



- Outline description. Description of the equipment, clearly defining the purpose and capability expected (and eventually achieved) of the project. Clearly identify the range, or variants, of the equipment covered, its purpose, operating cycle and environment and defining interfaces with other equipment and levels of competence expected of the operator(s);

- Safety Management System. Details of the Safety Management System including its aims and objectives, the managerial and technical tasks to be undertaken and the organisation responsible for implementing them;

- Responsibilities and resources. The management structure, responsibilities, resources and interfaces with contractors that are necessary for the implementation of the safety programme. This should include the roles and details of all personnel involved throughout the life of the project. It should include the Team Leader, the individual within the team with formally-delegated safety responsibilities, the Project Safety Manager, Equipment Capability Customer, Maintainers, Users and the Project Safety Committee. The reporting chain should be identified within the plan. A RACI (Responsible, Accountable, Consulted, Informed) Chart should be used to define the responsibilities and accountabilities of the authorities involved in the implementation of the Enterprise Project Safety Programme;

- Audit. Details of the audit arrangements for the project, including internal and independent audits;

- Requirements, objectives, targets and acceptance. A definition of the safety requirements, objectives, targets, regulation, licensing and certification requirements and acceptance criteria for the project. Details of statutory safety standards, legislation and regulations, and any restrictions or exemptions that may apply. The means and criteria by which the requirements are to be demonstrated and accepted are to be clearly defined (these elements will form part of the technical requirement for the project and will become deliverables under the contract);

- Scope of the Safety Case. Clearly identify the range and variants, of the equipment covered, its purpose, operating cycle and environment to be covered e.g. the operating envelope;

- Safety Case strategy. The definition of the strategy to be followed for the safety assessment. This should give a full breakdown of all the techniques to be used to identify, analyse, assess and control hazards;

- Safety Programme. The programme of work that identifies and schedules the tasks contained in the previous paragraphs. This programme should be linked to key stages in the Through Life Management Plan.



An outline of Project SMP has been provided in Annex A. Additional advice is available from domain-specific safety regulations.



Warnings and Potential Project Risks



The SMP is the principal mechanism for managing project risks associated with safety activities. If the plan is not accurate or is not kept up to date, then the effects of delays in the safety activities or changing project timescales may not be recognised and managed.



If the SMP is not sufficiently detailed, then required safety activities may not be identified and planned into the programme. This may have adverse effects on the project time and cost once the missing activities are recognised and performed. If the requisite activities are not undertaken at all, then either the safety performance may not be adequate, or the necessary safety assurance evidence may not be generated. The former would lead to avoidable accidents and the latter to an inadequate Safety Case that might prevent the system from being accepted into service.



If the SMP is not reviewed and endorsed by the Project Safety Committee (PSC), then it is possible that the Project Safety Management System described in the plan may not be an accurate reflection of the safety responsibilities as understood by other parties. The programme of activities contained in the SMP might not be achievable if the resources required are not available at the times assumed.



Procedure Completion



The PSC is responsible for drafting and endorsing the SMP and agreeing on the safety targets, requirements and acceptance criteria.  It is important that all organisations with safety responsibilities described in the SMP should review the SMP described and agree that it is accurate.



The SMP endorsed by the PSC shall be accepted formally by the Enterprise’s delegated authorities for procurement, support and operation. 



Safety Planning: Timing



Initial Production



The SMP should be produced at the earliest stage of the project, e.g. at the beginning of the Concept stage and be updated as the project progresses through the acquisition stages.



Review, Development and Acceptance



It is recommended that the SMP should be reviewed to a predetermined project programme, particularly if there are major changes to the programme.  It must accurately record arrangements and should be reviewed at each meeting of the PSC, or at least annually.



The SMP endorsed by the PSC shall be accepted formally by the Enterprise-delegated authorities for procurement, support and operation.  When any of the signatories change, the SMP shall be re-issued and formally accepted again by the delegated authorities.



The SMP evolves as the project matures and additional information becomes available or decisions are made.  Early iterations will only outline broad strategies and goals; later iterations will become more definitive.  This will enable important safety management tasks to be carried out during the subsequent acquisition stages.



Safety Planning: Required Inputs



This procedure for Safety Planning requires inputs from:



- Outputs from procedure SMP01 – Safety Initiation;

- Outputs from procedure SMP02 – Safety Committee.



The SMP must be integrated with other management plans produced by the Project throughout the acquisition cycle to ensure its effectiveness. It shall also be of sufficient detail to stand alone for all safety planning activities.



The development of the SMP will be based on the following:



- Overall project programme;

- User Requirements Document and System Requirements Document;

- Through Life Management Plan;

- Existing descriptions of the safety management arrangements for organisations involved in the project (e.g. Delivery Team Safety Management System descriptions).



Safety Planning: Required Outputs



Where relevant, the outputs from this procedure should feed into the following:



- System Requirements Document – for any specific Safety requirements;

- Customer Supplier Agreement – to document agreements on Safety information to be delivered by the Delivery Team;

- Through Life Management Plan;

- Safety elements of Outline Business Case and Full Business Case submissions.



PSC meeting minutes should record the review of the SMP and any decisions made regarding its amendment and 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 programme and send them a copy of this plan where required. Such advisers should include the internal advisors or 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 organisation 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, link to key stages in the Through Life Management Plan.



SAFETY CASE STRATEGY



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



APPROVAL



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



DISTRIBUTION



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



Annex B - RACI Chart example



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



ActivitySafety Delegation HolderProject Safety ManagerIndependent Safety AuditorContractor Project Safety EngineerEquipment UserSafety Case PreparationARIRISafety Case EndorsementAIRIIHazard Log AdministrationAI-R-Safety Requirements PreparationAR-RC



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



Acknowledgement 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.



Safety Planning: What are Your Questions?

#functionalsafetymanagementplanexample #gassafetymanagementplan #healthandsafetymanagementplandoc #healthandsafetymanagementplanexample #healthandsafetymanagementplantemplatenz #healthsafetymanagementplantemplate #ohssafetymanagementplan #safetymanagementplandefinition #safetymanagementplanexample #safetymanagementplanforconstruction #safetymanagementplaninmines #safetymanagementplantemplateqld #sitesafetymanagementplanexample #thelifesafetymanagementplanprovidesinformationandguidelinesforwhichofthefollowing #whatisthepurposeofasafetymanagementsystem

Simon Di Nucci https://www.safetyartisan.com/2022/04/27/smp03-safety-planning/

SMP02 Project Safety Committee

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



Definitions



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



Objectives



The key elements for the effective management and delivery of safety are coordination, agreement, and proper response by those authorities with responsibilities for the equipment. 



The PSC brings together those with safety management responsibilities and other stakeholders with relevant specific knowledge, authority, or Subject Matter Expertise. It, therefore:



- Provides a forum through which all those with safety responsibilities can ensure effective co-ordination on safety issues;

- Provides access for decision-makers to all those with relevant knowledge;

- Provides competent oversight of the Safety Case during its development and upkeep;

- Provides, through records of its meetings, an audit trail showing that suitable advice has been sought and that safety management decisions were well-founded.



The Enterprise PSC may be supported by Panels, Sub-Committees, or Working Groups with the appropriate level of Subject Matter Expertise and defined Terms of Reference to address specific safety issues.



Although contractors will be members of the Enterprise PSC, they may also need to form and chair their own Safety Committee. Typically this might be necessary on more complex projects where there are multiple sub-contractors. Enterprise will be represented on the Contractor’s Safety Committee to ensure that there is an adequate understanding of the in-service environment and the user’s needs. If there are both Enterprise and Contractor Safety Committees, then they must each have clear Terms of Reference, and their inter-relationship must be well defined.



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



The PSC should include representatives, as appropriate, from the following areas:



- The Delivery Team (including the Project Safety Manager, and other technical, contracts, and finance officers as required);

- Integrated Logistics Support teams;

- Equipment support teams;

- Customer representatives (project sponsor);

- User representatives (Equipment End User);

- Trials team;

- Maintenance specialists;

- Training Authorities;

- Prime contractor;

- Design organization;

- Independent Safety Auditor (if appointed);

- Specialist advisors (e.g. from Enterprise, certification authority, or industry safety consultants);

- Enterprise Safety Authority; and

- Enterprise Safety and Environmental Protection Group.



Other representatives that may be required to participate should include contractors, consultants, subject matter experts, safety sustainable development & continuity, operators, users, and maintainers of the equipment. These should also include reliability and quality managers, (other government departments or representatives of other nation-states governments or departments - for public sector projects.)



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 at Annex A - example Terms of Reference for a PSC. Further advice is available from QSEP.



Chair



The Committee(s) should be chaired by the safety-competent individual holding formally-delegated responsibility for safety within the Project.  A Letter of Delegation may detail the scope of the delegation holders' responsibility and authority to carry out the safety management tasks on that program.



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 there are insufficient attendees for the PSC to be declared quorate, the meeting can still proceed with decisions being noted and only implemented once an agreement has been received from the quorum ex-committee. 



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 Mechanisms



The PSC may meet regularly as a body, or its work may be 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. The key principles are to ensure that all relevant authorities are consulted, actions are agreed upon and properly allocated, and a record is kept of proceedings. A PSC can either be established for a single type of equipment, or a family of variants of equipment.



Smaller projects may choose to integrate the PSC activities with other meetings. As a minimum, the discussion of safety issues should remain a unique item on meeting agendas.



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.



Safety Management Committee



Where a number of similar equipment are managed in a single Delivery Team, consideration should be given to establishing a top-level Safety Management Committee (SMC) to set out and agree on the safety management policy and strategy for those projects. The strategy would detail the formation of PSCs for individual equipment, or groups of similar equipment e.g. radio systems, or support vehicles rather than a type of radio or vehicle.



The SMC will monitor and control the activities of the individual PSCs, which will operate in accordance with their own SMPs. Structures can be tailored to suit individual circumstances. Terms of Reference, including membership, for an SMC, should be similar to that of a PSC. The safety management policy and strategy for those projects will be recorded in a Safety Management System document, similar to an SMP. 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 is required to seek and consider relevant advice through the PSC but remains the decision-maker.



Whilst not all members of the PSC need to have specific competence and experience in Safety Management, it is essential that some committee members do have this competence and are consulted.  In addition to the safety delegation holder, whose competence must be established prior to 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 it is considered beneficial, a combined committee may be established for the safety and environmental management activities. It should be ensured that the programs are aligned as far as possible and that data is shared where relevant.



It is suggested that where there are separate safety and environmental committees, these meet consecutively over the morning and afternoon – with membership and specialists attending as appropriate to each.



The PSC may cover groups of similar projects within a Delivery Team where common activities are required, although separate committees are envisaged for very large, high risk or diverse projects within a Delivery Team.



The PSC may meet regularly as a body, or its work may be 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.



Records and Project Documentation



The records from this procedure will consist of PSC meeting minutes which should record the following:



- Those present;

- The discussions;

- Advice given;

- Decisions made;

- Recommendations to those with delegated authority for safety management; and

- Actions agreed.



Where relevant, the outputs from this procedure will feed into the following:



- System Requirements Document – for any specific safety requirements;

- Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;

- Through Life Management Plan;

- Safety elements of Outline Business Case and Full Business Case submissions.



Review and Agreement of Safety Documents



The role of the PSC includes reviewing safety documents and advising the safety delegation holder on their suitability. The agreement that the document is suitable can be signified in various ways and the Project Director should define, which is required. Methods for recording the review and its findings could include:



- Formal sign off of the document by all members of the PSC;

- A recommendation, recorded in PSC minutes, that the document is satisfactory and can be authorized for release by the agreed signatory.



Warnings and Potential Project Risks



If the PSC is not established early in the acquisition life cycle, then some of the stakeholders involved may not be identified and their needs may not be addressed adequately in the development of the safety requirements or the production of the SMP. This could also occur if the PSC is established with an incomplete membership.



If the PSC does not review and approve the safety tasks described in the SMP, then the activities may be inappropriate to deliver the required levels of safety performance and safety assurance.



If the PSC does not review and approve the Safety Management System described in the SMP, then they may not identify areas of disagreement concerning responsibilities for safety.



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.



Procedure Completion



Delivery Teams will complete the procedure, in conjunction with advice and information from members of the PSC.



Project Safety Committee: Timing



Formation



The PSC should be established 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.  Meetings will be required 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.  This will include considering 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:



- Outputs from procedure SMP01 – Safety Initiation;

- Documents to be reviewed such as:- Project Safety Management Plan;

- Independent Safety Auditor Audit Plan (if appointed);

- Independent Safety Auditor Audit Report (if appointed);

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



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:



- To set and keep under review the project’s safety policy and strategy;

- To set and keep under review the project’s safety targets and objectives;

- To define the system boundaries for safety responsibility;

- To advise the Chairperson of the Safety Committee on the safety responsibilities of each authority associated with the project;

- To advise the Chairperson of the Safety Committee on the standards, statutory regulations, and any restrictions with which the projects should comply;

- To review, monitor, classify and allocate new equipment hazards as they are identified;

- To 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;

- To agree on any control measures that are deemed necessary to reduce identified risks to ALARP;

- To ensure proper and timely availability of training and issue of documentation;

- To carry out actions from ISA, regulatory or internal audit findings;

- To 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?

#howtoselectsafetycommitteemembers #safetycommittee #safetycommitteechairmanresponsibilities #safetycommitteechairpersonresponsibilities #safetycommitteediscussiontopics #safetycommitteegoalsexamples #safetycommitteeiscomprisedof #safetycommitteetermsofreference #safetycommitteevisionstatementexamples

Simon Di Nucci https://www.safetyartisan.com/2022/04/13/smp02-project-safety-committee/

SMP01 Project Safety Initiation

In 'Project Safety Initiation' we look at what you need to do to get your safety project or program started.



Introduction



Definitions



A stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to 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; andc) Quality criteria, e.g. needed to realise benefits.Top Tip



This procedure assumes that the Program Director has already been appointed, and that clearly defined safety responsibilities have been formally delegated to a suitably safety-competent individual within the Delivery Team.  



Although this is written as a safety procedure, it is recognized that at this early stage the safety and environmental processes are very similar and may be carried out together. Where appropriate, the same formats and tools are recommended for stakeholder and legislative requirements to provide a single consistent basis for subsequent safety and environmental activities. These tools are described here for completeness. It is also recognized that in many projects, the roles of Project Safety and Environment Manager may be combined, and a single Project Safety and Environmental Committee may exist.



The purpose of Safety Initiation is to ensure that the safety management process is commenced on a firm basis by identifying basic information, interfaces, and responsibilities. These include:



- Stakeholders (including industry);

- Regulators and Approval Authorities;

- Project Safety Manager;

- Independent Safety Auditor if appropriate;

- Project Safety Committee;

- Project Safety Responsible, Accountable, Consulted, Informed (RACI) Chart;

- Enterprise internal safety regulator/audit group.



All applicable factors need to be lined up to ensure the success of a safety project or program.Top Tip



Project Safety Initiation: Procedure



Stakeholder Identification



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. This may include individuals or groups that:



- Have safety responsibilities at any stage of the project;

- Have safety requirements (including information) from the project;

- Hold safety information relevant to the project (e.g. other Delivery Teams with interfacing or sub-systems);

- Have specialist or operational knowledge that can aid the project in achieving safety requirements.



As a minimum, the following will be consulted:



- Project Sponsor (e.g. the Director of the End Users’ Business Unit);

- Equipment end user;

- Technical Director;

- Other Delivery Teams involved in any sub-systems of the project;

- Other Delivery Teams involved with systems, projects or systems platforms with which the system/project will be closely associated;

- Subject Matter Experts with specialist technical or professional expertise in a subject area relevant to the Project;

- Relevant Enterprise internal safety regulator/audit group (via Questionnaire Form SMP01/F/01 - Safety Operating Environment Questionnaire).



When stakeholders have been identified, their contact details and involvement in the project will be recorded in form SMP01/F/02 - Register of Stakeholder Requirements and Information.



Initially, stakeholders identified and consulted at this stage will be restricted to the Enterprise. However, any relevant external stakeholders identified e.g. (other) government departments, industry, research organizations, regulatory bodies, etc., should be logged and included in a communication plan, which identifies when they should be consulted, by whom, and for what purpose. The Project may choose to include external stakeholders at this stage.



Note that for projects that involve a high number of stakeholders, consideration will be given to developing a project communication plan that includes contact details, information requirements, lines of communication, responsibilities, and any 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



Identify Applicable Legislation, Standards, and Requirements



The identification of relevant legislation at the start of any project is essential so that any conditions for compliance can be incorporated into the acquisition process. Project Safety Manager (PSMs) will identify and maintain a register of applicable legislation as part of the development of the Safety Case, and continuously review it and revise it as necessary.



This is the initial identification of potentially applicable safety standards and requirements (including legislation, policy, and best practice standards) that may apply to the project over its lifetime. The Register of Safety Legislation and Other Significant Requirements (see Form SMP01/F/03 - Register of Safety Legislation and Other Significant Requirements) will be used to list and document these standards for each of the life cycle stages. A separate sheet should be used for each standard identified.



Within the Enterprise, each project’s Legislative Register should be taken to include matters of Government or policy and international treaty obligations. 



Note that this will be an evolving process through several stages of the project. The Preliminary Hazard Identification and Analysis procedure (Procedure SMP04 – Preliminary Hazard Identification and Analysis) will identify additional requirements, to be consolidated into the safety requirements (see procedure SMP10 – Safety Requirements and Contracts).



Useful information sources include:



- Other equipment safety standards;

- Other relevant legislation and standards for operations in other legal jurisdictions.



For more information on this vital task, see the post on System Requirements Hazard Analysis here.Top Tip



Create Project Safety Organization



Ultimately, the project safety management organization will be defined in the Safety Management Plan (SMP) (Procedure SMP03 – Safety Planning). However, in advance of the preparation of this document, it is necessary to set up key elements of the safety management organization, as follows:



- Appoint competent PSM;

- Appoint Independent Safety Auditor (ISA), if required;

- Form Project Safety Committee (PSC) (membership and role defined in Procedure SMP02 – Safety Committee);

- Produce high level definition of other project safety responsibilities, in the form of an initial project RACI (Responsible, Accountable, Consulted, Informed) chart for the safety management process defined for this stage of the project.



Appointment of an ISA is advisable for projects that are complex, novel, or assessed as having high levels of safety risk. The appointment of an ISA may also be mandated by domain-specific requirements or standards. 



Compliance



The organization uses a number of methods of enabling compliance:



- Delivery Teams develop System Specifications to meet User Concept Document statements from the Project Sponsor. This is an important method for advising industry of the Enterprise’s safety and environmental requirements;

- The Through Life Management Plan incorporates the impact of safety and environmental legislation on the relevant equipment both now and in the future (The Project Safety and Environmental Management Plans are integral parts of the Through Life Management Plan);

- Use of Enterprise guidance in the development of contracts and contract conditions.



Where the Delivery Team also develops the User Concept Document on behalf of the Project Sponsor, it is extremely important that these reflect the Enterprise safety and environmental performance objectives and targets, recognizing and emphasizing any politically or publicly sensitive issues. The advice of organizational Subject Matter Experts in Safety, Sustainable Development & Continuity must be sought in the construction of the User Concept Document.



Although reference to Enterprise guidance provides the Enterprise with some protection, any Invitation to Tender must explicitly describe the project’s requirements for safety and environmental management.  In addition, compliance and performance requirements, resulting from the User Concept Document and System Specification and the project’s Safety Management Plan.



Access to information about safety and environmental legislation is enabled via a number of organizations and media – the following provides some primary examples:



- Legislative Registers held by the Program Teams;

- Defence Regulator intranet pages, Enterprise’s Safety net etc;

- Websites and publications of the Health & Safety Executive, Professional Societies and of lawyers or consultancies specialising in providing information and knowledge of safety and environmental matters and current affairs;

- Suppliers, contractors and consultants;

- Other projects and Delivery Teams.



Identification of and compliance with all relevant safety and environmental legalization will always ultimately be the responsibility of the Delivery Team member with delegated authority for safety and environmental protection.



Since safety and environmental legislation is continuously evolving, Delivery Teams are strongly recommended to seek expert advice on new requirements that might be likely to come into force during the project life cycle.



The wider Enterprise may maintain a list of approved specialist contractors as part of a Framework Agreement for Technical Services enabling arrangement (AKA a list of approved suppliers). This maps suppliers' capabilities against a range of safety and environmental management areas, enabling Delivery Teams to select contractors with the necessary levels of experience and expertise for specific tasks.



Membership of the framework agreement is open to companies of all sizes and is secured by qualification against pre-determined criteria, rather than by competition. All members are subject to the same terms and conditions throughout the duration of the framework agreement.



Records and Project Documentation



Where relevant, the outputs from this procedure will feed into the following:



- System Specification – for any specific Safety requirements;

- Customer Supplier Agreement – to document agreements on Safety information to be delivered by the Delivery Team;

- Through Life Management Plan;

- Safety elements of Outline Business Case submissions.



In addition, as the competence of the PSM is relevant to the safety assurance on the project, the evidence should be retained from the selection process to verify the appointed individual is competent to perform the required responsibilities.



Warnings and Potential Project Risks



If Delivery Teams fail to carry out this procedure in a timely manner, there will be delays in engaging stakeholders, recognizing legislative or other requirements, or creating the safety organization. This will inevitably result in risks to project costs and timescales.



If the project fails to co-ordinate the treatment of stakeholders and legislative requirements between the safety and environmental management system, there is a risk that there will be inconsistent communication to stakeholders and duplication or omission of requirements (e.g. falling between the two).



The legislative and other requirements register will not be read across from one project to another, even if they are similar in scope, without a detailed review.



The competence of PSMs and ISAs is critical to the safety success of the project. It is important that this competence should be assured, and that records demonstrating that this has been done should be retained. If this is not done it will be difficult to demonstrate that safety and environmental responsibilities have been discharged correctly.



Procedure Completion



The PSM will identify the legislation, regulators, and approval authorities that the project will need to satisfy, and any requirements for independent safety certification.



The PSM will maintain a legislative register as an integral part of the Safety Case for each project.



The internal and external auditors should check for legal and policy compliance as part of their assessment of the Safety Management System (SMS), Safety Management Plan (SMP), and Safety Case.  It should be noted that responsibility for compliance still rests with those with delegated responsibility rather than with the auditor.



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 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



Project Safety Initiation: Required Inputs



The procedure may use the following reference inputs, as available:



- User Concept Documentation (for Acquisition Programmes);

- Any other information on the proposed functionality, use, support and context of the proposed system;

- Existing Hazard Logs for existing similar systems;

- Relevant Enterprise Policy.



Project Safety Initiation: Required Outputs



The Outputs of the procedure will comprise:



- Appointed PSM and ISA, if appropriate;

- Completed Form SMP01/F/01 - Safety Operating Environment Questionnaire;

- Completed Form SMP01/F/02 - Register of Stakeholder Requirements and Information, which should be reviewed and updated as the project proceeds;

- Completed Form SMP01/F/03 - Register of Safety Legislation and Other Significant Requirements, which should be reviewed and updated as the project proceeds.



The Delivery Team should consider addressing legislation and similar issues amongst standardization issues especially when producing and reviewing the standardization strategy and implementation plan. These issues occur throughout the life of the project which the Delivery Team controls. These also occur when updating the project standards database, and project Safety Initiation documents SMP01/F/03 with changes in legislation and international agreements.



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 Initiation: How would you kick off your Safety Program?

#projectandstakeholdermanagement #projectcharterstakeholderlistexample #projectgovernancestakeholdermanagement #projectmanagementstakeholderlist #projectmanagementstakeholderlisttemplate #projectstakeholderanalysisexample #projectstakeholderanalysistemplate #projectstakeholdercommunicationplan #projectstakeholderlisttemplate #projectstakeholdermanagementbestpractices #projectstakeholdermanagementexample #projectstakeholdermanagementstrategy #projectstakeholderregisterexample #whoisprojectstakeholder

Simon Di Nucci https://www.safetyartisan.com/2022/04/06/project-safety-initiation/

So Far As Is Reasonably Practicable

'So Far As Is Reasonably Practicable' is a phrase that gets used a lot, but what does it mean? How do you demonstrate it?



In this post, I will talk about how to demonstrate SFARP. I've been doing this on complex programs for 20+ years now, both in the UK and Australia. The concept of 'reasonably practicable' is much easier to apply than people think. I've watched a lot of programs over-complicate the process. We just don't have to do that!



I have some practical tips for you, not just theory. In Australia we do it like this ... and you can learn from this wherever you operate!



Attribution



This post uses text from 'How to Determine what is Reasonably Practicable to Meet a Health and Safety Duty', published by Safe Work Australia in May 2013.



This copyright work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Australia license. To view a copy of this license, visit here. In essence, you are free to copy, communicate and adapt the work for non-commercial purposes, as long as you attribute the work to Safe Work Australia and abide by the other license terms.



How is ‘reasonably practicable’ defined?



Section 18 of the WHS Act defines the standard that is to be met and describes the process for determining this:



S.18: In this Act, ‘reasonably practicable’, in relation to a duty to ensure health and safety, means that which is, or was at a particular time, reasonably able to be done to ensure health and safety, taking into account and weighing up all relevant matters including:



- the likelihood of the hazard or the risk concerned occurring; and



- the degree of harm that might result from the hazard or the risk; and



- what the person concerned knows, or ought reasonably to know, about the hazard or risk, and about the ways of eliminating or minimising the risk; and



- the availability and suitability of ways to eliminate or minimise the risk; and



- after assessing the extent of the risk and the available ways of eliminating or minimising the risk, the cost associated with available ways of eliminating or minimising the risk, including whether the cost is grossly disproportionate to the risk.



Note that this definition is actually a risk analysis process. The WHS Risk Management Code of Practice provides the minimum process that will meet this requirement.Top Tip



All Relevant Matters



The process requires that all relevant matters, including those listed in the section, are taken into account and weighed up when determining what is reasonably practicable in particular circumstances.



There are two elements to what is ‘reasonably practicable’. A duty holder must first consider what can be done—that is, what is possible in the circumstances for ensuring health and safety. They must then consider whether it is reasonable in the circumstances to do all that is possible.



Some of the matters listed in section 18 will be relevant to identifying what can be done, for example, if control measures that will eliminate or minimize the risk are available and suitable. Other matters will be relevant to identifying whether what can be done is reasonable to do, for example, if the risk and degree of harm are grossly disproportionate to the cost of implementing the control measure.



To identify what would be reasonably practicable to do, all of the relevant matters must be taken into account and a balance achieved that will provide the highest level of protection that is both possible and reasonable in the circumstances. No single matter determines what is or was at a particular time reasonably practicable to be done to ensure health and safety.



What Each of the ‘Relevant Matters’ Mean



FactorRelevanceThe likelihood of the hazard or the risk concerned occurring  The greater the likelihood of a risk occurring, the greater the significance this will play when weighing up all matters and determining what is reasonably practicable. If harm is more likely to occur, then it may be reasonable to expect more to be done to eliminate or minimize the risk. The frequency of an activity or specific circumstances will be relevant to the likelihood of a risk occurring. The more a worker is exposed to a hazard, the more likely they are to suffer harm from it.The degree of harm that might result from the hazard or the risk  The greater the degree of harm that could result from the hazard or risk, the more significant this factor will be when weighing up all matters to be taken into account and identifying what is reasonably practicable in the circumstances. Clearly, more would be expected of a duty holder to eliminate or minimize the risk of death or serious injury than lesser harm.What the person concerned knows, or ought reasonably to know, about the hazard or risk, and ways of eliminating or minimizing the risk  The knowledge about a hazard or risk, and any ways of eliminating or minimizing the hazard or risk, will be what the duty holder actually knows, and what a reasonable person in the duty holder’s position (e.g. a person in the same industry) would reasonably be expected to know. This is commonly referred to as the state of knowledge. The courts have consistently stated a duty holder must consider all reasonably foreseeable hazards and risks when identifying what is reasonably practicable.The availability and suitability of ways to eliminate or minimize the risk  This requires consideration of not only what is available, but also what is suitable for the elimination or minimization of risk. A risk control that may be effective in some circumstances or environments may not be effective or suitable in others, because of things such as the workplace layout, skills of relevant workers, or the particular way in which the work is done. Equipment to eliminate or minimize a hazard or risk is regarded as being available if it is provided on the open market, or if it is possible to manufacture it. A work process or change to a work process to eliminate or minimize a hazard or risk is regarded as being available if it is feasible to implement. A way of eliminating or minimizing a hazard or risk is regarded as suitable if it: is effective in eliminating or minimizing the likelihood or degree of harm from a hazard or risk does not introduce new and higher risks in the circumstances, and is practical to implement in the circumstances in which the hazard or risk exists.The cost associated with available ways of eliminating or minimizing the risk, including whether the cost is grossly disproportionate to the risk.  Although the cost of eliminating or minimizing risk is relevant in determining what is reasonably practicable, there is a clear presumption in favor of safety ahead of cost.  The cost of eliminating or minimizing risk must only be taken into account after identifying the extent of the risk (the likelihood and degree of harm) and the available ways of eliminating or minimizing the risk. The costs of implementing a particular control may include costs of purchase, installation, maintenance, and operation of the control measure and any impact on productivity as a result of the introduction of the control measure. A calculation of the costs of implementing a control measure must take into account any savings from fewer incidents, injuries, and illnesses, potentially improved productivity, and reduced staff turnover.The 'Relevant Matters' - we will look at each one of these in turn, below.



The first three Factors are covered in the Risk Management Code of Practice, so we won't repeat that stuff here. I just want to note:



Remember that "what you ought reasonably to know" includes what your legislator and regulator has published. You can't be ignorant of this basic stuff and claim to have minimized risks SFARP! Top Tip



Is the Control Measure Available and Suitable?



Investigations and inquiries may identify many ways to eliminate or minimize a particular type of risk. Some of these may, however, not be available ... or may not be suitable in the particular circumstances.



Examples:



- A device may not have been introduced into the Australian market, or may be incompatible with Australian operating conditions.



- Radio communication to minimise risks from people working in isolation or in remote locations may not be suitable in areas where there is no signal or a poor one.



- Mechanical lifting aids may not be able to operate in areas where there is insufficient room to move them around.



- Equipment may not be able to be used in areas where the necessary energy source, such as electricity or gas, is unavailable.



- Particular processes may not be able to be used if they rely on circumstances, including the behaviour of others, over which the duty holder has no control.



Availability



Equipment to eliminate or minimize a hazard or risk is regarded as being available if it is provided on the open market, or if it is possible to manufacture it.



A work process or change to a work process to eliminate or minimize a hazard or risk is regarded as being available if it is feasible to implement.



Suitability



A way of eliminating or minimizing a hazard or risk is regarded as suitable if it:



- is effective in eliminating or minimising the likelihood or degree of harm from a hazard or risk



- does not introduce new and higher risks in the circumstances, and



- is practical to implement in the circumstances in which the hazard or risk exists.



These tests of availability and suitability are very powerful, but they are often overlooked. Make sure that you apply these tests before you consider whether a control is reasonable - it saves a lot of effort. Top Tip



How to Determine what is Reasonable



Just because something can be done does not mean that it is reasonably practicable for the duty holder to do it. What is required is an assessment of what a reasonable person in the position of the duty holder would do in the circumstances, taking a careful and prudent approach and erring on the side of caution.



There are options for determining what is reasonable, including Codes of Practice and Standards. We will look at this in more depth in another lesson.Top Tip



The aim must be to keep trying to lower the likelihood and degree of harm until further steps are not reasonable in the circumstances. Questions you should ask to identify if they are doing enough are:



- Is there more I can do to either



- minimise the risk myself, or



- ensure another party with the relevant skills and expertise can properly implement health and safety measures and minimise risks?



- If the answer is yes to either of the above, is it reasonable for me not to do so?



Okay, here we are looking at Consultation, Cooperation and Coordination between a Duty Holder and workers or other Duty Holders. Look at the C, C&C Code of Practice for help with this. Top Tip



The more likely the risk, the more that is required to be done to eliminate or minimize it. The greater the degree of harm, the more that is required to be done to eliminate or minimize it.



If there is at least a moderate likelihood of death or serious injury, then the highest level of protection should be provided.

The Guidance



This statement is fine in a workplace, but if you are designing something like a car, a plane, or a ship - something complex which could hurt lots of people - then this approach is inadequate. You need to apply the concept of risk tolerability and a Cost-Benefit Analysis.Top Tip



It may not be reasonable to require expensive and time-consuming controls, for example, engineering controls, to be applied to minimize or further minimize a low likelihood of minor harm. It may however be reasonable to apply less expensive controls such as training and supervision to further lower the likelihood of the risk.



When considering each control or combination of controls, a duty holder must take into account the likelihood of a particular control effective. Guards may be removed, systems of work may not be understood and followed, and personal protective equipment may not always be worn. Further controls such as signs or supervision, may be needed to make a control more likely to be effective.



Cost



While cost is specified in Section 18 (of the WHS Act) as a matter to be taken into account and weighed up with other relevant matters to identify what is reasonably practicable, this must only be done after assessing the extent of the risk and the ways of eliminating or minimizing it.



The cost of implementing a particular measure may include the cost of purchase, installation, maintenance and operation of the control measure and any impact on productivity as a result of the introduction of the control measure.



A calculation of the cost of implementing a control measure should also take into account any savings it will yield in reductions in incidents, injuries, illnesses and staff turnover, as well as improvements in staff productivity.



Remember there must be a clear presumption in favor of safety over cost.Top Tip



Before determining whether expenditure to eliminate or minimize a risk is reasonably practicable in the circumstances, the PCBU must consider:



- the likelihood and degree of harm of the hazard or risk, and



- the reduction in the likelihood or degree of harm that will result if the control measure is adopted.



The more likely the hazard or risk, or the greater the harm that may result from it, the less weight should be given to the cost of eliminating the hazard or risk.



Okay, this is really talking about tolerability, as found in discussions of ALARP in the UK, although this Australian guidance avoids saying so! Top Tip



If you cannot afford to implement a control measure that should be implemented after following the weighing-up process set out in Section 18 of the WHS Act, they should not engage in the activity that gives rise to that risk.



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!



What are your questions about SFARP and Reasonably Practicable?

#howtoSFARP #learnSFARP #learnSFARPanalysis #ohsreasonablypracticabledefinition #reasonablypracticable #reasonablypracticablehealthandsafety #reasonablypracticableinhealthandsafety #reasonablypracticablelegaldefinition #reasonablypracticablelegaldefinitionuk #reasonablypracticablemanualhandling #reasonablypracticableohsact #reasonablypracticableworksafevictoria #SFARP #SFARPanalysistechnique #SFARPanalysistraining #SFARPanalysistutorial #SFARPtechnique #SFARPtraining #SFARPtutorial #SFARPvideo #sofarasisreasonablypracticable #whatiswhscompliance

Simon Di Nucci https://www.safetyartisan.com/2022/03/30/so-far-as-is-reasonably-practicable/

Safety Assessment Techniques Overview

In Safety Assessment Techniques Overview we will look at how different analysis techniques can be woven together. How does one analysis feed into another? What do we need to get sufficient coverage to be confident that we've done enough?



Learning Objectives: Safety Assessment Techniques Overview



You will be able to:



- List and ‘sequence’ the five types of risk analysis;

- Describe how the types fit together as a whole;

- Describe the benefits of each type of analysis;

- Describe an example of each type of analysis;

- Select analyses to meet your needs;

- Design an analysis program for different applications; and

- Understand issues driving the use of techniques and level of effort.



https://youtu.be/DLTXoYJiAkQ

This is the ten-minute demo version of the full, 70-minute video.



buy the full video here



Topics: Safety Assessment Techniques Overview



- Overview of Sequence;

- Hazard Identification;

- Requirements Analysis;

- Cause Analysis;

- Consequence Analysis; and

- Control Effectiveness Analysis.



Transcript: Safety Assessment Techniques Overview



Click Here to See the Transcript

Welcome to The Safety Artisan



I'm Simon, your host. And today we've got, quite a special subject.



I'm going to be talking about safety analysis techniques, and this is a special subject because it's by special request from my friends at the University of Southern California. Thank you to them. And what we're going to be doing in today's session is an overview of these different techniques, their benefits and the options that you have for applying techniques in order to come up with a whole programme of analysis.



Let's explain what I mean



What we're going to get out of today is after this you will be able to list and sequence the five types of risk analysis, and it says sequence in inverted commas because, as we'll see, it's not quite as simple as just going through it once in sequence, and that's it. We tend to reiterate, but anyway, there is a natural sequence to this stuff, and we'll see what that is.



Secondly, you'll be able to describe how these different types of analyses fit together and how they feed each other and complement each other. That's very important. If we're going to come up with a reasonable whole; we're going to describe the benefits of each type of analysis.



I will provide at least one example of each type of analysis, sometimes more than one.



We're going to talk about how you would select analyses to meet your needs when analysing a specific system. Because we don't always need to do everything. We don't always need to throw everything at the problem. some systems are simpler than others, and they don't need, the whole works in order to get a decent result.



With that in mind, we're going to be able to design an analysis programme for different applications or for different systems.



And finally, we're going to understand the issues that drive the use of techniques and the level of effort. The level of rigour that we need to apply now, to set expectations. There's no magic answer here. I can't tell you that the amount of hours that you have to spend on a problem is X squared, plus whatever.



We can talk about the factors that drive it, but I cannot give you a nice cut and dried answer. It just doesn't work like that.



Those were the learning objectives



What we're going to talk about, we're going to give an overview of the sequence and then I'm going to recap that at the end.



And then the five types of analyses we're going to talk about in order hazard identification requirements, analysis, cause analysis or cause or analysis, consequence analysis and control, effectiveness, analysis or control, identification and effectiveness analysis.



I'm going to talk about a couple of other things during that, which will help us pull things together. But those are the five main types that I'm going to talk about. Those are the five types of analysis that I said you would be able to list.  We've covered one learning objective already.



I promised you we were going to look at the overview of the sequence.



And I think this is what pulls it all together and explains it powerfully. So the background to this is we've got, an accident or mishap sequence. Whatever you want to call it and we start with causes on the left and causes lead two a hazard, and then a has it can lead to multiple consequences.



That is what the bowtie here is representing. It's showing that multiple causes can lead to a single hazard, and a single hazard can lead to multiple consequences.



Don't worry too much about the bow tie. I'm not pushing that in particular, it's a useful technique, but it's not the only one. We'll come onto that – that's the background.



This is the accident sequence we're trying to discover and understand.



I'm going to talk a lot about discovery and understanding



Yeah, typically, we will start with trying to identify hazards. There are techniques out there that will help us identify hazards associated with the system being used in a specific application, or purpose, in a specific operating environment.



Always bear in mind those three questions about the context, that help us to do this.



What's the system? What are we using it for? and in what environment?



And if we change any of those things, then probably the hazards will change. But we start off to preliminary hazard identification, which is intended to identify hazards. Big, big arrow pointing at hazards, but also, inevitably, it will identify causes and consequences as well, because it's not always clear. What is the hazard when you start? talking of discovery, we're going to discover some stuff.



We may finally classify what we're talking about later. we're trying to discover hazards. In reality, we're going to discover lots of stuff, but mainly we hope hazards, that's stage one.



Now, then we're actually going to step outside of the accident sequence itself. We're going to do some requirements analysis, and the requirements analysis has to come after the PHIA because some safety requirements are driven by the presence of certain hazards.



If you've got a noise hazard somebody's hearing might be affected, then regulations in multiple countries are going to require you to do certain things to monitor the noise. Let's say or monitor the effect that it's having on workers and put in place a program to handle that. The presence of certain hazards will drive certain requirements for safety controls or risk controls.



Then there are the broader requirements. Analysis of what does the law require, what the regulations require, codes of practise, etc. We'll get onto that, and one of the things that requirements analysis is going to do is give us an initial stab of what we've got to have – certain controls because we’re required to. That's a little bit of an aside in terms of the sequence, but it's very, very important.



Thirdly, and, fourthly, once we've discovered some hazards, we're going to need to understand what might cause those hazards and therefore how likely is the hazard to exist in particular circumstances, and then also think about the consequences that might arise from a hazard. And once we've explored those, we will be in a position to actually capture the risk.



 Because we will have some view on likelihood. And we would also have some view on the severity of consequences from considering the consequences. We'll come onto that later.



Finally, having done all those other things, we will be in a position to take a much more systematic look at controls and say, we've got these causes. We've got these hazards. We've got these potential consequences.  What do I need to do to control this risk and prevent this accident sequence from playing out?



What I need to put in place to interrupt the accident sequence, and I've put the controls. The dashed lines indicate that we've got barriers to that accident sequence, and they are dashed because no control is perfect. (Other than gravity. But of course, if you turn your vehicle upside down, then gravity is working against you, so even gravity isn't foolproof.)



No control is 100% effective



We need to just accept that and deal with that and understand. There is your overview of the sequence, and I've spent a bit of time talking about that because it is absolutely fundamental to everything you're going to do.



But let's move on and start to look at some of these individual types of techniques.



Which Safety Techniques do You Use? Leave a Comment below...

#howtouseariskassessment #safetyassessmentofaircraftsystems #safetyassessmentreportdid #safetyassessmentvsriskassessment #safetycaseassessmentguide #safetyreportassessmentmanual #safetyriskassessmentandmanagementplan #signsofsafetyassessmenttool #whatisahealthandsafetyassessment

Simon Di Nucci https://www.safetyartisan.com/2022/03/23/safety-assessment-techniques-overview/

The Safety Artisan is on Thinkific

I'm pleased to tell you that The Safety Artisan is on Thinkific!



Thinkific is a powerful and beautifully-presented online Learning Management System.  This will complement the existing Safety Artisan website.  My first course will be 'System Safety Assessment' with ten hours of instructional videos. The new course is here.



(Please note that this is the same course as my 'Complete System Safety Analysis Bundle' of 12 videos available here.  So, if you've already bought that - thanks very much - please don't buy it again, as you already have all the material.)



https://youtu.be/w3LvPFXAaFw

What will the System Safety Assessment Course do for you?



Transcript of the Video



Read the Transcript Here:

Welcome to the System Safety Assessment course



In this course, you will gain knowledge, skills, and confidence.  You will gain knowledge of what is involved in system safety assessment.  The individual tasks and techniques you need to carry out.



But more importantly, how to put them together into a successful program and how to tailor all these different tasks keeping some, but leaving out others so that you get an efficient and effective safety program, no matter what application or what system you are working with.



So that's the knowledge and the skills



You'll also get the confidence to be able to get you started.  Now, there is no substitute for live face-to-face training and coaching.  But this format is much more accessible to you and much more reasonably priced.  So wherever you are in the world, whatever time and day you want to do your learning, you can access this course and you can gain confidence to get you started.



So if you're worried about a job interview, what you're going to say or you're worried about how to do a job and there's nobody around to help you.  Then this course will give you the confidence to get started and to be aware of the pitfalls before you begin.



So what makes me confident that I can help you?



Well, first of all, I've got 25 years of experience applying system safety.



And I've done that in the UK, in the United States, in Australia, and in the European Union.  I've seen a wide variety of legal jurisdictions that I've worked in.  Also, I've worked on a wide variety of systems.  I've worked on planes, trains, ships and submarines, software, and I.T. systems all kinds of stuff.



I've worked on some gigantic multibillion-dollar projects and some much smaller ones.  So I know how to pragmatically apply this stuff, at a reasonable scale without spending stupid amounts of money.



And in fact, as part of my job as a consultant, I spent half the time telling clients to do less and spend less and still get an effective result.  So that's where I'm coming from.



I've also got experience teaching system safety in the classroom.  I've taught hundreds of students, from various different projects.  And now I have hundreds of online students, and I'm very pleased to be able to help all of those as well.



So that's why I think that I can help you



And I hope that you will enjoy this course and get a lot out of it.  Thanks very much for considering The Safety Artisan.



What do you think of the new page?

#riskassessment #riskassessmentdefinition #riskassessmentexample #riskassessmentframework #riskassessmentinsafety #riskassessmentmatrix #riskassessmentmethodology #riskassessmentprocess #riskassessmentreport #riskassessmentsteps #safetyassessment #stepstoriskassessment

Simon Di Nucci https://www.safetyartisan.com/2022/02/23/the-safety-artisan-on-thinkific/

The Risk Matrix

In this article, I look at The Risk Matrix, a widely used technique in many industries. Risk Matrices have many applications!



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.



Introduction



A risk matrix is a graphical representation of the various risks associated with a project and its corresponding risk management strategies. It helps to identify and prioritize potential risks.



What is a Risk Matrix?



A safety risk matrix provides a framework for ranking or classifying safety issues according to their significance. The matrix is sometimes called a “hazard ranking matrix” or a “hazard classification matrix”, but it is strictly applied to accidents, since these have harmful outcomes, whereas hazards only have the potential for harm. The matrix can be used as a risk screening tool to help decide which issues need treatment first or which need not be considered further at this time.



Risk matrices can cover exposure to different types of loss, including harm to humans, damage to the environment, financial loss or impact on reputation. If a loss in these diverse categories can be considered in common terms (e.g. the monetary impact of all types of loss), then a single matrix can cover all such issues together and prioritize which are the most significant.



The matrix covers a “risk space” defined by the two component parts of risk, namely likelihood on one axis and consequence (or severity) on the other. Each axis must span the full range of outcomes, which are considered possible for the system of interest. Each range is divided into a number of categories or bands (typically between 3 and 8) to define the cells of the matrix.



The bands on the two axes may be defined in terms that are purely qualitative, semi-quantitative, or fully quantitative, for example:



- Qualitative:- Likelihood is (Frequent/Reasonably Probable/Remote/Extremely Remote)

- Severity is (Minor/Significant/Severe/Catastrophic)

- Semi-quantitative:- Likelihood is (e.g. likely to occur once per year on one site)

- Severity is (e.g. a single death)

- Quantitative:- Likelihood is (e.g. between 1x10-4 and 1x10-5 per year on one site)

- Severity is (e.g. between 1.0 and 10.0 Fatalities and Weighted Injuries)



Each cell of the matrix is assigned an indicator defining the relative significance of issues falling in that zone. This indicator could be:



- A risk descriptor (e.g. Low, Moderate, High, Very High)

- A risk score or index (e.g. a number from 1 to 20)

- A priority category (e.g. High, Medium or Low)

- A risk class (e.g. A, B, C or D)

- A measure of expected rate of harm or loss (e.g. 5.4 Fatalities and Weighted Injuries per year or £45,000 per year)



Where likelihood and consequence are stated quantitatively, the axes are usually considered to have logarithmic scales. Adjacent bands will typically differ by one order of magnitude. In this case, lines of constant risk run diagonally across the matrix and the risk will range by a factor of 100 across the area covered by a single cell. This illustrates that the matrix is a coarse tool, which can show large differences in risk, but does not address fine detail, such as compliance with quantitative risk requirements.



To apply the matrix, users must have a list of the relevant safety issues (from Hazard Identification and Hazard Analysis) and estimates of the likelihood and severity of each possible accident (from Risk Estimation). The matrix is therefore a technique for Risk Evaluation, which follows on from Risk Estimation. The estimates of accident likelihood and severity may be generated by different methods, depending on the stage of the project, the information available and the significance of the safety issue being explored. For example, the estimates may come from:



- Engineering judgement by Subject Matter Experts with knowledge of similar systems

- Historical data from this or similar systems

- Detailed modelling (e.g. using Fault Tree Analysis and Event Tree Analysis or Bow-Tie Analysis)



Examples of Risk Matrices



The following example matrices show some of the variations in format, terminology and risk indicators across a range of sectors and standards.



Example 1: IEC 31010 Example risk ranking matrix. Severity on x-axis increasing left to right, likelihood on y-axis increasing bottom to top, with five “risk levels” which are linked to decision rules such as the level of management attention or the time scale by which response is needed.



IEC 31010 Risk Matrix



Example 2: Def Stan 00-56 Issue 2 Example accident risk classification table. Severity on x-axis increasing right to left, likelihood on y-axis increasing bottom to top, four risk classes identify significance and so management level for approval.



 CatastrophicCriticalMarginalNegligibleFrequentAAABProbableAABCOccasionalABCCRemoteBCCDImprobableCCDDIncredibleCDDDDef Stan 00-56 Issue 2 Example Accident Risk Classification Table



Example 3: IMO Guidelines on FSA. Example hazard risk index matrix. Severity on x-axis increasing left to right, likelihood on y-axis increasing bottom to top, risk index (RI) in each cell calculated by adding Severity Index (SI) for column and Frequency Index (FI) for a row. RI can be considered as log(risk), obtained by adding FI and SI.



FIFrequencySeverity (SI)1234MinorModerateSeriousCatastrophic7Frequent8910116 789105Reasonably probable67894 56783Remote45672 34561Extremely remote2345IMO Guideline on FSA: Risk Ranking Matrix



Example 4: ISO 17776 Offshore Sector Example risk matrix. Severity on y-axis increasing top to bottom, likelihood on x-axis increasing right to left to top, matrix areas define future action to be taken.



ISO 17776 Risk Matrix



Risk Matrix Assessment



When it Might be Used



The matrix is usually set up at an early stage of the lifecycle, defining the framework to be used for risk evaluation at subsequent stages. It should be used early in the lifecycle to provide a coarse sift of the identified safety issues so that attention can be focused on the most significant ones. This attention may involve more detailed analysis to understand complex accident sequences and to apply semi-quantitative or fully quantitative risk assessment techniques where appropriate.



Later in the lifecycle, the risk matrix may be used for determining the appropriate management level for review and acceptance of each safety issue. This ensures that the key risk drivers are brought to the attention of senior managers but they are not swamped with masses of information on less significant matters.



During the in-service stage of the lifecycle, the risk matrix technique can be applied to give an indication of significance for new safety concerns, such as those revealed by incidents or due to proposed design changes. Risk monitoring can be focused on the issues of highest significance as well as targeting resources for risk reduction.



Advantages & Disadvantages



Advantages



- Risk matrices provide a quick appreciation of the most significant issues so that attention can be focused where it will have most benefit.

- Matrices provide a visual representation which is easily understood and so aids communication with non-specialists.

- Risk matrices can cover impacts which are different in nature (e.g. harm to people, harm to the environment, material or financial loss), provided that these can be equated in common units (e.g. in money terms).



Disadvantages



- Risk matrices are good for examining different issues affecting one system or activity on the basis of their risk relative to each other. They are not effective for understanding absolute risk.

- There is no single, correct interpretation of the level at which “safety issues” should be selected for presentation on the risk matrix. This means that different analysts may choose different levels and the resulting list of prioritised issues is somewhat subjective. The apparent results may be changed by “accident splitting” (i.e. defining one safety issue as two or more different accidents, each of which will appear to have lower risk).

- Risk matrices consider safety issues one at a time and so do not help understanding the overall or aggregate risk exposure.

- When a variety of different outcomes is possible from a single issue (e.g. fire – consequences can range from no harm to multiple deaths) it can be difficult to choose which likelihood and consequence combination should be used.

- As a broad-brush technique, risk matrices should not be used for considering whether quantitative risk targets have been met or as the only technique for examining complex or high consequence issues. The matrix can, however, highlight high consequence issues so that they then receive more detailed consideration.



Risk Matrices for Project Management



In project management, we are aiming for specific outcomes, often represented as the project management triangle.



Project Management Triangle



In the center is quality (and/or safety), which is central to indicate that this cannot be compromised.  The three corners are cost, time, and scope (or requirements), and these can be traded off against each other.



This representation helps us to identify project risks by the effect that they might have on the project’s objectives.  ISO 31000 defines risk as “the effect of uncertainty on objectives”.  Again, the risk matrix allows us to identify and rank risks, identifying the biggest, most critical risks.  These risks are where we will focus most attention, looking for multiple controls, or defense-in-depth, for the most serious ones.   



An old saying is that “you can have a quick job, a proper job, or a cheap job; you can have two out of three, but you can’t have all three.”  Taken literally this is a little pessimistic, but it does remind us that if we set an absolute target on one of these axes, then we will likely have to trade the other two off against each other.   



This axiom also gives us some basic principles on which to identify controls.  We might desire controls that allow us to achieve all objectives at the same time, but this is often unrealistic.  Practical experience – encoded in a saying – suggests that we must be prepared to accept some trades in budget/schedule/scope.



Thus the risk matrix, in combination with some basic project management principles, enables more realistic decision-making.  (Real decisions involve saying ‘no’ to some things in order to say ’yes’ to others.)  Rather than naively thinking that we can have it all, the risk matrix supports robust early decision-making. 



This should make project success more likely – until somebody changes the objectives!



Additional Considerations



It should be noted that risk matrices from different standards and industry sectors are not always represented in the same way. The most common convention has a Cartesian representation (i.e. values increasing left to right and bottom to top on the two axes) so that risk increases from bottom left to top right, but the examples below show that several common matrices have a different format.



If risk estimates are generated by a team of Subject Matter Experts, their deliberations can be biased (consciously or unconsciously) if they know the risk matrix framework. There may be a tendency to choose likelihood and/or severity estimates that result in a lower apparent risk so that it attracts less management scrutiny.



Uncertainty of the estimates of severity and likelihood can be represented on a risk matrix by showing that risk with error bars rather than a single point. This can help understanding by senior managers.



Using common matrices for different systems does not necessarily result in risk estimates that can be compared in a meaningful way. The systems may have diverse risk exposure factors (e.g. number of people exposed, usage rate) and different numbers and types of accidents to consider.



(For more on risk management, see the FAQ.)



Do You Use a Risk Matrix in Your Work?

#3x3riskmatrixtemplateexcel #examplesofriskmatrix #howtocreateriskmatrix #riskmatrix3x3 #riskmatrix5x5 #riskmatrixapproach #riskmatrixbenefits #riskmatrixdesign #riskmatrixguide #riskmatrixhealthandsafety #riskmatrixhighmediumlow #riskmatriximage #riskmatrixinsafety #riskmatrixlowmediumhigh #riskmatrixmethod #riskmatrixmethodology #riskmatrixpowerpointtemplate #riskmatrixproject #riskmatrixrating #riskmatrixword #riskmatrices #riskmatrix #riskmatrixassessment #riskmatrixforprojectmanagement #riskmatrixinprojectmanagement #whatisariskmanagementmatrix

Simon Di Nucci https://www.safetyartisan.com/2022/01/26/the-risk-matrix/