“When will it be released?”

In the pantheon of my least favorite software questions, this ranks near the top.

“When it is done.”

This response has to rank near the top of management’s least favorite answers.

The problem above isn’t a simple battle between the management team and the development team about estimates. The problem shown above is a catastrophic misunderstanding of the difference between an estimate and a commitment and a needlessly flippant response to that misunderstanding. The question “when will it be released” is not a request for an estimate of any sort—not of time, of complexity, or of effort. It is a request for a commitment. A commitment that cannot in good faith be made.

Let me repeat that last bit for you one more time: the commitment that is being asked above cannot be made in its current form. The closest thing to an accurate answer to a commitment like that above would have to take the following maddening form:

“Assuming the team is structured like this ______, nobody has a sick day or a family emergency, no responses are needed from the client or from vendors, management doesn’t reallocate teammates for an emergency project, no new information is found, the team runs into no difficulties, and our current understanding of the problem accurately represents what the client expects, it is likely to be done by _______. Release can follow that.”

Look at that pile of caveats—and make no mistake, given more time I’m sure that we could come up with several more that aren’t listed here—for now, let’s assume that this is a fairly complete list. Look at the items that are outside of the team’s control: sick days and family emergencies, client response times, vendor response times, and management reallocation of teammates; a formidable list. Given that, how could anybody accurately assess when something will be delivered?

Simply put, they cannot. We learn this lesson time and again in organization after organization but the lesson never sticks.

Estimates are not commitments. Estimates are meant to be used for the singular purpose of making informed decisions, but none of those informed decisions should include delivery date. Some decisions that estimates can be helpful for do include determining what to charge, determining how to staff the project, coordinating multiple parts of a delivery, or even approximating when the work is likely to be done. Note that important difference: when work is likely to be done is very specifically NOT the delivery date. If you are using estimates to create a delivery date, you are taking on a tremendous risk.

I’ve made no pains to hide my general disdain for estimates. I typically refer to them as “polite fictions we share with one another”, “random guesses supported by lies”, and “suppositions with numbers attached”, and these are just the most polite terms. I loathe estimates because they are so often used poorly, but they can be a highly effective tool. It is up to you to ensure that your estimates stay estimates rather than sliding into the delivery-destructive bomb that is known as committment.

Teaching your entire delivery team and management structure the important difference between and estimate and a committment might be the single most loving act you can commit on behalf of your clients.