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 (mr.helton@verizon.net)

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

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?

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

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

Thanks for pointing that out! I’ve amended the intro slightly as my wording was somewhat missleading.

Tara

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.