Skip to main content

https://sfadigital.blog.gov.uk/2015/02/21/risk-management-for-agile-programmes/

Risk management for Agile programmes

Posted by: , Posted on: - Categories: Projects

In this blog post I take a look at how we identify, analyse and manage risk on our projects.

Risks are things that might negatively affect the outcome of a project. Risk is the direct result of uncertainty. If something is certain to occur, it's not a risk, and needs to be managed differently.

Risk analysis helps us understand and quantify the risks.

Risk management (sometimes called risk mitigation) is the plan we put in place to pre-empt, contain or mitigate the effects of risk on our project.

The important thing to remember is that even in simple programmes, things can go wrong, and we need to make plans to minimise their impact.

Yes, risk taking is inherently failure-prone.  Otherwise, it would be called sure-thing-taking.  Tim McMahon

 

Five step approach to Agile risk management 

  1. Identify
  2. Classify
  3. Quantify
  4. Plan
  5. Act
  6. Repeat (yes, this is a sixth step but only five need consideration)

 

Identify the risks

Risk SWOT analysis
Risk SWOT analysis

When identifying risks, we look for things which could be helpful (positively affect the project), or harmful (negatively affect the project).

We also look for risks which are internal (inside the organisation or within the project's influence) or external (outside the organisation or outside the project's influence).

We can combine these into a classic SWOT analysis of our project's  strengths, weaknesses, opportunities, and threats.

Classify the risks

Each risk needs to be categorised. A common way to do this is to categorise by:

  • the area it affects
  • the likelihood of it happening
  • the level of impact it could have on the project

 

Quantify the risks

Risk matrix
Risk rating matrix

So that we can measure risk and decide which deserve most attention, a subject matter expert should apply values to each risk's probability (how likely is it that it will occur) and impact (how bad it would be if it occurred).

Impact scores

  1. Very low: insignificant delay, reduction of quality, or increase in cost
  2. Low: minor delay, reduction of quality, or increase in cost
  3. Medium: moderate delay, reduction of quality, or increase in cost
  4. High: major delay, reduction of quality, or increase in cost
  5. Very high: catastrophic delay, reduction of quality, or increase in cost

 

Probability scores

  1. Very unlikely to occur (0 – 10% chance of occurring)
  2. Unlikely to occur (21 – 40%)
  3. Fairly likely to occur (41 – 60%)
  4. More likely to happen than not (61 – 80%)
  5. Very likely to happen (81 - 100%)

We multiply a risk’s impact score by its probability score to get its risk rating.

Plan and take action to pre-empt, contain or mitigate the effects of risk

Specific things have to happen, according to a risk's rating:

Risk score policy

RAID

In my next blog post, I'll look at how we used the RAID  (Risks, Assumptions, Issues and Dependencies) to manage risks on one of our agile projects.

Sharing and comments

Share this page