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!

Passing the point of no return

Pilots will know that when you are taking off there is a speed called V1. The plane has reached such a speed that there is not enough runway ahead of you to stop. So you are committed to take-off. Unfortunately V1 is usually less than V2 - the speed at which the plane can safely get off the ground. Any change after passing V1 – like a critical engine failure - can be catastrophic.

Many projects will feel like they have a similar point of no return. You have spent so much of time, effort, money and emotional investment that you have to go on. Going back to your old process may no longer an option: it is out of support or it won’t support new statutory requirements.
So what can you do if your project starts to fail after it has built up such a momentum?

Firstly Avoidance: your project management should have identified the risks before they happen, and mitigated them – a four engine plane is inherently safer that a single engine plane.

Secondly Act Decisively: A crew faced with an engine failure on take-off has to act quickly. They will have rehearsed the routines in simulators. Faced with a real situation they act in a split second. Can your project objectives and business case be quickly reconfigured so you still have a viable configuration? Throw out the catering trolleys to reduce weight for take off! But you can only act decisively if you have identified the risk.

If You Can, Stop. It is better to run off the end of the runway than to try to take-off without enough speed.

Finally Learn Lessons. All Air Incidents must be reported. There should be no fear of victimisation. Spin, cover-up or denial will only cause future catastrophes. If the crew followed procedures then they have nothing to fear. "Sully" Sullenberger, the US Airlines pilot who put down his crippled plane on New York’s Hudson River became a national hero. A project failure should lead to a process improvement.
A bank that bought PCs to re-equip its branch network found they were underpowered for the teller application when it was delivered. They could have sold them immediately to recover some cost but that would have realised an accounting loss. So the PCs sat in a warehouse for three years until they could be quietly scrapped. Was that the right outcome for me as a shareholder?

Risky Business

Here's a great white paper on project risk assessment in the context of corporate risk appetite.

http://www.projectperfect.com.au/white-paper-a-different-view-of-project-risk.php?b3note=riskmat

Unfortunately it doesn't extend onto management of project risks.

The Office Of Government Commerce also has some really useful risk potential assessment tools and techniques . They even have the spreadsheets set up to save you the math!

It just a shame that too many UK public projects don't stick to these principles. It is a major victory for common sense, the UK tax payer and for students of project management that Gateway Reviews are now published under Freedom of Information.

Whatever your views are on Prince2 there can be no doubt that its approach to project risk management is a sound framework. It will be interesting to see how the new guidance for Directing Successful Projects with PRINCE2 2009, aimed at project executives and sponsors, will clarify the project directors vital role in risk management.

How long will it be before this guidance has an impact on the Gateway Reviews?

Labour Saving Devices

Very occasionally an IT project will be producing something totally new and innovative which hasn't existed before. But the vast majority of IT change is all about improving business efficiency. The business case for the projects will have the costs of the projects which are offset by the benefits of reducing costs – most of which will be likely to be salaries.

In the new world economics you will need to go back and reassess any savings and benefits because there are some fundamental changes and major discontinuities in the economics that have come in to play.

In the old world order:

• your business volumes were growing at a healthy rate of, perhaps, ten percent. So your project efficiency gains will easily pay for the project costs. You simply don't have to recruit extra people to support the extra volume. You also save the additional HR costs including the recruitment fees and training costs.
  
• If you have very dramatic performance improvements then the headcount savings can be increased by normal staff turnover. When someone leaves you don't replace them. Again you save on the cost of on-boarding new staff.
  

Now the whole balance changes:

• As general unemployment increases then staff turnover suddenly stops. No-one will give up a job with several years of accumulated benefits for the uncertainties of a new job with the risk of "first in – first out". The goodwill of employees for a projects objectives will, not surprisingly, evaporate as benefits become threats to their personal livelihood.
  
• Any saving in employee costs completely change if the company has to make compulsory redundancies, with the costs and compensation that have to be made. These may well come on top of other redundancies that the organisation has hade to make because of drops in business volumes.
  
• And leaving the sensitive subject of job cuts – do the ecomomics of your project still stand if business volumes have dropped by ten percent?
  

I hate to see irony in such a black situation, where real people's livelihoods are at stake. Believe me: I've been there myself. But it is "funny" that as the need to make efficiency savings increases then it actually becomes harder to make those savings.

Risks out of control

In any project some of the projects costs and benefits are out of your control. Not through any fault of the project. It's just the way it is.
In any business case there will be a number of macroeconomic and other external factors in play, and with the market discontinuity in the last year these have seen unprecedented turbulence:

• Cost of funds -used for your IRR or NPV of cost and benefits, and possibly any project financing.
• Exchange rates, particularly for multinational projects : although for offshore work, the vendor bears this risk, any adverse movement in x-rates can impact the vendors appetite for continuing work, and so still pose a risk to the project.
• Raw materials costs, for the business or the project. Will high fuel prices blow your travel budget?
• End product prices and sales volumes. You will have heeded my warning not to justify projects on increasing sales without demonstrable justification but still a 50% drop in sales is going to impact the businesses willingness to invest in projects.
• And throw in a few non ecomomic factors. What would happen if 30% of you project team were suffering from swine flu in the month of go live?

How should a project cope with this turbulence?

• Firstly you should identify the risk. Any assumption made in planning should be documented and the risks from changes to the assumptions identified.
• Stress testing and scenario planning. Once you have established the assumptions see the impact on changing them: Double them and halve them. Double some and halve others. What does this do to your business case?

On the outcome of your scenarios then you can use the standard risk countermeasures:

• Prevention. If the risk has too big an impact then terminate the risk - even to the extent of stopping the investment.
• Reduction. If the project travel budget can't absorb a future increase in airfares then reduce travel plans now, and buy a good conference phone.
• Transference. Speak to your CFO or treasury department. Will they accept the risk for you? If you have FX exposure does the business have some opposite exposures? Offshore profits to be repatriated? Can the business hedge the risk?
• Acceptance. Just get over it. If your scenario planning shows the impact is small then the project board can decide to live with the risk and bear the costs when the happen.
• Contingency. Plan and budget for the impact, if the risk materialises. If airfares increase then stop travel or have a contingency budget only to be used if air fares increase. To be fair to your project sponsor you should also reduce the budget if air fares go down!

Management of risk should be a core discipline of your project management.

Increase Sales! and other lies to justify IT

"The website for the ten million pound sales campaign with this partner will take just two days effort to develop!" appealed the sales leader to the Star Chamber for technology project justification.

"This is not going to increase our revenue by one pound" said the CEO. "Our web developers' time is better spent on other projects. Next proposal..."

The CEO was right. The addressable sales opportunity was not going to get any bigger because of the website. The website was not going to reduce the sales force assigned to the program.

It is all too easy to justify benefits as simply increased sales. It is the easiest way to get a big number on the benefit side. And the easiest trap to fall into for a business case.

(A search on Amazon shows that there are 127 books with "increase sales" in the title, bought by sales people who justify the purchase as "cost £20, benefit increased sales".

They are written by very canny salespeople who have discovered the benefits of scalability: If they sell then their income is limited by the number of hours in their day. If they write a book on selling then their income is no longer limited by their time but the marketablity of their ideas.)

So if you use "increased sales" as one of your benefits look long and hard at it.

• The benefits of the process improvement are not the total sales increase – but the increase in net revenue, after allowing for the full cost of sales and marketing and all other overheads.
• It is essential that there is a clear link between the increase in sales revenue and sales process improvement. It is not enough to attribute the increase in sales revenue in the current year to the process change. You should provide some firm and auditable types of deals or specific sales that can be justified and backed by sales management - who will need to ensure that the specific sales revenues have not been double counted for benefits or commission elsewhere.
• If you have an innovative sales channel then you need to make sure that you allow for any loss of sales revenue from other channels.

If you don't have the specific link from the process improvement to the benefit the risk is all to clear in the current economic climate: The process is implemented but because of the global recession sales fall. Now where is the benefit in that?