Agile Risk Management – The difference between Risks and Issues
A Risk is an uncertain event that could impact your chosen path should it be realised. Risks are events that are not currently affecting you – they haven’t happened yet. Once a risk is realised, it has the potential to become an Issue.
It is important to point out that not all risks become issues. Some risks materialise and are absorbed into a sprint/project/programme with negligable or no impact at all.
The aim of risk management is to either…
1) prevent the realisation of a risk or;
2) to minimise/manage/neutralise the impact of this risk once it has been realised.
If you succeed in point 2 then the net impact of realising the risk may be totally acceptable i.e. no issue at all.
Risks may be attributed to Political, Environmental, Societal, Technological, Legal or Economic (“PESTLE“) factors.
We use two measures to describe a risk:
- The probability/likelihood of it being realised
- The impact it will have if it is realised
The field of Probability is a really complex science (Actuarial Scientists make a career of it!) – I once spent a month attempting to calculate the likelihood of a High School student achieving an A-grade. Despite considering over 100 input factors, there was always something else that could affect the outcome e.g. video game preference, choice of pet and favourite TV show. I could have gone on for years.
In faced-paced, dynamic environments like Software Development or Digital Publishing, we don’t generally have the luxury of spending weeks trying to figure out whether something is going to happen or not. We need to respond quickly and use our judgement to identify actions/activities that will help us to:
- Accommodate the potential outcome and;
- Make the potential outcome work to our advantage (if possible!).
Risks vary in impact severity – some have the ability to dramatically affect your preferred path, whilst others come and go without much notice.
A simple way of classifying a risk is through the use of a grading scale e.g. 1-5 or a Fibonacci sequence, with 1 being low impact/likelihood and 5+ being high impact/likelihood. For example:
- A User Story is severely underestimated in the first sprint, compromising the team’s ability to deliver their commitments (1,5)
- A User Story is severely underestimated in sprint 10, compromising the team’s ability to deliver their commitments (5,1)
In the first example, the Impact is low and the Likelihood is high. Most teams take a few sprints to find their pace. Business expectations are managed to this effect and there’s a strong chance that the schedule has been designed to assume a high degree of uncertainty during this time.
In the second example, the Impact is high and the Likelihood is low. We would not expect an established team to severely underestimate a User Story. As such, the impact is likely to be much higher.
For these types of classifications, you need to first agree on what would constitute a ’1′ or a ’5′ as you’re measuring the relative impact/likelihood of a set of risks. I accept that this is a less precise way of assessing risk but it seems to do the trick nevertheless
It is also important to point out that risks are usually thought to be all bad. Fact is, the net impact of realising a risk can be either positive or negative. With that said, positive risks are more regularly referred to as ‘opportunities’ and as such are handled differently.
Some examples of positive risks are:
- A User Story estimated as a ’21′ turns out to be far less effort than anticipated
- The design of the release plan enables the project to become self-funding within three sprint
Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!
Related Articles:
- Agile Issue Management for Projects and Programmes (agile101)
- Agile Risk Management for Projects and Programmes (agile101)
Good article, and I STRONGLY ENCOURAGE everyone to read Andy Bruce's earlier response. Andy has nailed the often missed point ...
You have completely demonstrated the whole scheme of software development within the above diagram on such a fine way. Truly ...
Great explanation, nice set of picture, this is exactly what I needed to show to people in my business the ...
Often the challenge with a project plan, is that in the earlier stages of a project very little due diligence ...
With all due respect to an otherwise factual and simple explanation of risk, an “issue” is not a realized risk… at least not always.
When contingency plans are in place, trigger identified and monitored, resources available and up to speed, there is no “issue.” It’s (the contingency) just another piece of work (the story defined previously). There is nothing to analyze, nothing unknown, just execution. It’s not an issue.
Hi Woody.
Thanks for pointing that out! I’ve amended the intro slightly as my wording was somewhat missleading.
Tara
Woody,
In Agile environments, one of the things you are trying to minimize is too much upfront work on developing contingencies that have a low probability or detrimental effect. You only want to build contingencies you really need and preferably just-in-time.
Tara – great article; I’m sharing ti with some co-workers!
Cheers!
Paul
Hi guys
currently in my organisation there is a pm methodology in place where they are adamant that issues are realised risks.
firstly, I personally don’t agree with this myself, but secondly i am trying to find information on the internet regarding PMBOK & their take on issues vs risks and there is no clear information anywhere regarding this…
can anyone refer me to specific information so I can explain to the people I am working with why an issue is not always a realised risk
thanks
mt
Why do you believe that “issues” are not realised risks? Do you believe tasks and projects will be completed more consistently or successfully by treating issues as something other than realised risks?
Regardless of known methodologies, how would you handle the types of “issues” you’re speaking about if you were in charge of your organization’s PM office?
Hi Roberto/Taylor,
All issues are indeed realised risks, however not all realised risks are issues.
An issue describes a negative event/situation that has happened or is happening.
A risk describes something positive or negative that *might* happen in the future – a possible event(s), which deviates from our expected outcome.
Truth is we don’t usually track positive risks in the same way as those which may disrupt our ideal path… we just pray/look forward/try our best to realise them!
Tara
Hi all — I enjoyed reading the above comments since this is always an ISSUE in understanding the workings of risk management (RSKM). Perhaps some confusion is in how we are using the word “realized”. Here is what I have taught my RSKM classes in the past and seems to have worked:
There are three steps of progression to realizing impact to your project:
1. You have a risk – the probability is greater than zero but less than 100%.
2. As the risk is “realized”, its probability moves to 100%. When it is regarded as 100% in all practicality, it becomes an issue. An issue exists in that small time zone between the risk turning 100% probability and getting an impact on your project. To be sure there is a risk associated with any issue – If the issue is not resolved, we would get the impact as described in the risk. Note that the uncertainty is now with resolving the issue. In agile daily scrum meetings many times the risk is discovered as an issue.
3. If the issue is not resolved, you should get the impact and then you have a problem. There is a residual risk with the problem in that if you do not solve the problem, the impact could get worse.
Consider an easy example to be an asteroid impact on the Earth. Currently there is a finite risk of a certain size range of asteroid to hit the Earth within the next 10 years. (There are many Earth orbit crossing asteroids.) Suppose tomorrow a group of credible astronomers and astrophysicists come out and say a particular asteroid will hit the Earth on its next orbit in about a year and a half. We no longer have a risk; we have an issue. If this issue is not resolved and the asteroid hits the Earth, we no longer have an issue; we have a problem – (or problems in this case – no place to live, bad weather, no food, no law & order, missing relatives, no gas for my car, no car, …). There are risks associated with each of these problems and it goes on and on.
Thanks for any comments – Mike Helton, Senior Risk Manager ()