The importance of identifying and managing risk early in your project
Houston, we've had a problem here.
James A. Lovell
Commander Lovell’s calm understatement of the issues facing the Apollo 13 Mission in 1970 speaks volumes for his strength of character and for the quality of the men that NASA sent into space. History tells us what followed – a resourceful and determined team, against great odds, brought the astronauts safely home. Of course, everyone had been well aware of the huge risks in the space programme. For Apollo 13 many were realised; if disaster was heroically averted, the failure in risk management remained.
How did it happen? The cause was tracked to a combination of multiple faults, including a fault in the craft’s Service Module that had been dormant for two years before the mission. Individually, they were probably not critical problems. Collectively, they very much were.
Thankfully, few of us will face life or death situations of this sort in our everyday commercial lives (although IFRS and regulatory projects can feel that way from time to time) but the principles of project risk management are the same for us as they were for NASA. Identifying and commencing the management of individual risks – and their aggregate effect – at the right, early, stage is an essential activity of project management. Effective risk management from project outset is a critical success factor.
Let’s not underestimate the difficulty of driving a major project through successfully. Usually such projects fail to meet many of their objectives – just getting to some sort of completion at all is celebrated as success. In 1999 the Standish Group reported that only 26% of software projects were successful. A long-standing US DoD study was gloomier still, estimating that only 12% of projects met their objectives in full. There are many causes for this, but one is clear, as an academic study* found in 2001. “Successful project completion depends to a great extent on the early identification of immediate risks.” That conclusion sounds right intuitively and our own practical experience bears it out. Things go a lot better when you have a realistic early view of risk.
Most organisations now have guidelines on the way projects should be approached, including risk management, but in practice the first run at risk is often a bit too late, a bit too narrow, a bit too academic and a bit unselective. Here is what we suggest you do …
1. Run an initial risk workshop in parallel with preparing the business case for the project. The risks being run are a material element in judging and modifying the business objectives, timescales and budgets. Once the business case is approved it’s too late - it gets very difficult to react to some key risk factors.
2. Think broadly about risk. Risk workshops can be difficult to structure and control. Don’t worry too much about this – the risks can be categorised later. Don’t constrain the risk thinking. It is also important not to focus just on project risk (“late delivery of communications links”, say) but also on the early risks for the live business (“users misinterpret new management information”). Each will inform project plans and risk management.
3. Quantify each risk and risk aggregations. A broad assessment (high, medium, low) of the impact and the probability of each risk is needed. That allows prioritisation of risk management and it provides a framework for monitoring how the risk profile of the project changes (good risk mitigation and management will reduce probability and impact, but some probabilities will nevertheless increase at different times).
4. Prioritise risks for management. The initial steps will inevitably identify too many potential “risks” to manage successfully. That said, many will have a low probability of occurring or a low impact (some risks won’t really be risks at all) and won’t require active management. It will be necessary to prioritise the identified risks, and the highest priority will require specific mitigation. Getting a handle on risk aggregation is more difficult, but important to understanding where your priorities will lie. You will need to consider the trigger for individual risks and the extent to which a single trigger is common to a range of risks, and the effect of several risks being realised at once (regardless of trigger). In most projects this could be an informed but subjective assessment of the risks identified. In more complex projects, risk models, simulations or quantitative techniques might need to be used.
5. Identify risk mitigation and management actions. Creating a response plan for each high-level risk will help ensure the risk is managed successfully. The response plan should include activities to mitigate the risk, as well as the resource allocated, action dates and periodic dates to monitor progress. This may go down to risks of quite low probability if their impact is very high. The response plans will also need to be reflected in the project plan.
6. Get contingency plans in place for the big risks. It’s better to think through what you’ll have to do, and be prepared to do it, before a risk is realised, rather than after. For significant risks that means formal contingency plans. You may still have to improvise – just ask NASA – but you’ll have a framework within which to do that.
The first five of these steps can all take place within the very earliest part of the project. They need to, because they will dictate changes to the activities and resourcing required. The sixth step may take a little longer, and can in any case take place over a timescale dictated by the timing of the risks concerned, but needs to be in place well before those risks can be realised.
If these steps take place, then you will have a reasonable framework for monitoring and managing the risk within your project. There will still be much for the project management team to do, of course, and there are always unforeseen problems. Even after Apollo 13, however, Commander Lovell could see the bright side:
Be thankful for problems. If they were less difficult, someone with less ability might have your job. James A. Lovell
We can see his point, but we’re more in the camp of wanting a quiet life. Not NASA material, obviously.
*Kirk Williams and Steve Shurety are part of the Business Consultancy team at EMB.