5

There is a major replacement/upgrade project in flight. The project touches on a number of existing systems that are not being upgraded some of which have business as usual issues e.g. lack of support, unauthorized installations, etc.

It is unknown what impact this may have on the delivery of the project.

Should the issues with the existing systems not being upgraded be captured as either as risks or issues?

  • If no, why?

    If yes, why?

  • 3
    The canonical answer is that a risk is something that may happen, an issue is something that has happened. But see my comment under @David Espina's answer around how valuable the differentiation is.... – Doug B Oct 15 '15 at 17:51
5

I'd say it is a risk because of the possible lack of maintenance and support. For example, lack of support has a high risk on delivery because you have to figure out the solution with small or non existing domain know-how.

5

This confusion about whether something is an issue or risk is a HUGE waste of time. It comes down to how one structured the event in one's mind. Are you focusing on the current problem being experienced or are you focused on the future? Are you being tactical or are you being strategic? Are you trying to cure the high blood pressure, the obesity, the high cholesterol, or are you trying to mitigate the heart attack and early death?

As you can clearly see, issues and the risks are linked. So where you log it and how you communicate it and how you work it all depends on where your focus is. If you are the leader, your focus is likely downstream, in the future, where strategy lives. Risk. If your a worker, your focus is likely here and now, getting to the end of the week, completing a task or sets of tasks. Issue.

But at the end of the day, where it is logged doesn't matter. What matters is you are mitigating the heart attack by curing the BP, obesity, cholesterol, etc.

  • +1 for the differentiation of risks and issues isn't a good use of time. Just have an "Issues/Risks" log instead of worrying about the differentiation. – Doug B Oct 15 '15 at 17:49
  • Agree to a large extent, however some understanding of the differentiation (or more so relatedness) is important to prevent double counting. Eg an issue will often inflate risks in multiple areas, if you don't call out this dependency (resolve the issue, the risks are mitigated) it can make things appear much more dire than they are. – mwan Oct 15 '15 at 22:57
5

I strongly support David's approach: the whole discussion isn't worth your time. It's something that everyone - specially, stakeholders - must be aware of. I'm just not 100% sure if it's possible to have an item as a risk for some and an issue for others - my gut feeling says that if something is a risk... it's a risk for everyone, top to bottom. But this vision is highly dependent on your environment.

Nevertheless, entering into the formalism of using risk or issue, I'd say that I'd consider a risk something I'm not sure would happen or impact the project. After all, an issue is a materialized risk.

So, you have the answer on your question:

It is unknown what impact this may have on the delivery of the project.

So, as it stands, it's a risk. Once there's a confirmation of impact, it becomes an issue.

  • +1 A risk is a measure of the potential for something bad happening, an issue is a reference to something bad that has happened. Issues can elevate risks and risks can eventuate and become issues. – mwan Oct 15 '15 at 22:52
1

There seems to be a lot of confusion on Risk and Issue. My simple understanding is:

A risk is an uncertain future event that has a positive or negative impact on the project objectives, should it occur (or business activities if you are considering BAU) [mathematically probability from 1-99%]

An issue on the other hand is something that has already happened [Probability=100%]

However, an issue or recurring issue(s) can lead to a potential risk such as single failure or repeated failures to patch/update a computer software might lead to the potential risk event of a hacker penetrating/hacking the computer/system/organization which will result in ........

  • This is the generally accepted definition. The issue is how people frame the situation. If a patient comes in obese, high blood pressure, high cholesterol, sedentary lifestyle, poor diet, family hx of heart disease, are you dealing with issues or a risk of heart attack? The simple definition offers no help here. Same thing on projects. Situations are far too complex to resolve with a simple definition and arguing whether it is a risk or issue is simply a waste of time, since you're mitigating the heart attack (risk) by curing all of those factors (issues). – David Espina Nov 21 '18 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.