Printer-friendly version
PDF version9.1. Introduction
9.1.1. Definitions
9.1.1.1.
Risk Acceptance in is defined Def Stan 00-056 as:
“The systematic process by which relevant stakeholders agree that risk may be accepted.”
9.1.2. Objectives
9.1.2.1.
The objective of Risk Acceptance is to ensure that every risk has been reviewed at appropriate management level prior to authorisation of the Safety Case Report by the member of the Project with formally-delegated safety responsibilities.
(Note “authorised” is used in accordance with the definitions in SMP12 – Safety Case and Case Report).
9.1.2.2.
Risk Acceptance is the final stage in risk management. Once risks have been assessed against requirements (Procedure SMP07 – Risk and ALARP Evaluation) and reduced where necessary (Procedure SMP08 – Risk Reduction), it will be agreed that sufficient evidence has been provided that the tolerability/ALARP (As Low As Reasonably Practicable) criteria have been met.
9.1.2.3.
There must be review at appropriate management level of each individual risk (and the aggregated risk for the system) before the Safety Case Report is finalised for major milestones. Completion of this procedure is a prerequisite for acceptance and signature of the Safety Case Report by the member of the Project with formally-delegated safety responsibilities.
9.1.2.4.
Risk Acceptance should occur only when there are positive answers to the questions:
“Have we done all that is Reasonably Practicable to reduce the level of safety risk posed by the identified accidents, individually and in total?”
and
“Are they now Broadly Acceptable or Tolerable and As Low As Reasonably Practicable?”
9.2. Procedure
9.2.1. Method
9.2.1.1.
Individual risks, and the overall risk posed by the system, may be accepted when the Project Safety Committee and Project Safety Manager agree that sufficient evidence has been provided that the tolerability criteria have been met.
9.2.1.2.
The Project Safety Manager should agree with the stakeholders a process for Risk Acceptance. The process should ensure that the detailed evidence produced by the contractor is aligned against the hazards listed in the Hazard Log in a way that supports visibility and review by the appropriate management level according to risk category.
9.2.1.3.
There are defined processes for acceptance of risks within each domain (i.e. ship key hazards, airworthiness, Ordnance, Munition & Explosives, etc.) which should be followed for these risks, even if the project as a whole is primarily in a different domain.
9.2.1.4.
The military imperative sometimes demands that personnel are exposed to levels of risk that in civilian operations would not be tolerated. Decisions to tolerate such risks in order to achieve an essential military capability must always be made at the appropriate level of seniority. A formal process for referring risks up the DE&S management chain is described in ASEMS Part 2 - GMP00 Risk Referral leaflet.
9.2.1.5.
The process for risk acceptance should address how the sufficiency and adequacy of the evidence will be demonstrated. Agreement that the Tolerability Criteria have been met, and that the risk has been reduced to a level that is ALARP, will be the minimum requirement. The agreement is between the Contractor, the Project Safety Manager and the Safety Panel, but, in many cases both parties should need to take due cognisance of outside bodies e.g. regulatory/certification bodies and users.
9.2.1.6.
The process for risk acceptance should be agreed at an early stage in the project and should be included in the Safety Management Plan. Discussions should involve the contractor’s, and the MOD’s, safety advisors; the Safety Panel; and representatives from any regulatory/certification bodies.
9.2.1.7.
In practice Risk Acceptance should be an ongoing process as individual hazards are resolved and evidence of this becomes available. This obviously reduces the risks to timescale and the peak workload on the Safety Panel. However care should be then taken to ensure that later changes and modifications do not invalidate previous Risk Acceptance. This requires effective change control and visibility of the impact of changes on hazards.
9.2.2. Records and Project Documentation
9.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.
9.2.3. Warning and Potential Project Risks
9.2.3.1.
Acceptance of risks on an ALARP basis will not be justified on the basis of project budget limitations.
9.2.3.2.
As in all safety matters, failure to get agreement on key issues affecting the Acceptance Process at an early stage in the life cycle will often lead to problems in cost and time terms.
9.2.3.3.
Safety Committees will resist any inclination to indulge in ever more complex calculations and analysis, which cannot be justified on time and cost grounds.
9.3. Timing
9.3.1. Production
9.3.1.1.
Risk Acceptance should take place after completion of Risk and ALARP Evaluation and Risk Reduction and prior to authorisation of the Safety Case Report by the member of the Project with formally-delegated safety responsibilites. However, if some of the risks cannot be accepted, then there may be a need to re-enter the Risk Reduction cycle.
9.3.1.2.
Risk Acceptance is an ongoing process by which all the individual risks in the Hazard Log are reviewed at appropriate management level where claims of tolerability and ALARP are to be made.
9.3.2. Review, Development and Acceptance
9.3.2.1.
Each major update shall be endorsed by the Safety Panel, authorised by the Project Safety Manager and accepted by the member of the Project with formally-delegated safety responsibilities.
If the evidence supporting Risk Acceptance is updated, management measures should ensure that the Hazard Log, Safety Case Report and other dependent activities are also updated.
9.3.2.2.
If the evidence supporting Risk Acceptance is updated, management measures should ensure that the Hazard Log, Safety Case Report and other dependent activities are also updated.
9.4. Required Inputs
9.4.0.1.
This procedure for Risk Acceptance requires inputs from:
- Outputs from Procedure SMP03 – Safety Planning;
- Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;
- Outputs from Procedure SMP11 – Hazard Log;
- Outputs from Procedure SMP12 – Safety Case and Safety Case Report;
- 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.
9.4.0.2.
The Risk Acceptance process and timing appropriate to the project should be defined in the Project Safety Management Plan, if necessary with reference to the contractor’s Safety Management Plan.
9.4.0.3.
The Risk Acceptance should use the following reference inputs, as available:
- Hazard Log;
- Risk Evaluations;
- Detailed evidence supporting the Risk Evaluations;
- ALARP justifications;
- Independent Safety Auditor Report(s);
- Safety Requirements in System Requirements Document and Contractual Documents.
9.5. Required Outputs
9.5.0.1.
The primary output of the Risk Acceptance should be the endorsement at appropriate management level of the evidence of tolerability and ALARP for each accident recorded in the Hazard Log.
9.6. Version Control
9.6.1. Version 2.3 to 3.0 Uplift
9.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.
9.6.2. Version 3.0 to 3.1 Uplift
9.6.2.1.
A minor uplift to correct spelling, grammar, and to remove some duplication of text.
9.6.3. Version 3.1 to 3.2 Uplift
9.6.3.1.
A minor uplift, GMP04 reference amended to 'GMP-00 Risk Referral Leaflet' to reflect the re-org of the GMPs.
9.6.4. Version 3.2 to 4.0 Uplift
9.6.4.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.
9.6.5. Version 4.0 to 4.1 Uplift
9.6.5.1.
Minor text changes to align with ASP taxonomy.
9.6.6. Version 4.1 to 4.2 Uplift
9.6.6.1.
Text change replacing Project Team with Delivery Team.
9.6.7. Version 4.2 to 4.3 Uplift
9.6.7.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.
