Printer-friendly version
PDF version1.1. Introduction
1.1.1. Definitions
1.1.1.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.
1.1.2. Objectives
1.1.2.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.2.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 Full Business Case approval), to review and update the project safety arrangements and ensure that they continue to be appropriate.
1.1.2.3.
This procedure assumes that the Team Leader (TL) has already been appointed, and that clearly defined safety responsibilities have been formally delegated to a suitably safety-competent individual within the Delivery Team.
1.1.2.4.
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.1.2.5.
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;
- Lead Functional Safety Management Office (FSMO).
1.2. Procedure
1.2.1. Stakeholder Identification
1.2.1.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:
- 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.
1.2.1.2.
As a minimum the following will be consulted:
- Equipment Capability Customer;
- Equipment User;
- Director Technical;
- Safety & Environmental Protection Group;
- 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 Safety Management Offices (via Questionnaire Form SMP01/F/01 - Safety Operating Environment Questionnaire).
1.2.1.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.1.4.
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 Project may choose to include external stakeholders at this stage.
1.2.1.5.
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.2.2. Identify Applicable Legislation, Standards and Requirements
1.2.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.2.2.2.
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 EMP03/F/01 SMP01/F/03 - Register of Legislation and 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.2.3.
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.2.2.4.
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.2.5.
Useful information sources include:
- Other equipment safety Joint Service Publications;
- Other relevant legislation and standards for non-UK operations.
1.2.3. Create Project Safety Organisation
1.2.3.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:
- Appoint competent Project Safety Manager (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.
1.2.3.2.
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.2.4. Compliance
1.2.4.1.
The organisation uses a number of methods of enabling compliance:
- 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;
- 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 DEFCONs and DEFFORMs in the development of contracts and contract conditions.
1.2.4.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.2.4.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.2.4.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.2.4.5.
Identification of and compliance with all relevant safety and environmental legalisation will always ultimately be the responsibility of the Delivery Team member with delegated authority for safety and environmental protection.
1.2.4.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.2.4.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.2.4.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.2.5. Records and Project Documentation
1.2.5.1.
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 submissions.
1.2.5.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.2.6. Warnings and Potential Project Risks
1.2.6.1.
If Delivery Teams 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.2.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.2.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.2.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 safety and environmental responsibilities have discharged correctly.
1.2.7. Procedure Completion
1.2.7.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.2.7.2.
The PSM will maintain a legislative register as an integral part of the Safety Case for each project.
1.2.7.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.2.7.4.
QSEP will assist Projects in identifying those acquisition programmes that have potential safety implications.
1.3. Timing
1.3.1. Initial Application
1.3.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.3.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.3.2. Review
1.3.2.1.
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.
1.4. Required Inputs
1.4.0.1.
The procedure may use the following reference inputs, as available:
- User Requirements 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 MOD Publications.
1.5. Required Outputs
1.5.0.1.
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 EMP03/F/01 SMP01/F/03 - Register of Legislation and Requirements, which should be reviewed and updated as the project proceeds.
1.5.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 EMP03/F/01 SMP01/F/03 - Register of Legislation and Requirements with changes in legislation and international agreements.
1.6. Version Control
1.6.1. Version 2.3 to 3.0 uplift
1.6.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.6.2. Version 3.0 to 3.1 uplift
1.6.2.1.
A minor uplift to correct spelling, grammar, and to remove some duplication of text.
1.6.3. Version 3.1 to 4.0 uplift
1.6.3.1.
Major reorganisation of all SMPs into a consistent format. Responsibilities, Alignment with Environment and guidance for different acquisition strategies has been removed and included in the POSMS summary. All further guidance has been placed into the Procedure section.
1.6.4. Version 4.0 to 4.1 Uplift
1.6.4.1.
Minor text changes to align with ASP taxonomy.
1.6.5. Version 4.1 to 4.2 Uplift
1.6.5.1.
Text change replacing Project Team with Delivery Team.
1.6.6. Version 4.2 to 4.3 Uplift
1.6.6.1.
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.
1.6.7. Version 4.3 to 4.4 Uplift
1.6.7.1.
Minor update to form SMP01/F/01 - Safety and Operating Environment Questionnaire to add a question on Position, Navigation and Timing (PNT).
1.6.8. Version 4.4 to 4.5 Uplift
1.6.8.1.
Update to Form SMP01/F/03 - Register of Safety Legislation and Other Significant Requirements to align with the form available on the DLST.
