Fast pris eller löpande räkning för ett IT-projekt – vad skyddar oss bäst?

Båda modellerna kan gå fel

Med fast pris vet ni summan i förväg, men får bara det som stod i offerten. Med löpande räkning betalar ni för det som faktiskt görs, men utan tak vet ni inte vad slutsumman blir. Ingen av dem är fel i sig. Det som spelar roll är hur väl uppgiften är känd när ni skriver avtalet.

När fast pris fungerar

Fast pris passar när omfattningen går att beskriva och bedöma: ”en kundportal med dessa tre flöden”, ”en koppling mellan CRM och ekonomisystem”. Då tar leverantören risken för att det tar längre tid, och ni slipper bevaka timmarna.

Två risker att känna till:

• Priset har en buffert. Leverantören räknar in osäkerheten. Ju osäkrare omfattning, desto större buffert.
• Alla ändringar blir tilläggsbeställningar. Det som inte stod i beskrivningen kostar extra, och ett vagt underlag ger många diskussioner om vad som ”ingick”.

När löpande räkning fungerar

Löpande räkning passar när ni utforskar: ni vet problemet men inte lösningen, eller behöver en person som arbetar tillsammans med teamet under en period. Det är en rimlig modell om ni sätter ett tak per månad, följer upp varje vecka och kan avbryta utan kostnad.

Risken är att ingen har ett eget intresse av att avsluta. Utan tak, och utan en tydlig plan för vad som ska levereras, kan kostnaden växa utan att något blir klart.

Mellanvägen: fast pris per steg

Det går att kombinera. Dela projektet i steg där varje steg är avgränsat nog att prissättas fast, och offerera nästa steg först när det föregående är levererat. Så arbetar Altu, och det beskriver vi på sidan om skräddarsydda system. Fördelarna:

• Ni kan ändra riktning mellan stegen utan att tvista om tillägg.
• Varje steg ger något ni kan använda och testa.
• Ni binder aldrig mer pengar än nästa steg.

Vad ett fast pris måste definiera

Före underskrift ska det stå vad som ingår, hur ni godkänner leveransen och vad som händer med ändringar:

1. Leveransens innehåll. Vilka flöden, vilka roller, vilka integrationer.
2. Godkännande. Hur ni testar, och hur länge ni har på er att reklamera.
3. Ändringar. Hur de begärs, prissätts och godkänns innan arbetet startar.
4. Äganderätt. Att kod och databas är era när ni betalat.

Frågor att ställa

• Vad ingår i priset, och vad ingår inte?
• Vad händer om något tar längre tid än beräknat? Vem betalar?
• Om vi vill ändra oss efter första steget, vad kostar det?
• Kan vi avsluta efter ett steg utan kostnad för nästa?

Fler frågor att ta med finns i Vad ska stå i en offertförfrågan för ett skräddarsytt system? och Vad ska en kalkyl för ett AI-projekt innehålla?.

Vill ni diskutera upplägg för ert projekt? Hör av er.