Why IT projects are underestimated

Image for post
image from reshot

We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don’t let yourself be lulled into inaction. Bill GatesThe UK government’s response to Covid shows how easy it is to underestimate a project and how you can overestimate your effort. Project takes longer, costs more and can often fail.

IT projects underestimate effort, complexity and time (all contribute to cost), whilst overestimate the effectiveness of everyone involved and the benefits.

How do underestimate?

Low estimates are what everyone wants to hear at the start of the project. Everyone wants to hear it the project will be quick, simple, with a fixed cost and lots of benefits. The people involved will find ways to support this line of thinking

  • The bid is decided on cost (e.g. lowest wins), not if it covers everything.
  • The high level requirements are more basic than the eventual low level requirements but this scope enlargement is not factored into the plan
  • Leadership wants a low bid and quick estimate

The goal of the team making the bid is to get a low cost and small timeline. The initial goal is accepting a low bid not the goal of delivering the project and often the team responsible is different.

No one gets in trouble for telling someone what they want to hear. There is no incentive for team choosing the bid to accept a more detailed plan that is more likely to deliver a successful project.

I seen the process where the project bid I helped put forward was rejected for a bid that had a lower cost but missed many of the steps that I felt the project would need to be delivered successfully. It made me wonder why they didn’t ask the other bid why they didn’t have this included in their plan and it highlighted problems to me. The goal of the team accepting the bids was to get the best value for money bid not the bid most likely to deliver the project successfully.

Incentives and performance reporting influences the behaviours and choices

The Distorting Power of Incentives

“Never, ever, think about something else when you should be thinking about the power of incentives.” Charlie Munger

Projects and plans

IT projects involve groups of people working together to deadlines, making quick decisions, making mistakes, replanning and creating multiple smaller systems which work together as a whole.

Projects involve customer teams/individuals doing an unfamiliar role and working to faster timelines than they are used to.

Plans are made but in projects the plans quickly go stale and our not in sync with the environment. Plans need to be updated regularly, a process most people don’t like doing because it involves telling leadership it’s going to take longer (plans never get shorter).

Why plans go wrong

It’s impossible to create a new system on paper and work out all the small details needed in the system. Why? You don’t know exactly how a system needs to work in detail at the start, you have to learn and iterate.

Initial system will have logical and technical bugs. No plans include this work because you don’t plan for the system to built incorrectly or unknown problems. This is where adding contingency is important but this is often viewed as a luxury that optimistically the planner hopes won’t happen to their project (spoiler alert — it will)

A system on paper/plan isn’t the system needed by the user. You only find this when it’s used and through feedback from using the system and trying to do their jobs.

Goals, priorities and working practices change over time, these change the order and the scope of plans.

UK government Covid response

Covid shows how easy it is to underestimate the difficulties in creating a new system or new process from scratch because we forget existing systems are built over many years of small improvements to a business process and system.

This article from the Guardian discusses what we should learn from the Covid crisis.

The article has a great quote
There is reason to be sceptical about the contention that Britain would have endured a less fraught crisis if only ministers had possessed more dictatorial powers. Things for which the NHS has responsibility have generally gone very well, a notable example being the smooth implementation of the vaccination programme. Things over which politicians have direct control — such as test and trace, the provision of protective equipment, the timing of lockdowns, the enforcement of quarantining measures and border controls — have not been glittering testimonials to the speed and quality of ministerial decision-making. It is not self-evident that the best answer to the health service’s many challenges is more Matt Hancock

NHS processes

  • Vaccination
  • Emergency plans to deal with hospitals that hit capacity

Government new initiatives and systems

  • Track and trace
  • Provision of protective equipment
  • Lockdowns
  • Boarder control and quarantine

The existing NHS systems and people responded excellently because the existing and had experience and skilled people running them. The hospitals expanded to deliver care despite hospitals hitting capacity (how many businesses could do that?) and the vaccination rollout has happen at a rapid pace.

To put the vaccination rollout into perspective, it’s the fastest national vaccination in history of the UK.

The systems which didn’t work was the new ones setup because it takes more time, effort and expertise. Most importantly you need the system, processes need to be tried to get the feedback and fix the problems.

During the implementation of a large project there is a need to make quick and decisive decisions. You will need to change plans to reflect reality, when your plan needs to change due to the environment and feedback.

Communicating and leading are vital skills on large projects, you have to be able to understand and resolve problems at rapid speed in order to not lose momentum. These are not common skills and often the lack of them is the cause of projects to slowly go wrong, 1 day at a time.

The outside view

We forget the the difficulty in creating and delivering new projects, the false steps, the problems, the bugs and changes. A great way to see how long something will take is to view it with the outside view, e.g. how long did similar projects take.

Early in the Covid pandemic , there were wild timelines given for a vaccine, if you look at the long view, you could see at best it would take 18 months

The outside view — how long will it take to create a vaccine for Covid-19?

Conclusion

Incentives cause projects to underestimated in complexity and over estimated with regards to the ability of the team to deliver them.

Unforseen problems are not taken into account because everyone wants to hear the project is going to be finished at the soonest possible time for the least amount of money.

Those who raise problems can be blamed for those problems and there is no incentive or benefit to raising problems.

There is a usually a big difference between the time we think a project will take and how long a project really takes.

Related articles

One thought on “Why IT projects are underestimated

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.