Sunday 25 March 2007

The argument for Quantative (Financial) Risk Assessments on Projects

Question Details: How does your organisation assess project risk?
Chris Phillips-Maund (chris_phillips-maund@hotmail.co.uk) wrote:

Hi Rob,
I have used many methods over the years.
Normal process is:
Have a project risk register
Identify risks - through brainstorming/workshop
Analyse the risks - Rate for Impact, Rate for Probability
For all risks at and above Impact = Medium and Probability = Medium identify mitigation plan and contingency plan
Optional - identify scale of impact (cost or time) if risk becomes an issue
Review on a regular basis - review top risks/issues at least weekly
Escalate top 3 or 5 risks and issues (and action plans) to senior management

I hope this helps
Regards
Chris
--------------------------------------------
Chris,

Like so many others, you identify the standard way of managing risks and emphasise the importance of mitigation - nothing new there. However without being able to measure the 'impact' of the mitigation against the impact of the risk, how can you decide what is the best course of action?

In simple terms; if the impact of this risk materialising is $100k, but the only mitigation you arrive at actually costs $110k - why would bother? Why not let the risk materialise and pocket the $10K you didn't spend?

Also, when you are working on a project with (or often against) a client, it can be sensible to price up a weighted risk (ie. risk impact $1M, probability 10%, weighted impact $1M x 10% = $100k) and say that we can take that risk for the existing price of the project, or the client can keep that $1M risk and we will knock $100k off the price of the project. At the end of the day, in environments where you deliver projects for clients; it all about taking risk on their behalf.
Multiplex where predominantly hired to take the risk of cost over-runs and delays on the building of Wembley, not because they're good builders. [They're not builders at all, they sub all the work out and in doing so parcel up the risk for their subcontractors.]

The other benefit of using financial analysis is that, at the programme level, it is often very difficult to do anything about risk that is managed at the project level and below (apart from rubbing your hands together in a concerned fashion in front of the project sponsor). Using a 'risk budget' approach enables you at the programme level to put a risk budget aside (maybe it doubles as the salary bonus budget?) and use financial tools like Earned Value to track the programme risk profile. When you get to the end of the project there should be very little risk of anything else going wrong and your risk budget should be close to zero.

I see little value when my colleagues say a risk is rated as 'medium impact' and 'medium probability' - whatever that means to you may not mean the same to me and chances are you'll burn time trying to define each low/medium/high with every new project and client.
Appreciate your thoughts on this topic Chris.

Regards
Rob Gourdie

No comments: