Risk Management

Risk Management

An introduction to risk management

A risk is something that might happen. It’s an uncertainty that might be good or bad for the project. An example of a “bad” risk might be a change in government policy which would mean an important government grant was withdrawn. A “good” risk is an opportunity. So a change in government policy might raise the profile of the project and provide access to an increased grant. This section focuses on mainly on managing risks that are likely to have a negative impact on the project, but it’s important to keep the flip side in mind as well.

Risk management helps you to do two things:

  • Reduce the likelihood of a risk occurring
  • Minimise the impact it will have if it does happen.  

There are four steps in the risk management process:

  • Identify
  • Analyse
  • Control
  • Monitor

The process is cyclical, as new risks may emerge at any point of the project lifecycle, and existing risks will need to be constantly reviewed and re-evaluated.  However, the risk management steps can be broadly mapped against the project stages (and their associated gateways) as follows:

Stage 1 - Project Mandate

 

Stage 2 - Project Proposal

  

Risk identification

Stage 3 - Business Case

Stage 4 - Project Start-Up

Risk analysis

Stage 5 - Project Delivery

Risk monitoring and control

Stage 6 - Project Close

 

Risk identification

It’s important to understand the potential risks to a project before making a decision on whether to go ahead with it. This step will help you to understand what those risks are so that, if the project is approved, you are more likely to be able to keep them under control.

Tips for identifying risks:

  • Involve other people in the process. For example, if you have an idea of who will be on the Project Team or Project Board, you could hold an informal workshop with them.
  • Use the information you’ve gathered so far and brought together in the project planning documentation to think about:
    - threats that may prevent or delay the achievement of the project’s objectives
    - opportunities that might help to achieve the objectives, or even exceed them.

An initial review of the potential risks associated with the project will be carried out as part of the Risk and Impact Assessment at stage 2 (project proposal).  At stage 3 (business case) you need to build on this to compose the risk description.  This describes the potential risk (what might happen) as well the impact (what the effect would be if it did). You might already be familiar with this way of writing a risk:

There is a risk that <risk> may happen, as a result of <cause>, leading to <impact>.

Where possible try to quantify the risk as well. This will make analysing the impact of each risk easier.  So you might write a risk as:

There is a risk that government funding is withdrawn [the risk] as a result of a change in policy [the cause] leading to a 10% cut in the overall project budget [the impact]. This would mean the loss of funding for one workstream manager on the project team and would extend the project duration by 6 months [quantifying the risk].

Once you have identified all the risks you can at this point, you should record them on the risk log. If possible, also summarise any controls (which will reduce the likelihood of the risk occurring) and mitigation (which will reduce the impact of the risk if it does occur), but you will be analysing these in more detail at the next stage.

Download the risk log template.

Risk analysis

You’ve already identified your risks so when you have more information about the project you can work out how big the risks are and how we can control them. You should involve the Project Team and Project Board (if you have one) in this process, usually in the form of a risk workshop during the project start-up stage.

The risk workshop is usually led by the Project Manager, but you can get help or advice from the Directorate Programme Manager and Risk Management Unit. By the end of the workshop, you will have developed a comprehensive risk register for your project.

Before the workshop you need to agree what the risk tolerances are. A risk tolerance is sometimes called a ‘pain threshold’ and is used to identify how much of an impact the Project or Programme Board will allow a risk to have before taking action.

We usually define risk tolerances in relation to four categories:

  • Meeting the project objectives
  • Impact on service delivery
  • Finance
  • Reputation.

For each of these, you need to decide how big an impact you are prepared to tolerate, using four levels – Negligible, Low, Medium or High. There is a standard risk tolerance table included in the Risk Register template, but you might need to tailor this to suit your specific project.

A simple example of a financial risk tolerance could be:

  • Over/underspend of less than 10% has a low impact
  • Over/underspend of 10-25% has a medium impact
  • Over/underspend of more than 25% has a high impact.

At the risk workshop you should:

1.

Review the list of risks you've already identified and recorded on the risk log. Are there any new ones? Can any be removed? Copy the risk desciption into the risk register, clarify the type of risk and assign a risk owner.

Then for each risk:

2.

Identify the current controls: What is being done to control the risk already, and is this adequate?

3.

Decide how likely it is that the risk will happen: Is it unlikely, plausible, possible, or probable?

4.

Use the tolerance table to decide how much of an impact the risk would have if it occurred.

5.

Calculate the current risk level, which is determined by the likelihood and impact. This shows you which risks are the most important and should be addressed first. (The spreadsheet will do this for you automatically, but the categories are shown in the table below).

6.

Identify the target risk level, based on the risk tolerance and the opportunity to improve the risk controls  (Some risks will always have such a big impact if they do occur that it will not be possible to reduce the risk level below amber.)

If the current risk level is either Red or Amber, and you decide that the current controls aren't adequate:

7.

Decide what additional actions are required to reduce the risk to the target level, assign someone to take that action and set a deadline.

Once you've done this, you have all the information you need to complete the project Risk Register

Download the Risk Register template

 

 

Impact

 

 

Negligible

Low 

Medium

    High   

Likelihood

 

      1     

      2     

      3      

  4  

High

4

4

8

12

16

Medium

3

3

6

9

12

Low

2

2

4

6

8

Negligible

1

1

2

3

4

Risk control and monitoring

There are two elements to controlling and monitoring risks when the project moves into its delivery stage:

  • Managing existing risks
    As part of the risk analysis you identified actions that needed to be taken to reduce the risk. Part of your job is to make sure these actions are completed, and then re-assess the risk to see if it’s had an effect, following the process you went through before. Of course, you might not be able to reduce the risk and you may have to accept that the risk will remain.
  • Identifying emerging risks
    Risk management isn’t a one-off “tick box” exercise. Risks and opportunities might present themselves at any time. Part of your job, and the Project Team and Board, is to ‘scan the horizon’ to identify these. But remember that neither you nor the Project Board has the monopoly on identifying risks. Anyone can identify a risk, and they should all be logged and analysed.

It’s easy in the hustle and bustle of managing a project to forget to keep the risk register up to date. It’s absolutely essential to effective project management that you take time out to do this, especially in advance of Project and Programme Board meetings in order to identify any risks that might need to be highlighted to the Board or escalated to the next level for advice or assistance.

Stage Reviews for projects in delivery will also provide an opportunity to review the risk register in detail.

ProjMann