What I like about the PMBOK® Guide – Sixth Edition is that the language allows for scope to adapt the information to your own environment. For example, the definition of the project risk management Knowledge Area starts like this:
Project Risk Management includes…
which opens itself up to the interpretation that there could be other factors included as well as the ones listed.
In this article, and over subsequent articles, we’re going to look at the Project Risk Management Knowledge Area. Why? This blog is normally about things to do with project financial management, and what’s more relevant than managing risk so you don’t get a massive budget impact? OK, I’m sure you can think of other relevant things, but risk management is definitely a factor in controlling your budget.
Doing risk management on your project involves:
- Risk management planning
- Identification of risk
- Risk analysis
- Response planning and implementation
- And monitoring risk.
The reason why we do it isn’t just to save the company’s purse. It’s to increase or decrease the likelihood and impact of risks (depending on whether they are opportunities or threats) in order to optimise the chance that the project will be successful.
Note: when I first started learning project management, on my first training course, risk was considered as a purely negative event. It’s thanks to thought leaders in the field and the development of the profession that risk is now more widely known to represent both the good things that could happen as well as the bad things. In other words, risk is a reflection of uncertainty, not doom.
Risk is not inherently bad – even the negative risk. We take risks in daily life, every time we cross the road, or take a flight. But we calculate the risk (subconsciously) and do it anyway if our brain tells us that the odds are worth taking.
Business and project risk are no different. The goal of project risk management is to identify the things that might happen on a project and weigh up whether it’s worth doing anything about them. Oftentimes, it is worth expending energy to do something about them because ignored risks can turn into issues and be suddenly a lot harder to deal with.
Levels of risk
There are two levels of risk on a project.
First, we have the individual project risk. Take a risk, assess it, and note the impact it will have on the project. That’s at a very granular level, and while we do a lot of that, and it’s a useful exercise, we also need to look at the bigger picture. That’s the next type of risk.
Second, we have overall project risk. Let’s say your project risks are all assessed as low impact and low likelihood. Individually, each risk isn’t very risky. But now let’s say you have 5,000 risks. That’s a lot of ‘not very risky risks’ and aggregated, the picture looks very different. When you consider how those risks might interact with each other, the picture gets even worse. If one risk happens, it could make others more likely, or more impactful. Overall project risk looks at the whole picture of the cumulative, aggregated position that is created by all the risks.
When you look at the risk profiles of several projects, you can see different trends emerging again. At a portfolio level, you aggregate the risk profiles of all the projects and programmes.
Ultimately, you want risk at any level to be in line with stakeholders’ risk appetite. When a project gets too risky, stakeholders will be nervous. The exposure to the business feels too great. The portfolio management team, in conjunction with the corporate risk team, will take that kind of decision.
At a project level, your role is to escalate up to the PMO, your programme manager or even your boss and let them know about the significant risks facing your project.
That’s the reason we have risk management processes. It makes all this easier. When you have a risk framework and structure within the organisation, you can more easily pass information to the places it needs to go and keep your risks in check.
Next time: I’ll be looking at trends and emerging practices in risk management for projects.
Pin for later reading: