Have you ever stopped to brainstorm the risks to your projects? If you’re like most technical professionals you just arrive at work in the morning, and start your project where you left off the previous day. You try to dot all the i’s and cross all the t’s, and then cross your fingers that unexpected things don’t blindside you.
Project management standards dictate that you plan in advance for risks to your project’s critical success factors. Each risk should be identified and ranked on a scale of Probability and Severity (1-10 or similar) in a risk log.
Risk = Probability x Severity
Once prioritized, there are 5 primary ways to manage your project risks:
- Avoidance.
- Acceptance.
- Monitor and Prepare.
- Mitigation.
- Transference.
Avoidance
Although often not possible, this is the easiest way of removing risk from a project. It involves the removal of the tasks that contain the risk from the project.
Sometimes you can remove a small part of a project which carries a large risk factor. In this case, proactive risk management planning is a very worthwhile endeavour.
Changing the project plan to remove a risk will involve changes to the project scope, resources, and/or time, but it can be the right response.
Acceptance
On the other end of the spectrum, acceptance involves planning the risk into the project. If a better response strategy cannot be identified, accepting the risk might be sufficient to proceed with the project.
Remember, all projects carry risk in some form. It is not imperative that all risk be eliminated. But they should be itemized and analyzed to the necessary extent that they are part of the project plan, and all the appropriate parties have signed on to accept the risk. Management should be notified that there could be implications to cost/time/etc. if the risk occurs.
It might be prudent to allow for a contingency – time, cost, or resources – as part of accepting a project risk.
Monitor and Prepare
Similar to accepting the risk, this response can be used for major risks that carry a high probability and/or severity, but must be accepted by the project. It involves the following two things:
- Creating plans for monitoring the triggers that activate the risk.
- Building action plans that can be immediately mobilized upon occurrance of the risk.
Let’s say management imposes an unrealistic deadline. The likelihood of project schedule overruns is high. The project plan could include “Weekly monitoring of schedule variance and a notification to X personnel as soon as the schedule variance is greater than Y.” When it happens, you don’t need to think. This is an example of Monitor and Prepare.
Mitigation
Since risk is a function of probability and severity, both of these factors can be scrutinized to reduce the risk of project failure.
- Probability of occurance. Take measures to reduce the likelihood of a risk occurring. This is usually a more preferable option than reducing the severity because it’s better not to experience the risk occurrance in the first place.
- Severity. Reduce the impact of the risk on the critical success factors of the project.
Here are a few ideas for brainstorming:
- Reduce complexity in procedures and/or operations.
- Perform additional testing.
- Add more resources.
- Add time to the schedule (create a buffer).
- Create additional or more detailed prototypes.
- Provide additional technical training to personnel.
- Perform more site visits.
- Write additional specifications.
Transference
Finally, you can transfer the risk onto another party. Naturally, this will usually require some form of trade-off (or cost). Shifting the consequence of a risk to a third party is not always easy but is often overlooked. Here are a few ideas:
- Purchase insurance.
- Outsource difficult work to a more experienced company.
- Use a fixed price instead of unit price contract (if you’re the owner; Vice versa if you’re the vendor).
- Remove warranties and/or guarantees.
Whatever method you use to manage your project risk, we hope that you spend the time to do it. Create a risk log for each risk item and write out a strategy to deal with each risk. I think you’ll find that project success will no longer be so elusive.
Pablo Straub says
November 22, 2019 at 6:45 pmRisk transference is now a deprecated term in favor of risk sharing. The reason is that if you have insurance you may recover money (usually after a long process) but the damage is already being felt by the organization/project.