Risk Management 101

On this page, you will learn the following:

  • What a risk is

  • Why you need to manage risks

  • The general risk management process

What is a risk?

Before looking at risk management, we need to understand what a risk actually is. The PMBOK gives a good definition - “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, or quality.”

When describing risks, we usually want to the cause, the affected area, and the consequences. Let’s look at an example risk given in the PMBOK - “due to the forecast of high winds in our area, there is a risk that the roof of the barn will blow off causing our cattle feed to be ruined and loss of our livestock”. Here we see the cause (high winds), the affected area (barn roof), and the consequences (loss of livestock).

Let’s look at another example, this one perhaps more familiar. “Due to ongoing support demands, there is a risk that the Senior Programmer will be shifted from the project, causing a delay in the schedule”. Here we see the risk cause (ongoing support), the affected area (the Senior Programmer) and the consequences (a delay in the schedule).

Why manage risks?

Project managers are given the objective of delivering a project within scope, schedule, cost and quality constraints. Risks are those events which can directly impact upon those objectives. Therefore managing risk is an essential part of the project management process.

There is a saying among project managers – “control your risks, or they will control you.”

The risk management process

The risk management process consists of the following steps -

  • Identification

  • Analysis

  • Treatment

  • Monitoring

We will describe each of these in detail.

Risk Identification

Your first step is to identify all of the key risks in the project. You do this by consulting with stakeholders and Subject Matter Experts. If you have a Project Management Office in your organization, they may well have a list of common risks. Some typical project risks are list at the end of this document.

Risk Analysis

Your next step is to assess the severity of each risk. You do that by first assessing the probability of each risk. A simple probability scale looks like this:

  • Unlikely

  • Likely

  • Very Likely

You must next assess the impact of a risk, which describes how big an impact the risk will have on a project if it is triggered. A simple impact scale looks like this:

  • Minor

  • Moderate

  • Major

Cross reference these on the following axis, to get an overall severity rating of Low, Medium, High or Extreme for each risk –

Risk Treatment

For each risk, you usually want to devise a treatment strategy. Typical options are:

  • Accept Do nothing about the risk, and accept the possible consequences
  • Avoid Don’t perform the activity that is causing the risk. For example, if a feature in a software development project looks like it might cause delays, you could choose to not develop that feature.
  • Mitigate Devise a plan to reduce either the probability or the impact of the risk. For example, you could add extra resources to the project.
  • Transfer Make another party responsible for the risk. For example, you could outsource the activity

Your treatment strategy will depend upon the severity of the risk. When you choose to avoid, mitigate or transfer a risk, you will need to provide details of how this will be accomplished.

For each risk, you should also define a contingency plan. This is a pre-defined set of actions that will be undertaken if the risk is triggered. An example contingency plan would be, “Schedule an immediate meeting of the Project Steering Group to resolve the problem.”

Risk Monitoring

Having identified, analyzed and treated your risks, you will need to actively monitor them. The frequency of this monitoring will vary – for example, you might elect to monitor the list weekly. There are three steps to the monitoring process –

  • Close - Look through the risk list and determine if any of the risks can be closed. Risks can be closed when the conditions causing the risk are no longer present. For example, if a risk applies to a particular phase of a project, that risk can be closed once that phase is over.

  • Update - Check the open risks to determine if the probability or impact has changed. If so, modify the appropriate field and leave a comment explaining why.

  • Identify - Finally, determine if any new risks have arisen since you last monitored the list. If so, you will need to analyse and treat those risks, as per the instructions above