What is the difference between a risk and an issue?
Anonymous
I am working with some folks who are PMs but not in the IT field. I'm a PM in the IS department and couldn't actually come up with a good clear distinction between an issue and a risk for the folks that I'm working with. Can someone help me define these two? Thanks. Saving Changes...
Hitesh PatelSenior Manager - Lead PMO| Meinhardt EPCM India Private LimitedRajkot, Gujarat, India
Issues and risks are not quite the similar thing.
However, nature of both is largely unknown before you begin.
With risks, you usually have a general idea in advance from past experience and past datas that there's a cause for concern.
An issue tends to be less predictable; it can arise with NO WARNING.
For example, unable to find qualified staff is an identifiable risk. BUT, when one of your staff may have a car accident, and hospitalized for one month, that becomes an ISSUE!
When you don't identify and reduce your RISKS at the beginning of a project, it may often become serious issues later on.
i.e. You are having only one guy for the certain kind of a job and nobody alse knows about that work and that guy somehow left your project and it becomes serious issue and your work will suffer because of this serious issue and may be you will loss your business. So, that kind of risk should be identified and responded earlier stage of your project.
I hope this post will clear the idea and difference between an issue and risk. Saving Changes...
PANKAJ KUMAR JOSHIGeneral Manager| Transrail Lighting LimitedNainital, Uttrakhand, India
Risk becomes issue when it comes. Issue is an unidentified risk for which you look for workaround. Issues and risk both happens due to poor project planning. Saving Changes...
Ricardo do_Rego_BarrosPM Consulting Director| Simplifique Gerenciamento de ProjetosRecife, Pernambuco, Brazil
Risk becomes issue when it comes. -Right! So I would say, the difference of a Risk and an issue, in the since that both affect to some extent project objectives, is the probability. This way, an issue is a Risk with 100% pobability. Be that because of poor planning, knowledge or fate, it will have to be treated via the actions planned beforehand or via actions set in response to the actual facts. In both cases we need to have a well kept action register, where both actions to possible to be and been (< and = 100%),are registered, assigned and treated till full closure, and where lessons learned are, written for consolidation and future reference in the company knowledge management system. Saving Changes...
PANKAJ KUMAR JOSHIGeneral Manager| Transrail Lighting LimitedNainital, Uttrakhand, India
You cannot keep issues records unless they have been raised. However you can maintain a risk register. You can update organisation process asset with the action taken for future projects. In that case for future project the issue will become a known risk. Saving Changes...
Ricardo do_Rego_BarrosPM Consulting Director| Simplifique Gerenciamento de ProjetosRecife, Pernambuco, Brazil
True statement, Pankaj!
And once raised, they are treated and kept in that action register (risks & issues). Saving Changes...
Krunal Naik, PMP,CSM,MBAProject Manager| https://www.linkedin.com/in/naikkrunalSouth Brunswick, Nj, United States
This is really interesting discussion and great perspectives from everyone. I agree with how they are interchangeable/connected or in some cases unhanded or unknown risks may generate potential issues.I personally think definition of issue and risk changes from organisation to organisation, and may also change from project to project or from team to team.
Definition of issue and risk also changes by how we are managing or escalating it. In many projects I have also observed issue is something team manages by itself or we typically have resource resolving it. Risk is something which takes is to next level and requires more processing and planning. Another perspective is issue can be classified more relevant to products i.e. features, usability,customer issues etc. while risks are more relevant to projects i.e. affecting budget, schedule,scope, quality resource management etc.
In HW projects we often call it issue and same thing is called bug for SW. Again severity, frequency and reproducible may change terminology and classify it as risk to the project! Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
The PMBOK Glossary defines an issue as "a point or matter in question or in dispute, or a point of matter that is not settled and is under discussion or over which there are opposing views or disagreements." It then defines a risk as "an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives."
What I take from it is that the issue lacks a sense of resolution. Sometimes an issue could simply require a decision with ensuing actions added to your project. I don't always agree that a risk that occurs becomes an issue.
The reason is, if you did your risk management properly - identification, qualitative and quantitative assesment, mitigation and contingency steps - then when the risk occurs, there should be no dissension. At that point, it should be a simple matter of implementing whatever was defined and agreed upon under the contingency section.
Of course, if the risk was missed or not properly managed, you may have to resolve what should have been done beforehand. Then you have an issue. Saving Changes...
For me both fall in same category just they got different wattages…where ISSUE stands for less weight and if the weight is too high it stats RISK…..so as PM the first responsibility to understand the RISK of Project and get settle in such that less ISSUE occurs. Saving Changes...
Yes, I'll go along with the chronological differentiator between issues and risks. We must also consider the escalation processes for each - how and when does the review board decide it can't mitigate the risk or issue and need to pass it to a higher authority and then, how to track it. Saving Changes...
I agree with the last post. When working with people from the business (or operations), I have advised people to restate issues in the form of a question that must be resolved. (E.g., "Our estimated development need has doubled. How will we provide enough development resources for this phase of the work?", "The new business model implementation has stalled for lack of clear requirements. Who owes the requirements for the compensation scheme in the new business model?", "The process improvement consultants have been fired. How will we support the business process projects that have already been launched?") This makes issues actionable. If something comes up that seems to land on the fence between issue and risk (the important thing is that you are paying attention to it...), ask for it to be restated as a question (Literally, "What is the question we need to resolve here?"). As a rule of thumb (and as the previous writer suggested), if the question is about something that could possibly happen, it is a risk. If the question is about a problem or situation that needs resolution, it is an issue.
Anyone that has lead successful projects has some competence in this area even if they use different terms (or no terms) to describe what they are doing. When you begin to answer the issue question, you may decide that the resolution to a particular issue is to commit to do nothing and live with or mitigate the RISK. Unresolved issues, almost by definition, represent one or more types of risks. Back to the example... "So, the consultants were fired--what happens if we just let everyone figure it out?" The answer is an informal assessment of the risk associated with a chosen issue resolution. (I hope something in there made sense.)
