Risk Management Plan Deliverable Template

From MIKE2.0 Methodology

The simplest type of Risk Management Plan is a "top-10 risks list. " This is the prioritized list of risks, and "the plan" consists of making sure everyone pays attention to it. The more formal approach to risk management is to factor it into the project schedule explicitly. This means that there will be development cycles whose purpose is to deal with risk issues

Examples

Listed below is an example Risk Management plan:

Example for a sample Risk Management Plan

INTRODUCTION

Purpose

Risk management is a critical process for managing uncontrollable project activities or circumstances that may result in negative consequences to project or product performance. The project team develops contingency plans to facilitate risk mitigation if agreed-upon conditions are not met. The primary purpose of this document is to:

• Describe the overall Approach to Risk Management for the XYZ Project.
• Describe the four key Steps of the Risk Management Plan:

1. Risk Identification;

2. Risk Analysis;

3. Risk Management and Mitigation; and

4. Risk Review and Monitoring;

• Illustrate application of the Risk Management Plan for DQ project work plan activities.

Scope

The process described in this plan is used to identify, assess, and document risks associated with the cost, resource, schedule, and technical aspects of the DQ Project.

Any risk that can impact the objectives of the XYZ project will be managed using this Risk Management Plan.

Roles and Responsibilities

The roles and responsibilities for performing the Risk Management Plan are as follows:

Table 1 1 Roles and Responsibilities

RISK MANAGEMENT METHODOLOGY

Overview

Implementing sound risk management procedures will minimise the likelihood and consequences of threats towards the overall success of the DQ Project. Whilst recognising that not all risk can be avoided, risk management practices aim to reduce the likelihood and adverse impacts of a risk event materialising.

The Risk Management Methodology defines the Steps as follows:

• Risk identification;
• Risk analysis and assessment;
• Risk management and mitigation; and
• Risk monitoring and reporting.

The four key steps of the Risk management Methodology will be described in detail, followed by illustrations of how the Risk Management Plan can be applied to work plan activities related to the XYZ Project.

Risk Identification

The first step of an effective Risk Management plan is to identify all risks associated with the XYZ project. It is recommended that two separate repositories be created specifically for the capture of risks and issues for the XYZ project. This will facilitate the tracking and monitoring of Risks and Issues for Project Management throughout the project phases.

Risk and Issue Management run hand-in-hand; the primary difference being a risk may occur, whilst an issue relates to an event that has occurred and requires some form of material response.

Once the Risk and Issues repositories have been established, they will then be used throughout the remaining stages of the Risk Management Plan to aid in mitigating risks and treating issues. Monitoring of both risks and issues throughout the life of the project is also facilitated by these repositories as part of Project Management Office activities.

Risk mitigation activities are pro-active approaches that seek to reduce the likelihood of risk events materialising. Where risk events do materialise and become actual issues, the appropriate treatment plans will be actioned with orderly responses to reduce the effects of the risk materialising.

Create Risks Registers

As defined earlier, a risk is an event that can have adverse impact upon the objectives of the XYZ project. Any identified risks throughout the life of the project will be recorded, tracked and monitored. As such, a repository will be required to store all risks deemed to have unacceptable levels of likelihood, consequence, or a combination of both.

All DQ project team members must have access to this repository, but Management of the repository should remain the responsibility of the Risk Manager. This will ensure the validity and completeness of the risk information in the register.

Create Issues Registers

As opposed to risks, which are events that may occur, issues are risk events that have occurred and require timely responses to minimise their effects on the DQ project. The likelihood of occurrence is therefore no longer a major factor, but rather the consequence of the occurrence.

Whenever an identified risk becomes an issue, or an unplanned event is identified as an issue through the course of the project, it must be recorded in the Issues Register. This enables the Risk Manager to gain a better perspective of where the issues lie and the impact they will have on the project, allowing for better management, monitoring, and recourse for impact minimisation.

Risk Identification Workshop

Risks may include technical, political, and managerial aspects of the project. Examples of risks to be managed include significant possibilities that the project could fail to meet its targeted objectives in areas such as schedule, cost, functionality, throughput or performance, reliability or availability, and use of critical resources.

Following the construction of the Risks and Issues Registers, all potential project risks must be identified. This will formally be captured through an initial Risk Identification Workshop. The identified risks will undergo an initial series of assessments before being populated into the registers.

Any member of the DQ team may identify issues or concerns that may prevent the project from progressing as planned. When a risk is identified, the team member will provide an initial assessment and report the potential risk to all other DQ team members via the Risk Register.

Verification of Identified Risks

Following the internally held workshops, the identified risks are presented to a targeted group of Project Subject Matter Experts (SMEs). The purpose here is to verify that the risks identified so far are legitimate risks that pose real threats to the success of the XYZ initiative.

It is also an opportunity for SMEs to contribute their own perceptions of risk to the XYZ Team, where the risks are then either accepted or added to the list of identified risks to be analysed and managed. SMEs will help the DQ Team to understand the risks and the impacts they pose on the project and their respective business areas.

Risk Analysis

The second step of the Risk Management Plan is to analyse the risks identified in step one.

In this process, the Risk Manager will gain a better understanding of the risks they are dealing with, and in doing so, will be able to categorise the risks by assessing the likelihood of occurrence and the consequence of occurrence.

A prioritisation of the risks will aid the Risk Manager to focus on the risks most likely to occur and/or most likely to have the biggest impact on the DQ project.

An action plan can be drawn up to help reduce the likelihood of occurrence and minimise the impact it poses on the project in the event that it does materialise. The responsibility of this action plan and the time frame in which it is invoked will lie with the risk owner, who is also identified in the Risk Analysis phase.

Understand Risk Impacts

Understanding the risks and the impacts they can potentially impose on the DQ project is crucial to the next step of Risk management, mitigation, and monitoring. Failure to understand the risks and their effects can lead to poor planning and execution of risk management practices.

It is therefore imperative that the DQ Team fully understand the risks that have been captured to try and reduce its likelihood of occurrence through mitigation, and/or to properly prepare a material response should the risk materialise.

A framework by which risk impact is measured must be determined. In cases where the risks will impact against cost, the impact can be measured financially in terms of potential monetary losses in the eventuation of the risk.

In cases where the risks will impact the project schedule, the impact can be measured in terms of set-back time to the project, which can then be translated back against the project baseline to measure the time cost in terms of financial cost.

An example of how risk impact might be quantified is tabulated in Figure 2

Figure 2 2 Example of quantifying risk impact

The importance of accurately measuring risk impact is demonstrated later in section 2.3.3 when the risks have been categorised and require prioritisation.

Categorise the Risks

Part of understanding the risks and their corresponding effects is to categorise the risks. This can be done by means of assessing the likelihood of the risk occurring and the consequences of the risk materialising to the project as a whole.

Likelihood is based on a subjective assessment by the Risk Manager, with input from the appropriate team members and SMEs, and is one of three categories:

Figure 2 3 Categorise the Risks

Consequence is also based on a subjective assessment by the Risk Manager, with input from the appropriate team members and SMEs, and can be one of three categories as follows:

• High – Risk that has the potential to have high impact on project cost, greatly delay schedule, or significantly impair performance.
• Med – Risk that has the potential to have some impact on project cost, slightly delay schedule, or slightly impair performance.
• Low – Risk that has relatively little impact on cost, schedule or performance.

Figure 2 of Section 2.3.1 illustrates a five-tier category rating for consequences, based on pre-determined quantifiable measures. Being a subjective assessment, it is up to the Risk Manager to determine the most appropriate means of rating risk impact.

The Risk Manager maps risk according to likelihood and consequence. This mapping results in a colour coding of red, yellow, or green and is then shown graphically in the Project Risk Map. The DQ Project will use the Project Risk Map shown in Figure 3 in order to facilitate the risk management process.

Figure 2 4 Project Risk Map

Prioritise the Risks

The Project Risk Map helps identify all risks that have been identified as being the greatest threat against project success.

Risks that have been given a Green colour coding ranks as low risk events that, while unavoidable, are acceptable in terms of likelihood and consequence. That is, the risk is recognised, documented in the registers, and communicated within the DQ Project Team, but no steps are taken to mitigate the risk as it is unlikely to occur. In the off chance that it does materialise, the effects can be readily contained with appropriate response actions.

Risks that have been given a yellow or red colour coding are the risks that require attention. These are risk events that are most likely to occur during the course of the project, and their consequences should they occur are severe enough to justify the preparation of proper mitigation and treatment procedures.

Between the risks highlighted in these red-flag areas, the most urgent of the risks must be first to receive mitigation and treatment attention. How these risks are prioritised may depend on the feedback from SMEs, possibly during a second workshop, or by more quantifiable means, such as using a scorecard system for measuring the risk (i.e. Probability of occurrence X Severity of consequence). Hence, the higher the probability of occurrence and the greater the impact of that risk materialising, the higher the priority is assigned to that risk.

Risk Owner and Action Required

Once the prioritised risks have been agreed upon with DQ team members and SMEs, action is required to identify the risk owner, establish the acceptable time frame for invoking any contingency plans, updating the risk register, and developing the risk action plan for mitigation and treatment.

The risk owner will assume responsibility for:

• Documenting the risk in the risk register;
• Monitoring and assessing the risk on a regular basis;
• Communicating the risk status to all stakeholders;
• Implementing appropriate risk management strategies to eliminate or minimise exposure; and
• Invoke contingency plans in the eventuation of the risk.

Timeframe for Required Action

The timeframe for the required actions must be established and agreed upon when identifying the risk owner and actions required of that owner. It must be decided how regularly the risk register is updated, how regularly the risk is monitored and re-assessed, when communications are required to stakeholders on the status of the risk, and the amount of acceptable time before invoking any contingency plans should a risk eventuate.

The agreed timeframe will be documented against each risk in the risk register.

Risk Management and Mitigation

Recording in Risk Register

The risk register plays a central role in the risk management plan. It is the repository in which all identified risks are documented and maintained, regardless of their category. Risks that have been closed should also remain in the repository for reference purposes in the event that the risk status is changed later in the project life cycle.

In addition to the risks themselves, details of the risk owners, any associated actions, and the timeframe for invoking those actions will also be documented against each risk in the risk register.

Access to the risk register will remain with the Risk Manager. However, for an effective and up-to-date risk register, it is recommended that risk owners also have access to their respective risks, and allowing them update privileges for those risks. This places the onus of risk responsibility back onto the risk owners.

Treatment Option

Given the priority listing of the identified risks to the project, action plans must be developed to mitigate these risks, and where risks become issues, develop treatment plans.

The Risk Manager, with input from the risk owner, SMEs, and DQ Team members, develops a mitigation strategy for each risk mapping as red or yellow that reduces the likelihood and/or consequence of the risk to an acceptable level. There are 4 mitigation strategies for managing risks:

• Acceptance  Where the likelihood of occurrence and/or impact of the risk is negligible to the project as a whole, the risk is accepted and a chance is taken that it will not occur. The risk is still documented, communicated, and monitored to ensure it remains at an acceptable level, but no further treatment is afforded to this type of risk. Risks that are accepted often fall into the green colour-coded category.

• Avoidance  Where the likelihood of occurrence and/or impact of the risk are too great to bear, then that aspect of the project is abandoned and alternative means are sought. In these cases, the risk is so great that the benefits would not be cost effective. Risks that are avoided often fall into the red colour-coded category in the upper top-right segment of the Project Risk Map, and often there are few mitigation strategies to reduce the likelihood and/or impact of the risk.

• Mitigation  It is widely recognised that all risks cannot be avoided, but most risks can be mitigated to reduce their likelihood of occurrence and/or the impact of the risk. A mitigation plan must be developed for each risk in the risk register to reduce the risk. It is then continually monitored to control the risk and to identify any residual risk that must be dealt with. There is often a contingency plan in place that will be invoked should the risk materialise.

• Contingency  Where a risk materialises and becomes an issue, the issue is documented in the issues register and the contingency plan against the risk is invoked. The contingency plan is essentially a back-up plan to address the project impacts of the issue.

Develop Risk Treatment Plan

For risks that have mitigation and contingency as their preferred treatment options, the Risk Manager, with input from the risk owner, SMEs, and DQ Team members, develops a risk treatment plan.

The risk treatment plan outlines the necessary mitigation steps to be undertaken that can effectively reduce the likelihood of occurrence and/or the impact of a risk to acceptable levels. It will also contain a contingency plan that will be actioned in the event that the risk is materialised.

It is the responsibility of the risk owner to enforce adherence to the risk treatment plan by all stakeholders, and to continually monitor the risk to ensure the risk management strategies are effectively maintaining the risk at acceptable levels.

In addition to the mitigation and contingency plans, the risk treatment plan should also identify:

• Responsibilities and accountabilities  in addition to the risk owner, the stakeholders have some responsibilities and accountabilities to ensuring the risk is contained to acceptable levels.

• Timetable for completion  for mitigation strategies, it is expected that those actions will remain active until the risk is closed. For contingency plans that are actioned, a timetable must be drawn up outlining when the plan should be invoked and its expected duration to completion.

• Expected Outcomes  implementing mitigation strategies seek to reduce the overall risk exposure. The expected outcome should demonstrate how the mitigation strategies have achieved that objective. Where contingency actions are in play, the expected outcome should demonstrate how the impact of a risk has been reduced.

• Budgets and reporting  where contingency actions are in play, the expected outcome may differ somewhat from the original objectives, and this may affect the overall project cost and schedule. The effects of invoking contingency plans on the project baseline and schedule should be explored in this section.

All information relating to the risk treatment plan should be recorded in the Risk Register, and where applicable, in the Issues Register as well.

Review Further Action and Allocate to Risk Owners

Where it has been determined that an existing risk should be a higher priority, the corresponding risk treatment plan must be reviewed by the existing risk owner with the Risk Manager, SMEs, and the DQ Team. Where deemed necessary, the treatment plan must be amended in accordance to the new level of threat that the risk now poses. It may also be necessary to allocate a new risk owner to the risk, as the consequence of the risk occurring may now involve a different or wider aspect of the project.

Risk Review and Monitoring

Risks are reviewed periodically based on their categorization. Documentation of these reviews should be maintained with the project documentation.

• Risks that map green should be reviewed quarterly with Senior Management.
• Risks that map yellow should be reviewed monthly with Senior Management.
• Risks that map red should be reviewed bi-weekly with Senior Management.

It is important to realize that the risk management process is iterative. Risks can occur at any time. Risks that are already identified will undoubtedly change in likelihood and consequence as the project develops.

Review Existing Risks, Mitigated Risks, and New Risks

For complete risk management, there needs to be continuous reviewing and monitoring of existing risks, mitigated risks, and any newly identified risks.

At each review stage, the status of the risk will be assessed to determine if it poses a greater level of threat to the DQ project, or if it is still being maintained at an acceptable level of risk. Depending on the status, it may be necessary to implement new mitigation strategies, continue with existing strategies, or invoke contingency plans. In cases where the risk is no longer relevant, it can be closed in the risk register.

Newly identified risks must be added to the risk register, and the process of analysing the risk must be undertaken.

Re-Prioritise Ongoing Risks

Risks that remain relevant to the DQ project and whose status has changed in the course of the project should be re-prioritised. There may be instances where the risks have increased and therefore they need to be pushed to a higher priority, and have their mitigation and contingency strategies re-evaluated.

Close Risks

Where risks are deemed to longer hold any relevance to the project, or where the likelihood of the risk occurring is negligible, the risk can be closed in the risk register. This essentially means there is no likelihood of the risk materialising. However, the risk should remain in the risk register for future reference in the event that the risk becomes relevant again.

Track and Monitor Plan Until Conclusion

By tracking and monitoring the risk treatment plan until its conclusion, the DQ project is insured against the risks identified as most likely to jeopardise project success. The risk owner should ensure that stakeholders are adhering to all mitigation strategies, that the treatment plan is on track, and that the likelihood of occurrence is minimised to acceptable levels. Any indication to the contrary should be reported to the Risk Manager and a decision must be made for the next course of action.