Learn about the differences between risks and issues.
A core part of project management is risk management, and this topic comes up a lot: how to define a risk or an issue? Simply stated, a risk is something which could happen. An issue is something which is happening.
A risk can have a probability of happening and an impact or severity to the project if it does happen. This can be quantified and then prioritized to address the most important risks first. An issue is happening and needs to be resolved. Since an issue is currently happening, it’s easier to quantify and assess the impact to the project.
These are both important to explain to stakeholders and leadership. As a Project Manager, I like to associate risks and issues with their respective project leg: schedule, scope, budget, staffing, or environment. It’s quite common to have a risk or issue which will affect more than one of these legs.
For instance: “If this network change doesn’t get made by 10/31, then we will be unable to use this new API. For each day that the API is unavailable, the project will fall behind schedule for completion and we will lose revenue.” Risks and issues can have inter-dependencies and cascading effects, like dominoes.
The next question is “which risks should I list” and my response to that is any risk which needs to be appropriately managed. If a risk seems obvious, but someone is concerned and what’s to manage it, then you should list it. You can also start first by listing every risk, identifying the probability and impact of the risk, and then deciding whether it needs to be managed and by whom.
Where to list risks? On a ‘Risk Register,’ which is like a checkbook or check register. Probability gets quantified: 1 – unlikely to occur, 2 – low likelihood of occurring, 3 – likely of occurring, 4 – high expectation of occurring. Impact can also be quantified: 1 – little impact, 2 – moderate impact, 3 – severe impact. Then you can weight and quantify the project legs. For instance, schedule may be weighted more heavily than budget, if your stakeholders say “we can’t slip on delivery.”
Identifying the risk and quantifying it is just one aspect to managing risks; someone needs to take ownership and be held accountable to manage the risk, so that these get mitigated, transferred, avoided or resolved before they become an issue to the project.
Do issues get listed on the Risk Register? Sure! It’s easier keeping everything in one place. You’ll just need to modify your template a bit. On your Risk Register, create another column which identifies the item as ‘Risk’ or ‘Issue,’ and be sure to include an Impact Date. This can be a date which the risk became an issue, or the date which the issue impacted the project. If you really wanted to get creative, you can also use your Risk Register to include the categories for ‘Assumptions’ and ‘Dependencies.’ These don’t get quantified, but are helpful to defend your scope, schedule, budget, staffing or environment project legs.
As mentioned previously above, another critical project management function is to be able to clearly communicate the project risks to stakeholders. Do I need to share every risk and issue with stakeholders? As a PM, I would say make the risk register available, but only the highest quantifiable risks should be shared, and any issues which have blockers from getting a resolution as well.
Communication on projects is always a big problem. Do you have any thoughts on improving communications? Please share with me your comments!