Software development is done by people who have an innate understanding of math and logic. Yet it seems that these skills break down when it comes to giving an accurate estimate on just when a development project is going to be done — just ask any project manager.
There has to be a reason why developers and development teams are so bad at estimating how long it is going to take them to finish an effort.
Not Knowing What They Don’t Know
When sitting down to map out a long development project, engineers will be able to clearly define all of the unknowns that they see in the project. When they make their time estimates, it is usually based on how long it is going to take them to tackle those unknowns. What developers don’t account for are the unforeseen problems that they might run into.
In their defense, it is nearly impossible to account for every issue, unknown or otherwise. This means that experienced developers must learn how to factor in time based on those unforeseen pitfalls that, if you don’t know to look for them, you fall right into. When justifying the time spent on a development project, you can point to unknowns, even those you may have been unaware of.
Lowest Bidder Syndrome
The world of software development is highly competitive. This means that developers and their companies are motivated to be the lowest bidder at all costs. When a developer is forced to lowball their bid, they are underestimating the effort that is going to be needed to complete the project. An honest estimate of the time might put a price on the project that is too high to remain competitive against other bidders. The long term effect is, even if the bid is won, there are major cost overruns the minute that everything doesn’t go exactly according to plan.
The Longer the Timeframe, the More Difficult the Estimate
It is easy to estimate things in the near term. When projects stretch into longer lengths of time, small errors and miscalculations begin to add up and snowball. This usually means that the longer the project is going to be in development, the more inaccurate the estimate is going to be.
Using Agile development methods can help to create more accurate estimates, but even using Agile there is a pretty large margin of error when trying to estimate long term projects. Breaking a long project up into smaller chunks and then reevaluating once that piece is done can help to fix the situation.
Confidence Issues
This can go either way, either under or overconfidence. Many software developers like to think that they can sit down and hammer out code at a feverish pace and get the project done with little to no bugs. Some have the opposite opinion of their skills, thinking it is going to take them forever to get even the smallest algorithm written.
Truth is, both of these will cause a project time estimate to be way off. Overconfidence leads to woefully underbidding time, while under-confidence will lead to too much padding in a schedule. Both are very difficult to deal with when attempting to estimate a software development schedule.
Should vs. Will
Software developers like to give estimates on how long a project should take to get done. They do not like to think about just how long it will take to get done. Unfortunately there is a very big difference in the two. An accurate estimate needs developers to take off the rose colored glasses and make real world estimates on time needed.
Whatever it is that causes developers to give such inaccurate estimates, they need to make sure their client knows that estimates can change, and to be prepared for an extended schedule.
