I find that I am often describing the differences between a risks, issues and assumptions. A simple way to cluster these together is with the acronym “RAID”. This is an acronym describing the
Similar to how a SWOT analysis has Internal/External and Positive/Negative dimensions to the acronym expansion, we can consider the same for RAID.
You actively monitor, taking actions as necessary for Risks and Issues, but you declare Assumptions and Dependencies, and don’t take any ongoing actions beyond occasionally confirming or challenging them. If an assumption or dependency fails a challenge, it will most likely move being an issue or a risk. Arguably, under close examination most assumptions and dependencies can usually be treated as a risk or an issue.
In many cases, risks and issue management stop at just a list of issues and risks. This doesn’t take it far enough. There is a simple lexicon that are relevant to both risks and issues.
|Risk||Realized||When a risk becomes real|
|Likelihood||The probability that a risk will become realized|
|Impact||What will occur if the risk becomes realized (see corrective action below)|
|Mitigation||Actions that are taken to either minimize the impact or likelihood|
|Contingency||What will occur if the risk becomes realized (see corrective action below)|
|Issue||Impact||What is happening as a result of the issue|
|Corrective Action||What is done to reduce the impact or remove the issue|
To play with the interaction of Risks and Issues, you can construct meaningful sentences covering the relationship by heavy the attributes previous described.
When the mitigation fails, a risk is realized and becomes issue. As part of managing the risk, you want to always have considered a contingency in case the risk becomes realized. When the risk becomes realized, your contingency becomes your corrective action. A risk that has a high likelihood of being realized needs a contingency, since that becomes your corrective action, when you address what is now an issue. A risk that has a high likelihood and high impact should be actively mitigated to make sure that it does not become a high impact issue that could sink a project.
As you can see there is a rich interaction between risks and issues.
A final word on the difference between risk aware and risk averse, another commonly confused risk management construct. Being risk averse means that there is a demonstrated aversion, or a disinclination, to risk. A project avoids anything that is risky. However being risk aware means that risks are accepted and managed within an effort. Risk aware projects carry risks as part of the project, knowing that there is a risk/reward tradeoff. Like anything, there is a sliding scale between the two. Being completely risk averse will render a project stagnant and non-innovative. Being completely risk aware and carrying too much risk can easily sink a project.
Finding the balance and understanding the upside if the risk doesn’t realize is the art form that keeps managers and entrepreneurs around.