Project Risk or Issue?

This item was filled under [ Project tools ]

Uh-oh. This is a show-stopper.  We can’t complete the project on time because the part that we need won’t be available for another 3 months! What will we do?

If you have managed projects for very long, you have run across a situation like this.  Is this a risk or an issue?  Does it matter?  A risk describes an uncertain event that might happen.  It is something that people are worried about.  If something has already happened that affects the project, then it is called an issue.  In the example given in the opening paragraph, we are certain that the part we need won’t be available when we need it.  This is an issue.  An example of a risk would be: “We may not be able to complete the project on time if the part we need does not arrive on time.”  In this case, we are not certain that we have a problem yet.

To be a project risk it must be something that might affect the cost, schedule, scope, or quality of the project.  If a risk will not materialize until after the project is over, then it is not a risk to the project.  It may be a risk to the program or organization, but not to the project.  The same is true of an issue.  Does it affect the things that a project manager is responsible for?  If not, then it should be handled by those responsible for the program or organizational area.

Being able to distinguish between these is one of the hardest things for project managers understand.  It causes problems because risks and issues are dealt with differently and dealing with non-project risks and issues wastes a lot of a project team’s time and energy.  The examples given so far are in the scope of the project.  Here is an example of a non-project risk:

“The system we are building is designed for 100 concurrent users, but if we get more than that it might run slow or even crash.”

If the project ends when the system is deployed, then this risk will never occur during the project.  If the requirements for the system say that it must support 100 concurrent users and it does, the it is not a project risk, it is scope creep.  The risk of actually getting more users than that and the ensuing consequences is the domain of business operations, not the project.

The source of this confusion is usually failure to distinguish between a project, a product, and a program.  A project delivers what is asked for, often a product. It does not make claims about the value or benefits of the product.  That is the domain of the program or product owner.  Sometimes the project manager, program manager, and product owner are the same person, but often they are not.

Risks are documented when they are discovered, most being at the beginning of the project.  The probability and impact are assessed and mitigation tasks are added to the project plan.  A contingency plan may be created to document what we plan to do should the risk occur.  These risks are monitored and updated as needed throughout the project.  Should they actually occur, they become issues.

Issues are problems right now that we have to do something about.  The actions that we take might involve adding tasks to the plan, extending the schedule or increasing the budget.  Issues are tracked and actions are taken until they are resolved and no longer affect the project.  These get a lot of attention in most projects.

That is the difference between risks and issues.  Handling each appropriately will communicate more effectively and make management much easier.

Tagged with: [ , , , ]
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

21 Comments on “Project Risk or Issue?”

  • David E
    2 January, 2011, 9:53

    In the first example regarding the unavailable part, you may have both an issue and a risk. This is where I see most get confused. The part is delayed x 3 months–this is an issue. The delayed schedule, though the author wrote “can’t complete…”, may still be uncertain and therefore a risk. Is another part from another vendor available? Are there other ways to recover? Indeed, if it is absolutely certain the schedule cannot be recovered, then it is an issue, too. But, the analysis of whether a current issue is causing another issue, or risk, still needs to be done.

  • 2 January, 2011, 22:32

    You are correct David. Perhaps I should have chosen a better example. In this example I was trying to convey that the delay was certain, therefore it was an issue. I would treat it as an issue and look for other recovery options such as you suggested. The part that made it an issue was that we were certain that the plan would not work the way it was. Something had to be done. With risk we always have hope that it will not materialize because of the uncertainty. Thanks for the comment. :)

  • Jim Duggan
    6 January, 2011, 21:01

    Another way of looking at the difference between a risk and an issue, is from a planning perspective. A risk identified during the planning process is something that you can plan for and possibly plan mitigating deliverables. You can factor in the cost of risk.
    An issue is something that has occured during the course of execution of the plan that may require adjustment to the plan; from a scope,schedule, budget or quality perspective. The opportunity to plan is lost; an issue is something you just need to deal with (hopefully this has been accounted for in the plan!).
    The idea behind assessing risk during the planning process and throughout the project, ultimately, is about avoiding issues (as much as is possible in an uncertain world).

  • Nina
    7 January, 2011, 9:59

    Issues are the realization of risks (either previously identified or not)…good risk planning helps to reduce the number of issues you have during execution – but you don’t perform Risk Planning only ONCE, it must be continously refined as new risks emerge during execution. While there will always be issues – things that happen that impact the ability to execute as planned – with a strong focus on risk identification and planning, hopefully you won’t encounter show-stoppers!

  • 7 January, 2011, 10:31

    Jim and Nina: You are both correct that risk planning should happen throughout the project and not just at the beginning. :)

  • Padmakar
    10 January, 2011, 23:00

    The risk will become an issue once it happened and the issue should be resolved. As long as it did not happen, it is a risk and plans to be done to mitigate it. If the team would like to face the risk, when it occurs, what ever the plan that was done as part of the risk response planning to be implemented for attacking the issue and to be resolved.

  • Eyas Al-Farra
    11 January, 2011, 6:28

    If will not mitigate the risk it will become an issue and it will cost us more money to resolve it, so we should plan our risk carefully and spend time to think of the best way to avoid this risk by way our project will success and will go smoothly

  • John Stanfield
    13 January, 2011, 0:38

    Great comments. I experienced the same issue on a recent project, that being the blending of risks & issues. They were all in the same pot. Generally the issues were what got discussed under the banner of risk management. Sometimes we got it right, but with the lack of precision the program wasn’t as effective as it could be. As we get continue to become more risk-educated we will continue to add definition and distinction to details. With that we will separate the risks and issues. Its similar to the concept of the inuit having 200+ words for snow. They live it, they understand it, its part of their culture as they distinguish between subtle details. To the amateur looking at the north pole, its just snow…just like the issues are risks.

  • 14 January, 2011, 3:04

    This is an interesting discussion, and of course one that has been had many times before. I would add a couple of additional points about risks and issues not yet mentioned (though perhaps implied):

    Issues are not just “realised risks” (though realised risks are certainly issues). In other words things can happen that hadn’t been identified in the risk log.

    Risks can be positive / desirable: in which case you may want a risk to occur. However although to be pedantic you might say that once it has occurred it’s an issue, arguably you wouldn’t treat it in the same way. So SOME risks that occur aren’t really issues.

    In the world of PM seldom are things purely black and white!

  • 14 January, 2011, 9:18

    Well said Bruce. Issues could be said to be realized risks even if they were unidentified risks. You are correct that realized opportunities would not be treated the same as issues.

  • 19 January, 2011, 20:06

    Excellent topic Bruce! I run into this on almost every project – especially when we are settng up risk and issues lists….

    I agree with many of the comments – there is no straight black and white answer to the difference. What we use for most teams is the simple definition:
    A risk is something that might happen and an issue is something that has or will happen.

    That seems to help staff members keep them straight. OF course then we have to see what to call a risk after the trigger occurs – guess that is a real issue to be dealt with!!

  • 24 January, 2011, 3:22

    Technically Bruce is right but from from a practitioner’s perspective, this is just splitting hairs. Planning tries to prevent a risk from becoming an issue, and if nothing can be done (or nobody listens) – it becomes an issue.

    Since many of the issues can originate from poorly handled risks, its important to keep them together and harp on them during postmortem lessons :-(

  • Bill Aitchison
    14 February, 2011, 15:14

    Perennial topic! The discussion indicates the lack of certainty around risks and issues. A few comments – Issues are not things that may or will happen. Something that may happen is a risk (if it has consequences for the project), something that will happen is a planning event. Issues are something that do happen. Not all risks that come to fruition are issues. If the risk mitigation is built into the plan then if it happens the plan is in place and the consequences are managed within the plan. This is not an issue.
    With reference to the original ‘risk or issue’ question, if the delay of three months is certain, it is a) not a delay b) not a risk and c) not an issue. It is a planning (scheduling) event. Now, if the project delivery is critical and cannot be achieved with the resulting schedule – that’s an issue.

  • 14 February, 2011, 15:40

    Good points Bill. You are absolutely correct that if you have a contingency plan for a risk that occurs then you do not have an issue. I also see your point about the 3 month delay I used as an example. I usually track any task delay as an issue on my projects because they can become critical even if they do not start out that way. It is also useful in post-mortems to help us estimate better in the future if we have captured some detail about causes of delay via issue tracking.

  • Peter
    10 March, 2011, 13:00

    Strange how this subject turns up again and again all over the world. ;-)

    Risk Management ? Project Risk Management ? Product Risk Management.
    A risk is not an issue, but can turn into one, at which moment it ceases to be a risk.

  • Suhasb
    29 April, 2011, 0:06

    Tell me one thing…One of the key resource resigned..if we do not hire a resource then it is a risk but if we are unable to find the right candidate – Is this issue right? and if we do not find in perticular time line then it will be risk realised. So my point here is issue can become a risk? Issue means some thing which is a problem but not impacting on scope, time or cost if we solve in time line…but if do not take in time line then it will become a risk?

    What do you say?

  • sachin
    5 May, 2011, 3:22

    Your are correct Suhasb…I am also trying the same example that if
    there is dependency on things and things didnt happend as expected which was not part of you plan due to not in scope at project level but at program level. Then after occuring of issue, if the issue is not resolved over a period of time(time limit) then it becomes risk to project/program which is dependent on stakeholders.

    Bruce Lofland and David, am i making sense?
    Why cant issue becomes risks to high level output if not addresses timely…?

  • 5 May, 2011, 20:04

    Sachin and Suhasb: What you are calling an issue is actually risk mitigation, not an issue. Risk mitigation are the actions taken to reduce the impact or probability of a risk occurring. An issue is a problem that is preventing the project from being executed as planned. Issues do not usually turn into risks.

    In the example Sachin gave, the risk was identified when the key resource resigned. The action of hiring a suitable replacement before it impacts the project is the risk mitigation. If a suitable replacement could not be found in time, then you have an issue. Does that make sense?


  1. Tweets that mention Project Risk or Issue? - Project Management Tips and Techniques - PM Technix --
  2. Project Risk or Issue? | MSA BLOG
  3. Risk Or Issue? How Do I Know and Why Should I Care?

Leave a Comment