A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts.
Written by Elizabeth Harrin from GirlsGuideToPM.com.
This is an occasional series on project risk management, and last time we looked at what options are available to you as part of your risk response strategy. Today, we’re looking at how do you actually implement risk responses.
There’s a whole risk response process in the PMBOK® Guide that helps you work out how to approach this part of managing your project.
The Implement Risk Responses process is where you take your response plans and actually do the work to make them happen. The execution of risk response plans is important because you can’t always rely on talking about a potential problem as enough to get it remedied.
There’s no single time to be doing this – you’ll be identifying risks the whole way through your project, so as and when you’ve come up with a new one, you’ll prepare the risk response plan and then implement it. Make time during the project to ensure you think through how to do the implementation part of the risk response strategy – incorporate it into your regular risk meetings.
The inputs to this process are:
The project management plan, and in particular, the risk management plan section
Project documents including the lessons learned register, the risk register (because this is where you will have written down what you are supposed to be doing) and risk reports if you have them
Organisational process assets.
The risk management plan will include the names of people responsible for the risk management process, and that’s helpful for assigning ownership of the management actions. You may also have info in there that relates to the level of acceptable risk – this is what you are trying to achieve by doing your risk management activities. It’s not always necessary to remove the risk completely; sometimes just reducing it to a level that’s acceptable to the project or the business is enough.
The OPAs are things like the corporate lessons learned repository which might give you insights into how other risk management approaches were implemented and what were effective techniques at doing so.
Tools and Techniques
The tools and techniques are going to depend very much on what kind of implementing you are doing. How to implement the ‘acceptance’ strategy is obviously very different to an approach where you are going all-out to mitigate it with a huge action plan.
However, there are some common threads to what kinds of tools and techniques you can adopt here, including:
Expert judgement (drawing on the expertise of your team leaders and your own knowledge about how best to implement the plans)
Interpersonal and team skills, especially influencing – that’s mainly going to fall to you to ensure that the work gets done
Project management information system (document and record what you are doing).
Basically, use your PM knowledge to ensure that the planned actions for risk response actually happen.
The outputs of this process are:
Change requests (because your plans might involve adding or removing tasks to your project schedule, for example)
Project document updates, especially to the issue log, lessons learned register, team assignments (as people’s work assignments need to be updated to reflect their new tasks), the risk register and risk reports.
And, of course, the work of doing the risk responses – built into your To Do lists and action logs, and discussions with team members.
As you get more experienced with project management, you won’t spend much time thinking about ‘doing’ this process. It just happens naturally as part of the things you’re doing on the project. It becomes an integrated part of how you manage risk, and so much aligned to the other parts of risk management that it all flows together. I don’t have meetings where I sit down and say, “Today we are going to do the implement risk responses process.” That’s just not a called out part of how we make risk management happen… but the process does happen. It’s simply integral to everything else and a natural part of how we work together as a team.
The process exists to remind you to make sure that risk responses aren’t something that you simply talk about. You want to avoid that issue of writing down risks and having a lovely risk log, but all the risks sit on there and nothing happens to actually take action on them.
Next time I’ll be looking at how to monitor risks to ensure that your action plans are being carried out as you would expect and are having the right impact on your project.
I would like to add to that by copying (with permission) from the book "Bullet Dodging - A Risk Management Handbook for ICT Projects" as below:
"Once you have determined your risk response plans, you’ll need to implement them if you’re going to manage your project’s risk exposure as intended.
You can start this process as soon as you complete the first risk response plan, and you will continue until you close the project.
Some of the risk response plans will be easier to implement than others. And, some of them you will be able to defer implementing. But you should track all of them in the risk register. And you should integrate all of them into any other relevant project documentation.
One of the most important documents to update is the project schedule. This is the project document that is going to be the most helpful in implementing the risk response plans.
If you’re going to reap the benefits of the risk response plans, you need to put a process in place to ensure that the risk response plans are executed as intended. Your process should ensure that expectations are communicated and that there is a method to monitor, control, and track risk response plans. And, your process should include a mechanism for addressing any risk response plans that don’t achieve the intended results.
8.1 Implementing Risk Response Plans for Threats
If the risk response plan for a threat has been identified as being outside of the scope of the project, or if the response would be outside of the project manager’s authority, then you should escalate the risk.
Assess the risk and consult the risk management plan. The plan should instruct you on how to escalate the risk, who you should escalate the risk to and when you should escalate the risk.
Escalation should be collaborative to ensure that the risk is accepted by the party that you are escalating it to. If there is any resistance or conflict, seek guidance from the project sponsor and/or the project board.
Update the risk register with the actions taken and update any related project documentation. There is no need to further monitor the risk.
If you have identified a risk that has a high probability and a large negative impact, you may decide to avoid it completely. Avoiding reduces the probability of it occurring down to zero percent.
Depending on the source of the risk, you could use different methods to avoid the risk.
You might be able to avoid the risk by extending the schedule. This might be especially effective for a risk whose source pertains to holiday periods or seasonal events.
If the source of a risk relates to the project strategy, you might be able to avoid the risk by changing the project strategy.
If the source of the risk is a particular element, function, or interface of the project, you may be able to avoid the risk by descoping the project. If there is a particular element, function, or interface that is a source of great risk, you could simply exclude it from the scope.
Obviously, these are all large changes and would almost certainly need to go through your change control process. Your risk management plan should describe how the change control process works for your project.
Update the risk register with the actions taken. And, update any other relevant project documentation. There is no need to further monitor the risk.
If the nature of a risk is such that a transfer risk response plan is feasible, you may choose to transfer the risk.
You can transfer a risk through a number of methods. You may be able to take out an insurance policy against the risk. You might be able to arrange for performance bonds, warranties, guarantees, or any other agreement that can transfer ownership of the risk to another party.
Transferring risk rarely completely eradicates the risk from your project. Transferring usually leaves you with some residual risk and/or secondary risk.
For example, insurance contracts often have a deductible/excess clause where your contract will have to bear the risk for the first percentage or defined amount. Such a clause would leave your project with a secondary risk for the amount of the deductible/excess.
Almost every other method of transferring risk will result in your project wearing at least some counterparty risk. What happens if the party that you’ve agreed to transfer the risk to goes bankrupt? That is one example of a secondary risk that your project may still be exposed to.
Update the risk register with the actions taken and record any residual and/or secondary risks. You may decide to create risk response plans for both the residual and secondary risks, and you will need to continue to monitor both the residual and secondary risks and update any other relevant project documentation.
If a risk mitigation option is cost effective, you may determine that risk mitigation is the most appropriate risk response plan.
Mitigating a risk means that you either reduce the probability of the risk being realized and/or you reduce the impact that risk would have on the project if the risk was realized.
If you have determined that mitigation is the most appropriate risk response plan for a risk, you will need to identify all the actions that you will need to take to mitigate the risk.
Once you have mapped out all the actions, you will need to integrate those tasks with the other project documentation.
For example, you’ll need to integrate the risk mitigation actions into your schedule and manage any dependencies. You’ll also need to ensure that you adjust your resource plan to accommodate the extra activities. And, you’ll need to adjust your budget to ensure all the required activities are funded.
Once you have updated all the project documentation with the mitigation plan, you’ll need to monitor the mitigations process and keep the risk register up to date."