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...
For what it's worth, here's what I think. And this post does overlap some of those below.
Risks and Issues are intangible characteristics of all projects and in one way or another, represent a need to take action. So the first thing to note, whether it’s an issue or a risk, is to record it somewhere and set some action points to manage it.
I think there are definitions risks and issues which oversimplify the difference, stating that a risk is an event that has not happened yet and an issue is an event that has. This is dangerous advice as it all depends what your requirement is. In project terms certainly, risks and issues should ALWAYS refer in some way to the objectives of the project. To give an analogy, if you are growing a grass lawn, the fact that there may have been no rain on a given day it not necessarily an issue, despite the fact that the day has already ended. It may however create a risk that the grass may not grow. In this case, the event to which we need to refer is the growing of the grass (which hasn’t happened yet) and not the lack of rain during the past day (which has happened).
Part of the problem with defining risks and issues is the compulsion or need to record an event as either a risk or an issue, and not both. In reality, an issue, which is "an event that has already happened", may represent a risk of another event happening "at some point in the future". When that event happens, it ceases to be a risk and itself becomes an issue. This lifecycle of risks and issues may carry on ad infinitum causing untold confusion and work attempting to manage it, if all are recorded simultaneously. It is owing to the circular nature of risks and issues, and the need to monitor and manage only once, that best practice is to record either a risk or an issue, but not both.
In project management, there are therefore two important things to note when recording risks and issues in order to get the distinction right:
1 If the event referred to has already affected quality, timeline or budget, it’s an issue. If the event referred has not yet affected quality, timeline or budget, but might in the future, it’s a risk. So ask yourself the question: Has this situation affected quality, timeline or budget yet? If the answer is yes, it’s an issue, otherwise it’s a risk.
2 Risks should be described in the form: “There is a RISK to X if Y happens. What can we do about Y?”. Issues should be described in the form: “Y has happened that affects X. What can we do about X?” Saving Changes...
Anonymous
Keep in mind that risks can also have positive outcomes. We tend to think of risks as being hazards. However, I think it is sometimes more appropriate to look at risk as variability/volatility. For example, if you are a trader on a stock exchange, the old adage "the greater the risk, the greater the reward" really applies. I have worked with hedge funds where traders were fired for not carrying enough risk in their portfolios. Thus, their cautious risk attitude reduced the amount of risk built into their portfolios and reduced the liklihood of blockbuster returns for the fund. In the hedge fund world this is as big a sin as being too risky with investor's money.
Risk can be active one and can be planned in advance too.
Risk will have mitigation strategies too Saving Changes...
Richard HowProgramme Management Consultant| How Associates LtdHarthill, South Yorkshire, United Kingdom
I have found its best to try to describe it in a way the business people will understand, try to have a relevant example that relates to their world. I always give the line that a risk is something that may happen and an issue is something that has happened. But when dealing with the building trade I use this example.
"on a building site, risk management is wearing a hard hat, issue management is getting stitches put in the gash on your head"
in retail terms
"risk management is employing a store detective to catch shoplifters, issue management is completeing the paperwork explaining to head office where the stock went"
in IT terms
"risk management is taking regular backups of business critical data, issue management is keeping the business afloat whilst you triy to rebuild the business critical data from scratch." Saving Changes...
Anant KuslekarManager-Software Projects| rtech-iis4, K, India
Thinking as below:
Topic: Heart-Patient travelling from India to Singapore.
Risks:
(1)If Plain Crashes
(2)If Fleight Delay
(3)If Lost Passport
(4)Readyness for suspected Heart-trouble
(5)Suspected Oxygen Scarcity
Though all risks said to be managed:
Patient decide to get down from plane, just before flying since he suffers from anxiety-tension....So this issue becomes show-stopper.
This is issue.
Saving Changes...
Bipin Lekshmanan PMPProject Manager| Wipro TechnologiesEdison, Nj, United States
Ha-ha! I like Anant;s example! Good one. Saving Changes...
Haris NeophytouFounder, CEO & Research Director| InterFusion Services LtdLimassol, Cyprus
Very interesting points everyone. Because there is clearly a close corelation between these two entities - risk and issue - I wish to cite Pascual Jordan, in order to share my philosophy regarding this burning 'issue' :) with the rest of you.
"Observations not only disturb what is to be measured, they produce it." Saving Changes...
In looking at Webster's an Issue is something one is concerned with or a disagreement. A Risk is a potential event that may or may not impact a project. The attributes of each are substantially different. A risk has such attributes as risk strategy, mitigating actions, contingency plans, impact, probability, timing, risk owners, etc. An issue has such attributes such as an issue owner, follow up actions, and dates associated with these. It is possible for an issues to become a risk as one learns more about it. I think we would be doing a disservice to wait until an event occurs to include it in an issue log. That prevents any type of pre-planning in which the issue owner may learn more about it. In the past I have included events that are concerns that have not occured, just so we can get a head start on them... Saving Changes...
One other item...I may be wrong but it seems when I took the PMP exam many years ago, it a risk occured it is a 'realized risk' instead of a 'potential risk'. Just because something occured does not mean it is an issue. If it impacts the project it would be a 'realized risk'. Saving Changes...
