We all want to deliver excellence. But one ‘nugget’ of wisdom in consulting is that it is best to under-promise and over-deliver.  The implication is we should say we only need to do X but then deliver X + Y and everyone will love getting more than they expected. But is this really a good idea?

What if a patient went in for a single bypass surgery and afterwards the doctors said they did two? Should the patient be happy? Should he/she 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 more surgery.

We need to recognize that software development is the execution of a set of procedures which are deeply tied to the client’s health in complicated ways. Each technical decision, even at the level of a database stored procedure, for example, is like a small incision that shapes the outcome of the whole project. But sometimes it becomes an imperative on a project to deliver both mightily and most vigorously, to bear down upon a set of deliverables and try to just knock the client’s socks off. This is not bad. But what about over-delivering by under-promising?

I’ve come to think of that idea as just plain wrong. More surgery does not automatically make for a successful outcome. 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. And when the pressure is on to “just do more than expected” we need to remind ourselves that over shooting and under shooting both miss the bulls eye.