I många projekt, även om de drivs agilt, behövs någon form av uppskattning av hur mycket projektet kostar även om det oftast endast är en grov uppskattning som efterfrågas. Om inte annat för att för sin egen del få en uppfattning om projektet är realistiskt eller inte.
Det finns mycket skrivet om hur man skall planera sitt projekt, göra budget, riskanalys osv. Problemet med dessa metoder, som jag ser det, är att det i mindre projekt blir mycket svårt att räkna hem arbetstiden för att göra en kostnadsuppskattning. Självklart blir kostnadsuppskattningen antagligen bättre, men det är inte självklart men mer om det i en annan artikel, om man lägger tid på det. Om man som konsultbolag bjuder på många projekt blir man inte konkurrenskraftig om offertarbetet tar för mycket tid.
Det finns som hjälp olika modeller där man uppskattar antalet funktioner i programmet och sedan beräknar antalet kodrader osv utgående från tidigare erfarenheter från liknande projekt. Jag minns att på min första arbetsplats fanns det personer som jobbade med administrativa system. De skissade på antalet skärmbilder (24X80 tecken) som skulle visas och om det var inmatning eller bara presentation. Det känns som rimligt i en känd isolerad miljö göra denna typ av relativt säkra kostnadsuppskattningar när både användargränssnitt och datormiljön är väldigt stabil.
Det görs också riskanalyser och många andra saker under planeringen av ett projekt. Problemet är att det inte är det som man känner till som är det svåra att uppskatta kostnaderna för. Svårigheten ligger i att förstå tidsåtgången för det som man inte känner till i planeringen av projektet. Här gömmer sig många saker som t ex oförutsedda händelser i omvärlden, risker inom mindre kända områden osv. Man kan kalla det okända okändheter (uknown uknowns) vilket Donald Rumsfeldt myntade i början av 2000-talet med vilket han menade, enligt min tolkning, saker man inte ens vet att man inte vet.
Här är en artikel som beskriver hur ett projekt kan systematisk jobba med okända okändheter
Alltså ännu mer att tänka på vid uppskattning av projekt. Vad som för mig känns alltmer som den enda vägen framåt för mindre projekt är att använda genomförda projekt och dess faktiska kostnader för att estimera ett projekt. Det liknar lite det man gjorde under 80-talet inom administrativa system. Självklart varierar funktionaliteten mycket men om man skriver ner vad projektet gjort, olika svårigheter osv kan ett nytt projekt som skall kostnadsuppskattas förhoppningsvis jämföras med de dokumenterade. Att sedan bedöma om det nya projektet innebär mer eller mindre arbete inom olika områden är ofta lättare att göra än att estimera det nya projektet. Man får göra en bedömning av skillnaderna och därmed vilka kostnadsförändringar man skall göra varefter en justering av projektets kostnadsuppskattning kan göras. Här får man också se upp med de okända okändheterna eftersom det ny a projektet inte är en exakt kopia på det gamla.
En del av Dr Steen Lichtembergs metod har som en komponent för kostnadsuppskattningar, verktyg som liknar ovanstående resonemang. Man inleder med att gör en uppskattning utefter egna erfarenheter. Sedan multiplicerar man med faktorer för olika typer av förändringar som det nya projektet kommer att stå inför., t ex att utvecklingsmiljön ändras, ny projektmedlemmar som skall läras upp eller något annat.
Har man tidigare gjort projekt så kan man med hjälp av ”velocity”-begreppet inom Agil utveckling också förbättra kostnadsuppskattningarna genom att man uppskattar tiden efter det man känner till och sedan anpassar man till de vanliga verklighetsproblemen som är svåra att uppskatta genom att använda velocity-faktorn.
Den som estimerar får då möjlighet att utgå från att ”Om du har 4 h ostörd tid, hinner du med uppgiften på den tiden” Det är mänskligt att lättare kunna sätta sig in i hur lång tid det tar om man bedömer hur mycket ostörd tid jag behöver för uppgiften. Likaså är det lättare att följa upp om uppgiften verkligen går som man tror. Se till att få riktigt ostörd tid vid tillfällen och se hur det går.
Denna metod kan rekommenderas för de delar som skiljer sig från tidigare projekt. Men allt bygger på att man har verkliga referenspunkter att hålla sig i och att ha projektkostnaderna är dokumenterade. Det kan vara ett litet, medelstort eller stort projekt osv.