Pages

Sunday, November 23, 2008

Optimism Bias

Optimism bias is the demonstrated systematic tendency for appraisers to be over-optimistic about key project parameters. It must be accounted for explicitly in all appraisals, and can arise in relation to:

  • Capital costs
  • Works duration
  • Operating costs
  • Under delivery of benefits

To minimize the level of optimism bias in appraisal, best practice suggests that the following actions should be taken:

  • Project managers, suitably competent and experienced for the role, should be identified
  • Project sponsor roles should be clearly defined
  • Recognised project management structures should be in place
  • Performance management systems should be set up

For large or complex projects:

  • Simpler alternatives should be developed wherever possible
  • Consideration should be given to breaking down large, ambitious projects into smaller ones with more easily defined and achievable goals
  • Knowledge transfer processes should be set up, so that changes in individual personnel do not disrupt the smooth implementation of a project
AOF

Project Estimates

A common problem I have in a corporate environment is to accurately portray an estimate. We are estimating time and cost for software projects. The key issue is that software development estimates are highly inaccurate in the early stages, with errors of 200-400% quite common and a high degree of positive skew is evident. Overruns are more common than under runs and extreme overruns are alarmingly common.

The main problem is to express the uncertainty as clearly as the expectation, without appearing too elaborate.

In the past, we might say "There is a 90% chance that it will take 1-2 years and cost 5-15 million dollars". This magically turns into "You said it would take 1 year and cost $5m!".

We are dealing here with people who have zero statistical sophistication. There is a confounding factor that people want low numbers so their project gets approved over others.

I have some ideas:

1. Plot time or cost by probability.
2. Plot time by cost as a probability density cloud.
3. Express estimates like this (wide range, round numbers)
"
More than $3m
Less than $30m
"

Tim

P.S. I feel someone will suggest "Do better estimates then you won't have a problem". The fact is, until you have dug into the technical uncertainties and have defined requirements in detail you are subject to major technical risk and scope screep risk. You also have a serious problem of framing - the number the customer first thought of is likely to be way under the mark.

-- Tim Josling (email), May 15, 2003

Find about more on this
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0000Vz

Thursday, November 20, 2008

Mike Cohn's Blog - Succeeding With Agile®