Estimation vs. commitment
I love estimating software projects.
Oh, who am I kidding?! Most IT professionals hate being asked how long the task will take. They hate it for a good reason: they find it worthless, and they know their estimates are usually wrong anyway. As such IT professional, for me, Software Estimation by Steve McConnell is mind blowing.
The book quickly became one of my favorite technical books, among McConnell's Code Complete. It describes a lot of aspects related to software estimates, and not only the actual techniques to create the estimates, but also everything surrounding the estimates, such as how to present them to the stakeholders.
While it would be impossible to talk about all the subjects described in this book, I would rather focus on just one aspect which looked interesting for me when reading this book, and which I wish I knew before: the distinction between an estimate and a commitment.
An estimate is purely technical. This is the thing you measure (using the precious techniques described in McConnell's book), and which is not subject to negotiation. Your boss cannot tell that your estimate of nine weeks for a new feature is not OK, because the feature should be shipped in seven weeks: unless your boss changes the actual requirements, it's nine weeks. Not eight or ten:
A software estimate is the result of an analytical activity, and it isn't rational to negotiate the estimate.
A commitment, on the other hand, is an engagement, from a developer or a team or a project manager, to deliver the product for a given date. The commitment is based on the estimate, and takes in account the risk of not meeting the schedule. Sometimes, it might be acceptable to commit to a date even if you have 10% probability to meet the deadline; sometimes, it should be better to commit to a date which has a high probability of success. Therefore, a commitment can be negotiated.
During my whole career as a freelancer, I misunderstood this essential difference between estimates and commitments. Now that I recall the projects I worked on, in every case, when a customer was asking me for an estimate, he wanted a commitment instead.
Real estimates are simply too technical. Therefore, customers won't understand them and won't care. An interesting case was a recent project where I had made an estimate with a nice PERT chart, and all the steps marked as N ± M, such as “5 ± 2 days.” I thought I did a great job, until I received an e-mail from the customer's ex-Microsoft consultant telling that the sum of all the steps is too high, that M is too big and that I should get rid of the ± M part. I attempted to explain:
- That the sum of all steps makes absolutely no sense,
- That high values for M are explained by the fact that there is practically no information about the project, that our developers didn't know the technology well enough, and for a bunch of other factors,
- That removing the plus-minus qualifier won't make the uncertainty go away,
- That PERT's critical path matters.
But the customer kept insisting that the estimate should be changed, and so I did an additional fake version of it, while making sure it has no legal value whatsoever.
I understand now that what the customer actually wanted is to get our commitment for a given date. It belonged to me to provide not a detailed estimate, but a single commitment for a given number of days, and negotiate it based on the risk only I would know from the actual estimate which would be kept internal.
I am convinced that most non-technical stakeholders should only see a commitment, not an estimate. If you're asked to do an estimate, make sure you understand what the person actually needs. If you've already done an estimate and the person attempts to negotiate, this is a good sign that it's the commitment, and not an estimate, which was needed. In my opinion, it would even be safer to systematically communicate a commitment first, and then, only if the person appears more technical that you thought, provide an estimate at the origin of the commitment.