Time estimation. Done.

Arseni Mourzenko
Founder and lead developer
161
articles
November 6, 2014
Tags: management 33

When I start­ed my ca­reer as a free­lancer, I used to re­cur to or­di­nary tech­niques of the good old wa­ter­fall-style pro­ject man­age­ment. It is not sur­pris­ing that I also scrupu­lous­ly tried to de­ter­mine the time and the cost of a pro­ject be­fore start­ing one. Not that it was a pleas­ant task or that I wasn’t notic­ing that the real time I was spend­ing on a pro­ject had noth­ing to do with the eval­u­a­tions. While I un­der­stood that it doesn’t make too much sense to eval­u­ate a task I nev­er done be­fore, based on a one page long non-spec writ­ten by a per­son who seemed that he have no idea what the fu­ture pro­ject is about; it’s just that I thought I have no choice, and that this is a game we all have to play. Af­ter all, what would be a dif­fer­ent al­ter­na­tive? Ask­ing the cus­tomer to give a blank check?

Read­ing for a few hours about Ag­ile was large­ly enough to learn that no, we, pro­ject man­agers, don’t have to play the stu­pid game. The game is es­sen­tial for wa­ter­fall pro­jects, where, in­deed, an un­fin­ished pro­ject is a use­less pro­ject. But who would be so dumb to use wa­ter­fall for a pro­ject which is just de­scribed in a few bad­ly writ­ten para­graphs, and where the cus­tomer in per­son has no idea about the ac­tu­al needs? Well, it ap­pears that lots of com­pa­nies do that, but I di­gress.

The idea of eval­u­at­ing time for an IT pro­ject makes no sense. It makes sense out­side IT in­dus­try. For ex­am­ple, a com­pa­ny who built a bridge can be asked to build an­oth­er bridge which is very sim­i­lar to the first one. There would be room for ran­dom­ness, like a larg­er riv­er, or large build­ing near­by, or soft­er coasts, but still, it would be close enough to the pre­vi­ous pro­ject to be able to give an es­ti­mate. A com­pa­ny who built forty bridges had done enough es­ti­ma­tion mis­takes to be able to as­set some­thing pre­cise enough, based on the gaps be­tween the es­ti­ma­tion and the real cost, ob­served in the forty pro­jects done in the past.

Now, what would hap­pen if a com­pa­ny which built small bridges across rivers for fifty years is asked to build the five kilo­me­ters long bridge across an ocean? How pre­cise would be the es­ti­mate now? Would it re­al­ly make sense?

In IT, there are no iden­ti­cal pro­jects. If the same team is asked to do a pro­ject they al­ready did, they will sim­ply take what’s al­ready done. The same can­not be done with bridges: you can’t copy-paste a bridge to an­oth­er lo­ca­tion: build­ing the same thing still re­quires time and mon­ey. In IT, every pro­ject is new; oth­er­wise, it’s not a pro­ject, but a clone of a pre­vi­ous one. Since the pro­ject is new, the es­ti­mate can’t be based on facts and hard data. Let’s say a team cre­at­ed an app for iOS. Now, it’s time to cre­ate the same app for An­droid. Would it take ex­act­ly as long as it took to cre­ate the iOS app? Would it be short­er, be­cause all the ar­chi­tec­ture is al­ready done? Would it be longer, be­cause the team is com­posed of iOS de­vel­op­ers who don’t know An­droid well enough?

Time es­ti­ma­tion of an IT pro­ject is quite ran­dom. It’s less ran­dom for some pro­jects which are well-de­fined, with clear and com­plete re­quire­ments and a no changes to the re­quire­ments pol­i­cy. It’s more ran­dom for oth­er pro­jects where the whole de­scrip­tion is two or three para­graphs of text writ­ten by some­body who re­al­ly want­ed to avoid think­ing a bit about the dif­fer­ent as­pects of the pro­ject.

This means that when­ev­er some­body agrees to do a weak­ly-de­fined pro­ject for a giv­en amount of mon­ey, there is some­thing wrong. In the past, I gave two-num­bers es­ti­mate: the av­er­age price—the price I ex­pect the pro­ject would cost, and the max­i­mum price—the price the cus­tomer will pay no mat­ter what. There was some­thing wrong with that. Every time. One of those wrong things was that it made it to­tal­ly im­pos­si­ble to let the cus­tomer ad­just the re­quire­ments over time, and changes to the re­quire­ments would be ac­cept­ed only at the “end of the pro­ject”. Wa­ter­fall? Any­body?

In Ag­ile world, there is still agree­ment upon cost, but in­stead of agree­ing what the en­tire pro­ject would cost, the cus­tomer agrees that a giv­en amount of hours of a team will cost a giv­en amount of time, and that the team ex­pects to de­liv­er spe­cif­ic fea­tures for the first sprint. This makes the pro­ject ex­treme­ly flex­i­ble for the cus­tomer. A six-months pro­ject can stop af­ter three months, be­cause the cus­tomer be­lieves that the pro­ject is ma­ture enough, or be­cause the cus­tomer doesn’t have enough mon­ey, or be­cause pri­or­i­ties changed, or… what­ev­er. In­stead of a wa­ter­fall black­out with a dilem­ma be­tween con­tin­u­ing a pro­ject no mat­ter how much does it cost, and can­celling it with­out hav­ing any­thing con­crete, the cus­tomer is now con­front­ed to hard data and the pos­si­bil­i­ty to take a de­ci­sion to end the pro­ject at any time, while hav­ing a work­ing piece of soft­ware.

An IT pro­ject is not some­thing which has a well-de­fined end of life. Un­like a bridge, whose build­ing process ter­mi­nates ex­act­ly when the bridge is ready to be used, a soft­ware prod­uct evolves. This makes its end high­ly un­pre­dictable most of the time. Some pro­jects end be­cause the cus­tomer doesn’t have mon­ey. Oth­ers—and this is the case of too many prod­ucts—end be­cause they are a com­plete fail­ure. In very rare cas­es, pro­jects end be­cause the cus­tomer con­sid­ers that there are no more fea­tures to im­ple­ment, and more im­por­tant­ly, no bugs left.

The un­pre­dictabil­i­ty of a pro­ject lifes­pan is an ad­di­tion­al in­di­ca­tor that it doesn’t make sense to es­ti­mate the over­all time it would take to ac­com­plish it. We can’t ac­com­plish a pro­ject, since in or­der to do it, we must first be able to pre­dict when the pro­ject will be fin­ished.

Con­clu­sion:

Why, as a cus­tomer, you don’t want to deal with some­one who claims he can es­ti­mate your pro­ject?