Why your (IT) estimations are wrong!

I often find that the budgets are considered beforehand without enough information, forcing the sales department or the CEO to add an additional risk %, usually hidden between minor tasks, or adding hours to QA/Testing and Project management, as a way to cover the reality: Your company sucks at estimating.

Let's say in a hypothetical situation:

Estimate for project
One month for design and architecture
Four months for development
One month for testing

Working on the design and architecture took 5 weeks for many reasons, that's a 25% additional cost. My experience tells me that this will affect development and testing as well, and most companies will not rearrange anything as it will risk the contract.

Every time we have a delay, we must rearrange the planning and dates and speak with the team to know if this affects other tasks as well, so we reestimate

From there my understatement is that we need to readjust the estimate with better data, making a development reestimation and we will have a reschedule of the whole project.

Unfortunately, we really cant rearrange the project often, as a call to sales telling the price just got 25% more expensive and will be delayed x weeks is a really bad idea for developing your business.

What's the solution to this issue?

Help your sales department or your IT team with more information, so they can make more accurate estimations.

Statistics will tell us that our initial estimate is wrong by a factor of +/-X. What happens is that researchers have seen that as time pass the estimations are closer to reality, and the issue is that the customer will understand the deviations as a failure, forcing the sales department or the CEO to have 2 different methodologies:

1. Add a % on the budget just as risks: This makes his company less competitive.
2. Create extended documentation, even mockups that are extremely detailed so they can use water fountain methodologies: It is not always possible as this needs a full budget.
3. Go full agile, just estimating 2-week sprints: Many customers are against it as they truly believe that your company is going to waste their money.

All the details that are known upfront, the details will emerge and estimate better, it is called the cone of uncertainty, so even with the best documentation and design, changes will happen.

The Cone of Uncertainty

This shows that in the very early stage you estimate that it is one year, this will have a factor of +/- 4 in the potential estimation variation.

Later during development will take +/-2 so as we see it gets more and more accurate. The problem is that the estimates are never 100% accurate. Even at the final stage, your estimates will be inaccurate, just the margin of error will be smaller.

Now that we have looked into the issue, What's the solution?

What agile estimation throws away the big estimation and suggests that we must have a reestimation on each iteration. This is a different value system, deviations are not errors, but recalibrations of the original schedule making the curve of uncertainty a guide for planning.

Each iteration of sprints we need to have a meeting with the project owner, project manager, and team to understand the project status and apply a real agile, where we develop better documentation as we experience the development process in each project, where we can create our own cone of uncertainty.