SMP13. In-Service Safety Management System

System Revision ID ASEMS Document Version Effective From State
3716 3.1 03/11/2017 - 00:15 Extant

13.1. Overview

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

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

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

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

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.1.1. Required Outputs

13.1.1.1.

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

The principal means of bringing together this information should be through the Safety Management Plan and its RACI (Responsible, Accountable, Consulted, Informed) chart, defining the involvement of the different authorities.

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

13.2.1. Objectives

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 Team Leader 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.3. Responsibilities

13.3.1. Accountability

13.3.1.1.

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

13.3.1.2.

For military aviation the responsibilities for developing an In-Service Safety Management System as defined in this procedure rests with the Release to Service Authority rather than the Team Leader

13.3.2. Procedure Management

13.3.2.1.

The Team Leader may delegate the management of this procedure to a member (Safety Manager) or members of the Delivery Team.

13.3.2.2.

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

Whilst Team Leaders responsible for acquisition 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.3.2.4.

The final decision of wether 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.3.3. Procedure Completion

13.3.3.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.4. When

13.4.1. Identification of SMS Requirements

13.4.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.4.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.4.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.4.2. Refinement of Safety Management System Requirements

13.4.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.4.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.4.3. Confirmation that Arrangements are in Place

13.4.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.4.4. Maintenance of Safety Management System Documentation

13.4.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 Team Leader and the Front Line Command Duty Holder.

13.5. Required Inputs

13.5.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.5.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. Project Team, Project 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.6. Required Outputs

13.6.1. Safety Management System Documentation

13.6.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.6.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.6.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.2. Records and Project Documentation

13.6.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 Project Team;
  3. Through Life Management Plan;
  4. Safety elements of Initial Gate and Main Gate submissions.

13.7. Further Guidance

13.7.0.1.

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

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

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.7.1. Warnings and Potential Project Risks

13.7.1.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.7.1.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.7.1.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.7.1.4.

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

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

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

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.8. Version Control

13.8.1. Version 2.3 to 3.0 Uplift

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

13.8.2. Version 3.0 to 3.1

13.8.2.1.

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

Subject to Policy Clauses

1.6

Significant Occurrences and Fault Reporting

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

1.7

Learning From Experience

Operating Centres, Project Teams or equivalents shall ensure accidents and incidents are investigated to identify opportunities to reduce the likelihood and impact of reccurrence. Lessons learned shall be shared amongst all relevant stakeholders to maximise benefit.

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

Monitoring

Operating Centres, Project 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 Project Teams' or equivalents' safety and environmental management systems. ii) Project Teams or equivalents shall audit the safety and environmental management systems of their projects. iii) The DE&S Quality, Safety and Environmental Protection Team shall audit the safety and environmental management systems of Operating Centres and Project Teams.

3.10

Review

Operating Centres, Project 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

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

4.4

Compliance with Legislation and other Requirements

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

4.6

Safety Hazard Identification

Operating Centres, Project 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, Project 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, Project Teams or equivalent shall monitor and record incidents where the performance of their Product, Systems or Services either caused or had the potential to cause harm to individuals or damage to the environment and use this information to keep their risk assessments valid.

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

Change Management

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

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.

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.