Recently we have been working with a client where there was much debate about the legitimacy of some of the Risks recorded in their risk registers. We recalled a similar challenge when working with another client in the past where I wrote the paper on which this article is based to present the views of those involved in the discussion.
This article seeks to provide guidance on what constitutes ‘Uncertainty’ and what should be included as a ‘Risk’ event. It ultimately seeks to ensure that Uncertainty and Risks are incorporated consistently within estimates and schedules. In the following text, this is achieved through indicating the sorts of challenges that we could adopt to distinguish between legitimate Risks and those items that constitute Uncertainty around planned activities.
I’ve posted this article in the hope of initiating some useful debate about how best to determine the legitimacy of Risks and whether Uncertainty should be recorded in the risk register or if there is a more effective approach for managing them separately. We would be interested to hear your views and approaches that you/ your clients take. If you have no objection, I’d like to incorporate some of the learning from the debate and provide an improved version of this article once a wider understanding of the various viewpoints has been collated.
Distinguishing Uncertainty from Risk events
Where a source of uncertainty has been identified, clarity is required as to whether it is Uncertainty or a Risk event. This can be established by asking the following question:
“Will the impact of the identified uncertainty lead to additional activities being added to the plan, or would it result in only increasing the durations and costs of existing activities?”
Where Uncertainty represents variability around planned activities, Risks represent alternative unplanned outcomes that could give rise to additional activities, costing more and extending timescales.
If the area of uncertainty will lead to extra activities/ work scope being added to the plan, it could be a valid Risk. If the activity/ work scope does not change but merely costs more or takes longer, it should be considered as Uncertainty.
Uncertainty
An item which is a known element of delivering the project is certain to have an impact during its delivery and so this should be part of the base estimate/ plan. When estimating these values, it is often done with incomplete knowledge and so, in order to ensure this is adequately reflected in a model, a range is applied which reflects the level of confidence in this value.
Uncertainty could be defined as
“…the variability in the estimated value (cost or duration) of a planned activity/ known scope…”
Cost Uncertainty ranges should consider variation in estimated quantities and unit rates (e.g. uncertainty in work content, labour rates, outputs, the pricing and quantities of equipment and materials).
Duration Uncertainty ranges conversely should include any factors that could influence the duration of planned activities such as the production rates of planned tasks.
At an early stage where no firm quotes and limited appreciation of how the project will be implemented have been established, there is likely to be a broader uncertainty range than where quotes have been received, design has been progressed and a clear approach has been planned. This is effectively illustrated in the commonly used diagram below:
Figure 1: Illustration of Estimating Uncertainty
Where variability is included within Uncertainty ranges rather than Risk, this does not imply that the uncertainty is trivial or does not require significant and specific control. The management and progress of individual activities can have a major effect on the project outcomes and this activity is central to a Project Manager’s role supported by Project Controls (i.e., through managing Issues, engaging stakeholders and driving efficiencies in the overall delivery of the project). I would be interested in views of whether this should be recorded in the risk register or if there are other ways you have seen this managed effectively.
Risk
Risk events represent further costs or timescales to deliver activities that were not originally planned/ anticipated. Risks are subject to quantitative assessments where the probability of occurrence is always assigned a value of less than 100%. This contrasts with anything which is a part of the base scope, having a 100% likelihood of happening.
If an event is incorrectly added as a Risk rather than included in base costs with associated Uncertainty ranges, this is in effect underplaying the Risk exposure since there is 100% chance of this event happening. Clearly it is better that the project sets aside the whole cost that is needed to deal with an event than only the proportion that is included in contingency when weighted by probability.
There are numerous definitions for a Risk but what they all have in common is that they are an uncertain event and they have the potential to impact on the achievement of planned objectives.
APM defines a Risk as:
“…an uncertain event or set of circumstances that, should it occur, will have an effect on achievement of one or more objectives…”
The ISO 31000 definition distils this to the basic essential features:
“effect of uncertainty on objectives”
What this description does miss is distinguishing between an event and uncertainty around planned activity.
A Risk is an uncertain event; if it is something that is within the project’s knowledge (i.e., they know it will happen), then this is known scope. Where a Risk has a very high chance of happening, we are essentially saying it is ‘almost certainly’ going to happen; in this instance it is better incorporating it in the base estimate. Furthermore, where a Risk has already impacted, this no longer represents an uncertain event (it is now an issue) unless there is a chance that the Risk could impact again. If it could happen again, the Risk should be retained on the Risk Register, evaluated to reflect the chance of it re-occurring and controls strengthened by taking lessons from previous experience.
It is important to consider context when establishing whether an area of uncertainty is a legitimate risk; for example, by understanding what has been included in the current base estimate/ plan. If contaminated land is being excavated, then we should have allowed for some variability in the base estimate. Alternatively, if we’ve assumed the land is free-release then a Risk could be that the land is found to be contaminated. Understanding the variables allowed for and not allowed for within the base estimate/ plan determines whether certain considerations might be allowed for as Uncertainty or included as a Risk.
I’ve tried to summarise the key points above in the following flowchart which asks a series of questions to help determine whether an area of uncertainty should be captured as a Risk event.
Figure 3: Is it a risk?
The above challenges can help drive the identification of the true underlying Risk through discussions with the project team. It is important that the challenged risk is not eliminated without a detailed discussion to ensure that it is adequately captured and appropriately factored into any modelling that is to be undertaken. It is possible that the area of uncertainty initially raised is not a legitimate Risk but the discussion that the project team embarks upon to defend their Risk may give rise to the actual Risk event.
The main intent of this article was to canvas opinion on what should be recorded in the risk register and if ‘Uncertainty’ should not be included, is there a pro-active process whereby this key area of uncertainty is effectively managed. Please let me have your comments as I would value your views.
