“But what if…?” is something I hear a lot on my projects. Perhaps my project team members are particularly pessimistic, but we seem to find it easy to identify lots of risks that could affect the successful outcome of our project!
You don’t have to be a pessimistic person to be able to identify project risks – in fact, being able to see the big picture and work out what could potentially create problems is a good skill to have and one that can save your project thousands of dollars. It is often a lot cheaper to deal with preventing a problem than to deal with the problem itself if it actually happens.
So how do you deal with risks once you have identified that they exist on your project? There are 4 ways of handling potential problems on projects. Here are your risk management choices: acceptance, avoidance, transference or mitigation. Let’s look at each of those in turn.
One of the strategies you can use if you identify a risk to your project is to do nothing. That’s right – literally do nothing except make a note in your risk management software and note down that you are doing nothing about it. This is called acceptance, and it is where you accept that a risk might happen and just say, “Oh well.” It’s a wait and sees approach, one that means you also accept the fact that if the problem does actually happen, you’ll be dealing with that instead of putting any effort into stopping it happening in the first place.
There aren’t many risks that I accept on my projects, but there are some. A good example is if you are organizing an outside event, like a company barbeque. It might rain. It might not. But you can’t control the weather anyway, so you may as well just accept that you may get wet. If a risk is very small you could also simply accept it, as this could be easier and a better use of your time than trying to do something about it.
With other risks, you can avoid them completely. This involves making (sometimes drastic) changes to your project plan and schedule to avoid the potential problem. For example, if Easter is your company’s busiest time, launching new back end financial management software then may not be the greatest idea. If everyone is already busy, giving them new software to learn when they’ve got customers hanging on the phone is going to make launching your project much harder than it needs to be. Much better to change the schedule and launch your new software before or after the busy time.
I have used this technique successfully to choose to go live dates at slow times. I’ve also used avoidance techniques as a way to prevent other problems: when you are worried about how stakeholders will react and any negative impact they could have on the project, good communication and stakeholder engagement is an avoidance strategy to ensure that you don’t let that negative impact affect your project.
Transference is not something I use very often, but I have written it into project contracts. It is when you transfer the risk to someone else. They then take on the responsibility for managing the risk and the impact and the management plan. An example would be where a third party contractor becomes responsible for something, such as new functionality within a piece of software, and it is then their responsibility to ensure this section is adequately implemented by taking responsibility for the training and so on.
It’s also used for financial risk, and taking out insurance is one way to transfer the risk to another party. You could ensure your project equipment, for example, so that if it is damaged or stolen another company (the insurance provider) has to deal with sorting out replacements, and the financial cost of the replacement and its delivery is also their problem. You still acknowledge that damage or theft might happen but the ownership for sorting it out if it does is no longer sitting with your team or company.
Risk mitigation is probably the strategy that I use the most, and you probably do too. If you act early you can often limit the impact of a risk. Ideally, mitigation activities mean bringing the potential impact of the risk if it did happen or likelihood of the risk happening down to acceptable levels. Those levels are set by you and your project sponsor and are probably recorded in your project documentation or risk management plan.
Mitigation is a very common approach and you can probably come up with lots of examples yourself. One that I have used is introducing more testing on to a project. A testing phase is often something that gets cut but it is important and thorough testing can identify problems early enough for you to fix them.
You could also mitigate any problems on your project by starting small and building a prototype or a sample before committing to the whole thing. You could train a small group before rolling out your training to the entire company. You could walk through a process before you implement it for real. There are generally lots of things that you can do that fall into the category of mitigation so you’ll find yourself using this one a lot.
These are the four options open to you when it comes to managing negative risks – things that could cause problems on your project. You can use the options independently or blend options together to further reduce the chance of the risk bringing your project to its knees. Whichever strategy you choose to go for, make sure that you record your decision and the appropriate actions that need to be taken in your risk log. Then, of course, you have to complete those actions to ensure that the risk is managed effectively!