The High Cost of Low Software Estimates

Daniel Miller

Rate me:

4.60/5 (6 votes)

13 Oct 2015CPOL1 min read

8.9K

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."

CodeProject

This article was originally posted at http://blog.millerdatabases.com/2015/10/high-cost-of-low-software-estimates.html

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By

Daniel Miller

Chief Technology Officer Shift iQ

Canada

I have been building software systems for more than 20 years, working for organizations that range from small non-profit associations in my local community to global Fortune 500 enterprises.

I specialize in the design and implementation of online database solutions. My work-related research interests include software design patterns and information architecture.

Comments and Discussions

Fair comment, to be sure, but my point here is not to endorse a process where estimates are deliberately overstated in order to fleece a project sponsor. (In this article I assume everyone is being honest with themselves and with one another. If that is not the case then we have an entirely different set of problems with which to contend.)

Rather, my point is that a business should always be prepared for a worst-case scenario on overall project cost. Software projects carry a high degree of inherent risk, and if a sponsor can't afford a realistic worst-case then there is no business case, and the project should not begin in the first place.

On many (perhaps most) software projects there is enormous pressure to fix cost and schedule too early, before the feature set is fully identified and understood by users and by developers.

Along with this comes a corresponding pressure to minimize cost and schedule. And the rationale here makes sense: because we are dealing with so many unknowns in the early stages of a project, we ought to minimize our collective risk.

And this, in turn, often leads developers to take shortcuts that an otherwise accurate estimate would not tempt them to make. (Similarly, at least from my experience, a conservative over-estimate does not tempt an honest developer with dangerous shortcuts in early stages like architecture and database schema.) Sometimes you get lucky and shortcuts end well, but quite often they create enormous technical debt instead, requiring significant rework, and at the end of a project (assuming it is not cancelled), the total cost is considerably higher than it would have been with a more conservative estimate at the start.

The logic might be silly, but I don't think so. It is certainly a pattern I have observed many times in many different organizations, where neither low-balling nor high-balling has come into play.

If projects A and B have the same size and complexity, and if A is approved on the basis of an estimate that turns out to be far too low, and if B is approved on the basis of an estimate that turns out to be far too high, and if neither project is cancelled, the total cost for A is almost certain to exceed the total cost for B.

And I think this leads to your advice, which I agree with completely: the most effective (and cost-efficient) project team arrives at a carefully considered middle ground when the sponsor and developer work together. The estimate then becomes a goal that everyone shares equally, and if features can be added or removed to meet that goal then the project is much more likely to succeed. The same can be said of cost and schedule: budgets can be increased or decreased, and schedules can be extended or curtailed, if the project team works well together and communicates openly.

modified 15-Oct-15 0:08am.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.