We all want to deliver excellence and make our customers happy. And one ‘nugget’ of wisdom in software projects is that it is best to under-promise and over-deliver. The idea is we should say we can only do X but then deliver X + Y because everyone loves getting more than they expected. But is this really true?

What if a patient went in for a single bypass surgery and afterwards the doctors said they did two bypasses? Should the patient be happy? Would the patient say “Hey, I got a deal, it was a two-for-one-bypass!” Probably not. The patient might wonder if it was really necessary and be concerned about healing from so much surgery.

We need to recognize that software development is the execution of a set of procedures which are deeply tied to the customer's well-being in complicated ways. Padding a project with extra value and driving a team to "over deliver" on a product is not, actually, guaranteed to make the customer any better off than doing "more surgery" is guaranteed to be a better cure.

Of course surgery is not the most apt metaphor for software development. But it is useful to highlight some things that we overlook if we think of software only as a product (and that more “product” is always better):

• All projects are invasive, no matter how necessary or strategically important. Like medical procedures they must first do no harm and then seek to cure.
• Putting a lot of effort into adding extra whiz bang features, UI gloss, or performance optimizations all come at a cost to the client as increased maintenance, support, training, higher desktop or server requirements, and so on. These are long term costs and together can be significant!
• Trying to beat schedules or, worse, purposefully over-estimating to get an easier schedule to beat, ignores the fact that delivery has to be carefully timed for testing, user acceptance, deployment, training, support and so on. Trying to coordinate all of this with stakeholders while rigging and jumping schedules is really bad planning and wastes everyone’s time.
• Over delivering means delivering unexpected new features or working on a schedule not approved by the stakeholders. How is doing anything not approved by the stakeholders really better?

In short, I think that over delivering is just as bad as under delivering. Our goal should always be to deliver the feature sets we defined with all stakeholders on the schedule agreed upon. Honest communication about what is expected and when is the only way a project can succeed. When the pressure is on to “just do more than expected” we need to keep in mind that over shooting and under shooting both miss the bulls eye.