Why IT projects estimates are wrong

Image for post
Image for post

We start IT projects as optimists and finish them as pessimists #HoskWisdom

No one starts a project thinking “this project will be late”. When we start project the requirements seem straightforward, the solution seem good and you have an eager team ready to go.

Then the project starts…………

Suddenly the assumptions are wrong, requirements are multiplying and SME’s have gone on holiday. IT projects are difficult, many of them fail, most developers have worked on at least one failed project but when we start a new project we think

This time it will be different

Hope is not a strategy

I’m not saying don’t have hope but be prepared for difficulties and don’t lose hope when things get tough (because they will). The solution you thought you were delivering will be a lot different from the project you end up delivering. This shouldn’t wear down you hope it should reinforce it because it means you have adapted to feedback and delivering what’s needed not what the high-level requirements hinted at.

High-level requirements are a guide to what the solution but without the details. High-level requirements create high level solutions, and they are always right with no gaps. They are a starter, a placeholder for everyone to learn more about and estimate what’s required both with the requirements and the solution.

The inside view of an IT project is your estimate, the outside view looks at the average length of similar projects. It’s difficult to take a statistical or average view of project lengths because every project is different, but we should use average project lengths to help review the project estimates and give it the smell test.

Estimates are likely to have been optimistic because they used high-level requirements, the more you dive in the details, the more requirements will appear. Everyone should be prepared for this, the real requirements are unknown at the start of the project, so it’s impossible to estimate them.

Estimates do not predict any problems such as

  • Technical problems
  • People leaving, starting
  • Virus pandemics which cause everyone to work from home!
  • Changes of priority/decisions
  • No SME’s

You can’t plan for unforeseen events, problems and people, but you can check for optimistic estimates by comparing it with similar projects. Compare the number of complications that occurred on similar-sized projects (team size, project length, scope)


Projects evolve and learn more about the detailed requirements, the team and the solution. It’s not the challenges which are important, it’s the projects response to them.

IT Projects are a team game and it’s not made up of separate teams (Customer, contractors, developers, different technical teams, etc). A project team is one whole team who all have to trust and work together to create one solution.

The team has to be flexible and respond to changes, mistakes and feedback to create whats best for the business.

The solution you end up with at the end of the project will be different to the solution you planned to create.


Projects will change from the initial scope. Everyone involved thinks their project will be special and with the talented people can do it quicker than other projects. 99 percent of the time they won’t, base rates guide us when are optimism tries to take over.

Use similar projects as a guide

  • how long did it take?
  • how many problems happened?
  • What extra requirements appeared?

Don’t forget estimates are not commitments.

IT projects are the fastest way to grow grey hairs” #HoskWisdom

Keep learning

Countering the Inside View and Making Better Decisions

picture from here

Written by

Have been working with Dynamics 365 since version 4 and enjoy reading and delivering enterprise projects

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store