Whilst I can agree with much of this - particularly that Risks (uncertainties) and Issues (certainties) are subject to different processes and that they can be interlinked and cyclical - the one thing I can't agree to is that ISSUES have already happened.... It is an ISSUE (certainty) that if I go into Space without an environmental suit, I will most certainly freeze and suffocate; it hasn't happened yet but I know I will need to solve the issue before I go there... For my family, it is a Risk that I have a coronary infarction and die in the next few minutes (albeit a tiny Risk) but it is an ISSUE that ultimately I will die... Notwithstanding, ISSUES can also be unforeseen negative events though unless we live in a P3M environment where we accept the axiom that ANYTHING CAN HAPPEN - we would not accept that all Issues come from Risks. So an ISSUE does not always materialize from a foreseen or unforeseen RISK.
Thanks for this thoughtful comment Chris. I was almost persuaded that an issue can happen in the future, but then i read again what you wrote about going into space. It contains the word "if", which introduces an uncertainty - "if" allows for "if not". In this case, to go or not to go is a choice that you (or someone else) can make. While the choice is not yet made, there is no issue and you are completely safe. It is not certain that you will go (with or without a suit). So you're exposed to a risk that you might go into space with a suit that is incapable of supporting your life, with the impact that you'd die. But you can manage that risk - either get a good suit or decide not to go. As son as the decision is made to send you into space with an inadequate suit, then the issue exists. A heart attack is a risk, but your ultimate death is a fact, because it is certain that you are mortal now. (Sorry to end on a morbid note!) But i did enjoy reading your comment, thanks again.
In ISSUE Management - I look at the IMPACT (which may have been assessed if it was previously a RISK or may need to be assessed specifically if it has not arisen from a RISK) and the PROXIMITY based on a scalar that is appropriate to the lifecycle of the Project, Programme or Portfolio. Think of a cabin in a forest fire. Every ember blowing over the roof is a small risk of the cabin setting alight; a mile away is a raging forest fire. The small fires burning centimeters from the cabin steps are issues as they are warming the wood and the wood WILL combust - but it hasn't happened yet. In Issue Management, the Criticality or Priority of an Issue is a function of IMPACT X PROXIMITY; PROXIMITY can also be applied as a further level of granularity in RISK Management. So if PROBABILITY x IMPACT = RISK SCORE; RISK SCORE x PROXIMITY = CRITICALITY (or PRIORITY). In ISSUE MANAGEMENT, we know that there is 100% certainty already so it's the IMPACT x PROXIMITY that gives us our CRITICALITY / PRIORITY. But of course, you won't always deal with a low level Issue before a high-level risk; AND - these are only Quantitative Assessments; you must still listen to your instinct which is based around your subjective assessment of the quality of data you have...
Yes to all this! Perhaps you should post a video on issue management?! My video is delibertely short and can't go into this level of detail, plus I'm aiming to clarify the concept of risk by comparing it with non-risks. But I agree with all you say here, thanks.
Well... all those things are important, and management teams need to track them all. But there's a danger that putting them all in one log confuses things, and makes it hard to focus on each one. I definitely recommend separate logs: a risk register, an action log, an issue register, and a decision log.
Aren't problems by default connected to risks as the causes of risks? By mitigating a risk we address either the problem or the consequence? So by identifying a problem shouldn't we automatically do a risk analysis?
Actually problems have two connections to risks. First, a problem that exists now can be a cause of risk. Secondly, a negative risk that occurs would result in a problem. (Note that this isn't true for upside risks or opportunities, which would result in a benefit.) It may not be necessary to do a risk analysis for every problem that occurs, because not all problems can lead to risks. I hope this clarifies, and thanks for your comment.
I understand the difference between the Risks and issues. Issues have an uncertain impact on the project objectives (cost and schedule) and therefore issues have to be taken into account when quantifying contingency during a quantitative risks analysis. If I leave issues in the issue log, then I will not quantify their impacts on project contingency. Also, John Hollmann uses a terminology called systemic risks to describe 100% probability risks (uncertainties or a subset of issues) to include them in contingency quantification. You have to take into account, the 100% systemic risks (a subset of issues) into account when it comes to contingency otherwise, you will be underestimating the contingency for the project. What do you guys think?
Hi Bahy, thanks for your comment. This is nearly right, but not quite! An issue is happening now, so its occurence is certain, and so is its impact - it is already affecting our ability to achieve objectives. By contrast, a risk has not yet happened and it may never happen - it is a FUTURE uncertainty - but if it did happen it would affect our ability to achieve objectives.
Thanks for this question Damas. No, a problem is not the same as a threat. A problem is something that we are experiencing now, and a threat is something that has not yet happened. A problem is definite - it has already happened; but a threat is uncertain - it may never happen. If a threat is not managed effectively and it happens, then it will result in a problem, so we can say that a problem is the result of an unmanaged threat. I trust that this is clear. I hope you successfully manage most of your threats so that you get fewer problems!
Hello again Damas. You should look at the ISO 27000 family of international standards for Information Systems Security, particularly ISO 27001. More details here: www.iso.org/standard/iso-iec-27000-family
There really isn't any difference, they are two words that mean the same thing. Some mehodologies talk about a Problem Register, and others include an Issue Log. But neither a problem or an issue is the same as a risk!
Whilst I can agree with much of this - particularly that Risks (uncertainties) and Issues (certainties) are subject to different processes and that they can be interlinked and cyclical - the one thing I can't agree to is that ISSUES have already happened.... It is an ISSUE (certainty) that if I go into Space without an environmental suit, I will most certainly freeze and suffocate; it hasn't happened yet but I know I will need to solve the issue before I go there... For my family, it is a Risk that I have a coronary infarction and die in the next few minutes (albeit a tiny Risk) but it is an ISSUE that ultimately I will die... Notwithstanding, ISSUES can also be unforeseen negative events though unless we live in a P3M environment where we accept the axiom that ANYTHING CAN HAPPEN - we would not accept that all Issues come from Risks. So an ISSUE does not always materialize from a foreseen or unforeseen RISK.
Thanks for this thoughtful comment Chris. I was almost persuaded that an issue can happen in the future, but then i read again what you wrote about going into space. It contains the word "if", which introduces an uncertainty - "if" allows for "if not". In this case, to go or not to go is a choice that you (or someone else) can make. While the choice is not yet made, there is no issue and you are completely safe. It is not certain that you will go (with or without a suit). So you're exposed to a risk that you might go into space with a suit that is incapable of supporting your life, with the impact that you'd die. But you can manage that risk - either get a good suit or decide not to go. As son as the decision is made to send you into space with an inadequate suit, then the issue exists.
A heart attack is a risk, but your ultimate death is a fact, because it is certain that you are mortal now. (Sorry to end on a morbid note!)
But i did enjoy reading your comment, thanks again.
In ISSUE Management - I look at the IMPACT (which may have been assessed if it was previously a RISK or may need to be assessed specifically if it has not arisen from a RISK) and the PROXIMITY based on a scalar that is appropriate to the lifecycle of the Project, Programme or Portfolio. Think of a cabin in a forest fire. Every ember blowing over the roof is a small risk of the cabin setting alight; a mile away is a raging forest fire. The small fires burning centimeters from the cabin steps are issues as they are warming the wood and the wood WILL combust - but it hasn't happened yet. In Issue Management, the Criticality or Priority of an Issue is a function of IMPACT X PROXIMITY; PROXIMITY can also be applied as a further level of granularity in RISK Management. So if PROBABILITY x IMPACT = RISK SCORE; RISK SCORE x PROXIMITY = CRITICALITY (or PRIORITY). In ISSUE MANAGEMENT, we know that there is 100% certainty already so it's the IMPACT x PROXIMITY that gives us our CRITICALITY / PRIORITY. But of course, you won't always deal with a low level Issue before a high-level risk; AND - these are only Quantitative Assessments; you must still listen to your instinct which is based around your subjective assessment of the quality of data you have...
Yes to all this! Perhaps you should post a video on issue management?! My video is delibertely short and can't go into this level of detail, plus I'm aiming to clarify the concept of risk by comparing it with non-risks. But I agree with all you say here, thanks.
I really appreciate your clear definition for risk and problem
Thanks for this positive and encoruaging response Jose.
Wow, great clear demarcation between risk issues, good job!
Thank you!
How i wish Ill be trained by my boss with the same expertise as him. Very knowledgable 👏
Thank you for your positive and encouraging feedback. I'm sure your boss also has valuable experience to share with you.
A wonderful explanation as usual..
Thanks Imran.
Well Explained
Thanks.
Inestimable and fruitful description .
Thanks Pouya, I'm glad it was helpful.
It's so true, yet strange that PMOs have a DAIR/RAID log. Log Risk, Issues, Actions and Decisions all in one tracker. Need some revival!!
Well... all those things are important, and management teams need to track them all. But there's a danger that putting them all in one log confuses things, and makes it hard to focus on each one. I definitely recommend separate logs: a risk register, an action log, an issue register, and a decision log.
Even after working as a GRC consultant, there are lots to learn. This videos are perfect teachings and tips I needed. Thank!!
Glad it was helpful!
Aren't problems by default connected to risks as the causes of risks? By mitigating a risk we address either the problem or the consequence? So by identifying a problem shouldn't we automatically do a risk analysis?
Actually problems have two connections to risks. First, a problem that exists now can be a cause of risk. Secondly, a negative risk that occurs would result in a problem. (Note that this isn't true for upside risks or opportunities, which would result in a benefit.) It may not be necessary to do a risk analysis for every problem that occurs, because not all problems can lead to risks. I hope this clarifies, and thanks for your comment.
Thank you Risk Doctor i appreciate your response
great explanation as always,
Thanks Salman, glad you liked it.
very informative !!!!
Glad it was helpful!
I understand the difference between the Risks and issues.
Issues have an uncertain impact on the project objectives (cost and schedule) and therefore issues have to be taken into account when quantifying contingency during a quantitative risks analysis.
If I leave issues in the issue log, then I will not quantify their impacts on project contingency.
Also, John Hollmann uses a terminology called systemic risks to describe 100% probability risks (uncertainties or a subset of issues) to include them in contingency quantification.
You have to take into account, the 100% systemic risks (a subset of issues) into account when it comes to contingency otherwise, you will be underestimating the contingency for the project.
What do you guys think?
Hi Bahy, thanks for your comment. This is nearly right, but not quite! An issue is happening now, so its occurence is certain, and so is its impact - it is already affecting our ability to achieve objectives. By contrast, a risk has not yet happened and it may never happen - it is a FUTURE uncertainty - but if it did happen it would affect our ability to achieve objectives.
Nice talk
Thanks.
Thanks
Welcome
Can we take problem as threat?
Thanks for this question Damas. No, a problem is not the same as a threat.
A problem is something that we are experiencing now, and a threat is something that has not yet happened.
A problem is definite - it has already happened; but a threat is uncertain - it may never happen.
If a threat is not managed effectively and it happens, then it will result in a problem, so we can say that a problem is the result of an unmanaged threat.
I trust that this is clear. I hope you successfully manage most of your threats so that you get fewer problems!
@@Risk-Doctor thanx..I would like to learn more about risk management in Information Systems kindly advice.
Hello again Damas. You should look at the ISO 27000 family of international standards for Information Systems Security, particularly ISO 27001. More details here: www.iso.org/standard/iso-iec-27000-family
@@Risk-Doctor Thanx
What is the difference between Problem and issues.
There really isn't any difference, they are two words that mean the same thing. Some mehodologies talk about a Problem Register, and others include an Issue Log.
But neither a problem or an issue is the same as a risk!
Appreciateive
Thanks Manoj.