Det är nog inte så många som har hört talas om ”osäkerhetskonen”, gör man en Google sökning på det så finner man inte så många nyttiga träffar, men söker man på ”Cone of Uncertainty” så får man en hygglig mängd. Jag tycker detta är konstigt då jag ofta använder mig av denna metod för att beskriva osäkerheten i olika stadier av projektet, fast oftast så använder jag den engelska termen även om jag förklarar på svenska.
Osäkerhetkonen är ett riktigt bra sätt att beskriva osäkerhet i projekt och i synnerhet om man använder sig av agila projektmetodiker eftersom vi blir bättre på att estimera ju mer vi lär oss om det vi skall estimera. Projekt per definition har en osäkerhet kring det som skall levereras och för att hantera risker som relaterar till osäkerheten så gör vi ofta förundersökningar, prototyper eller Scrumspikes för att bevisa att konceptet håller och flyttar oss då längre ner i osäkerhetkonen och estimeringar blir mer pålitliga och närmare sanningen.
Forskning indikerar på att i början på projekt livscykler så är osäkerhetsfaktorn 4 gånger både på upp och ner (Boehm, B (1981). Software Engineering Economics, Prentice-Hall.). Så om ett projekt estimeras till att ta 100 timmar så kan det lika gärna ta 400 som 25 timmar vilket inte inger något större förtroende hos sponsorer.
En fråga som jag ofta fått när man presenterar osäkerhetskonen för sponsorer är om man inte kan lägga mer tid på estimeringar för att minska variansgapet. Mitt svar blir då att det inte går, då man måste estimera på det som skall göras tillsammans med de resurser som är med i projektet. Det jag brukar föreslå är att man kan göra ett testskott på högriskområden och bryta ner projektet i mindre delar och raffinera processen igen. Det man inte vill göra är att binda sig till den första tidsestimeringen för hela projektet utan att estimeringen bör göras kontinuerligt under projektets gång för att dra nytta utav erfarenheten man samlat på sig under tiden. Från ett affärsmässigt perspektiv är detta ibland svårt att få till då man vill veta hur mycket det kommer att kosta före man drar igång då bindande kontrakt skall skrivas under före man drar igång. I dessa fall skulle jag rekommendera att ha riktigt bra marginaler.
Iterativa projekt har fördelen att man vet vilken hastighet (velocity) som teamet har levererat tidigare iterationer på och då flyttar man sig naturligt närmare spetsen på konen. Ju fler iterationer man genomfört ju bättre estimeringar får man vilket är en trevlig visualisering att ha med sig som produkt ägare eller projektledare när man träffar sponsorer eller plockar prioriterar från backloggen.
Att kunna tid och kostnadsestimera systemutvecklingsprojekt är en svår konst att bemästra. Men om det inte krävs kreativitet och osäkerhet kring detaljer så gör man nog bäst i att köpa in en färdig lösning istället för att utveckla i egen regi.