We all know the difference between an issue and a risk, right? Well, if we’re not clear, let me explain.
Think of an issue is an event which wasn’t planned to occur on your project but it has occurred and now requires management action. One of your project team quitting mid project; your sales director requesting a change to the requirements; a bug in the software which preventing a database being updated correctly are all examples of issues. Each one will need to be resolved one way or another by someone with authority.
When deciding what do to about an issue, it’s important to weigh up the pros and cons of taking a particular action i.e. what will be the benefits versus the costs of taking the action?
A risk on the other hand is an event which hasn’t yet happened. It might happen at some point in the future, or it may not. Risks therefore are about uncertainty. Perhaps there is a risk of your supplier going bankrupt, a risk of your business critical system software not working properly, a risk of you crashing your car on your way home from work.
If the risk event does eventually happen however it will have an impact on the project, usually in terms of cost, time and benefits, but maybe also on scope, quality and other risks. It’s therefore important to try to qualify these impacts before they occur. If your supplier does indeed go bankrupt during your project, you will need to find an alternative supplier which will likely incur additional costs and might well delay the project.
Precisely because risks are uncertain, it’s important to estimate the likelihood of the event to occur i.e. that your supplier will go bankrupt? You will need to make an assessment based upon your understanding of the situation.
Depending upon the likelihood of the event occurring and the impact if it does occur, you can then plan one or more mitigating actions in response. Whichever actions you plan however, must be in proportion to the level of risk. In other words, for risks which have a low impact and medium or low likelihood, you might decide to accept them i.e. do nothing about them.
For risks which have a high impact (let’s say on costs), and medium or high likelihood, you might decide it’s worth spending a reasonable sum to reduce the chances of the risk occurring. If by selecting the cheapest supplier, you run the risk of them going bankrupt, you might decide to choose another (and potentially more expensive) supplier if you consider there is less chance of them going bankrupt.
So can a risk become an issue? Absolutely. Let’s say your supplier did indeed go bankrupt during your project. At that point there is no uncertainty any more. The fact now is that the uncertain event (the risk) has occurred. We didn’t plan for the supplier to go bankrupt but we now need to do something about it. It has now become an issue and a suitable decision will need to be taken by someone with authority.
As you can see, risks can become issues, but they can stay as risks forever if they never actually occur.
Brainstorming risks early on your project, putting in place mitigating actions and tracking these consistently throughout the project are all part and parcel of being a project manager. Keeping track of issues and taking sensible decisions accordingly are also part of the day to day work of the project manager.
What were some of the biggest risks which you had to deal with on your projects? Looking back, could you have dealt with them any better? I’d be happy to hear your stories.