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 co-ordinated 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 SMP's are to be produced both by the MOD 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 MOD Project rather than plans produced by the contractor or Independent Safety Auditor.
The SMP details the MOD’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 MOD Project SMP forms an essential element of the Through Life Management Plan. Each project requires a 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 MOD through-life safety management of the equipment is established. The SMP is the formal record of the way the MOD manages safety for a project.
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;
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 MOD’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 MOD 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.
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 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 MOD 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 Project SMP has been provided at Annex A. Additional advice is available from domain specific safety regulations.
3.2.3. Warnings and Potential Project Risks
The SMP is the principal mechanism for managing project risks associated with the 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 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 resources required are not available at the times assumed.
3.2.4. Procedure Completion
The PSC is responsible for drafting and endorsing the SMP and agreeing 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 MOD delegated authorities for procurement, support and operation.
3.3.1. 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.
3.3.2. 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 MOD 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.
3.4. Required Inputs
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).
3.5. 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.
3.6. Annex A - Template for a Safety Management Plan
Title of equipment or system to be procured with Requirement reference number.
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 Ship Safety Management Office (SSMO), Ammunition Support Group (ASG) or the Defence Ordnance Support Group (DOSG). In cases where there is no natural alignment with a particular domain advisor, then consult QSEP for advice.
PROJECT SAFETY MANAGEMENT SYSTEM
A description of the Safety Management System within the MOD 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 MOD, contractor and specialist advisors;
- Safety reviews, feedback and reporting procedures;
- Transfer arrangements;
- Design changes;
- Contractor’s trials.
- Safety requirements arising from legislation;
- MOD 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 interfaces with associated equipment safety cases.
This plan will be approved by person with delegated authority.
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.
3.7. 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:
Safety Delegation Holder
Project Safety Manager
Independent Safety Auditor
Contractor Project Safety Engineer
Safety Case Preparation
Safety Case Endorsement
Hazard Log Administration
Safety Requirements Preparation
R - Responsible
A - Accountable
C - Consulted
I - Informed
3.8. Version Control
3.8.1. Version 2.3 to 3.0 uplift
Major uplift from the Acquisition System Guidance (ASG) to online version. POEMS has undergone major revision. Refer to the POEMS Transition Document for details.
3.8.2. Version 3.0 to 3.1 uplift
A minor uplift to correct spelling, grammar, and to remove some duplication of text.
3.8.3. Version 3.1 to 4.0 uplift
- Further guidance is now part of the main procedure
- Removal paragraphs duplicated with SMP02
- Restructure the SMP into a format consistent with all other SMPs
- The Safety Management Plan template and RACI chart example are now included as Annexes.
- Paragraphs on responsibilities and alignment with Environment have been removed and included with the POSMS introduction.
3.8.4. Version 4.0 to 4.1 Uplift
Minor text changes to align with ASP taxonomy.
3.8.5. Version 4.1 to 4.2 Uplift
Text change replacing Project Team with Delivery Team.
3.8.6. 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.