PRINCE2 Guidance for effective risk management
Align with organizational and other policies and processes
A project may need to align its risk management approach with organizational, programme or portfolio policies, standards or processes. This might include:
- aligning with any centrally defined risk management policies, standards and approaches
- using any centrally defined risk management techniques
- adopting any centrally deployed tools
- aligning with any centrally defined risk management roles or competency frameworks.
Organizations will often require that a consistent, mandated process is used across different projects, typically to ensure they can assess the overall risk exposure of the organization across projects.
This will also be the case when organizations are seeking to develop their project management maturity using a maturity model such as P3M3
Recommended risk management procedure
PRINCE2 recommends, but does not mandate, a risk management procedure based on Management of Risk: Guidance for Practitioners (Office of Government Commerce, 2010).
The procedure consists of five steps, the first four of which are sequential:
- identify: context and risks
- assess: estimate and evaluate
‘Communicate’, the fifth step,’ operates in parallel as the outputs of any of the other steps may need to be communicated to stakeholders at any point in the process.
All the steps are repeatable. When additional information becomes available, it is often necessary to repeat earlier steps based on the new information.
Understand the project board’s attitude to risk
A key decision that needs to be recorded within the risk management approach is the project board’s attitude towards risk-taking. This will determine the amount of risk that is acceptable and will, in turn, help set risk tolerances.
Example of risk tolerance
A large electrical retailer would not tolerate any disruption to its core retail or warehouse systems during the peak trading period extending from November through to January. During this period, it does not allow changes to these systems unless they are needed to keep the company running.
A project would need to escalate to the project board any risk that might impact these systems during this period.
Project size, scale and complexity, and risk impact
Ensure that the risk management approach is appropriate not only to the project’s size, scale and complexity but also to the project’s likely risk impact. It is important that the risk management approach for a project supports effective decision-making on the project and does not create an undue burden or bureaucracy.
In general, smaller, simpler projects will need correspondingly simpler risk management arrangements.
For example, on a less complex project the project manager would typically directly undertake most risk management activities. However, on more complex projects these activities might be delegated to a dedicated risk manager or risk management team.
Similarly, a risk register might be held in a simple list on a whiteboard, in a spreadsheet or in a dedicated IT system. What is important is that the risk management approach is appropriate.
In determining the appropriateness of the risk management approach it is critical to consider not just the project’s cost, size, scale and complexity but also the potential scale of risk impact from the project.
It is possible for projects to create impacts that far outweigh their apparent size, scale and complexity. For example, a small, simple project to replace core IT network infrastructure has the ability to stop an organization working if it goes wrong.
Project delivery approach
It is important that the approach to managing risk works with and supports the project’s chosen delivery approach. For example, a risk management approach that includes monthly risk review meetings is unlikely to effectively support an agile project delivery approach where deliveries may be happening every 2 weeks.
PRINCE2 does not mandate a particular format for risk management products, nor does it mandate specific timings for risk management activities. What is important is that they are appropriate for the format and pace of the project.
A risk register may be written on a whiteboard and reviewed as part of a daily stand-up meeting (see section 184.108.40.206) as part of an agile delivery approach. In this context it is just as valid as risks stored in a dedicated IT system that is reviewed at a monthly meeting.
It is also important to recognize that the project’s delivery approach might work to mitigate or reinforce specific risks.
For example, an agile way of working inherently ensures that customers do not inappropriately constrain and over-specify requirements at the beginning of a project, which can be a risk in a more traditional ‘waterfall’ approach.
Similarly, even though agile is characterized by a high level of engagement with customers directly involved in the project, it can lead to uncontrolled changes to the agreed baseline if not managed correctly.
More traditional approaches tend to reinforce the impression of ‘controlled change’, but at a risk of appearing unresponsive.
What is important is that the risk management approach recognizes these inherent differences
In a commercial context there may be a need for more than one risk register as some project risks could be unique to only one party, with good reasons for them not to be visible to the other party. Where a joint risk register is used, care should be taken to establish whose risk it really is, and the risk owner appointed accordingly.
For example, on a fixed-price contract any cost overruns will impact the supplier’s business case, but timescale overruns will typically impact the customer’s business case.
Establishing a risk budget
It might be appropriate to identify and ring-fence an explicit risk budget within the project’s budget. This is a sum of money to fund specific management responses to the project’s threats and opportunities (e.g. to cover the costs of any contingent plans should a risk materialize).
The risk budget is based on the aggregate cost of all the project’s planned risk responses. For simpler projects it will usually be enough to add up the cost of all risk responses.
However, for more complex projects care needs to be taken that the aggregation of the factored costs is not skewed by a small number of large risks. This is where analytical techniques, such as Monte Carlo simulation and associated software tools, can help.
As the project progresses, some of the risks previously identified will occur and others will not. New risks may be identified during the life of the project whose response costs will not have been included within the risk budget. This means that it is prudent to include a provision for unknown risks (yet to be identified) in the risk budget.
As the risk budget is part of the project budget, there may be a tendency to treat it as just another sum of money that the project manager can spend. This culture should be discouraged in favour of the risk management approach defining the mechanisms for control of, and access to, this budget.