Introduction to Risk management
Risk management is a process that allows individual risk events and overall risk to be understood and managed proactively, optimizing success by minimizing threats and maximizing opportunities.
This document aims to provide a quick reference guide to assist those undertaking risk management activities on a project, highlighting some key aspects and areas of best practice to incorporate. It is not intended to be a comprehensive description of the risk management process and nor does it replace the Project Management Framework or Corporate Risk Management Strategy.
Risk Management Process
Project risk must be assessed, reviewed, and actively managed throughout the project life cycle. All projects should be assessed for technical, safety, financial and other risks, with preventative actions and contingency plans developed for the more significant risks.
The Project Management Plan or (a separate Risk Strategy) should document how risk is going to be managed on the project. This should include:
- How risks will be assessed (scoring methodology)
- How differently scored risks will be treated and prioritized
- How often the risk management plan (also called a risk register) including control measures, will be reviewed, and by whom
- When and how risks will be escalated.
Identify and record risks
A risk is an uncertain event or set of circumstances that, should it occur, will have an effect on the achievement of one or more objectives.
Project Risk Identification
Risks can be identified at any time during the project life cycle as risk management is a continuous and ongoing process.
During the conception phase, it is important to consider the events that could prevent the project from achieving its overarching objectives; this could help decision-makers determine if the project is feasible.
In the definition phase, once project objectives are defined in the project management plan, risks to achieving these objectives must be carefully identified. A risk identification session could be a workshop with the project team facilitated by an impartial person or the project manager.
Risks should continue to be identified throughout the implementation phase either through regular project reviews or in specific risk meetings (recommended for more complex projects). Everyone involved in the project should be encouraged to highlight risks and suggest solutions.
Identified risks should be logged in a risk management plan (risk register). Once risks have been added to the document it should remain a live document throughout the project lifecycle being reviewed regularly and updated as things inevitably change.
Clear risk descriptions are vital to:
- Fully understanding the risk, resulting in a better assessment of the potential impact and the possible solutions
- Communicate effectively with stakeholders, minimizing the chance of misinterpretation.
To clearly describe a risk there are three aspects that need to be included in the statement: the cause, risk, and effect:
Analyzing and prioritizing risks
The methodology for scoring risks should be defined and agreed upon with the Project Sponsor/Board. This avoids differing interpretations and helps prioritize risks, therefore optimizing efforts to focus on mitigating the most severe threats. A useful tool for this is to agree on scoring criteria, noting that:
- The level of detail should be proportionate to the complexity and value of the project
- The exact criteria should be tailored to the project’s specific circumstances, taking into account things like risk appetite (how much risk the organization is prepared to accept on the project) and the specific constraints (on this project is meeting the schedule more important than coming in on budget or vice versa?)
- It may also be useful to incorporate risk proximity into your scoring and prioritization ie. how soon is the risk likely to be realized if it is not mitigated.
- Assessment of project risk will also feed into the corporate risk management process using the categorization criteria set out in the corporate risk management strategy.
Example: probability scoring criteria
Example: impact scoring criteria
When defining the scoring grid keep in mind the calculation that the STFC risk register template performs to generate the RAG status in order to develop criteria that give a sensible spread:
Quantification of risk
STFC’s Project Management Framework includes the need to calculate an agreed amount of contingency and/or working margin as a direct result of risk analysis5. To do this the cost impact of risks must be quantified to at least the same level of detail required to score risks in a consistent.
For some projects this level of quantification is sufficient however in other cases, particularly on larger or more complex projects, putting more effort into detailed risk quantification can enable the application of more sophisticated risk analysis techniques such as Monte Carlo analysis which can be used to calculate the likelihood of meeting the project budget or completion date.
Once risks have been assessed, proportionate mitigation actions and control measures should be planned. The aim of the planned activities should be to respond in the most appropriate way to achieve one of the following responses:
Implement and Monitor
Once the planned control measures and mitigation actions are implemented, their effectiveness should be regularly reviewed (at an interval specified in the Project Management Plan) to ensure that they are having the intended effect and allow re‐planning if additional action is needed.
The full risk register should also be regularly reviewed with new risks identified and updates made to any risks which have changed. The frequency of this review and who undertake it should be documented in the Project Management Plan.
Active risks and their management should be a key element of project reporting both to help the Project Manager best understand and manage risks to the project and to effectively communicate these risks to the Project Sponsor and other stakeholders (Project Review Committee, Audit Committee, Executive Board), including escalating risks to the Project Sponsor where appropriate.