Printer-friendly version
PDF version7.1. Introduction
7.1.1. Definitions
7.1.1.1.
ALARP stands for “As Low As Reasonably Practicable” and is defined in Def Stan 00-056 as:
“A risk is ALARP when it has been demonstrated that the cost of any further Risk Reduction, where the cost includes the loss of defence capability as well as financial or other resource costs, is grossly disproportionate to the benefit obtained from that Risk Reduction.”
7.1.1.2.
Risk and ALARP Evaluation is defined in Def Stan 00-056 as:
“The systematic determination, on the basis of tolerability criteria, of whether a risk is broadly acceptable or tolerable and ALARP, and whether any further Risk Reduction is necessary.”
7.1.2. Objectives
7.1.2.1.
The objective of risk and ALARP Evaluation is to compare the Risks identified in Risk Estimation to tolerability criteria and to judge whether they are currently acceptable or must be subject to Risk Reduction.
Risk and ALARP Evaluation provides input to:
- Risk Reduction;
- Risk Acceptance, and determining the management level for Risk Acceptance;
- Option selection;
- Hazard Log;
- Safety Case Reports;
- Identifying areas of higher risk for focussing safety effort.
7.1.2.2.
At successive stages of the project and in progressively greater detail, Risk and ALARP Evaluation seeks to answer the question:
“How significant are the Safety Risks posed by the identified Accidents, individually and in total and could we reasonably be expected to reduce them further?”
7.2. Procedure
7.2.1. Method
7.2.1.1.
Risk and ALARP Evaluation identifies where the project currently meets tolerability criteria, and where further action is needed to achieve this. It thus provide one of the main inputs to the Safety Case and, ultimately, to the acceptance of the system.
7.2.1.2.
The Delivery Team will ensure that Risk and ALARP Evaluations are undertaken, to determine whether the achieved risk level for the identified accidents associated with the system are ALARP and tolerable, or broadly acceptable.
7.2.2. ALARP Procedure
7.2.2.1.
ALARP is a shorthand term to indicate that all steps have been taken to reduce risks from accidents, unless the cost is grossly disproportionate. For assessment purposes, ALARP is interpreted as the reduction of risk to the lowest level practicable bearing in mind the benefits flowing from the acceptance of the Risk and taking into account the cost of further reducing the risk.
7.2.2.2.
Stage 1 – Application of Good Practice to Common Risks: The first stage of demonstrating ALARP is to identify all Hazards that are addressed by application of good practice. This situation will apply particularly to occupational hazards such as electrocution, lifting, working at height, radiation hazards, etc.
7.2.2.3.
A universal practice in industry may not necessarily be good practice or reduce risks to ALARP in a specific case. Furthermore good practice may change over time; for instance a new technology may make a higher standard reasonably practicable.
7.2.2.4.
Stage 2 – Application of Analysis to Non-Common Risks: Where some hazards are not addressed by application of good practice, it is necessary to systematically analyse the design to see if further Risk Reduction is reasonably practicable.
7.2.2.5.
For most military systems, good practice is unlikely to cover all the risks that need to be addressed in order to demonstrate that a system is tolerably safe, especially relating to functional hazards. In this case, Cost-Benefit Analysis (CBA) of potential changes needs to be systematically undertaken. Costs can be balanced against the ‘Value of Prevention of a Fatality’ (VPF), and other factors such as delay or reduction in capability. (The Department for Transport publishes VPF figures annually).
7.2.2.6.
A systematic analytical procedure to be used when demonstrating the achievement of ALARP for non-common risks is shown in Figure 7.1 above. The characteristics are:-
a. A Risk Assessment. A predictive Risk Assessment may be required at various stages of the ALARP analysis process, for example:
- an assessment of the initial proposal can be used to determine its position relative to the defined Safety Criteria,
- if more than one option is identified, an assessment of each option will be required to feed into the optimisation analysis,
- an assessment will need to be made of the chosen solution.
b. Identification of Options. This is the fundamental stage in the ALARP analysis process and involves defining the various courses of actions, or options, available and identifying possible risk reduction measures. Measures to reduce the Risk include the following:
- Elimination of hazards leading to risk,
- Reduction in the frequency of initiating events (eg improvements in plant, site services reliability or availability),
- Improvement in the reliability, availability or responsibility of systems and equipment,
- Possible introduction of new/additional systems and equipment to mitigate consequences of a hazard or improve reliability of safety/containment systems,
- Improvement in operator procedures and/or alarms to facilitate correct operator action,
- Improvements in emergency response procedure,
- Increase in separation, segregation and diversification of safety related equipment.
c. Optimisation Analysis. In order to be able to choose between different options or to judge whether or not a particular Risk Reduction measure makes the risk ALARP, some comparison and selection process is required. In some cases, particularly practical problems at the operational stage, a decision using engineering judgement and common sense based on experience may be all that is needed. In more complex operational situations and at the design stage the decision making process will normally have broader scope and may require a quantitative decision-aiding technique. The two main decision-aiding techniques in general use are decision analysis, and CBA (See below). These techniques can be used for guidance but any other relevant factors, including non-safety factors, should be taken into account.
d. Safety Justification. The discussion of ALARP within the Safety justification will be sufficient to demonstrate that a logical and comprehensive approach has been adopted to identify all candidate Risk Reduction measures, and to optimise these. In this way the route from the identification of measures at the ALARP review stage to the final choice of the preferred measures is clear, as is the rationale for choosing these measures in preference to others. The level of detail included for a given measure need not be extensive where the acceptance or rejection of that measure is clear. However, where a number of alternative measures exist, sufficient detail will be included in the Safety justification to support the decision in favour of the measure ultimately selected.
e. Feedback. The final stage of the ALARP analysis process will be the implementation of the chosen design option or operational procedure. It is important that lessons learnt from the implementation be fed back to given improvements either in the next application or in other similar proposals. Similarly, any incidents or failures that are experienced should be fed back into future Risk Evaluations as appropriate.
7.2.2.7.
Decision analysis can be used when there are numerous factors which may affect the optimum solution or when some of the factors are difficult to quantify in monetary terms. Each factor is attributed a weighting to express its relative importance. Each option is assigned a score against each factor. The score is multiplied by the weighting to produce a weighted score against each factor and the sum of the weighted scores for each option calculated. The option having the highest score will be the preferred solution.
7.2.2.8.
CBA can be used where the only relevant factors are cost and risk. It is applicable where a judgement needs to be made between the benefit to be derived from a measure which reduces the risk and the cost of that measure. Affordability is not a legitimate factor in considering costs but the projected use or remaining life of a system or facility could be taken into account. CBA requires that a monetary value be assigned to the detriment (the VPF) to enable the net benefit to be quantified in the same units as the total cost of the measure.
7.2.2.9.
The value of the VPF is an area of some debate. For the purpose of Risk and ALARP Evaluation, a value of about £1,000,000 could be used, together with a suitably pessimistic estimate of the number of fatalities. However, this is an emotive subject and no authoritative guidance is available.
7.2.2.10.
In many practical instances, Risk Reduction measures have been introduced which have involved expenditure of considerably more than this. In these cases other factors (eg the measure is already common practice elsewhere) or other indirect benefits (eg maintenance of good industrial relations or reputation) which are difficult to quantify have been taken into account in reaching the final decision. CBAs is therefore best used when comparing a number of options in order to grade them in terms of value for money, rather than using it as the sole tool for rejection or acceptance of a particular measure.
7.2.2.11.
Further information on ALARP can be found in Def Stan 00-056.
7.2.3. ALARP Evaluation
7.2.3.1.
The aim is for all identified Risks and the overall risk posed by the system to be assessed as being Broadly Acceptable. Should this not be the case, the risk should be reduced to a level that is Tolerable and ALARP.
7.2.3.2.
The ALARP principle accepts that risk reduction may cease when the cost of any further work becomes grossly disproportionate to the benefits gained. In this context, the term ‘cost’ includes factors additional to finance including penalties to military capability. However ALARP does not mean that no further improvement is possible within the original project budget – this is not a sufficient justification of ALARP.
7.2.3.3.
As for all risk management activities, ALARP Evaluation is an iterative process. Whenever there are changes to the system (whether by design or by evolution), changes to assumptions, changes in the operating environment or changes through age, there should be a re-assessment of all risks falling within the scope of the change.
7.2.3.4.
Decisions on whether Risks are ALARP can also change over time as new Risk Reduction technologies become available, the concept of “best practice” changes or the perceived value of Risk Reduction alters. Whether a potential measure to reduce risk is reasonably practicable may also be affected by decisions to extend the life and these should be taken into account.
7.2.3.5.
Table 7.1 shows how both the level of risk and whether a risk is ALARP need to be considered when determining whether the risk is acceptable.
7.2.3.6.
| Level of Risk | Have the risks been shown to be ALARP? | |
|---|---|---|
| Yes | No | |
| Unacceptable | Unacceptable - unless there are exceptional reasons for the activity to take place | Unacceptable |
| Tolerable | Acceptable | Unacceptable |
| Broadly Acceptable | Acceptable | Acceptable - but risk should be reduced wherever reasonably practicable |
Table 7.1 Judging the Acceptability of Risk
7.2.3.7.
The project will demonstrate any claims that all reasonable steps have been taken to ensure that Risk is Tolerable and ALARP and demonstrate that they have exercised their common law “duty of care”. The level of evidence required is a function of the level of risk and the domain. This will also involve demonstrating that further Risk Reduction methods have been actively sought and considered in a systematic way.
7.2.3.8.
Project Safety Managers should continuously monitor risk levels and consider updating their target requirements as circumstances change through:
- Changes in assumptions or “claims” within the Safety Case;
- Undertaking Safety Assessment to assess the “gaps”;
- Only permitting implementation of changes following consideration of the new Risks and any additional Risk mitigation;
- Updating the Safety Case and where necessary a new Safety Case Report before any new operation proceeds.
7.2.3.9.
If an individual Risk is ALARP, but lies outside of the Tolerability range, then the Risk Estimation and assessment should be reviewed to confirm that the system poses intolerable Risk that cannot be further mitigated. This may require radical measures such as considering redesign of some elements of the system which are preventing Risk from being reduced to a Tolerable level or alternatively a modification of the capability required from the system. Procedure SMP09 – Risk Acceptance, gives further information on what action to take if a risk cannot be driven down into the Tolerable region and remains Unacceptable.
7.2.4. Tolerability Criteria
7.2.4.1.
Tolerability Criteria provide the means for categorising risks as either Unacceptable, Tolerable or Broadly Acceptable. Specific tolerability criteria for a particular domain, function or accident type may be available from Safety Management Offices. Where specific tolerability criteria are not available, Health and Safety Executive guidance in this area should be applied. Ultimately the Project Safety Committee for the project is the authority for setting tolerability criteria, but there is a need to maintain consistency across projects.
7.2.4.2.
Tolerability Criteria should be appropriately recorded (e.g. in the Safety Management Plan), and used during the remainder of the acquisition process. Where the system is an element of a super-system, or relates to other (pre-existing) systems, the Project should seek to ensure that the tolerability criteria are compatible with those of the other systems. Where existing systems have used tolerability criteria that are no longer appropriate, e.g. due to changes in MOD policy, a strategy for reconciling and managing the differences should be established and agreed by the PSC.
7.2.4.3.
Distinct tolerability criteria may be agreed for different groups of people who may be harmed by an accident involving the system. For instance, one set of tolerability criteria may be defined for trained personnel who are directly involved with the system, another, more stringent, set of tolerability criteria may be defined for people, such as MOD employees, who are indirectly involved with the system during the course of their duties. A third set, more stringent still, may be defined for people who are independent third parties, such as the general public.
7.2.4.4.
The tolerability criteria should be devised such that both individual risks (i.e. risks posed by individual accidents) and the overall risk posed by the system can be assessed.
7.2.5. Risk Evaluation
7.2.5.1.
The project, in agreement with all relevant stakeholders and authorities, shall establish tolerability criteria based on relevant legislation, standards and MOD policy. These shall form the basis for making a judgement as to whether a Risk is Broadly Acceptable or Tolerable and ALARP.
7.2.5.2.
The tolerability criteria shall be considered to have been met when individual risks and the overall risk posed by the system have been demonstrated to be Broadly Acceptable or Tolerable and ALARP.
7.2.5.3.
The risk and ALARP Evaluation shall be reviewed and revised through the life of the contract, as the design changes or as information becomes available. The project should demonstrate the effectiveness of the Risk and ALARP Evaluation process and the suitability of the techniques employed.
7.2.6. Records and Project Documentation
7.2.6.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 (TLMP);
- Safety elements of Outline Business Case and Full Business Case submissions.
7.2.6.2.
The Hazard Log is the primary mechanism for recording the results of the Risk and ALARP Evaluation. See Procedure SMP11 – Hazard Log, for more details.
7.2.6.3.
The results of the Risk and ALARP Evaluation should be reported in a form which records the following:
- The input information used (e.g. User Requirements Document version, Concept of Use document, design standard, Criteria applied);
- The approach adopted;
- The people consulted;
- The Hazards, Accidents and Accident Sequences identified, together with their Risk level estimates;
- Conclusions reached on the acceptability of each identified Risk, together with the justification;
- Identification of areas where further Risk Reduction is considered to be necessary.
7.2.6.4.
These results form part of the Safety Case body of evidence and may be recorded in a standalone report or as part of a wider report on safety (e.g. Safety Case Report).
7.2.6.5.
The Safety Case Report (Procedure SMP12 – Safety Case and Safety Case Report) is where the project will demonstrate the adequacy of the Risk and ALARP Evaluation process and the suitability of the approach adopted.
7.2.7. Warnings and Potential Project Risks
7.2.7.1.
Acceptance of risks on an ALARP basis must not be justified on the basis of project budget limitations.
7.2.7.2.
Setting of the tolerability criteria is clearly critical to the Risk and ALARP Evaluation process. Judgement may be involved, and there is therefore some subjectivity (particularly in qualitative criteria). There is thus a temptation to address a failure to meet criteria by changing the criteria first. This should be resisted, particularly where a feasible risk reduction option is available, since the project may be failing its ALARP duty.
7.2.7.3.
Risk and ALARP Evaluation may take place at various stages in the project, for example to support the various issues of Safety Case Reports. In the Demonstration and Manufacturing phases it is likely that the assessment effort will be provided by the contractor. Project Safety Managers need to monitor that the results of trials and tests are examined carefully and confirm or otherwise earlier assessments of tolerability, and the assumptions on which they were based.
7.2.7.4.
Unless the PSC actively seek Risk Reduction measures, ALARP can only be claimed through compliance with good practice. This may be a weak and inappropriate justification in many cases.
7.2.8. Procedure Completion
7.2.8.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 contractors. In all cases Project Safety Committee (PSC) members and other stakeholders should be involved in providing input and agreeing outputs.
7.2.8.2.
In large or complex projects, the Project Safety Manager shall co-ordinate Risk Estimation across the project to ensure that a consistent and coherent approach to Risk Estimation is adopted by all parties.
7.3. Timing
7.3.1. Production
7.3.1.1.
Risk and ALARP Evaluation follows Risk Estimation, and hence is an iterative process, commencing in Assessment and continuing through Demonstration and Manufacture as the design is refined. At each phase, the Risk and ALARP Evaluation will be a major input to the Safety Case Report
7.3.1.2.
In addition, any significant new hazards identified In-service will require Risk and ALARP Evaluation, and Risk and ALARP Evaluation for the Disposal phase should be updated with latest information in preparation and planning for Disposal.
7.3.2. Review, Development and Acceptance
7.3.2.1.
Each major update to the Risk and ALARP Evaluation shall be endorsed by the Independent Safety Auditor (where the project appoints an Independent Safety Auditor) and the Safety Panel, through endorsement of the Hazard Log and Safety Case Reports for Full Business Case, System Acceptance and Introduction to Service.
7.3.2.2.
If Risk and ALARP Evaluation is updated, management measures will ensure that the Hazard Log, Safety Case and other dependent activities are also updated. In particular any new requirements for Risk Reduction must be highlighted.
7.4. Required Inputs
7.4.0.1.
This procedure for Risk and ALARP Evaluation 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.
7.4.0.2.
The Risk and ALARP Evaluation methods and timing will be defined in the Project Safety Management Plan, if necessary with reference to the contractor’s Safety Management Plan.
7.4.0.3.
The Risk and ALARP Evaluation may use the following reference inputs, as available:
- Risk Estimation;
- Tolerability Criteria;
- System Requirements Document;
- Accident and incident history from relevant existing systems in service.
7.5. Required Outputs
7.5.0.1.
The primary outputs of the Risk and ALARP Evaluation are the Safety Case statements/evidence of tolerability of risks and documented ALARP justifications plus identified needs for Risk Reduction.
7.5.0.2.
Detailed information on tools and techniques for Risk and ALARP evaluation is provided in the Safety Manager’s Toolkit.
7.6. Version Control
7.6.1. Version 2.3 to 3.0 uplift
7.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.
7.6.2. Version 3.0 to 3.1 uplift
7.6.2.1.
Minor amendments to include removal of spelling mistakes, poor grammar and duplicated text.
7.6.3. Version 3.1 to 3.2 uplift
7.6.3.1.
Reference to 'Safety Manager's Toolkit' amended to 'ASEMS Toolkit' following the release of the Sustainable Procurement Tool.
7.6.4. Version 3.2 to 4.0 uplift
7.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.
7.6.5. Version 4.0 to 4.1 Uplift
7.6.5.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.
