Managing risk within a project is a good idea. That’s generally agreed upon. Risk Management is essential and contributes significantly to successful project deliverables. Where it can and does go wrong is when there is an over-reliance on the risk factors of the project. When these factors start driving the way the project moves forward, problems arise. Risk management is crucial, but it’s not the be all and end all of the project. However, that’s what often occurs in risk-averse organizational cultures.
To help understand how risk within projects can be better managed it is worth considering a number of aspects of the risk identification and mitigation processes involved.
Appropriate monitoring and mitigation
For large, complex programs covering numerous disciplines, (like lengthy construction, software, and telecommunications projects) it is appropriate to have a risk set-up that matches that complexity. The set-up needs to identify risks in the disparate areas of the program and allow judgments to be made across the program as a whole. A Risk Manager (and team members) might gather the requisite management information, for example. Difficulties arise, however, when the scale of the project is reduced but the risk processes of large complex programs are applied. When this happens, the risk process starts to drive the program and stops providing a benefit.
Record risk once in multiple related projects
Far too often the same risks are identified across multiple related projects or within a program of projects. Even with sophisticated risk software, the potential for confusion is great with different scores being applied to probabilities and impacts. Make sure you identify the one true risk and record and track it within the correct project. If other projects or a higher level program need to be aware of it, that is fine. Make them aware of it, but make sure you don’t start double or triple scoring the same risk.
More risk records mean longer projects
It’s strange but true. The more risks you identify and manage within a project the greater the chance the project might not come in on time. The reason for this? Well, think about it. It’s very easy to identify lots of risks for any project, but it’s how far you go that really matters. Get right down ‘in the weeds’ and you will still have to identify risk owners and people to investigate mitigation strategies, etc. All this takes valuable time and effort away from the main job of project delivery. So, make sure you have the important risks identified and managed, and keep reviewing them to ensure your list is up to date.
Accept the risk as is
Once you have identified your set of appropriate risks for your project you need to decide what to do about each and every one of them. Putting in place some form of mitigation may be necessary. This will add cost to the budget, but that’s just the way it is. Having said this, there could be risks that you decide to accept because the probability of them occurring is so low and/or the cost of putting in place some mitigation is high. You aren’t ignoring the risk. You are making a conscious decision to accept that it may happen.
Opportunities arise
Risks happen in any project, and some may have been predicted and planned for while others may not have been. The project is the project with its set requirements. That’s what everyone accepts as the truth. But what if a risk occurs which starts to make you think seriously about the validity of the project or the direction in which it’s going? When reviewing the project risks and looking at those that have occurred, ask yourself the question “Does this project still need to go in this direction or should we consider altering it?” Of course, the ultimate choice might mean cancelling the project altogether, which is never an easy decision.
So, are all risks bad? Of course not. If you make sure you are managing the risks that are appropriate to the project, and you make related programs and projects aware of those risks, then you’ve covered most of your bases. Opportunities can be anywhere within a project space, but just remember to think about them as you go through the risks – it makes that risk review meeting far more meaningful.
Copyright © 2010 Paul Slater
