Maybe you are familiar with the "under-promise, over-deliver" terms. In the case you don’t, the way I see it, they basically explain the good practice of setting stakeholder’s expectations under the level of what would be the final deliverable.
But what happens when someone, trying to make an over-deliver, end up by delivering something else that does not match the stakeholder expectations?
I call that "other-deliver":
How we should call something that in the mind of who delivers it is "far better from what they are expecting!" but when is finally delivered, the stakeholder claims "this is definitely not what I wanted!!!"?
Again, "other-deliver".
What is a developer doing when coming with the ideal solution that will solve everything and does anything but the only thing is expected to? Well, that developer is probably "otherdeliverying".
Maybe the point is not as much as seeking under-promise and over-deliver, else, getting first off the other-deliver.
So what can we do about it? I think that if an updated status of what the delivery will be about is always in both parties minds then the chances of falling into an other-deliver will be uncertain. Keeping an updated status may come in many flavors: meeting minutes, backlogs, tasks lists, SLA (Service Level Agreement).
These updated status tools would be helping on setting on the stakeholders the expectations needed in order to make the next over-deliver.
What do you think?
