Fast pris för webbprojektet känns ofta tryggt för kunden initialt. Men det finns ingen garanti för att man kommer att bli nöjd med resultatet. Med ett agilt arbetssätt jobbar alla tillsammans, även kunden. Då ligger garantin istället i att slutresultatet kommer att bli bra.
För bägge alternativen finns det en fast budget att förhålla sig till. Skillnaden handlar i hur man förhåller sig till vad som ska byggas. Vid fast pris är slutresultatet exakt definierat innan man börjar. Men i det agila alternativet lämnas stort utrymme för att göra förändringar undervägs. Det sker genom att kunden och leverantören tillsammans gör prioriteringar för att uppnå bästa möjliga resultat.
Att begära fast pris för ett webbprojekt är inte fel i sig. Det fungerar bra när bägge parter är helt överens om exakt vad som ska göras, när det ska göras och hur det ska ske. Det är när ett fast pris ska sättas på ett otydligt definierat projekt som det blir problematiskt. Kommer saker och ting att behöva göras på ett annorlunda sätt än det som initialt estimerades, kan tid och därmed också kostnader snabbt skena iväg.
Samma sak gäller om siten ska integreras med andra system eller om det finns externa parter inblandade. Under sådana förutsättningar blir det snudd på omöjligt att sätta ett fast pris.
Att upphandla utvecklingsprojekt till fast pris kräver mycket av beställaren. Vad webbplatsen eller lösningen ska kunna göra behöver vara specificerat på ett tydligt sätt så att leverantören förstår det. Alla kritiska detaljer om hur projektet ska fungera mellan parterna och när leverans ska ske måste också upp på bordet. Finns det externa kopplingar eller andra externa aktörer med i bilden blir kravställningen lätt så komplex att ett agilt arbetssätt är att föredra.
Så gott som all prissättning i IT-branschen sker utifrån tidsestimat, även för fast prissättning. Man beräknar det antal arbetstimmar som behövs för att bygga och leverera lösningen och det fasta pris man får består i praktiken av ett antal timmar. Vill beställaren i ett fast pris-projekt göra ändringar eller tillägg under resans gång så kommer budgeten sannolikt att spricka. Man får också räkna med att leverantören kommer att vilja ta höjd för den risk det innebär att lämna fast pris på ett utvecklingsprojekt.
Det ligger i beställarens intresse att fastprisestkmat också bygger på timmar. Att budgetar baseras på timmar möjliggör en bra planering och uppföljning, vilket i sin tur gör att leverantören kan lämna relevanta deadlines och leveransdatum, och hålla dem.
Det kan kännas skrämmande att gå in i ett projekt där inte allt på på förhand är tydligt specificerat. Det kan lätt upplevas som att gå på löpande timräkning och man oroar sig för att timmarna ska skena iväg. Men poängen med det agila arbetssättet är att man säkerställer att timmarna används på ett optimalt sätt. Både leverantören och beställaren är med och prioriterar vad som ska göras så att mesta möjliga värde och bästa möjliga resultat uppnås.
Att kunna förhålla sig till och dra full fördel av ett agilt arbetssätt handlar mycket om ett mindset hos beställaren. Finns det redan tidigt ett tydligt fokus på vad lösningen ska ge, snarare än att få fram lösningen i sig, så får man mer ut av sin investering.
Om man redan i budgeteringsfasen pratar effektmål snarare än lösning skapar det förutsättningar för att projektet ska bli lyckat och att beställaren blir nöjd med slutresultatet. Projektet kan då inriktas på att ta fram en produkt som ger maximal effekt för pengarna.
Den agila budgeten förutsätter en agil projektmetodik, till exempel Scrum. Den bygger på att lösningen tas fram iterativt från prototyp via en serie av versioner där den stegvis förbättras och byggs på. Fördelen med det är att man tidigt har en första version av produkten på plats med alla dess kritiska funktioner. Den kan sedan testas, förbättras och stegvis byggas på med mer funktionalitet tills dess att budgeten är slut. Man börjar med det som är högst prioriterat och rör sig ner i prioritering. På så sätt läggs inte tid på mindre viktiga funktioner så att budgeten tar slut innan de viktigaste är färdiga.
Under vilka förutsättningar passar fast pris bra och när är det agila arbetssättet ett bättre alternativ? Det är inte alltid lätt att avgöra. Här är några fingervisningar som kan hjälpa till att bedöma vilket som blir bäst för det aktuella projektet.
Att bli utsatt för någon typ av cyberattack eller ett intrång kan få allvarliga konsekvenser. Men att uppnå ett ganska bra skydd är inte särskilt svårt.
MVP är en förkortning för Minimum Viable Product. Det är ett viktigt koncept inom mjukvaruutveckling.
SEO har många lager och är mer komplext än man tror. Här är det viktigaste du behöver veta för att klättra i sökresultaten.
Hur mäter man och optimerar man CX – Customer Experience?