SMP01. Project Safety Initiation

System Revision ID ASEMS Document Version Effective From State
3695 3.1 09/01/2017 - 01:15 Extant

1.1. Overview

1.1.0.1.

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 organisation for the project.

1.1.0.2.

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 Main Gate approval), to review and update the project safety arrangements and ensure that they continue to be appropriate.

1.1.0.3.

This procedure assumes that the Team Leader (TL) has already been appointed and has been assessed as having appropriate competence in safety management to receive safety delegation defining his responsibilities for safety.

1.2. Procedure

1.2.1. Objectives

1.2.1.1.

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:

  1. Stakeholders (including industry);
  2. Regulators and Approval Authorities;
  3. Project Safety Manager;
  4. Independent Safety Auditor if appropriate;
  5. Project Safety Committee;
  6. Project Safety Responsible, Accountable, Consulted, Informed (RACI) Chart;
  7. Lead Functional Safety Management Office (FSMO).
1.2.2. Questionnaire

1.2.2.1.

The questionnaire contained in Form SMP01/F/02 - Register of Stakeholder Requirements and Information, should be completed and future help co-ordinated across the safety community.

1.2.3. Stakeholder Identification

1.2.3.1.

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:

  1. Have safety responsibilities at any stage of the project;
  2. Have safety requirements (including information) from the project;
  3. Hold safety information relevant to the project (e.g. other Delivery Teams with interfacing or sub-systems);
  4. Have specialist or operational knowledge that can aid the project in achieving safety requirements.

1.2.3.2.

As a minimum the following will be consulted:

  1. Equipment Capability Customer;
  2. Equipment User;
  3. Director Technical;
  4. Safety & Environmental Protection Group;
  5. Other Delivery Teams involved in any sub-systems of the project;
  6. Other Delivery Teams involved with systems, projects or systems platforms with which the system/project will be closely associated;
  7. Subject Matter Experts with specialist technical or professional expertise in a subject area relevant to the Project;
  8. Relevant Safety Management Offices (via Questionnaire Form SMP01/F/01 - Safety Operating Environment Questionnaire).

1.2.3.3.

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.

1.2.4. Identify Applicable Legislation, Standards and Requirements

1.2.4.1.

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.

1.2.4.2.

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 in the safety requirements (see procedure SMP10 – Safety Requirements and Contracts).

1.2.4.3.

Useful information sources include:

  1. Other equipment safety Joint Service Publications;
  2. Other relevant legislation and standards for non-UK operations.
1.2.5. Create Project Safety Organisation

1.2.5.1.

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

  1. Appoint competent Project Safety Manager (PSM);
  2. Appoint Independent Safety Auditor (ISA), if required;
  3. Form Project Safety Committee (PSC) (membership and role defined in Procedure SMP02 – Safety Committee);
  4. 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.

1.3. Responsibilities

1.3.1. Accountability

1.3.1.1.

The Team Leader is accountable for the completion of this procedure.

1.3.2. Procedure Management

1.3.2.1.

Team Leaders may delegate the management of this procedure to a SQEP member or members of the Delivery Team (DT).

1.3.3. Procedure Completion

1.3.3.1.

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

1.3.3.2.

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

1.3.3.3.

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.

1.3.3.4.

QSEP will assist TL's in identifying those acquisition programmes that have potential safety implications.

1.4. When

1.4.1. Initial Application

1.4.1.1.

In an acquisition programme, 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.

1.4.1.2.

The procedure can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process.

1.4.2. Review

1.4.2.1.

The registers of stakeholders and requirements should be reviewed and updated after Initial and Main Gate as part of the review and update of the SMP.

1.5. Required Inputs

1.5.0.1.

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

  1. User Requirements Documentation (for Acquisition Programmes);
  2. Any other information on the proposed functionality, use, support and context of the proposed system;
  3. Existing Hazard Logs for existing similar systems;
  4. Relevant MOD Publications.

1.6. Required Outputs

1.6.0.1.

The Outputs of the procedure will comprise:

  1. Appointed PSM and ISA, if appropriate;
  2. Completed Form SMP01/F/01 - Safety Operating Environment Questionnaire;
  3. Completed Form SMP01/F/02 - Register of Stakeholder Requirements and Information, which should be reviewed and updated as the project proceeds;
  4. Completed Form SMP01/F/03 - Register of Safety Legislation and Other Significant Requirements, which should be reviewed and updated as the project proceeds.

1.6.0.2.

The Delivery Team should consider addressing legislation and similar issues amongst standardisation issues especially when producing and reviewing the standardisation 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, SSIP Annex E, and project Safety Initiation documents SMP01/F/03 with changes in legislation and international agreements.

1.6.1. Records and Project Documentation

1.6.1.1.

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 Initial Gate submissions.

1.6.1.2.

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.

1.7. Further Guidance

1.7.0.1.

Although this is written as a safety procedure, it is recognised 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 recognised 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.

1.7.1. Stakeholder Identification

1.7.1.1.

Initially, stakeholders identified and consulted at this stage will be restricted to MOD. However, any relevant external stakeholders identified e.g. other government departments, industry, research organisation, 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 Team Leader may choose to include external stakeholders at this stage.

1.7.1.2.

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.

1.7.2. Identify Applicable Legislation, Standards and Requirements

1.7.2.1.

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. PSMs will identify and maintain a register of applicable legislation as part of the development of the Safety Case, and to continuously review it and revise it as necessary.

1.7.2.2.

Within the MOD, each project’s Legislative Register should be taken to include matters of Government or European Union policy, especially where these bind all UK Government departments, including MOD. Recourse to law by European institutions is increasingly possible for non-compliance with European policy for public procurement.

1.7.3. Compliance

1.7.3.1.

The organisation uses a number of methods of enabling compliance:

  1. Delivery Teams develop System Requirements Documents to meet User Requirements Document statements from the Equipment Capability Customer. This is an important method for advising industry of the MOD’s safety and environmental requirements;
  2. 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);
  3. Use of DEFCONs and DEFFORMs in the development of contracts and contract conditions.

1.7.3.2.

Where the Delivery Team also develops the User Requirements Document on behalf of the Equipment Capability Customer, it is extremely important that these reflect the DE&S safety and environmental performance objectives and targets, recognising and emphasising any politically or publicly sensitive issues. The advice of organisational Subject Matter Experts in Safety, Sustainable Development & Continuity must be sought in the construction of the User Requirements Document.

1.7.3.3.

Although reference to DEFCONs and DEFFORMs provides MOD 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 that result from the User Requirements Document and System Requirements Document and the project’s Safety Management Plan.

1.7.3.4.

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

a. Legislative Registers held by the Programme Teams;

b. Defence Regulator intranet pages, DE&S’s Safety net etc;

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

d. Suppliers, contractors and consultants;

e. Other projects and Delivery Teams.

1.7.3.5.

Identification of and compliance with all relevant safety and environmental legalisation will always ultimately be the responsibility of the Team Leader with delegated authority.

1.7.3.6.

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.

1.7.3.7.

MOD maintains a list of approved specialist contractors as part of the Framework Agreement for Technical Services enabling arrangement which is defined as "the procurement of applied technical knowledge outside of an existing prime contract".  A Framework Agreement for Technical Services includes a Market Knowledge Arrangement matrix. 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.

1.7.3.8.

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.

1.7.4. Create Project Safety Organisation

1.7.4.1.

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

1.7.5. Guidance for Different Acquisition Strategies

1.7.5.1.

The requirements for Project Safety Initiation do not change for acquisition conducted through intergovernmental agreements, OCCAR, multilateral or collaborative programmes. It is MOD policy that the same standards are met, and that assurance that these standards have been met can be demonstrated.

1.7.6. Warnings and Potential Project Risks

1.7.6.1.

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

1.7.6.2.

If the project fails to co-ordinate the treatment of stakeholders and legislative requirements between 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).

1.7.6.3.

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

1.7.6.4.

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 Team Leaders have discharged their responsibilities correctly.

1.8. Version Control

1.8.1. Version 2.3 to 3.0 uplift

1.8.1.1.

Major uplift from the Acquisition System Guidance (ASG) to online version. POEMS has undergone major revision. Refer to the POEMS Transition Document for details.

1.8.2. Version 3.0 to 3.1 uplift

1.8.2.1.

A minor uplift to correct spelling, grammar, and to remove some duplication of text.

Subject to Policy Clauses

1.4

Interfaces

Interfaces between organisations shall be identified so that risks across them can be appropriately managed and effectively communicated.

3.1

Safety and Environmental Management System

Operating Centres, Project Teams or equivalents shall operate in compliance with established Safety and Environmental Management Systems.

3.2

Safety and Environmental Management Plan

Operating Centres or equivalent shall ensure that all Products, Systems or Services have a suitable and sufficient through life safety and environmental management plan.

3.3

Stakeholder Agreements

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

3.4

Availability of Resources

Operating Centres, Project Teams or equivalents shall ensure the availability of resources necessary to establish, implement and maintain the safety and environmental management system and detail these in a through life safety and environmental management plan.

3.5

Core Element Documentation

Operating Centres, Project Teams or equivalents shall establish, maintain and retain suitable and sufficient information that describes the core elements of the safety and environmental management system(s), their interaction and any related documentation.

3.6

Accountability

Within Operating Centres, Project Teams or their equivalents, named individuals shall be appointed who shall have defined roles, responsibilities, accountabilities and authority for ensuring safety and environmental management systems are established, implemented and maintained in accordance with the requirements of ASEMS.

4.3

Identification of Legislation and other Requirements

Operating Centres or equivalent shall establish and maintain a procedure for identifying and accessing the relevant safety and environmental legislative and other requirements that are applicable to their projects.

4.4

Compliance with Legislation and other Requirements

Project Teams or equivalents shall establish, and demonstrate compliance with, relevant legislation and other requirements.

4.7

Safety and Environmental Objectives and Targets

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

4.10

Independent Assurance

The Project Team Leader or equivalent shall ensure independent review of the Safety and Environmental Management System as appropriate and commensurate to the risk.

5.4

Consultation

Operating Centres, Project Teams or equivalent shall ensure that all stakeholders are identified and consulted so that their views and responsibilities are considered when managing safety and environmental risks.

6.1

Roles and Responsibilities

Operating Centres, Project Teams or equivalents shall demonstrate that competence requirements have been established for all roles in accordance with the DE&S System Safety & Environmental Protection Role Profiles.

6.3

Competence

The system safety and environmental competence of all staff in posts with system safety and environmental responsibilities shall be regularly assessed, monitored and recorded.

Process Maps

SMP A1
Assessment Phase Activities

Process map 1 for the Assessment phase of a POSMS

SMP C1
Concept Phase Activities

Click here to view

SMP DM2
Development / Demonstration and Define Baseline Design

Click here to view

Tools

Bow-Tie Diagram

The bow-tie technique was first developed as a technique for developing safety cases in the Oil and Gas Industry. The principle of the technique requires the identification of hazards, circumstances (threats) and events leading to the risk realisation (usually as a fault tree), and then, a tree of consequences leading from the event to the consequences and the estimated loss (usually with an event tree).

Covered by Audit Question Sets

1.4

Audit Question Set Section 1.4 Interfaces

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

3.1

Audit Question Set Section 3.1 Safety and Environmental Management System

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

3.2

Audit Question Set Section 3.2 Safety and Environmental Management Plan

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.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.4

Audit Question Set Section 3.4 Availability of Resources

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

3.5

Audit Question Set Section 3.5 Core Element Documentation

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

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.

4.3

Audit Question Set Section 4.3 Legislation Identification and Other Requirements

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

4.4

Audit Question Set Section 4.4 Legislation Compliance and Other Requirements

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

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

6.1

Audit Question Set Section 6.1 Competence

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

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.