SMP13. In-Service Safety Management System

System Revision ID ASEMS Document Version Effective From State
4610 4.3 16/07/2021 - 00:15 Extant

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

  1. Operation (including compliance with Safety limitations on use);
  2. Emergency preparedness;
  3. Maintenance;
  4. Training;
  5. Storage;
  6. Transportation;
  7. Disposal (e.g.: consumables, damaged items, LRUs at end of their life).

b) Safety Information Management:

  1. Incident and accident data;
  2. Suggested safety improvements;
  3. Maintenance of Hazard Log;
  4. Maintenance of Safety Case;
  5. Maintenance of Safety Management Plan (including Disposal Plan);
  6. Monitoring changes to safety legislation;
  7. Provision of safety information to other stakeholders;
  8. Receipt of safety information from other stakeholders;
  9. Archiving of safety information.

c) Safety Performance Reviews and Continuous Improvement:

  1. Reactive (incident reporting, investigation and corrective action);
  2. Planned (audit and inspection);
  3. Safety performance monitoring;
  4. Review for changes in system usage which might affect Safety;
  5. Comparison of achievement with expectations;
  6. Continuous Improvement;
  7. Audit of the in-service Safety Management System (self/peer/independent as required)

d) Configuration Management:

  1. System build standard (hardware and software) – Safety consideration as an integral part of configuration control;
  2. Obsolescence management;
  3. 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):

  1. Hazard Analysis;
  2. Risk Estimation;
  3. Risk and ALARP Evaluation;
  4. Risk Acceptance.

f) Lines of Development:

  1. Personnel (e.g. manpower numbers);
  2. Training (e.g. individual and collective);
  3. Facilities and Estates (e.g. infrastructure and training facilities required to support the system in service through to disposal);
  4. Sustainability (e.g. resources, spares and support to sustain safe operation);
  5. Concepts & Doctrine (e.g. military tactics, techniques and procedures and their interaction with the safe use of the equipment);
  6. 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:

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

  1. 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?
  2. User and maintainer documentation – has it been approved and issued?
  3. Support Arrangements, Maintenance Policy, Integrated Logistics Support etc. – have they been implemented?
  4. Limitations or restrictions on operation – where they are needed, have they been published?
  5. 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:

  1. Modifications to the equipment are introduced;
  2. There is a change in use;
  3. There are changes in legislation requiring retrospective action to ensure compliance;
  4. 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:

  1. Outputs from Procedure SMP01 – Safety Initiation;
  2. Outputs from Procedure SMP02 – Safety Committee;
  3. Outputs from Procedure SMP03 – Safety Planning;
  4. Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;
  5. Outputs from Procedure SMP05 – Hazard Identification and Analysis;
  6. Outputs from Procedure SMP06 – Risk Estimation;
  7. Outputs from Procedure SMP07 – Risk and ALARP Evaluation;
  8. Outputs from Procedure SMP08 – Risk Reduction;
  9. Outputs from Procedure SMP09 – Risk Acceptance;
  10. Outputs from Procedure SMP10 – Safety Requirements and Contracts;
  11. Outputs from Procedure SMP11 – Hazard Log;
  12. 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:

  1. Through-Life Management Plan;
  2. Integrated Test, Evaluation and Acceptance Plan;
  3. Project Safety Management Plan including RACI (Responsible, Accountable, Consulted, Informed) chart;
  4. 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.);
  5. 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.

Subject to Policy Clauses

1.6

Significant Occurrences and Fault Reporting

All Delivery Teams shall record and report significant Product, System or Service faults, accidents, incidents and near misses to the DE&S Safety, Health & Environment Committee through the Quality, Safety and Environmental Protection Team.

1.7

Learning From Experience

Operating Centres, Delivery Teams or equivalents shall ensure accidents and incidents are investigated to identify opportunities to reduce the likelihood and impact of recurrence. Lessons learned shall be shared amongst all relevant stakeholders to maximise benefit. Lessons learned (i.e. Audit Reports and LfE Artifacts) shall be shared amongst all relevant stakeholders and stored on the BMS/SharePoint as appropriate.

1.8

Training

DE&S sponsored courses for system safety and environmental protection and sustainability shall be the recognised route to support suitable and sufficient competence throughout DE&S.

2.1

Organisation and Arrangements

Operating Centre Directors or equivalent shall document their Organisation and Arrangements that shall: i. communicate their commitment to Secretary of State for Defence’s policy statement; ii. foster a proactive safety and environmental culture; iii. continually improve the safety and environmental management systems and their outcomes; iv. and comply with legal and other appropriate requirements.

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

Safety and Environmental Management System

Operating Centres, Delivery 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.4

Availability of Resources

Operating Centres, Delivery 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, Delivery 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.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.4

Compliance with Legislation and other Requirements

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

4.6

Safety Hazard Identification

Operating Centres, Delivery Teams or equivalent shall establish, implement and maintain a procedure for the on-going proactive identification of safety hazards.

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

Change Management

Operating Centres, Delivery Teams or equivalents are to ensure that all new or increased safety risks arising from changes to Products, Systems or Services or to their operating environment are managed appropriately

5.7

Non-compliance Reporting

In circumstances where the ability of the Delegation Holder to achieve compliance with the requirements of ASEMS may have been compromised, Operating Centres, Delivery Teams or equivalents shall take immediate steps to correct the situation. Actions required could include improving the clarity of the authority, instructions or responsibilities provided, increasing resources or correcting deficiencies in practices or procedures. Where resolution of the problem lies outside the control of the Delegation Holder, the issue is to be referred through the line management chain. This requirement is to be applied to any further levels of delegation as necessary.

6.1

Roles and Responsibilities

Operating Centres, Delivery Teams or equivalents shall demonstrate that competence requirements have been established for all roles in accordance with appropriate standards including the DE&S System Safety & Environmental Protection Competence Maps, Assignment Specifications and Success Profiles.

Process Maps

SMP DM13
Safety during Manufacture

Click here to view

SMP DM4
Review & Refine Safety Assessment

Click here to view

Covered by Audit Question Sets

1.6

Audit Question Set Section 1.6 Significant Occurrances and Fault Reporting

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

1.7

Audit Question Set Section 1.7 Learning From Experience

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

1.8

Audit Question Set Section 1.8 Training

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

2.1

Audit Question Set Section 2.1 Organisation and Arangements

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

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

Audit Question Set Section 4.6 Safety Hazard Identification

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

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

Audit Question Set Section 5.2 Change Management

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

5.7

Audit Question Set Section 5.7 Non-Compliance Reporting

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

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.