SMP02. Safety Committee

Printer-friendly versionPrinter-friendly versionPDF versionPDF version
System Revision ID ASEMS Document Version Effective From State
4995 5.1 06/03/2024 - 12:30 Extant

2.1. Introduction

2.1.1. Definitions

2.1.1.1.

A Safety Committee is defined in Def Stan 00-056 as:

“A group of stakeholders that exercises, oversees, reviews and endorses safety management and safety engineering activities.”

2.1.2. Objectives

2.1.2.1.

The key elements for the effective management and delivery of safety are co-ordination, agreement and proper response by those authorities with responsibilities for the Products, Systems, or Services (PSS). 

2.1.2.2.

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

  1. Provides a forum through which all those with safety responsibilities can ensure effective co-ordination on safety issues;
  2. Provides access for decision makers to all those with relevant knowledge;
  3. Provides competent oversight of the Safety Case during its development and upkeep;
  4. Promotes the recognition of diverse perspectives amongst stakeholders including but not limited to those derived from dissenting views, analyses, or challenges to the Safety argument during Safety discussions/deliberations (following an implementation of an AJAX recommendation); 
  5. Provides, through records of its meetings, an audit trail showing that suitable advice has been sought and that safety management decisions were well founded.

2.1.2.3.

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

2.1.2.4.

Although contractors will be members of the MOD 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. MOD 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 MOD and Contractor Safety Committees, then they must each have clear Terms of Reference and their inter-relationship must be well defined.

2.2. Procedure

2.2.1. Membership

2.2.1.1.

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

  1. The Delivery Team (including the Project Safety Manager, and other technical, equipment, integrated logistics, contracts and finance officers as required);
  2. Customer representatives (Capability or Equipment Customer);
  3. User representatives (Equipment User);
  4. Trials team;
  5. Maintenance specialists;
  6. Training Authorities;
  7. Prime contractor;
  8. Design organisation;
  9. Independent Safety Auditor (if appointed);
  10. Specialist advisors (e.g., from MOD, certification authority or industry safety consultants);
  11. Defence Safety Authority.
  12. DE&S Quality, Safety, and Environmental Protection Group

2.2.1.2.

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

2.2.1.3.

More information on PSC membership has been provided at Annex A - example Terms of Reference for a PSC. Further advice is available from QSEP.

2.2.2. Chair

2.2.2.1.

The Committee(s) should be chaired by the safety-competent individual holding formally-delegated responsibility for safety within the Project.  The Letter of Delegation will detail the scope of the delegation-holder's responsibility, which is supported by the associated assignment specification, and authority to carry out the safety management tasks on that programme.

2.2.3. Quorum

2.2.3.1.

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 authorised members should be in attendance:

  • Delivery Team safety delegation holder
  • Project Safety Manager
  • Design organisation
  • Customer representative (Capability or Equipment Customer)
  • Safety Case Report author

2.2.3.2.

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.

2.2.3.3.

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 agreement has been received from the quorum ex-committee. 

2.2.4. Meeting Frequency and Mechanisms

2.2.4.1.

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 and properly allocated, and a record is kept of proceedings. A PSC can either be established for a single PSS, or a family of variants of a PSS.

2.2.4.2.

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

2.2.5. Working Level Support

2.2.5.1.

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 PSS. Integrity working groups could consider structure, propulsion or other electrical or mechanical systems, reporting significant issues to the PSC.

2.2.6. Safety Management Committee

2.2.6.1.

Where a number of similar PSS 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 the safety management policy and strategy for those projects. The strategy would detail the formation of PSCs for individual PSS, or groups of similar PSS (e.g., radio systems, or support vehicles rather than a type of radio or vehicle).

2.2.6.2.

The SMC will monitor and control the activities of the individual PSCs, which will operate to their own SMP's. Structures can be tailored to suit individual circumstances. Terms of Reference, including membership, for a 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 a 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

2.2.6.3.

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 organisation of the programme. The emphasis should be on establishing a Safety Committee with a suitable chair of the PSC and Terms of Reference.

2.2.7. Project Safety Committee Authority and Competence

2.2.7.1.

The chair of the PSC should hold a Letter of Delegation and supporting assignment specification which details the authority for carrying out the safety management tasks on that programme.

2.2.7.2.

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.

2.2.7.3.

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

2.2.7.4.

As a minimum, the Project Safety Manager should have system safety competence to practitioner level.  Competence requirements for the safety delegation holder will be defined in a relevant Assignment Specification.

2.2.7.5.

Where it is considered beneficial, a combined committee may be established for the safety and environmental management activities. It should be ensured that the programmes are aligned as far as possible and that data is shared where relevant.

2.2.7.6.

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

2.2.7.7.

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.

2.2.7.8.

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.

2.2.7.9.

The Ordnance Safety Review Panel (OSRP), Release To Service and Naval Authority Certification procedures are activities that are carried out independent of the PSC. The PSC may include updates from such assurance activities.

2.2.8. Records and Project Documentation

2.2.8.1.

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

  1. Those present;
  2. The discussions (including challenges to the safety argument raised and the PSC's response);
  3. Specialist advice (including guidance/recommendations from industry and/or Independent Specialist Advisors);
  4. Decisions made;
  5. Recommendations to those with delegated authority for safety management;
  6. Actions agreed.

2.2.8.2.

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

  1. System Requirements Document – for any specific safety requirements;
  2. Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Outline Business Case and Full Business Case submissions.
2.2.9. Review and Agreement of Safety Documents

2.2.9.1.

The role of the PSC includes reviewing safety documents and advising the safety delegation holder on their suitability. Agreement that the document is suitable can be signified in various ways and the assigned individual holding formally-delegated responsibility should define which is required. Methods for recording the review and its findings could include:

  1. Formal sign off of the document by all members of the PSC;
  2. A recommendation, recorded in PSC minutes, that the document is satisfactory and can be authorised for release by the agreed signatory.
2.2.10. Warnings and Potential Project Risks

2.2.10.1.

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.

2.2.10.2.

If the PSC do 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.

2.2.10.3.

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

2.2.10.4.

If the PSC do not meet with sufficient frequency, then they may not identify in a timely manner, any issues with the safety programme. This could result in impacts on project time and cost.

2.2.10.5.

If the PSC attempts to control the detail design solutions, rather than relying on the contractor’s Safety Committee and design function, then MOD will take responsibility from the designer. MOD staff will be represented on the contractor’s Safety Committee and shall exercise influence at that forum and through setting appropriate requirements.

2.2.10.6.

If the PSC does not adequately consider diverse perspectives amongst stakeholders, then they may not identify issues within the safety programme. Furthermore, if the PSC’s discussions, including challenges to the Safety argument raised and the PSC’s response, are not adequately recorded, then there would be no clear audit trail to support the Safety decisions made.

2.2.11. Procedure Completion

2.2.11.1.

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

2.3. Timing

2.3.1. Formation

2.3.1.1.

The PSC should be established during the earliest stage (following the reorganisation, this will be the gateway) of a project by the Customer, or Requirements Manager, through the Capability Working Group, in conjunction with the relevant assigned individual holding formally-delegated responsibility, to set out the safety requirements for the PSS.

2.3.2. Meetings

2.3.2.1.

The required frequency of the PSC meetings depends on various factors including the stage of the project, the complexity of the PSS 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.

2.3.2.2.

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 PSS or its usage is changing, and seeking counter-evidence that shows the predicted level of safety performance is not being achieved in practice.

2.4. Required Inputs

2.4.0.1.

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

  1. Outputs from procedure SMP01 – Safety Initiation;
  2. Documents to be reviewed such as:
    1. Project Safety Management Plan;
    2. Independent Safety Auditor Audit Plan (if appointed);
    3. Independent Safety Auditor Audit Report (if appointed);
    4. Other Safety Audit Plans (e.g., self or Peer audit);
    5. Safety Audit Report;
    6. Hazard Log Report;
    7. Safety Requirements;
    8. Safety Assessment Report;
    9. Safety Case Report.
  3. Acquisition System Guidance Functional Competencies for System Safety Management (SYSSAF 1);
  4. Records of previous meetings of the Safety Committee.

2.5. Required Outputs

2.5.0.1.

The outputs of the procedure will comprise:

  1. Established Safety Committee membership;
  2. Defined Terms of Reference for the Safety Committee (see Further Guidance – Examples Terms of Reference for Project Safety Committee);
  3. Records of Safety Committee meetings, including advice given and actions agreed as per 2.2.8. Records and Project Documentation;
  4. 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 authorised by the assigned individual holding formally-delegated responsibility. If authorisation is not recommended, then the reasons should be recorded.

2.6. Annex A

2.6.1. Example Terms of Reference for Project Safety Committee

2.6.1.1.

Terms of Reference for – Project XXX

2.6.1.2.

Purpose:

To provide a forum for monitoring and co-ordinating 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 assigned individual holding formally-delegated responsibility or in a larger Delivery Team to the Safety Management Committee.

2.6.1.3.

Tasks:

  1. To set and keep under review the project’s safety policy and strategy;
  2. To set and keep under review the project’s safety targets and objectives;
  3. To define the system boundaries for safety responsibility;
  4. To advise the Chair of the Safety Committee on the safety responsibilities for each authority associated with the project;
  5. To advise the Chair of the Safety Committee on the standards, statutory regulations and any restrictions with which the projects should comply;
  6. To review, monitor, classify and allocate new PSS hazards as they are identified;
  7. To carry out reviews of the project’s Safety Case and progress on achieving safety targets, to a predetermined programme, issuing the results to the assigned individual holding formally-delegated responsibility;
  8. To agree any control measures that are deemed necessary to reduce identified risks to ALARP;
  9. To ensure proper and timely availability of training and issue of documentation;
  10. To carry out actions from ISA, regulatory or internal audit findings;
  11. To operate a system for reviewing and monitoring safety performance and maintain the Safety Case.

2.6.1.4.

Membership:

  1. Delivery Team responsible for the procurement aspects of the project;
  2. Customer representative (Capability or Equipment Customer);
  3. Safety Manager;
  4. Design organisation;
  5. Delivery Team responsible for the support aspects of the project;
  6. Equipment User;
  7. Training Authority;
  8. Maintainer;
  9. Maintenance Authority;
  10. Specialist Advisors (as required):
    1. Defence Safety Regulators;
    2. Weapons Engineering and Safety Centre of Expertise;
    3. Weapon Technical Services;
    4. Land Accident Prevention and Investigation Team;
    5. Military Aviation Accident Investigation Team;
    6. Serious Equipment Failure Investigation Team;
    7. Independent Safety Auditor;
    8. Interfacing Delivery Teams;
    9. Technical Specialists (such as Fire SQEP).

2.7. Version Control

2.7.0.1.

Version 5.0 to 5.1 Uplift

Update to add Fire SQEP to Annex A as an example member.

Version 4.3 to 5.0 Uplift

  • New wording at Para 2.1.2.2. (d) to capture diverse perspectives amongst stakeholders including but not limited to those derived from dissenting views, analyses, or challenges during Safety discussions/deliberations.
  • New wording at Para 2.2.8.1. (b)-(c) to include the recording of any specialist advice and challenges to safety arguments, including the PSC’s response.
  • New wording at Para 2.2.10.6.  to highlight potential project risks if the PSC does not adequately consider and record diverse perspectives amongst stakeholders during Safety discussions/deliberations.
  • Replaced ‘Team Leader’ with ‘assigned individual holding formally-delegation responsibility’.
  • Minor amendments to text within the SMP (e.g., typos, grammar, etc.).

 

Version 4.2 to 4.3 Uplift

Minor amendment to replace reference to Initial Gate and Main Gate and change these to Strategic Outline case, Outline Business Case and Full Business Case. This change brings terminology in line with JSP 655.

 

Version 4.1 to 4.2 Uplift

Text change replacing Project Team with Delivery Team.

 

Version 4.0 to 4.1 Uplift

Minor text changes to align with ASP taxonomy.

 

Version 3.1 to 4.0 Uplift

Major reorganisation of all SMPs:

  • Restructure into a consistent format.
  • Responsibilities, Alignment with Environment and guidance for different acquisition strategies have been removed and included in the POSMS summary.
  • All further guidance has been placed into the Procedure section, and duplicated text has been removed
  • Annex A has been created for the PSC Terms of Reference template.

 

Version 3.0 to 3.1 Uplift

Minor changes implemented, including clarity of Safety Committee structures. A minor uplift to correct spelling, grammar, and to remove some duplication of text

 

Version 2.3 to 3.0 Uplift

Major uplift from the Acquisition System Guidance (ASG) to online version. 

More like this

Subject to Policy Clauses

2.2

Communication

Operating Centres, Delivery Teams or equivalents shall ensure that communication procedures are implemented that provide an effective flow of safety and environmental information upwards, downwards and across their organisation.

3.3

Stakeholder Agreements

Agreements between Stakeholders shall define and document system safety and environmental responsibilities.

3.6

Accountability

Individuals deployed to assignments which require the formal delegation of safety and environmental responsibilities, accountability and authority shall be mapped against, and comply with the requirements of, the DE&S Acquisition Safety Taxonomy (S&EP Leaflet 17/2023) and DE&S Acquisition Environmental Taxonomy (S&EP Leaflet 18/2023).

3.7

Monitoring

Operating Centres, Delivery Teams or equivalents shall establish, implement and maintain a suitable and sufficient procedure to monitor and measure safety and environmental performance of their safety and environmental management system on a regular basis.

3.8

Audit Frequency

Compliance with the documented safety and environmental management system shall be verified via audit at planned intervals according to a published schedule, and as required.

3.9

Internal Audit

At planned intervals commensurate with the risk: i) Operating Centres shall audit their Delivery Teams, or equivalents, safety and environmental management systems. ii) Delivery Teams or equivalents shall audit the safety and environmental management systems of their projects. iii) The DE&S Quality, Safety and Environmental Protection Team or their representative, shall audit the safety and environmental management systems of Operating Centres and Delivery Teams.

3.10

Review

Operating Centres, Delivery Teams or equivalents shall review their safety and environmental management systems, at planned intervals commensurate with the risk, to ensure their continuing suitability, adequacy and effectiveness.

4.1

Safety Cases

Delivery Teams (DTs) or equivalents shall establish and maintain through-life safety cases that provide a compelling, comprehensible, and valid argument that a Product, System, or Service is safe for a given application in a given operating environment. For Platforms and Large Complex Systems, DTs shall utilise the Safety Case Maturity Tool to assess the breadth and appropriate coverage of the produced safety case report and submit findings to QSEP for inclusion in the Safety Case Maturity Dashboard.

4.7

Safety and Environmental Objectives and Targets

Operating Centres, Delivery Teams or equivalents shall establish and maintain relevant safety and environmental objectives with a resourced programme to achieve targets.

4.8

Accident and Incident Records

Operating Centres, Delivery Teams or equivalent shall monitor and record accidents, incidents and near misses where the performance of their Product, Systems or Services results in harm to individuals or damage to the environment and use this information to keep their risk assessments valid.

4.9

Assessment Approval

Safety and/or environmental case reports shall be personally approved by the individual with formally delegated authority to confirm their acceptance with the progress of the safety and/or environmental case/assessment and of the risks and impacts associated with the project.

4.10

Independent Assurance

Independent review of the Safety and Environmental Management System shall be ensured, as appropriate and commensurate to the risk, by the individual with formally delegated authority for safety and environmental protection. Information/findings arising from independent assurance shall be stored on the BMS/SharePoint as appropriate.

5.1

Risk and Impact Assessment

All foreseeable Safety Risks and Environmental impacts shall be identified, assessed, prioritised and managed.

5.4

Consultation

Operating Centres, Delivery Teams or equivalent shall ensure that all stakeholders are identified and consulted so that their views and responsibilities are considered when managing safety risks and the delivery of sound environmental performance.

5.9

Specialist Advice

Delivery Teams or equivalents shall ensure all specialist advice (including guidance/recommendations from industry and/or Independent Specialist Advisors) is documented and formally reviewed by the appropriate Safety and/or Environmental committees. Additionally, the Executive Safety Responsible and/or Executive Environmental Responsible is to ensure that the Senior Responsible Owner is informed if any appropriate independent advice/guidance is not followed. This clause applies to both safety and environmental specialist advice.

6.2

Suitably Qualified and Experienced Personnel

Operating Centres, Delivery Teams or equivalents shall ensure that those engaged in safety and environmental protection are suitably qualified and experienced to discharge their safety and environmental responsibilities.

6.3

Competence

The competence of all staff with system safety and environmental responsibilities shall be regularly assessed, monitored and recorded. Staff with formally delegated system safety and environmental responsibilities shall demonstrate their competence to receive the delegation prior to deployment, and their competence shall be regularly monitored and recorded.

Process Maps

SMP C1
Concept Phase Activities

Click here to view

Covered by Audit Question Sets

2.2

Audit Question Set Section 2.2 Communication

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 2.2.

3.3

Audit Question Set Section 3.3 Stakeholder Agreements

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.3.

3.6

Audit Question Set Section 3.6 Accountability

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.6.

3.7

Audit Question Set Section 3.7 Monitoring

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.7.

3.8

Audit Question Set Section 3.8 Audit Frequency

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.8.

3.9

Audit Question Set Section 3.9 Internal Audit

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.9.

3.10

Audit Question Set Section 3.10 Review

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.10.

4.1

Audit Question Set Section 4.1 Safety Cases

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.1.

4.7

Audit Question Set Section 4.7 Safety and Environmental Objectives and Targets

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.7.

4.8

Audit Question Set Section 4.8 Accident and Incident Records

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.8.

4.9

Audit Question Set Section 4.9 Assessment Approval

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.9.

4.10

Audit Question Set Section 4.10 Independent Assurance

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.10

5.1

Audit Question Set Section 5.1 Risk and Impact Assessment

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 5.1.

5.4

Audit Question Set Section 5.4 Consultation

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 5.4.

5.9

Audit Question Set Section 5.9 Specialist Advice

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 5.9.

6.2

Audit Question Set Section 6.2 Competence

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 6.1

6.3

Audit Question Set Section 6.3 Competence

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 6.4.