Managing risks in a project is very different to managing risks in a business. This article covers some of the ideas around managing risks in a project, more specifically, with a view to managing the implementation aspect of the project, rather than the project as a whole – because this is a large subject. I’ll try to keep this a little generalized so it’s relevant to all types of project implementation in business.
Managing risks is not about avoiding failure in a project implementation, but instead, accepting that things can go wrong and being prepared with a plan if that happens.
The first step in managing risks in a project implementation is to come up with an implementation plan. You’ll want this to be very clear so there’s no ambiguity about the steps. It should be written in such a way that someone else (with the appropriate skills) can implement your plan. This doesn’t mean that it should be so basic that a monkey could do it, but you need to be able to know exactly what was done if you or another suitably skilled person were to read the plan 5 years later.
The reason for this is because you (or someone else) may need to find out exactly what was changed after the project has been implemented. An example of why this is necessary is that there could be a problem that wasn’t considered which pops up a few weeks after implementation, and you’ll need to know exactly what was done. Another example might be that you need to rebuild your whole system (exactly) years later, and you’ll need to know what was done to replicate the whole thing.
Next you’ll need to identify the stakeholders. The stakeholders are the people who will be affected by the implementation of your project. This is so you can keep people informed, schedule work and communicate outages.
The next step is to list all the risks around your project implementation. Once you have this list, you should decide which risks you are going to have a plan to mitigate, and which risks you (and relevant stakeholders) are going to accept. You’ll need a rollback plan as a catch all in case your project implementation and risk mitigation plans fail, and to catch any risks you have not considered. Your risk mitigation and roll back plans should be at least as detailed as your implementation plan, because when it hits the fan, stress will make implementing your roll back plan harder and you’ll be more prone to mistakes. You should also plan what triggers cause your mitigation plans to be implemented (for example, the rollback plan might be triggered if the implementation is not completed and continuing with the implementation would not leave enough time for the rollback plan if the implementation were to drag out any longer).
The next task is around resource allocation. As part of your planning, you need to ensure that you have resources (human or otherwise) to implement your project, including those required to cover any risks you have chosen to mitigate.
Finally, you’ll need to make a plan to support the project post implementation. This means planning for future usage of resources (human or otherwise), and considerations for supporting the project after it’s implementation.
If you’ve worked in risk management before, you might recognize that this article is quite general. That’s because (coming from an IT background, where risk management is detailed and specific) I’ve tried to keep it as generic as possible so it can spur thoughts of approaching risk management for projects in all aspects of business. This same line of thought can be applied to implementing a server replacement project, the deployment of new PPE in a factory, or the deployment of a new office in another region (though this would obviously touch on the issue of risk management at a business level).
I hope this helps start the conversation about risk management and gives you some thoughts about how to go about managing risk in whatever line of business you are in.
