What to read first: Worst case analysis: When, why, and how
The main post discussed ‘cases’ for risks. There is always a reasonable worst case, and usually some other cases, each milder or more extreme.
Depending on the format of your risk register, you can represent cases of a risk in two ways.
- One risk record including multiple ‘cases’, each with a separate consequence and likelihood assessment. Depending on your pathway to risk evaluation and treatment, you may also need separate ‘level of risk’ or acceptability fields for each case.
- A separate risk record for each case, with cross references between cases of the common risk type.
|Risk register extract|
|Risk ID||Risk||Case||Case consequence description||Estimated case likelihood||Consequence criterion value|
|4||Staircase accidents||a||Reasonable worst||Someone has a staircase accident, suffers a bone fracture injury, and recovers within a reasonable time.||Low (indicatively, 15%)||Disappointing|
|b||Extreme||Someone suffers a bone fracture from a staircase accident, resulting in some level of permanent disability.||Very low (indicatively, 2%)||Bad|
|Risk register extract|
|Risk ID||Risk, with consequence description||Estimated likelihood||Consequence criterion value|
|15||Staircase accident – reasonable worst case: Someone has a staircase accident, suffers a bone fracture injury, and recovers within a reasonable time. (See also risk ID 16.)||Low (indicatively, 15%)||Disappointing|
|16||Staircase accident – extreme: Someone suffers a bone fracture from a staircase accident, resulting in some level of permanent disability. (See also risk ID 15.)||Very low (indicatively, 2%)||Bad|
The two representations are practically equivalent at the level of the risk register. Either way, there should be a good narrative explanation of each of the cases, and of their ratings. If your risk register is in a database or a rigid template, the two ways of showing ‘cases’ may lead to different formats.
If you persist in using ‘heat maps’, you may perceive a difference in the two representations, as the dot count or cloud sizes might change between the two ways of registering cases.
The consequence criterion value in your risk register may be called the ‘consequence level’, ‘impact rating’ or similar. Typically, it is a range on a consequence ‘scale’. There may be supported by a code indicating the affected objective, or the consequence type. Consequence criteria have been explored at length in previous posts. The consequence scale for the staircase injury example is here.
If you use a discrete scale for likelihoods, you might translate the likelihood percentages into discrete levels. The Clear Lines prefer to stick with percentages, with the qualifier that no likelihood percentage value is a numerical fact. Likelihood percentages should never be interpreted as either precise or factual.
Both representations of ‘likelihood’, and others, can be consistent with ISO 31000:2018.