Därför får ni ert plattformsbyte prissatt två gånger

Ni har fått en offert. Ni har skrivit på. Arbetet drar igång, och några månader in kommer nästa siffra: en ny prislapp på det som visade sig vara svårare än väntat, eller ligga utanför scopet.

Att det kommer ett andra pris överraskar sällan den som räknat på projekt förr. Förklaringen ligger i hur den första kalkylen gjordes.

Priset sätts innan någon vet hur arbetet ser ut

I en vanlig offert sätts priset på arbete som ännu inte är påbörjat. Ingen vet hur lång tid integrationen mot ert affärssystem tar innan någon öppnat det. Ingen vet vilka undantag som gömmer sig i er prislogik, eller hur de ska hanteras som standard.

Det är inte oärligt, det är vad ett estimat är. Osäkerheten finns där på riktigt. Bygger man varje lösning nästan från grunden går osäkerheten knappt att få bort. Frågan är vem som bär den.

Osäkerheten är dessutom lätt att underskatta. En genomgång av 5 392 IT-projekt visar att kostnadsöverdragen inte fördelar sig jämnt kring ett medelvärde. De flesta drar över lite. Ett mindre antal drar över våldsamt.

Ungefär vart femte projekt blir minst femtio procent dyrare än budgeten. Och de projekten stannar inte vid femtio procent. I genomsnitt slutar de på drygt fem gånger summan som stod i offerten. Det värsta fallet i materialet var ingen stor satsning, utan en liten anpassning av ett arbetsflöde.

Medelvärdet beskriver alltså inte den risk ni tar. Och det syns aldrig i en offert.

Bilden är densamma i projekt av normal storlek. Mellan 60 och 80 procent av alla mjukvaruprojekt drar över på arbetsinsats eller tid. Det typiska projektet landar ungefär en femtedel över det beräknade, medan genomsnittet ligger dubbelt så högt. Skillnaden beror på att några få drar iväg och lyfter snittet. Oftast är det de större projekten som underskattas.

Ett förtydligande om siffrorna: de tal som brukar citeras i branschen är betydligt högre än de här, men kommer oftast från konsultrapporter och inte från forskning. Vi håller oss till de lägre.

Det svåraste att bedöma är integrationen

Prislogik, kundunika rabatter, lagersaldon och orderflöden ser enkla ut i en kravspecifikation och beter sig annorlunda i produktion. Ett pris som ser fast ut räknas i praktiken ofta om vid varje order, utifrån avtal, volym och kundgrupp. Den komplexiteten syns inte i offerten. Den syns senare i er fakturering.

Verklig användning driver fram tilläggen

Först när lösningen är i drift visar det sig vad kravspecen missade, och varje sådan upptäckt blir en ny beställning. Efter ett traditionellt projekts go-live kommer de många och tätt. Varje förändring blir en ny beräkning och en ny diskussion. För er betyder det att budgeten aldrig riktigt stämmer.

Underhållet är ingen restpost

Underhållsfasen står för runt 60 procent av vad en programvara kostar under hela sin livstid. IEEE Computer Society anger spannet 60 till 80 procent. Bygget är alltså den mindre delen av notan.

Den vanliga tumregeln säger att underhållet kostar 15 till 25 procent av byggbudgeten varje år. Den siffran kommer från system med få kopplingar utåt. En kundportal eller återförsäljarportal är kopplad till plattformen, affärssystemet och flera externa tjänster, och för den är 15 till 25 procent snarare en lägstanivå.

Vi har räknat på det och redogör för resultatet i en separat artikel. Bara Litium och Business Central står tillsammans för mer än fyrtio tillfällen om året då något runt lösningen förändras, utan att ni har beställt en enda av dem.

Det är den kostnaden vi byggt vår modell kring.

Varför vi vågar lämna fast pris

Vi lämnar fast pris. Det är rimligt att fråga hur vi vågar det.

Svaret är att vi oftast redan har byggt det som ska prissättas. Funktionerna i vårt bibliotek är i drift hos andra bolag, med integrationer mot Business Central, Monitor och Jeeves. Vi vet vilken kvalitet de håller och hur väl de fungerar ihop med resten av en lösning. Att sätta pris på något som redan finns är en helt annan sak än att sätta pris på något som ska tas fram iterativt, ibland utforskande.

Där ligger skillnaden. Ett sådant arbetssätt är rätt när ingen ännu vet vad som ska byggas, och då hör osäkra estimat till bilden. Det går inte att sätta ett exakt pris på något som ska utforskas fram, det ligger i sakens natur. På standardiserat arbete går det.

Det gör också att mindre behöver byggas nytt. Ju mindre av ett projekt som är nytt, desto mindre finns det att underskatta.

Vi räknar dessutom annorlunda på det som byggs för flera. När en funktion tas fram för att sedan användas av fler bolag delas utvecklingskostnaden. Ni betalar för er andel av den och för anpassningen till er, inte för hela framtagningen.

Tre nivåer, samma prislogik

En funktion levereras i tre nivåer, beroende på hur unikt behovet är. Standard fungerar som den är. Anpassad använder vi när er process skiljer sig något. Kundunik tar vi fram när behovet bara finns hos er, och då bygger vi den avskild från resten, så att den inte påverkar övriga delar när plattformen uppgraderas. Alla tre levereras till fast omfattning och fast pris.

Det förändrar också vad go-live betyder. I stället för att vara startskottet för tilläggsfakturor blir det början på ett avtalat ansvar till fast månadskostnad. Vi följer versionerna på både plattformen och integrationen mot affärssystemet och ser till att de fortsätter fungera ihop. En uppgradering blir alltså inte en ny offert. Ni kan börja med en produktwebb och senare lägga till en kundportal på samma grund, utan att börja om.

Macro Design, en del av Svedbergs Group, tog frågan i den ordningen. De tecknade Care i samband med att implementationen av deras nya webbplats och återförsäljarportal på Litium avtalades. Förvaltningen hade en prislapp innan bygget drog igång, inte efter.

Vad upplägget kräver av er

Fast pris förutsätter låst omfattning. Vi lägger mer tid på förarbetet och stänger scope innan bygget startar, vilket betyder att ni behöver bestämma er tidigare än i ett löpande projekt. Dyker ett nytt behov upp längre fram prissätter vi det för sig. Skillnaden är att grunden vi räknar på redan finns, så siffran kommer snabbt och håller.

Vill ni ha full frihet att ändra riktning längs vägen är löpande räkning det ärligare valet. Vill ni veta vad det landar på innan ni börjar passar vårt upplägg bättre.

Två frågor att ställa nästa leverantör

Hur mycket av det ni offererar finns redan i drift hos någon annan idag? Och vad händer med priset när scope ändras efter go-live?

Svaren säger det mesta om vilken sorts siffra ni har framför er.

Vill ni ha en jämförelsepunkt gör vi en nulägesanalys av er lösning. Ni pekar ut er domän och avsätter två timmar för ett möte. Inom 72 timmar efter mötet får ni tillbaka en inventering av er nuvarande funktionalitet och era integrationer, en funktionsspecifikation för lösningen framåt, en prototyp som visar hur den skulle se ut och en komplett kostnadsbild med tidsplan. Analysen kostar ingenting, och underlaget är ert att använda oavsett vad ni bestämmer er för.

Källor

Fördelningen av kostnadsöverdrag och exemplet med arbetsflödesanpassningen: Flyvbjerg, Budzier, Lee, Keil, Lunn och Bester, "The Empirical Reality of IT Project Cost Overruns: Discovering a Power-Law Distribution", Journal of Management Information Systems, vol. 39 nr 3, 2022.

Andelen projekt som drar över mer än 50 procent och snittet bland dem: Flyvbjerg och Gardner, How Big Things Get Done, 2023, appendix A.

Andelen projekt som drar över, det genomsnittliga överdraget och skillnaden mellan medelvärde och median: Moløkken-Østvold och Jørgensen, "A Review of Surveys on Software Effort Estimation", IEEE International Symposium on Empirical Software Engineering, 2003. Jämförelsen med konsultrapporternas högre tal finns i Jørgensen och Moløkken-Østvold, "How large are software cost overruns? A review of the 1994 CHAOS report", Information and Software Technology, 2006.

Underhållets andel av livscykelkostnaden: IEEE Computer Society, med liknande siffror i ISBSG:s projektdatabas. Tumregeln på 15 till 25 procent per år är branschpraxis från system med få externa kopplingar och inget uppmätt värde för integrerade portallösningar.

Antalet förändringstillfällen per år: Litiums publika release notes och Microsoft Learn för Dynamics 365 Business Central. Räkningen finns i vår artikel om vad en TCO-kalkyl behöver innehålla.