Answer this question in 5 seconds or less:
A cricket bat and a ball cost £1.10 in total.
The bat costs £1 more than the ball.
How much does the ball cost?
You guessed £0.10, right? With a little more time, you’d probably get the right answer, which is £0.05.
It’s a contrived example, but hopefully the above test proves why, some of the time, human intuition is just plain wrong and most of the time that’s down to inherent cognitive biases that we all carry around with us.
The Context
You may be wondering what this has to do with project management?
Research from the Said Business School at Oxford University shows that an average IT project has, when comparing actual performance versus the planned performance (and these figures ignore any impact of scope creep):
- A cost overrun of 125%
- A time overrun of 25%
- A benefit shortfall of 29%
There are many reasons why IT projects specifically are challenging but seasoned Project Managers working in an organisation they know well are still poor at estimating project delivery costs and time.
There are lots of cognitive biases that can impact project delivery, but in this post I wanted to focus on three that I think are particularly relevant to estimation and planning.
So, these biases?
Optimism bias / Planning fallacy
The first, and probably the most significant in most instances, is ‘optimism bias’. In short, humans generally underrate our chances of being hit by a car and overrate our life expectancy.
This also impacts our ability to correctly estimate project duration and cost – we may naturally optimistically assume things about the future project performance that rationally, based upon prior experience and an understanding of the risk profile, aren’t likely to be true.
‘Planning’ fallacy’, is a phrase coined by Daniel Kahneman back in the 70’s. This is very closely related to optimism bias – a tendency to underestimate time, cost and risk and overestimate the benefits that a project will deliver. Ouch, so a project takes longer and costs more than you predicted, contains more risk during execution and will deliver less benefit – on this basis, I suspect lots of projects wouldn’t pass the business case stage if the business case were more aligned with reality.
For projects that are large, high profile or have a high impact of failure, it is well worth considering external validation of a project plan, including estimates. You may also consider reference class forecasting to validate that your overall time and cost estimates are within a suitable percentage of similar completed projects. If your Azure migration is estimated to take 3 months and cost £100,000 but a similar project in a similar organisation is still ongoing after 9 months and has cost over £1m then either that project is very unlucky or your estimates are overly optimistic.
Confirmation bias
The second is ‘confirmation bias’. This is the tendency to search for, interpret, favour, and recall information in a way that confirms or supports one’s prior beliefs.
To bring this to life, if you very strongly believe that undertaking a certain activity, say migrating a legacy email service to O365, can be undertaken in 2 weeks then due to confirmation bias you may possibly:
Only seek information on timescales or risks from consultants that you believe will support your view.
Downplay the risks associated with the timescales – to be optimistic and document risks are lower impact and/or likelihood of occurring than you objectively might reasonably believe.
The above points sound vaguely dishonest and I have exaggerated the example to make a point but less extreme behaviour than this is demonstrated by all of us, subconsciously.
As you can imagine, there is a cumulative effect when this bias is coupled with optimism bias and anchoring.
Anchoring bias
Finally, ‘anchoring’. This is an intriguing bias and is best demonstrated with an example: a group of people were asked whether Mahatma Gandhi died before or after age 9, or before or after age 140. Clearly neither of these anchors can be correct, but when the two groups were asked to suggest when they thought he had died, they guessed significantly differently (average age of 50 vs. average age of 67). Ie, they ‘anchored’ their guestimate based upon an initial suggestion.
Anchoring can occur when the joint project management and technical teams discuss time and cost estimates. If a PM guestimates 5 days for an activity that is actually much larger than that, then the mere fact they’ve suggested 5 days is likely to ‘drag down’ the estimate below where the team member would naturally have put it.
A less obvious example – have you noticed that Microsoft Project defaults to “1 day?” as a default for each task? How many project managers have been subconsciously anchored towards 1 day, I wonder?!
Other factors
There are lots of other reasons that could lead to a divergence between planning and execution, these include:
1. Unforeseen external events impacting the plan. Coronavirus for example – I’m sure that has delayed many a project and this kind of ‘once in a life-time’ event is hard to foresee or plan for in any reasonable way.
2. Broader organisational priorities impacting the plan. If the CEO thinks that his new ERP platform is a higher priority than your project then it is likely that your project will become resource-starved and therefore drift on timescales, at least.
3. The “yes, sir” syndrome. Where a PM and / or team is so terrified of producing a plan that is poorly received, they will simply produce something that they know will be acceptable to the project board even if they know that this plan is not practically achievable. It is common in these kinds of scenarios to see weekly RAG status as all Green, all Green, all Green…and then a sea of all Red until the end of the project, if the project survives to completion that is.
4. Areas of technical uncertainty. It is often forgotten that most projects involve an element of development, integration or customisation that is unknown to the implementers.
5. Third party delays. WAN links being delivered late, a delay on the delivery of equipment that sits on the critical path, a third-party contractor who goes sick.
6. A short horizon. Typically, a PM will have much better confidence about activities that are happening next week than they will in 6 months.
A note on contingency
I think it is also worth keeping contingency out of all estimates to start with. Instead, have a policy for yourself and all others that provide estimates, that any time / cost estimates, no matter how ‘rough’ are delivered without contingency baked in.
This then allows you to:
- Make an informed decision on a project-wide standard for time and costs estimates.
- Have confidence you aren’t piling contingency upon contingency – or leaving it out entirely!
- Alter the contingency in order to model different ‘what if’ scenarios.
- Make a more credible time/cost trade-off decision without the contingency position muddying the decision-making process.
Summary
In short, lots of cognitive biases influence our everyday thinking. In our experience, it really does pay to step back once a project plan or estimate is complete and think about anchoring, planning fallacy, confirmation bias and optimism bias specifically and review each estimate, both yours and others, with this in mind. This should be done not just at the detailed planning stage but also during initial business case creation and feasibility modelling where these biases could creep in.
