Printer-friendly version
PDF version13.1. Introduction
13.1.1. Definitions
13.1.1.1.
A Safety Management System is defined in Def Stan 00-056 as:
“The organisational structure, processes, procedures and methodologies that enable the direction and control of the activities necessary to meet safety requirements and safety policy objectives.”
13.1.2. Objectives
13.1.2.1.
This procedure is concerned with ensuring that the in-service arrangements for sustaining the safety performance of equipment introduced to service, are recognised, put in place and operated. They should also be recorded in the Safety Case to demonstrate in an auditable way that this is being achieved.
13.1.2.2.
Several aspects of the In-Service Safety Management System will fall under the heading of “Lines of Development”. Aspects such as personnel, training, sustainability, infrastructure and facilities will be considered in an integrated way, to ensure that the potential new military capability can be provided from the In Service Date with acceptable levels of Safety.
13.1.2.3.
Other aspects of the In-Service Safety Management System will relate to applying Risk Management as the system changes (e.g. due to obsolescence, enhancement or new usage) and maintaining the Safety Assurance so that it reflects the current system design and usage.
13.1.2.4.
The In-Service Safety Management System will also deal with safety performance monitoring and audits/inspections to ensure that levels of risk being achieved do not increase because of slack practices or ignorance.
13.2. Procedure
13.2.1. Method
13.2.1.1.
The in-service arrangements for sustaining the safety performance of equipment introduced to service should be recognised, put in place and operated. They must also be recorded in the Safety Case to demonstrate in an auditable way that this is being achieved. The different aspects of the Safety Management System should be considered under the following headings:
13.2.1.2.
a) Implementation of Safety Controls:
- Operation (including compliance with Safety limitations on use);
- Emergency preparedness;
- Maintenance;
- Training;
- Storage;
- Transportation;
- Disposal (e.g.: consumables, damaged items, LRUs at end of their life).
b) Safety Information Management:
- Incident and accident data;
- Suggested safety improvements;
- Maintenance of Hazard Log;
- Maintenance of Safety Case;
- Maintenance of Safety Management Plan (including Disposal Plan);
- Monitoring changes to safety legislation;
- Provision of safety information to other stakeholders;
- Receipt of safety information from other stakeholders;
- Archiving of safety information.
c) Safety Performance Reviews and Continuous Improvement:
- Reactive (incident reporting, investigation and corrective action);
- Planned (audit and inspection);
- Safety performance monitoring;
- Review for changes in system usage which might affect Safety;
- Comparison of achievement with expectations;
- Continuous Improvement;
- Audit of the in-service Safety Management System (self/peer/independent as required)
d) Configuration Management:
- System build standard (hardware and software) – Safety consideration as an integral part of configuration control;
- Obsolescence management;
- Documentation (Safety consideration as part of documentation configuration control – e.g. Operator and Maintainer Manuals, Training syllabus).
e) Risk Management (e.g. for modifications and enhancements):
- Hazard Analysis;
- Risk Estimation;
- Risk and ALARP Evaluation;
- Risk Acceptance.
f) Lines of Development:
- Personnel (e.g. manpower numbers);
- Training (e.g. individual and collective);
- Facilities and Estates (e.g. infrastructure and training facilities required to support the system in service through to disposal);
- Sustainability (e.g. resources, spares and support to sustain safe operation);
- Concepts & Doctrine (e.g. military tactics, techniques and procedures and their interaction with the safe use of the equipment);
- Equipment & Technology (e.g. integration into systems of systems, including interface and interoperability issues to consider for Safe operation).
13.2.1.3.
The Risk Management of the system during development should result in several control measures which will determine requirements on the In-Service Safety Management System. The Safety Case should also identify Safety Management System prerequisites on which the achievement of tolerable safety depends. The Safety Case should show that these have been put in place and are effective.
13.2.1.4.
The Safety Management System description should identify the responsibilities and interfaces for all aspects of the defined In-Service Safety Management System, particularly because many different authorities are likely to be involved.
13.2.1.5.
The Duty Holder responsible for the Product, System or Service is likely to be part of the Front Line Command. The Duty Holder may also be the lead user, but in all circumstances, these should be consulted in the development of the safety management through the life of the Product, System or Service. The ability to determine what risks are acceptable by a Safety and Environmental Management Committee or Project is in the context of the Front Line Command’s Duty Holder model and that Duty Holder’s willingness to accept the risk as presented to them.
13.2.2. Records and Project Documentation
13.2.2.1.
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.
13.2.3. Warnings and Potential Project Risks
13.2.3.1.
If the requirements for the In-Service Safety Management System are not identified at an early stage of the project, then suitable arrangements may not be put in place. This could result in delays in bringing the system into service or in an inability to sustain the necessary level of safety performance in-service.
13.2.3.2.
If the stakeholders do not agree the responsibilities and interfaces for the In-Service Safety Management System, then there may be gaps and it may not be adequate to sustain the necessary level of safety performance.
13.2.3.3.
If the status of the arrangements for In-Service Safety Management System are not confirmed as adequate before the equipment is brought into service, then it is possible that the necessary level of safety performance will not be achieved or sustained.
13.2.3.4.
The In-Service Safety Management System arrangements will be recorded in various places because of the many authorities involved. For instance, the Safety Management System manuals of different Delivery Teams, user authorities, contractors and support authorities may contain relevant information as well as other documents recording arrangements for incident and accident reporting and investigation.
13.2.3.5.
If the In-Service Safety Management System is not documented (e.g. in the Safety Case, Through Life Management Plan or Safety Management Plan), then there will not be documentary evidence to demonstrate that it is complete and adequate. If there were to be a safety incident, it would be difficult to argue that the arrangements were effective and complete.
13.2.3.6.
If the effectiveness of the In-Service Safety Management System is not monitored or not stimulated through audit and inspection, then it is likely that it will decay over time through sloppy practice or ignorance.
13.2.3.7.
If the In-Service Safety Management System is not developed over time, then it may become inappropriate and less effective as changes happen to the system, its support, usage or the organisational structures of authorities involved in the Safety Management System.
13.2.3.8.
From the earliest stages of a project, the Safety Management Plan should identify the in-service arrangements require to sustain the safety performance of the system. These requirements can only be identified through dialogue with stakeholders, in particular the Equipment User.
13.2.3.9.
Before a Product, System or Service enters service, any residual risks and their proposed, or actual mitigations, should be examined and a case made that all necessary controls are in place. These are likely to include:
- Arrangements for training – do the courses match the training requirements set out in the Safety Case, are courses available, are the first users and maintainers trained?
- User and maintainer documentation – has it been approved and issued?
- Support Arrangements, Maintenance Policy, Integrated Logistics Support etc. – have they been implemented?
- Limitations or restrictions on operation – where they are needed, have they been published?
- Emergency and Contingency arrangements – are these in place and do they meet the requirements?
13.2.3.10.
The adequacy of the existing In-Service Safety Management System should be reviewed when:
- Modifications to the equipment are introduced;
- There is a change in use;
- There are changes in legislation requiring retrospective action to ensure compliance;
- On disposal.
13.2.3.11.
In addition, the adequacy and effectiveness of the In-Service Safety Management System should be examined as part of a detailed safety audit or inspection or during a periodic major review of the Safety Case.
13.2.4. Procedure Management
13.2.4.1.
It is the responsibility of the Delivery Team to ensure that the In-Service arrangements for sustaining the safety performance of equipment introduced into service, are recognised, put in place and operated
13.2.4.2.
Whilst DE&S Projects do not have the direct control to put in place all aspects of the In-Service Safety Management Systems,they do have the key role in co-ordinating all the authorities involved and ensuring that arrangements are in place before the equipment comes into service
13.2.4.3.
The final decision of whether the risks presented by an In-Service Product, System or Service are acceptable rests with the Front Line Command Duty Holders. These Duty Holders will provide direction on further mitigation measures they deem appropriate and the implementation of any such requirements will form part of the in-service phase.
13.2.5. Procedure Completion
13.2.5.1.
The Project Safety Manager will be responsible for the completion of the procedure. However, in most cases, a large part of the detailed work will be carried out by others. In all cases, Project Safety Committee members and other stakeholders should be involved in both providing input and completing actions.
13.3. Timing
13.3.1. Identification of SMS Requirements
13.3.1.1.
From the earliest stages of a project, the Safety Management Plan should identify the in-service arrangements require to sustain the safety performance of the system. These requirements can only be identified through dialogue with stakeholders, in particular the equipment user.
13.3.1.2.
The Responsible, Accountable, Consulted, Informed (RACI) chart which is part of the Project Safety Management Plan will cover involvement with the In-Service Safety Management System defining the authorities and their involvement with each activity.
13.3.1.3.
The Integrated Test, Evaluation and Acceptance Plan (ITEAP) will cover all aspects required to be in place to accept the Military Capability into service.
13.3.2. Refinement of Safety Management System Requirements
13.3.2.1.
As the project proceeds through its life cycle and more information becomes available on the design solution, the requirements for its In-Service Safety Management System can be refined in greater detail. This will usually be recorded in the Safety Management Plan, which is reviewed and agreed by the Project Safety Panel.
13.3.2.2.
As the design is finalised, the In-Service Safety Management System will also be fully defined and recorded in the Safety Case. This may be through a standalone Project Safety Management System document or as part of the Safety Plan.
13.3.3. Confirmation that Arrangements are in Place
13.3.3.1.
Before the equipment is accepted into service, the Project Safety Committee must review the arrangements that exit, or are being put in place, to ensure that measures to manage and control risks are ready and adequate.
13.3.4. Maintenance of Safety Management System Documentation
13.3.4.1.
The Safety Management System defined in the Safety Case must be reviewed and updated so that it correctly reflects the arrangements in place throughout the in-service period. For Land Systems, the part 3 Safety Case shall be jointly signed by both the member of the Project with formally-delegated responsibility for safety and the Front Line Command Duty Holder.
13.4. Required Inputs
13.4.0.1.
This procedure for the Safety Case and Safety Case Report requires inputs from:
- Outputs from Procedure SMP01 – Safety Initiation;
- Outputs from Procedure SMP02 – Safety Committee;
- Outputs from Procedure SMP03 – Safety Planning;
- Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;
- Outputs from Procedure SMP05 – Hazard Identification and Analysis;
- Outputs from Procedure SMP06 – Risk Estimation;
- Outputs from Procedure SMP07 – Risk and ALARP Evaluation;
- Outputs from Procedure SMP08 – Risk Reduction;
- Outputs from Procedure SMP09 – Risk Acceptance;
- Outputs from Procedure SMP10 – Safety Requirements and Contracts;
- Outputs from Procedure SMP11 – Hazard Log;
- Outputs from Procedure SMP12 - Safety Case and Safety Case Report.
13.4.0.2.
This procedure should draw on information in the following documents, and it should also define changes that should be made to their content:
- Through-Life Management Plan;
- Integrated Test, Evaluation and Acceptance Plan;
- Project Safety Management Plan including RACI (Responsible, Accountable, Consulted, Informed) chart;
- Safety Management System Manuals of stakeholders (e.g. Delivery Teams, Delivery Teams providing sub-systems, Users, authorities responsible for safe storage, transportation, disposal, inspection, audit, incident investigation etc.);
- Customer/Supplier Agreements (or similar) defining interfaces and responsibilities for certain Safety Management activities.
13.5. Required Outputs
13.5.1. Safety Management System Documentation
13.5.1.1.
The In-Service Safety Management System arrangements should be recorded in various places because of the many authorities involved. For instance, the Safety Management System manuals of different Delivery Teams, user authorities, contractors and support authorities should contain relevant information as well as other documents recording arrangements for Incident and Accident reporting and investigation.
13.5.1.2.
The principal means of bringing together this information should be through the Safety Management Plan and its RACI chart, defining the involvement of the different authorities.
13.5.1.3.
The Project Safety Case should contain a description of the In-Service Safety Management System in operation to ensure that the safety performance of the equipment is achieved and sustained through life.
13.6. Version Control
13.6.1. Version 2.3 to 3.0 Uplift
13.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.
13.6.2. Version 3.0 to 3.1 Uplift
13.6.2.1.
A minor uplift to correct spelling, grammer and to remove some duplication of text.
13.6.3. Version 3.1 to 4.0 Uplift
13.6.3.1.
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
13.6.4. Version 4.0 to 4.1 Uplift
13.6.4.1.
Minor text changes to align with ASP taxonomy.
13.6.5. Version 4.1 to 4.2 Uplift
13.6.5.1.
Text change replacing Project Team with Delivery Team.
13.6.6. Version 4.2 to 4.3 Uplift
13.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.
