It is important to ensure that the risk management approach is appropriate not only to the project size, style and complexity, but also to the projects 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.
As an 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 White Board, 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 current size, scale and complexity.
For example, a small, simple project to replace core IT network infrastructure can stop an organization working if it goes wrong.
It is important that the approach to managing risk works with and supports the Projex chosen delivery approach. As an example, a risk management approach that includes monthly risk review meetings is unlikely to effectively support and agile project delivery approach where deliveries may be happening every two weeks.
PRINCE2 does not mandate a 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 white board and reviewed as part of a daily standup meeting 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 projects delivery approach might work to mitigate or reinforced specific risks.
For example, an agile way of working inherently ensures that customers do not inappropriately constrain all and over specified requirements at the beginning of a project. This 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 pro cheese tends 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 who’s 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.
It might be appropriate to identify and rings cents an explicit risk budget within the project’s budget.
This is a sum of money to fund specific management responses to the project threats and opportunities, that is, to cover the costs of any contingent plans should a risk materialize.
The risk budget is based on the aggregate cost of all the projects planned risk responses.
For simpler projects it will usually be enough to add up the cost of all risk responses. 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 progress is, some of the risks previously identified will occur while 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, within 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 favor of the risk management approach defining the mechanisms for control of off, and access to, this budget
David spent 25 years as a senior project manager for USA multinationals, and has deep experience in project management. He now develops a wide range of project-related downloadable video training products under the Primer and Projex Academy brand names. In addition, David runs project management training seminars across the world, and is a prolific writer on the many topics of project management.