Budget, Scope and Schedule are three constraints a project manager has to deal with to produce deliverable. Any one of these three is changed, remaining are also affected.
Risks and issues in a project are documented and monitored. During the documentation phase, it becomes cofnusing when we have to classify it into either risk or issue category. Here is the basic info on difference between risk and issue –
Risk is a future event that may have an impact on triple constraint. It may happen or it may not. We can plan for risk based on its probability and impact on deliverable – risks can be avoided completely, or can be minimized, or can be transferred to other party, or we can meet head on.
An issue is present problem or concern influencing triple constraints. In other words, an issue is raised when something has gone wrong and will impact triple constraint.
A risk can become an issue, but issue is not risk – it has already happened.
Hope this helps. Thank you for reading the post.
27-Oct-2010 : More details added in other post https://virk.wordpress.com/2010/10/26/project-risk-management-101/
Categories: I.T., Management, manager, PMP, Project, Project Manager
Leadership and Management 
good but not sufficient. Give more detail difference.
Thank you. Clear, concise words.
I believe that Quality should also be one of the project contraints.
Graham, thanks for the input. I think that quality of the deliverable should be defined in the scope; and we perform quality control and quality assurance tasks in order to make sure what we deliver is what has been promised in the scope.
What are your thoghts on it? Quality must be a constraint in some sectors and not the schedule. Please share your ideas.
Thanks.
“A risk can become an issue, but issue is not risk – it has already happened.”
I believe there’s another perspective. An issue can lead to (and in most circumstances DO LEAD TO) more risks. Most “issues” are problems which have happened during the execution of the project … yet not necessarily impacting the Scope/Budget/Time of the project. Example : Tech Lead resigned is an issue (this may have even been tracked as a risk earlier) … it leads to the risk that you may not be able to deliver on time. I sometimes feel that there is not much point in splitting hair over risks and issues … both need nearly the same level of attention.
I look forward to comments.
While I was browsing more sites for this topic, found another site that kind of aligned with my thoughts above : https://acc.dau.mil/CommunityBrowser.aspx?id=17740
It says … issues are nothing but risk triggers.
Thanks for your comment and input.
You are right that if issue is not resoved correctly or accepted solution to the issue is with known limitations, it may introduce new risk to the project but issue is not becoming risk.
Just to add more detail:
This is how to document risk – If condition X happens then impact to Scope/ Schedule/ Cost will/may occur.
This is how to document issue – Duet to X condition, Y has happened causing impact to Scope/ Schedule/ Cost.
I think this article may give further inputs on the topic being discussed.
http://www.pmnetwork-digital.com/pmnetworkopen/201206?sub_id=tc2Vr8hMwWG8#pg30
Thanks a lot and best wishes. DURAI