When being under an estimate can be a problem

Recently, I wrote about how software projects should be measured by other criteria than time and budget.  Time and budget measurements aren’t going away, though, so we need to make sure that we act appropriately to make sure that focusing too much on time and budget harms our ability to deliver business value.

The problems associated with being on a project over the original estimate are relatively straightforward.  Pressure to meet a pre-determined schedule could result in all parties involved cutting corners, which could result in poor designs, incomplete implementations, inadequately tested features, and so on.  Very likely these results are already familiar to you.

But what happens if the software development process is significantly under budget?  (Yes, it happens.  I’ve been involved in several.)  Generally, one of two things happens:

1. The project is completed significantly under budget
2. Scope creep is allowed and unnecessary features are added

The first one is not a problem.  The estimate was, after all, just an estimate.  If you’re good at estimating, you should be under half the time and over half the time, assuming a reasonable tolerance for error each way.  But what about the second result?  For reasons I wrote about in an earlier post, adding features just because you can doesn’t mean that you should.  These features, if not thought-out properly (and they usually aren’t), will likely add maintenance costs and additional points of failure.  If any stakeholders in the project must use the entire budget, define some “nice-to-have” features ahead of time.  This way these features can the thought and planning they deserve.