Projektestimering - en gissningslek

Att estimera ett projekt är en vetenskap i sig, eller rättare sagt, är ingen vetenskap alls. Vad är det egentligen för vanföreställning som kan få beslutsfattare, inköpare, styrgrupper och andra projektintressenter att på allvar tro att någon med precision kan uppskatta tidsåtgång, budget och exakt innehåll i ett IT-projekt? Inte ens ett litet projekt kan med exakthet estimeras. Faktum är att vi har problem med de enklaste estimeringar. De flesta går förmodligen bet på att gissa hur lång tid det tar att skala ett kilo potatis. Hur ska man då kunna gissa vilken dag om ett år ett IT-projekt med tjugo medarbetare kan leverera? För gissningar är precis vad det handlar om. Vid upphandlingar går (tyvärr) oftast kontraktet till den som offererar det lägsta priset, vilket i IT-sammanhang brukar vara ekvivalent med den kortaste leveranstiden. Att säga att man kan leverera ett projekt på en viss tid och inom budget är en sak, att göra det är en helt annan. Beställarna vill gärna se fastprisåtaganden. Leverantörerna vill helst se löpande räkning. Man vet nämligen att det är behäftat med stor risk att binda sig vid ett fast pris, framförallt när det krävs att man behöver dumpa priset för att få kontraktet. Tyvärr finns det i regel alltid minst en förlorare i ett fastprisåtagande. De två möjliga scenarierna är att:

  1. leverantören estimerar för högt, dvs projektet går fortare att genomföra, och
  2. leverantören estimerar för lågt, dvs projektet tar längre tid att genomföra.

I det första scenariot kommer leverantören att lägga mindre tid och mindre resurser i sin leverans än beräknat. Det innebär att, jämfört med löpande räkning, så kommer beställaren att betala ett för högt pris.

I det andra scenariot kommer leverantören förr eller senare (förhoppningsvis förr) att upptäcka att estimatet inte kommer att hålla och att hans beräknade förtjänst kommer att minska eller rentav förvandlas till en förlust. Vad gör leverantören? Jo, han försöker med alla till buds stående medel begränsa sin förlust, dvs minimera sina kostnader. Han kommer att skära i kvalitet, minska i testning, kanske hyra in junior (billig) personal eller på andra sätt spara tid och pengar. Beställaren kommer att få sin leverans, som förvisso är enligt budget, men som sannolikt inte håller måttet i övrigt.

Om författaren
Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.