Do you know how they are different? Here’s our complete guide to understanding how these concepts work and how they impact the projects your teams are leading.
What is a risk event?
A risk event is a specific event or happening that could negatively or positively affect a project’s chance of meeting its intended goals.
Risk events are individual moments or sets of circumstances that have an impact on the project. These are the risks you put on your risk register. For example, the possibility of a key supplier going bust, supplies being delivered late or an important team member being taken ill.
Risk events are subject to the risk management processes that we have written about many times before. The project team can identify the known risks and then work to manage them so the impact on the work is reduced or avoided. You can create mitigation plans, and in the event of a positive risk, work to exploit it.
What is project risk?
Project risk represents the effect of all uncertainties on the project overall. It determines how exposed the project is to the consequences of what might happen. It’s a way of consolidating and referring to all the things that might influence the outcome of a project – the foreseen risks and also the unforeseen risks that haven’t made it on to the risk register.
Project risk is therefore more conceptual. You can aggregate all the risks on the register but that still doesn’t quite get you to a full understanding of what overall project risk would be. Individual risk events may react to each other, or alongside each other, or trigger each other. You can do some forecasting and modelling for these situations, but you can’t easily predict everything.
For example, you can’t predict what the stock market will be doing next week as a result of a world event that hasn’t yet happened – but that might have an impact on your company’s strategy or leadership team, and that effects your project. You might be able to plan in some way for these, but often a project team is unable to manage, mitigate or resolve them effectively because the remedy is too big and falls outside of the project’s sphere of influence.
Projects that are high risk are in danger of going off track or failing to meet their specified objectives.
How do you work out project risk?
Project risk is the result of all the risk events and other causes of uncertainty. In a paper for PMI, Dr David Hillson recommends that overall project risk should be addressed at the pre-project or concept stage. As you define the benefits for the project, also define the degree of risk that is allowable for the project to take.
From there, overall risk is managed implicitly, meaning it’s in the back of your mind every time you make a decision about how to set up the project, who will work on it, what’s in scope, and so on. Each decision is reviewed through a lens of how risky the project is overall, based on that initial evaluation. A risk workshop will help you uncover all of this.
Project risk at this high level is not going to be driven by a single risk event, so you can do a better analysis if you understand the cause and effect shaping the risk picture. Look, for example, at some of the common risk management techniques for categorizing risk like PESTLE (Political, Economic, Social, Technological, Legal, Environmental) and similar. Once you’ve done some analysis on the risk, you can use Monte Carlo simulations or other risk analysis techniques to answer questions like, “What’s the range of outcome variation likely to be?” or “What’s the chance of this project succeeding (or failing)?”
Your overall assessment of project risk is going to be a single statement or number based on your risk management approach. For example, high, medium, or low, or a mark on a 10-point scale – whatever method you use to label risk.
Managing project risk
Let’s say you’ve identified a range of risks that you feel have the power to disrupt the project in some way. They are entered onto the risk log and the team begins the management activities required to ensure they are adequately handled.
You’ve got a robust process for dealing with risk event and we’re not going to cover that in this article.
Project risk can be managed in a very similar way. The risk profile of the project should underpin all the decisions taken and shape how the rest of the project unfolds. For example, if the project is considered very risky, you could decide to de-scope certain aspects to bring the overall risk level down. Here are some other options for de-risking a risky project:
- Use a different delivery approach e.g. switch to agile for incremental delivery or go ‘big bang’ when there is a risk from delivering in a phased way
- Change the priority of other projects in the portfolio so that the risky project has a higher profile or more oversight
- Move around resources so the most appropriate people are on the riskiest work, and that there are enough people supporting the project – a dedicated PMO team could be an appropriate response for a large risky project
- Work to narrow the variation in outcome by applying best practices, standard methods, checklists and processes
- Outsource the project or set up a joint venture to split the risk
- Add contingency
- Cancel the project – in the event that the project is deemed risky to the point that failure would endanger the business in a way that the leadership team is not prepared to accept.
Changing levels of risk
As with all risk management activities, as you start to actively bite into the risk to reduce it, the risk level changes. That’s the same with project risk as with risk events. Keep an eye on your risk level at the project level as it may well shift – either way – during the life of the project. This can be a role for your project steering group or board.
Risk events and the overall level of project risk are clearly linked. However, if you can split the concepts in your mind, you can better manage the likelihood of things going wrong on the project and make smarter decisions about how to lead the work.