Consistently underestimating the cost of projects

Get Started. It's Free
or sign up with your email address
Rocket clouds
Consistently underestimating the cost of projects by Mind Map: Consistently underestimating the cost of projects

1. Some factors leading to the systematic underestimation of projects are:

1.1. Plans are (adversely) influenced from up the hierarchy

1.1.1. "It must fit!"

1.1.1.1. "This project is strategically important, so we are gonna have to make it fit within this budget/deadline"

1.1.2. "It will fit"

1.1.2.1. "If we just trim some of the fat off these estimates, it will fit in our budget/time constraints

1.1.3. Leaders tend to fight over estimation, so estimates are skewed to the left

1.1.4. EFFECT: estimates are fit to measure...

1.2. Estimation is performed by humans and humans are prone to the planning fallacy

1.2.1. Planning fallacy:

1.2.1.1. People display an optimism bias and underestimate the time needed

1.2.2. Inexperienced people tend towards low estimates...

1.2.3. Even experienced people tend to have incomplete recall of previous experience

1.2.4. EFFECT: estimates are naturally optimistic...

1.3. Low estimates are perceived in a better light

1.3.1. low estimates lead to greater "can do" kudos and self-gratification

1.3.1.1. we have a strong desire to please

1.3.2. EFFECT: low estimates have greater short-term rewards

1.4. Estimations make wrong assumptions

1.4.1. they assume no

1.4.1.1. social issues

1.4.1.1.1. e.g., internal discord, turf wars, etc.

1.4.1.2. resource issues

1.4.1.2.1. people with the right capabilities arrive late or not at all

1.4.1.2.2. people are time sliced between multiple initatives

1.4.1.2.3. people are not set up for success (i.e., right access to systems, tools etc)

1.4.1.3. coordination issues

1.4.1.3.1. misaligned priorities between dependencies

1.4.1.4. scope creep

1.4.1.4.1. accurate estimate but for a different solution

1.4.1.4.2. estimate doesn't take into account the impact of renegotiation

1.4.2. EFFECT: estimates don't factor in speed bumps...

1.5. Estimations may account for common cause but never special cause variations (risks)

1.5.1. black swans are uncommon but not that uncommon (1 in 6)

1.5.1.1. technology issues

1.5.1.1.1. e.g., surprise tech impediments, etc.

1.5.1.2. external surprises

1.5.1.2.1. e.g., new/unknown regulations, environmental considerations, competitors, etc.

1.5.1.3. ...

1.5.2. EFFECT: estimates can be way off...

2. What are some of the negative impacts of consistent underestimation?

2.1. Reduced choices and collateral

2.1.1. technical foundation

2.1.2. opportunities and synergies

2.2. Statistically reduced chance of on-time completion

2.2.1. impacts (knock on effects) of a late project on other projects

2.2.2. Destructive late-project dynamics

2.2.3. Long-term effect on morale, confidence, job satisfaction, trust, collaboration, etc.

3. What can we do to systematically bring back estimates to a mid-range value?

3.1. Use reference class forecasting instead of absolute effort estimation to move us statistically into the middle

3.1.1. aka relative estimation and yesterdays weather in Agile speak

3.2. Clarify the common confusion between precision and accuracy

3.2.1. define estimates as ranges instead of a single value (which can, and does, get confused for a firm date)

3.3. Don't fund big projects/programs

3.3.1. rather fund each MVP (< 3 months) where the above factors have less impact

3.4. Make estimation assumptions more visible/transparent

3.4.1. what has been accounted for and what hasn't

3.4.2. which should provide justification for more or less contingency