What have we got to loose?

Let's develop some consequences of the cone of uncertainty - in particular the high risk and uncertainty at the start of the project.

All is not lost down the cone of uncertainty. Although the inaccuracy is high at the start, the stakes aren't high because you have no investment in the project.

We're talking here in general terms about a typical project.

You could see scenarios where you have to have investment or commitment right up front; where, say, you are committed to a fixed price delivery or have to meet some absolute deadline like a regulatory change (although in

such cases you would have requirements specified so you would be some way down the curve already).

If we look at the spending through the project (Shown in the second chart of cumulative expenditure - with the steepness of the curve showing the "Rate of Spend" ):

• Spending doesn't really start in earnest until you get into the main development phase of the project - when construction starts or the programmers start to cut the code.
• That's the point too where most of the project capital expenditure gets made, such as purchases of hardware and licences for the production environment.

If we put together the risk and the cost we end up with the Value at risk - or to put it in plain English -"What have we got to loose?"

This goes from the start of the project when the risks are highest but the investment is low. The value at risk then rises steeply as we progress; the spending rockets while the uncertainties and risks are still significant. As we reach the home straight the risk decreases. You will see that I haven't taken it down to zero when the project is delivered. Most phased project payment schedules will have a "retention" at the end to cover those snags that come up after delivery.

(Try that the next time you call out a plumber to fix a leak - "I will pay you 90% now and the rest when it has stayed dry for a month")

Let us not forget too, that for the user, delivery acceptance is only the start of the benefits that will come from the project, which will have risks too.

So what does this all mean for project risk management?

• If the project is going to fail it is best to let it fail at the start - and your early risk assessments should consider this.
• You need to have gateway reviews at the start - for assurance you have the governance in place.
• You then need to have reviews at the start of any project phase where the value at risk is going to increase.
• And you need to have project assurance all over the project through the main build/development phase when the value at risk peaks.

This, of course, assumes complete honesty and assurance that each phase is complete with the quality needed. So what if you start development -with its high spend rate - when in reality the requirements aren't fully defined? Well the simple maths says that you should apply the higher rate of uncertainty during the requirements specification to the higher spend during development and the value at risk suddenly rockets!

We've seen how by taking a few generalisations about a project we can quickly infer a lot more about the risks of a project. Let's go on to think about how we can bend some of these rules to our project advantage..

Planning Uncertainty

I came back to Mike Cohn's great book on Agile Estimating and Planning. The Agile Manifesto that values responding to change over following a plan doesn't at first seem to warrant a whole book on planning. It still needs to be done - as well illustrated by his quote :

"A good plan violently executed now is better than a perfect plan executed next week." - General George S. Patton

The book starts with a useful tool for any project manager - "Cone of Uncertainty":
This clearly shows what we all know:

At the start of the project, when we don't know exactly what needs to be done, our estimates for the work to be done are the least accurate.

Unfortunately for the hapless Project Manager it's at start of the project, when the business case for the project is being prepared that accurate estimates are most needed!

Different authors give different vertical scales to this cone of uncertainty, with the upper extreme of estimate accuracy (or should I say inaccuracy?) varying between 1.4 and 4. Some (as I have) also skew the uncertainty toward the high end - on the basis that most things get more complicated, rather than easier than expected.

So what are the lessons for the project manager as he gets drawn into the Cone of Uncertainty?

• It is essential to communicate to the project board and stakeholders that the initial estimates are inherently less accurate.
• It is good advice that project managers should always qualify any estimates with a probability: "There is a ninety percent chance this phase will be delivered ontime" - although you may get a reputation for avoiding commitment to deadlines if you do this too much!
• It shows that the milestones/project checkpoints, particularly before the start of detailed design and development, are essential steps to re-estimate costs and the business case, before committing to the increased expenditure as you get down to detail.
• If you have a project contingency budget to cover this early uncertainty you may need to review that contingency as the estimating improves, so it doesn't get spent "covering up" other issues that arise later.
• It is not an excuse that you should leave all estimating until the end of the project so it will be 100% accurate!