Estimation vs. commitment

I love es­ti­mat­ing soft­ware pro­jects.

Oh, who am I kid­ding?! Most IT pro­fes­sion­als hate be­ing asked how long the task will take. They hate it for a good rea­son: they find it worth­less, and they know their es­ti­mates are usu­al­ly wrong any­way. As such IT pro­fes­sion­al, for me, Soft­ware Es­ti­ma­tion by Steve Mc­Connell is mind blow­ing.

The book quick­ly be­came one of my fa­vorite tech­ni­cal books, among Mc­Connell's Code Com­plete. It de­scribes a lot of as­pects re­lat­ed to soft­ware es­ti­mates, and not only the ac­tu­al tech­niques to cre­ate the es­ti­mates, but also every­thing sur­round­ing the es­ti­mates, such as how to pre­sent them to the stake­hold­ers.

While it would be im­pos­si­ble to talk about all the sub­jects de­scribed in this book, I would rather fo­cus on just one as­pect which looked in­ter­est­ing for me when read­ing this book, and which I wish I knew be­fore: the dis­tinc­tion be­tween an es­ti­mate and a com­mit­ment.

An es­ti­mate is pure­ly tech­ni­cal. This is the thing you mea­sure (us­ing the pre­cious tech­niques de­scribed in Mc­Connell's book), and which is not sub­ject to ne­go­ti­a­tion. Your boss can­not tell that your es­ti­mate of nine weeks for a new fea­ture is not OK, be­cause the fea­ture should be shipped in sev­en weeks: un­less your boss changes the ac­tu­al re­quire­ments, it's nine weeks. Not eight or ten:

A soft­ware es­ti­mate is the re­sult of an an­a­lyt­i­cal ac­tiv­i­ty, and it isn't ra­tio­nal to ne­go­ti­ate the es­ti­mate.

A com­mit­ment, on the oth­er hand, is an en­gage­ment, from a de­vel­op­er or a team or a pro­ject man­ag­er, to de­liv­er the prod­uct for a giv­en date. The com­mit­ment is based on the es­ti­mate, and takes in ac­count the risk of not meet­ing the sched­ule. Some­times, it might be ac­cept­able to com­mit to a date even if you have 10% prob­a­bil­i­ty to meet the dead­line; some­times, it should be bet­ter to com­mit to a date which has a high prob­a­bil­i­ty of suc­cess. There­fore, a com­mit­ment can be ne­go­ti­at­ed.

Dur­ing my whole ca­reer as a free­lancer, I mis­un­der­stood this es­sen­tial dif­fer­ence be­tween es­ti­mates and com­mit­ments. Now that I re­call the pro­jects I worked on, in every case, when a cus­tomer was ask­ing me for an es­ti­mate, he want­ed a com­mit­ment in­stead.

Real es­ti­mates are sim­ply too tech­ni­cal. There­fore, cus­tomers won't un­der­stand them and won't care. An in­ter­est­ing case was a re­cent pro­ject where I had made an es­ti­mate 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, un­til I re­ceived an e-mail from the cus­tomer's ex-Mi­crosoft con­sul­tant 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 at­tempt­ed to ex­plain:

• That the sum of all steps makes ab­solute­ly no sense,
• That high val­ues for M are ex­plained by the fact that there is prac­ti­cal­ly no in­for­ma­tion about the pro­ject, that our de­vel­op­ers didn't know the tech­nol­o­gy well enough, and for a bunch of oth­er fac­tors,
• That re­mov­ing the plus-mi­nus qual­i­fi­er won't make the un­cer­tain­ty go away,
• That PERT's crit­i­cal path mat­ters.

But the cus­tomer kept in­sist­ing that the es­ti­mate should be changed, and so I did an ad­di­tion­al fake ver­sion of it, while mak­ing sure it has no le­gal val­ue what­so­ev­er.

I un­der­stand now that what the cus­tomer ac­tu­al­ly want­ed is to get our com­mit­ment for a giv­en date. It be­longed to me to pro­vide not a de­tailed es­ti­mate, but a sin­gle com­mit­ment for a giv­en num­ber of days, and ne­go­ti­ate it based on the risk only I would know from the ac­tu­al es­ti­mate which would be kept in­ter­nal.

I am con­vinced that most non-tech­ni­cal stake­hold­ers should only see a com­mit­ment, not an es­ti­mate. If you're asked to do an es­ti­mate, make sure you un­der­stand what the per­son ac­tu­al­ly needs. If you've al­ready done an es­ti­mate and the per­son at­tempts to ne­go­ti­ate, this is a good sign that it's the com­mit­ment, and not an es­ti­mate, which was need­ed. In my opin­ion, it would even be safer to sys­tem­at­i­cal­ly com­mu­ni­cate a com­mit­ment first, and then, only if the per­son ap­pears more tech­ni­cal that you thought, pro­vide an es­ti­mate at the ori­gin of the com­mit­ment.