Dockyard of ships that can’t sail

Bad­ly man­aged pro­jects of­ten share an el­e­ment: the will­ing­ness to de­liv­er all fea­tures in a giv­en amount of time and with­in bud­get.

Giv­en how we con­cep­tu­al­ize the no­tion of a de­liv­er­able out­side IT world, it feels in­tu­itive. When I or­der a piece of hard­ware on­line, I ex­pect it to be de­liv­ered on time and ex­pect the pack­age to con­tain every­thing I or­dered, not only a part of it. When I buy an ob­ject in a su­per­mar­ket, I ex­pect it to be avail­able im­me­di­ate­ly, un­di­vid­ed.

But again, our rep­re­sen­ta­tions which work out­side IT world fails mis­er­ably when it comes to soft­ware de­vel­op­ment. If you want to fail a pro­ject, if you want to ob­tain fic­tion in­stead of a work­ing prod­uct, then re­quir­ing the whole pro­ject to be fin­ished for a giv­en dead­line is the most ef­fec­tive thing to do.

Build­ing fic­tion

We, de­vel­op­ers and pro­ject lead­ers, build fic­tion be­cause, with­in the mod­el of a fixed, com­plete, dead­line-bound de­liv­ery, this ap­pears to be the only pos­si­ble way to re­spond to cus­tomers’ needs. In a wrong way, but still re­spond.

IT pro­jects are, in essence, or­gan­ic sys­tems which con­stant­ly grow and evolve. This process stops only in two cas­es: ei­ther be­cause the sys­tem reached its sta­ble state, which, in prac­tice, is ex­treme­ly rare, or be­cause the sys­tem is con­sid­ered dead, in oth­er words ei­ther sus­pend­ed with­out pre­cise plans to main­tain or change it, or de­fin­i­tive­ly aban­doned.

If we ac­cept this as­ser­tion as grant­ed, it ap­pears that de­liv­er­ing the pro­ject for a pre­cise dead­line makes no sense what­so­ev­er: since it evolves or­gan­i­cal­ly all the time, the only way to “de­liv­er” it for a dead­line is to con­sid­er it dead when it reach­es it—not some­thing to wish for a pro­ject.

Agreed, there are a few cas­es where the pro­ject has a fi­nite state, i.e. when the orig­i­nal WBS, SOW and func­tion­al and non-func­tion­al re­quire­ments are so com­plete that there is no room for ran­dom­ness or fuzzi­ness. Note that this re­quires not only to know ex­act­ly every as­pect of the fu­ture soft­ware prod­uct, but also every quirk which can be caused by the un­der­ly­ing tech­nolo­gies. I’ve nev­er seen such a prod­uct.

So, we de­cide to cram an or­gan­ic, con­stant­ly evolv­ing sys­tem into a box of a re­quire­ment to de­liv­er the whole thing on an ar­bi­trary date. This can lead to two types of dis­as­ters: ghost pro­ject or quick-hack mess.

Ghost pro­ject

A pop­u­lar mar­ket­ing ap­proach con­sists of prepar­ing con­tent which shows some of the fea­tures of a prod­uct, with­out hav­ing any prod­uct be­hind, a sort of emp­ty shell. For ex­am­ple, a com­pa­ny can pub­lish a video which shows a user ma­nip­u­lat­ing the fu­ture web ap­pli­ca­tion, while the video was done from sta­t­ic HTML pages with no code be­hind.

As a mar­ket­ing ap­proach, it’s a per­fect­ly valid way to show­case a prod­uct which is not yet done.

As a way to make real prod­ucts for real cus­tomers, it’s a to­tal fail­ure. While a pub­lic which might, one day, pur­chase your prod­uct, can be sat­is­fied by a “don’t touch that; don’t go there” pre­sen­ta­tion, a cus­tomer who or­dered a prod­uct and al­ready in­vest­ed hun­dreds of thou­sands of dol­lars in it won’t be. Even if such pre­sen­ta­tion would be a suc­cess, very rapid­ly, the cus­tomer will start test­ing the app, in­ter­act­ing with it, dis­sect it, to find that you de­liv­ered just a bunch of fan­cy pic­tures.

In prac­tice, com­pa­nies which de­liv­er ghost pro­jects are near­ly nonex­is­tent, prob­a­bly be­cause such com­pa­nies will come out of busi­ness pret­ty fast.

Quick-hack mess

The quick-hack mess, on the oth­er hand, is very fre­quent in the world of pro­ject fail­ures. It con­sists of de­liv­er­ing some­thing which looks cor­rect to stake­hold­ers, while the team knows very well that the prod­uct is ei­ther un­fin­ished, or even re­al­izes very well that the pro­ject is a com­plete fail­ure. The pro­ject is still of­fi­cial­ly con­sid­ered fin­ished by the team, so they are able to say: “Hey, we de­liv­ered the pro­ject on time” to the ones who pay them. Lat­er, when the stake­hold­ers start to re­veal bug af­ter bug, the team qual­i­fies it as “main­te­nance of a pro­ject de­liv­ered on time.” I’m sor­ry, they are ly­ing.

I won’t even start list­ing all that’s wrong with this ap­proach. In short, it is one of the four ma­jor caus­es of pro­ject fail­ures, the three oth­er be­ing bad man­age­ment, com­mu­ni­ca­tion is­sues and in­com­pe­tence. There is no way to de­liv­er any­thing ac­cept­able, since once the quick-hack mess is de­liv­ered, the dark pe­ri­od be­gins for the team: the pe­ri­od where the team will spend sleep­less nights fix­ing one part of the code base just to no­tice that it broke some­thing else­where. The des­per­ate fight for “just make it work” stops ei­ther when the cus­tomer has enough of re­port­ing bugs, or doesn’t have mon­ey to pay ex­tra for a nev­er ready pro­ject.

Some­times, this des­per­ate fight can be short: the pro­ject can’t even be de­ployed in pro­duc­tion; the cus­tomer un­der­stands that he was screwed from the be­gin­ning, and can­cels the pro­ject. Sad­ly, of­ten, the cus­tomer who al­ready spent hun­dreds of thou­sands of dol­lars is hes­i­tat­ing to de­clare a fail­ure, and con­tin­ues to pay, er­ro­neous­ly be­liev­ing that “in a week, all bugs will be solved,” sink­ing into the self-de­cep­tion and the de­nial of the fa­mous 90% Done syn­drome.

How to avoid build­ing fic­tion

De­vel­op­ers do well what you de­mand them to do. If you ask them to de­liv­er crap un­der sched­ule, they do it. If you change the state­ment of the prob­lem, it would be solved dif­fer­ent­ly. In oth­er words, by shift­ing the prob­lem out of the fa­mil­iar con­cept of de­liv­er­able into the world of Ag­ile, the pro­ject is mag­i­cal­ly saved from be­ing dis­as­ter, or at least the 100% prob­a­bil­i­ty of be­ing a dis­as­ter.

In Ag­ile, there is no pro­ject as a de­liv­er­able: there are tasks, sort­ed and grouped with­in a set which can be done with­in a short pe­ri­od of time (call it Sprint or what­ev­er you like). The abil­i­ty to sort tasks im­plies pri­or­i­ties. The abil­i­ty to group them im­plies a ful­ly-func­tion­al, work­ing sys­tem which is pushed into stag­ing, and can be even­tu­al­ly pushed into pro­duc­tion, if need­ed.

This rad­i­cal­ly changes the rules of the game. In­stead of be­ing forced to de­liv­er a sys­tem where every as­pect looks as work­ing, but none re­al­ly works, you de­liv­er a well-writ­ten, main­tain­able, ex­ten­si­ble parts of the sys­tem you fin­ished in a giv­en amount of time, keep­ing the rest of the sys­tem un­der de­vel­op­ment.

Tar­get fea­tures, and don’t waste time cre­at­ing sched­ules.

De­liv­er reg­u­lar­ly, de­liv­er of­ten, and make some­thing which works at every de­liv­ery. If the pro­ject is can­celled, at least you have some­thing which al­ready works, and works damn well.

What could pos­si­bly hap­pen? An un­hap­py cus­tomer would be an­gry that the prod­uct isn’t fin­ished? It wouldn’t be any­ways. What would be the ben­e­fit of ly­ing, in­stead of giv­ing a pre­cise im­age of what is al­ready done and what fol­lows?