Konsten att beställa agila systemprojekt

Idag efterfrågas agila projekt på flera håll. Agila projekt är en fantastisk möjlighet att lyckas med ett projekt som är svårt att definiera från början. De agila projekten utvecklades när beställare fann att det var allt för stora initiala kostnader med att göra förstudier och dokumentation som med stor sannolikhet skulle komma att förändras under utvecklingens gång. 

Ett agilt projekt passar när ni behöver utveckla något helt nytt, där det ska finnas möjligheter att förändra längst vägen och utforma projektet såsom ni har behov av. För att få en produkt som löser just era specifika behov. 

Fördelarna är uppenbara, den svåra biten är självklart kostnadsprognosen eftersom projektet i sin natur ska utvecklas så som ni har behov av. Det vanligaste är att skapa ramar för vilka kostnader som ska ingå och hur mycket resurser som finns tillgängliga för ett projekt.

Hur agilt kan ett uppdrag vara?

Att mäta agilitet i sig är väldigt svårt. Ett sätt skulle kunna vara att mäta antalet timmar som ligger till grund för ett projekt och vad projektet sedan slutade med. Men det innebär ju att själva lösningen och komplexiteten inte räknas med. Men för tydlighetens skull har vi ett exempel. Vi har grävt i vår data från våra senaste 10 projekt (ca 1000 h i storlek) och sammanställde hur stort estimatet var då projektet startade tills vi stängde det, för att se hur estimatet förändrades. Svaret blev i snitt +85%. Variationen är väldigt stor, allt från -6% till +222% (blå staplar i grafen nedan).

Hur kan det variera så mycket? 

Variationen innebär att komplexiteten i uppdragen har skiljt sig åt. I ett projekt där timmarna blir högre än estimatet i samråd med beställare har projektet med stor sannolikhet tagit en vändning som inte förutsågs från början, vilket är syftet med ett agilt projekt. De mest agila projekten är de som resulterat i förändringar av tidsramarna. Exempelvis om man under projektets gång vill koppla ytterligare ett system till lösningen så påverkar detta projektet som helhet.

Vad är alternativen?

Ett sätt att minska variationen (blå staplarna i diagrammet) i projektet är att genomföra detaljerade förstudier såsom nämndes i början av inlägget. Detta kan driva både kostnad och kalendertid i sig. Dessutom tenderar scoopet att växa i och med en mer grundlig sondering av de behov som finns i organisationen. Detta kan i sin tur skapa dyrare projekt med fler men mindre “nyttig” funktionalitet. Givetvis beror behovet av förstudie på typen av uppdrag och handlar egentligen om vilken grad av förstudie som sker innan man som kund är redo att beställa.

Variation är bra

Med andra ord kan det vara bättre att snabbt komma igång med att implementera basfunktionerna för system, för att efter införande reflektera och förädla. Det är alltså i regel viktigare att de stora frågorna har en bra match, att systemet är rätt för er verksamhet. Att det går att koppla ihop med er övriga miljö. Att det är kompatibelt med era planer för framtiden och så vidare. 

Kostnadskontroll även i agila projekt

Hur håller man kostnadskontrollen i ett agilt projekt när tidsåtgången kan variera? En reflektion kring analysen av de 10 projekten som nämndes tidigare är att det går att ha fantastiskt bra kostnadskontroll trots stor variation i tidsåtgång. Exempelvis har vi i våra projekt lagt stor vikt kring att i samsyn med beställaren, gå igenom vad som ingår i uppdraget och inte. Snittet ligger på 0% i avvikelse och variationer mellan -10% och +7% (röda staplar i grafen nedan). Som beställare är denna parameter viktig, om inte viktigast.

Kostnadskontroll innebär att projektet inte skenar iväg, det kommer inte byggas funktioner hej vilt och beställaren kommer inte få funktioner som är betydligt mycket dyrare än vad de skapar mervärde. Projekten är och bör vara levande, men även i agila projekt ska man ta aktiva beslut, med leverantören som rådgivare och kunden som beslutsfattare.

Beställare av agilt projekt

Beställ uppdraget utifrån ett “måste ha”-läge, dvs endast rena krav ligger till grund för estimat och fokusera sedan på ett bra sätt att fånga upp och styra alla ändringsönskemål i projekten, samt hitta en leverantör som kan möta ert krav på arbetssätt. I detta blogginlägget kan du läsa mer om MVP (Minimal Viable Product) och vad ett “måste ha”- läge innebär. 

Sammanfattning

• Syftet med agila projekt är att de ska vara levande och hitta era unika utmaningar och lösningar på dem
• Hitta en leverantör som har bra kostnadskontroll
• Hitta ert “måste ha”-läge
• Leverantören är rådgivare och du som kund beslutsfattare
  

Är du nyfiken på vidare läsning? Kolla in guiden om att utveckla en egen affärsapplikation.