Risk management framework is critical for any project. You need a clear workflow, processes, and documents to efficiently overcome risks. Otherwise, you may end up wasting time and resources for nothing.
When I was a junior project manager, I worked in one of software development companies. It did not have a risk management framework. Therefore, when I started exploring the topic I had made all possible mistakes.
The biggest problem for me was poor project integration. Controlling risks throughout the whole project lifecycle was hard. I also suffered from inefficient processes. They were inconsistent during different stages of a project. Thus, moreover, I experienced sticky resistance from the management.
Risk management framework described in PMBOK® Guide solved many problems for me.
Risk Management Framework
First of all, PMI’s framework is not the only one. Moreover, many companies develop their custom risk management processes. Therefore, it might be a good idea for you to explore them first. There is a good chance they are already established and efficient.
Before we go on, you need to understand a critical concept. Risk management is not free. It has its costs.
You are avoiding or mitigating problems. Sounds very cool. However, trying to avoid all problems is very expensive. The benefits diminish rapidly. Therefore, there should be a balance between acceptable risk levels and the budget of risk management.
Also, risk management is not only about threats. You must look for opportunities too. Which means you need to exploit different situations to the benefit of your project.
For example, you can get a better expert for the same price. Great! Go for it and secure the resource. You can spend extra efforts on one activity to significantly reduce duration and risks of the other. That is an excellent opportunity as well.
OK. So, what does PMI framework prescribes? To begin with risk management, I will limit to five processes and one artefact.
1: Identify Risks
First of all, we need to identify as many risks as practical. At what moment of a project do we do it? Risk management happens from project initiation till its closure. Constantly.
Isn’t it expensive? No. You do it on your own. If you have a robust and educated team, they do it also separately. The general mindset for the project team is to look for risks all the time. They should also report them. And you need to log the risks for further analysis.
Also, you can arrange analysis of separate parts of a project or product. For example, analysis of requirements, specifications, schedule, budget, processes, or management plan in general. The goal is the same – to identify risks.
Most of the time you will use interviews and meetings. You will talk with stakeholders to explore risks they see. Alternatively, you will set up brainstorming meetings to collect feedback from the team and subject matter experts.
Every risk you identify should be logged into Risk Register.
2: Qualitative Analysis
Now you have a long list of risks. Some have a severe impact on the project if they happen. Some have good chances to happen. Therefore, you need to grade them.
In qualitative analysis, there are no formulas or calculations. It is all about scaling the risks from one to ten, one to five, or from “Low” to “High”, etc. It is a subjective analysis.
There are two parameters that you need to analyse. There are:
- Impact – impact a risk can cause to the project. It may be expressed in additional work, delays to schedule, extra costs, human resources attrition or demotivation, etc. Risks may affect all and many project aspects.
- Probability – likelihood a risk will happen. Keep in mind that a risk that will happen for sure is not a risk. It is a fact.
The ultimate goal is to prioritise the risks and identify the ones that warrant a response. Additionally, you will want to create a watch list. It will include risks that may evolve and cause problems later.
3: Quantitative Analysis
This process is focused on calculating numerical values of probability and impact of risks. You can use following approaches:
- Expected monetary value
- Sensitivity analysis
- Decision trees
- Historical data
- Expert judgement
Actual calculations, techniques, and tools depend on the organisation. For the sake of proper integration, they should be consistent with all other parts of project management plan.
4: Risk Response Plans
You need to understand it right. Here, you define what you will do with each risk and include it into your project plan. Risk management is not an outside activity. It is part of planning. You are planning how you will avoid problems.
The actual actions to overcome a risk is called contingency plan. Additionally, you must have reserves of time, resources, or money. These reserves are a part of project baselines.
Moreover, risk management is iterative. You embed risk response actions into your plan. Now you need to check the whole project management plan from the start. You will end up in risk management again to verify that no new serious risks were introduced.
You never end up with a plan with no risks at all. After several iterations you still have:
- Secondary Risks – These are new risks that appear as the result of your risk management. However, you are ready to accept them. So, sometimes the only way is to transform one risk into another. For example, when time constraints are strict but the budget is not. You will deal with risk using the extra money.
- Residual Risks – These are low impact and low probability that are not worth the effort. Nevertheless, you need to track them.
5: Monitor and Control Risks
Risks are not static. They change and evolve, new ones appear, so risks become irrelevant. So you need to be constantly on the look out. Therefore, you need to review the risk register periodically. Also, you need brainstorm to identify new risk from time to time.
Additionally, you need to ensure that risk response plans are effective. Whenever a risk happens, your response action takes effect. However, it may just not work. Alternatively, be inefficient. In such case you must have a plan B. It is called a Fallback Plan.
Now you know the basic structure of project risk management framework. Go back to the risk management examples and try to see the steps described above.
This is only an overview of the framework. We will talk about each part of it in details next.