Estimating too low on a software development project can destroy your budget and ruin your project schedule. Here's the reason why.
I have been developing software for more than twenty years, and I have experienced first-hand the consequences of estimating too low (and estimating too high).
Estimates at the beginning of a software project are rarely accurate, given the team's limited knowledge of the project. More often than not, users don't yet know all of their own requirements for the system to be developed, and developers don't yet know everything about the domain in which the solution will operate.
Building software is a process of continuous improvement, and a well-run project attacks the areas of highest variability first in order to reduce uncertainties as quickly as possible. Ideally, your estimate for a software project should be allowed to evolve along with the software itself.
And remember: the potential for an exponential overrun on cost and/or schedule increases the lower you set your targets. On the other hand, when targets are set too high the probability of a cost/schedule overrun is linear even in a worst-case scenario. In other words, your risk/reward and cost/benefit ratios are much better for an over-estimate than they are for an under-estimate.
An accurate estimate is best, of course, but an estimate that is too low can be much worse for your bottom line, so if you need to err on one side or the other, then you are almost always better off to estimate high.
As the saying goes, "Hope for the best but prepare for the worst."
I have been developing software for more than twenty years, and I have experienced first-hand the consequences of estimating too low (and estimating too high).
Estimates at the beginning of a software project are rarely accurate, given the team's limited knowledge of the project. More often than not, users don't yet know all of their own requirements for the system to be developed, and developers don't yet know everything about the domain in which the solution will operate.
Building software is a process of continuous improvement, and a well-run project attacks the areas of highest variability first in order to reduce uncertainties as quickly as possible. Ideally, your estimate for a software project should be allowed to evolve along with the software itself.
And remember: the potential for an exponential overrun on cost and/or schedule increases the lower you set your targets. On the other hand, when targets are set too high the probability of a cost/schedule overrun is linear even in a worst-case scenario. In other words, your risk/reward and cost/benefit ratios are much better for an over-estimate than they are for an under-estimate.
An accurate estimate is best, of course, but an estimate that is too low can be much worse for your bottom line, so if you need to err on one side or the other, then you are almost always better off to estimate high.
As the saying goes, "Hope for the best but prepare for the worst."
Comments
Post a Comment