Från idé till specifikation och prototyp

”Här är en ritning av mitt drömhus, spika ihop något så hörs vi vid deadline.” säger ingen husbyggare.  Ändå är det precis den inställningen många har när det gäller sina drömmars IT-bygge. Allt började med en vision (eller, för all del, ett problem som borde fixats för fem år sedan) och nu är det äntligen dags för Den stora IT-satsningen, där denna vision ska bli verklighet. Men i denna process kan mycket gå fel, visar det sig, gång på gång. Vi startar från början:

50 procent inte enligt plan

Över 50 procent av alla projekt går inte enligt planen och cirka 15 procent räknas som regelrätta misslyckanden, enligt organisationen The Project Management Institute årliga undersökning 2018. Och oavsett om satsningen anses lyckad eller inte så slösas i genomsnitt cirka 10 procent av projektets totala budget bort på icke nödvändiga utgifter.[1] Det är inte speciellt uppmuntrande siffror.

I en bransch i ständig förändring finns det många osäkra faktorer som kan förstöra och förändra förutsättningarna för att lyckas, från en natt till en annan. Men trots detta ska man akta sig för att tillskriva makten åt slumpen. Saker går inte alltid enligt plan och slumpen kan sätta käppar i hjulen för de mest rutinerade projektledare, men skillnaden mellan ett lyckat projekt och ett misslyckat är att ta hänsyn till oförutsedda händelser och på så sätt ta makten över den.

Ritning på en servett

Fredrik Wångberg är CEO på Strikersoft och har jobbat med utvecklingsprojekt sedan början av 90-talet, och han har sedan start sett att folk är villiga att ta stora risker då det gäller denna typ av satsning. Man har en idé man vill komma igång med direkt och struntar därför i förarbetet, vilket garanterat är både dyrare och mer riskabelt i längden. 

– Det är lite som om de skulle krafsa ner ritningen för miljonvillan på en servett, ge den till en snickare och be denne börja bygga med kommentaren: ”du som expert vet väl vad som ska göras” – det skulle ingen göra.

Men när det kommer till IT-satsningar vill man gärna ta genvägar och förutsätter att idéer  blir verklighet bara någon tillräckligt skicklig sätter sig och knackar lite kod. En investering i förstudie, grafisk demo och prototyper ses som ett för dyrt steg. 

– Det slutar ofta i besvikelse, bränd budget och försenad leverans, säger Fredrik Wångberg.

Men det finns några riktlinjer att följa för att minska brandrisken och släcka potentiella budgetbränder innan det är för sent.

Det första steget – ta ett steg tillbaka

I början av ett projekt är det lätt att låta otåligheten styra. Man ser sin vision så tydligt framför sig, ett tjusigt bygge som fungerar fantastiskt. Det enda som återstår är ju att omvandla visionen till verklighet och det så snart som möjligt. Men i skuggan av en riktigt bra idé som tornar upp sig i all sin tydlighet är det viktigt att inte rusa rakt fram utan ibland stanna upp och ta ett steg tillbaka. Hur tydlig är egentligen visionen? Går den att koka ner till konkreta krav och user storys; vem ska använda produkten, på vilket sätt, för att göra vad?

Vid ett husbygge räcker det inte med en teckning på ett hus med väggar, tak, fönster och en dörr eller två – det krävs detaljerade ritningar och konkreta kravspecifikationer, bygglov och markanalyser. Var ska huset byggas? Vad finns det för andra faktorer att ta hänsyn till? Hur ser grunden ut? Är verkligen den där klippavsatsen 112 meter över havet den optimala platsen för en radhuslänga med småbarnsfamiljer?

På samma sätt måste man i ett IT-projekt inte bara tänka kring själva strukturen och bygget i sig. Man måste även ta hänsyn till utomstående faktorer som kan påverka projektet, både på kort och lång sikt, inom den egna organisationen och då det gäller tredje part. Det spelar ingen roll hur snyggt huset är om det rasar i sjön eftersom man la grunden på sank mark. Eller kanske inte la någon grund överhuvudtaget. Eller om det visar sig att utbyggnaden av terrassen inte får plats på tomten i fråga.

Tidigt identifiera risker

Bogdan Shelest är chef för R&D på Strikersoft och säger att detta är det första att undersöka i kontakten med en ny kund; var befinner de sig i denna process? Bogdan poängterar också vikten av att tidigt identifiera risker för att på så sätt kunna minimera dem.

– Innan vi börjar måste vi förstå vad kunden har för mål och förväntningar på oss och på projektet, och om de är redo att börja eller om man måste gå tillbaka och specificera idén bättre.

Ett exempel på en tydlig riskfaktor är för otydliga eller orealistiska specifikationer, till exempel om man vill bygga en ny produkt på en lastgammal plattform. Bogdan Shelest berättar att det händer att de ibland tvingas säga nej till kunder som har en allt för orealistisk bild av vad som krävs.

– Vi berättar alltid för kunderna om deras projekt är orealistiska eller omöjliga att genomföra, men då föreslår vi alternativ och försöker hitta ett sätt att lösa problemet. Då får de antingen göra sin hemläxa själva och återkomma senare, eller så kan vi hjälpa dem att utforma mer realistiska mål. Men oavsett så är de ofta väldigt tacksamma för att vi är öppna och ärliga.

Rita kartan steg för steg… 

När man har klart för sig var man befinner sig och vart man ska, är det dags att bestämma hur man ska ta sig dit, vad är steg 1? Vilka ramar finns då det gäller tid och pengar, resurser och kompetens? Finns all kompetens på plats? Här handlar det inte om att sätta en deadline eller två, eller göra en plan för allt som ska göras fram till slutmålet – det är ett säkert sätt att spräcka budgeten. Istället handlar det om att kartlägga vad som krävs för att man så snart som möjligt ska få ut något av den nya produkten. Ett vanligt problem är att man vill garantera en deadline då allt ska vara färdigt. Men ett datum är ingen magisk formel som automatiskt innebär att allt kommer vara klappat och klart just den dagen. Problemet är nämligen att ”allt” som ska vara klart är omöjligt att förutsäga i början av ett projekt.

Sara Bern är key account manager på Strikersoft och har under sina 30 års i branschen stött på denna inställning till ”deadline-garantin” åtskilliga gånger.

I 99 procent av fallen ändras förutsättningarna

– Att ”garantera en deadline” – det är alltid en chimär. I 99 procent av fallen så kommer kraven ändras, och ändras inte kraven så ändras förutsättningarna.

Därför bör man alltid arbeta agilt, berättar Sara Bern, det vill säga dela upp arbetet i små delmål och ta ett steg i taget, något som kan verka omständligt men som lönar sig i slutändan.

– I en osäker och föränderlig värld så tjänar man på att jobba på det sättet. Man får direkt och snabb återkoppling och man kan dra i handbromsen och styra om i tid. Det är ofta värt mycket, man sparar både tid och resurser.

Men för att detta ska fungera gäller det att alla deltagare verkligen förstår vad det innebär att jobba agilt.

– Ett vanligt scenario är att en del tror att de kan komma med en grundidé och sedan släppa allt och vila i tre månader för att sedan få slutprodukten. Det fungerar tyvärr inte så. Ska man ha korta återkopplingsloopar så innebär det också ett ansvar under hela utvecklingsprocessen. Finns inte den nära kontakten uppstår det lätt förseningar.

... i rätt riktning

För att undvika att samtliga tror att de vet hur drömhuset ser ut och kan vägen dit men sedan stegar iväg åt helt olika håll är det viktigt att säkerställa att alla har en gemensam uppfattning om hur drömhuset faktiskt ser ut. Det gäller att noggrant specificera och visualisera kraven och på så sätt säkerställa att alla har samma uppfattning om vart man är på väg.

– I ett tidigt skede måste man beskriva vad användarna vill uppnå och börja visualisera slutprodukten utifrån flera synvinklar, berättar Sara Bern.

Ungefär på samma sätt som man kompletterar svartvita husritningar bestående av mått och siffror med bilder och modeller av visionen, så kan man undvika kommunikationsmissar mellan produktägare, utvecklare och designers genom prototyper för användargränssnittet och tydliga beskrivningar i både text och bild.

Använd användar-kompassen

Testa produkten så snart det är möjligt. Få ut den på marknaden eller till en mindre grupp användare, beroende på vad som är mest lämpligt. Anpassa sedan produkten utefter respons och behov; ta bort det som inte funkar och lägg till det som saknas.

– Man jobbar på en ständigt prioriterad backlog-lista av önskemål, berättar Sara Bern. Det gäller att hela tiden förfina sin plan genom att titta noggrannare på de krav som ligger närmast i tiden. De som ligger lite längre bort höftar man och skissar på, många av dem kommer inte ens att bli aktuella eftersom kraven från marknaden, kunder med flera kommer att förändras under projektets gång.

Minimal Viable Product

Vid större projekt är målet att så snart som möjligt skapa en MVP (Minimal Viable Product) som kan testas på marknaden. På så sätt skapar projektet mervärde i ett tidigt skede och man har möjlighet att kontinuerligt anpassa arbetet utifrån de aktuella förutsättningarna och i relation till verkligheten, snarare än att försöka se in i framtiden och skapa en ”färdig” slutprodukt. Det vill säga ”färdig” tills man testar den och inser att man tyvärr inte var synsk och att allt måste göras om. Med det agila arbetssättet och kontinuerlig respons från användarna, där man utvärderar varje delsträcka för att säkerställa att man fortfarande är på väg åt rätt håll, så upptäcker man felstegen i tid innan man hunnit gå vilse.

Som en sammanfattning ger vi dig sex konkreta tips:

1. Ha en tydlig vision

• Går visionen att omsätta till konkreta krav och user stories? Vem ska använda produkten, på vilket sätt och för att göra vad? Är den realistisk och genomförbar?

2. Ta hänsyn till interna och externa faktorer

• Hur ser strukturen ut? Långsiktiga och kortsiktiga faktorer som kan påverka projektet. Internt och externt. Identifiera risker för att kunna minimera dem.

3. Sätt ramar och kartlägg vad som krävs

• Tid
• Pengar
• Resurser
• Tillgänglig kompetens

4. Arbeta Agilt

• Sätt mål och delmål. Ta ett steg i taget.

5. Förankra och skapa delaktighet

• Se till att alla delprojekt förankras och att alla förstår innebörden av att arbeta agilt.
• Beställare och utförare behöver vara delaktiga under hela processen till färdig produkt.

6. Testa produkten så snart det är möjligt

• Vid stora projekt skapa en MVP (Minimal Viable Produkt). Få ut den på marknaden och anpassa sedan utifrån respons eller behov. Ta bort och lägg till.

När låneförmedlaren Enklare fyllde fem år var det dags för en rejäl digital upprustning. Satsningen hade varit nedprioriterad under en längre tid, men nu stod det klart att hela systemet behövde göras om. Man gjorde en ambitiös affärsplan och anställde en ny IT-chef. Valet föll på Anders Jönsson, tidigare VD för Crowdsoft och med över 25 års erfarenhet inom IT- och informationsbranschen.

 – Man hade ett system i början som man har byggt på och byggt på och ”ståltrådat” och hackat och plåstrat, berättar Anders Jönsson.

Det var hög tid att sätta igång och han fick en överskådlig plan och en hygglig budget.

– Vi behövde komma igång NU. Det fanns medel, men nu sitter vi med en ganska liten IT-avdelning och alla hade redan massor att göra och var ganska slutkörda, så vi insåg att vi måste ha mer folk.

Anders föreslog att de skulle outsourca enskilda projekt och Enklare tog därför kontakt med systemhuset Strikersoft.

All kompetens redan på plats

Ett systemhus påminner om när man vid ett husbygge tar hjälp av en byggnadsentreprenör, med den skillnaden att istället för att byggnadsentreprenören i sin tur anlitar arkitekter, byggfirmor, takläggare och så vidare, så finns all kompetens redan på plats. På så sätt kunde Enklare förstärka sitt team utifrån behov, beroende på var i processen de befann sig.

– Man får in superduktiga utvecklare som kan göra alla grejer själva – databasskikt, användargränssnitt, affärslogik, api-anrop – och som förstår vad man säger, kan hålla tidsplaner och kvalitet, så vi kan hålla vad vi har utlovat.

Projekten ifråga är hittills tre stycken, som alla är av olika karaktär. Ett litet, ett lite större och ett jättestort. Det första gällde en helt ny produkt för Enklare som skulle möjliggöra deras inträde på marknaden som el-leverantör. De började med att en utvecklare från Strikersoft blev en del av Enklares team under två veckor för att kartlägga kraven och målen. Anders Jönsson poängterar även vikten av välfungerande kommunikation och konkreta kravspecifikationer.

– Det går inte bara att säga: ’Nu ska vi sälja el, kan ni lösa det?’ Du måste bryta ner det i rimliga arbetsportioner och samla in krav utifrån ett perspektiv som är implementerbart, både för att utvecklarna ska veta vad produktägaren vill ha och för att produktägaren ska förstå vad man får, vad som kostar och varför.

Första testversion

Utvecklaren åkte sedan tillbaka för att ta fram en första testversion, och när de hade en grund kompletterade de med ytterligare en utvecklare från Strikersoft.

– Det är ett väldigt mycket bättre och mer kostnadseffektivt sätt att arbeta. Men vi måste göra vår hemläxa och bryta ner det i krav som personen kan ta vid och förfina och fördjupa.

Anders Jönsson säger att en stor fördel att anlita Strikersoft som systemhus är att de får tillgång till experter inom alla tänkbara områden, så att de för varje steg i den agila processen kan anpassa kompetensen.

– Det är ett väldigt flexibelt och kostnadseffektivt sätt att arbeta. Om något problem uppstår eller man kommer på något nytt finns det alltid möjlighet att snabbt få tillgång till rätt resurser i rätt tid. Om vi inte hade jobbat på det här sättet hade vi inte kommit i mål alls, förklarar Anders Jönsson.

 _{[1] https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf
https://computersweden.idg.se/2.2683/1.686551/darfor-misslyckas-projekt-fortfarande}