Tidsuppskattarens dilemma - om kostnader i IT-projekt

Vår bransch har tyvärr ett dåligt rykte när det gäller förmågan att hålla uppsatta kostnadsramar. Det dåliga ryktet är välförtjänt men det är inte så enkelt som att vi avsiktligt underskattar kostnaden för ett projekt. Tvärtom ägnar i alla fall vi på Exsitec mycket kraft på att bli bättre på att tidsuppskatta våra projekt.

Om vi tänker oss att den kända omfattningen i en tänkt lösning gör att projektet tidsuppskattas till 500 timmar så accepterar nog de flesta att det kan vara så mycket som +/- 20% i avvikelse mellan tidsuppskattning och verkligt utfall. Det är alltså rimligt att tänka sig att en leverantör i utbyte mot att göra projektet på fastpris skulle ta ett riskpåslag på 100 timmar och alltså sälja mot ett fast pris motsvarande 600 timmars konsulttid.

En leverantör som är trygg i sin projektkalkyl bör kunna lämna ett fastpris på den kända delen av ett projekt. Vår grundregel är att om risk/osäkerhet bedöms till mer än 30% av totalen så skall vi vara uppriktiga kring detta med kunden och vi skall inte lämna något fast pris.

Men problemet ligger oftast inte där, utan det ligger i vad som ingår i "den kända omfattningen" eller snarare vad som inte ingår. Som leverantör måste man arbeta med avgränsningar för att kunna lämna ett fast pris och vi försöker alltid vara tydliga med avgränsningarna i ett projekt.

Exempel på vanliga avgränsningar:

• Vi känner inte till varken struktur eller kvaliteten på data i kundens gamla system och det kan på goda grunder antas att den förändring man vill göra i verksamheten gör att gammal data inte längre är relevant. Vi kan därför inte trovärdigt uppskatta hur mycket tid en datakonvertering tar.
• Vi kan inte veta hur van kundens personal är vid att arbeta med IT-baserade hjälpmedel och vi vet därför inte hur mottagliga de är för utbildning och hur mycket stöd som behövs efter projektet. Stöd efter driftsättning brukar vi uppskattat enligt bästa förmåga, men det går inte att veta med någon stor säkerhet.

Dessutom finns det tillägg eller ändringar som varken kund eller leverantör kan uppskatta innan projektet:

• Ett systeminförande är ett inlärningsprojekt där den lösning man i slutänden går i drift med inte är samma som man tänkte sig när man inledde projektet. Vi kan inte uppskatta hur mycket tid vi kommer lägga på ändringar eller tillägg under projektet.
• Kundunika rapporter och integrationer till andra befintliga system är också oerhört svårt som leverantör att lämna en god uppskattning på.

Den totala effekten i ett projekt kan ofta vara något i nivå med figuren nedan.

Det är alltså ett projekt som från början uppskattades till 500 timmars konsulttid, som med ett riskpåslag, med nedlagd tid för att hantera definierade avgränsningar, samt med tid för tillägg och ändringar samt att stötta kunden i att använda systemet har tagit totalt 1000 timmars konsulttid.

Om man som leverantör tydligt har berättat om avgränsningar och gett kunden chansen att ta beslut kring alla tillägg och ändringar under projektets gång skulle nog de flesta leverantörer av verksamhetsstödjande IT-system tycka att detta är ett ganska hanterbart och ansvarsfullt hanterat projekt. Det är inte konstigt att ett estimat på en känd omfattning om 500 timmar i verkligheten tar 1000 timmar innan det är fullt i drift i kundens verksamhet.

Tidsuppkattarens dilemma är då - när jag vet att de 500 timmarna kommer bli mer för kunden - hur kan jag kommunicera detta på ett uppriktigt sätt som ger kunden kontroll över kostnaderna utan att skrämma bort kunden när man jämförs med konkurrenter?