Projekt för digitalisering i 3 steg – 2: Få ut max av utvecklingstiden

Projekt för digitalisering i 3 steg – 2: Få ut max av utvecklingstiden

Det här är det andra blogginlägget i en serie om digitaliseringsprojekt som vi valt att kalla för Projekt för digitalisering i 3 steg. Vi delar upp ett digitaliseringsprojekt i tre steg: 

  • Hur du kommer igång 
  • Hur du får ut mest av varje utvecklingstimme
  • ..och slutligen hur du får största möjliga värde ur din investering efter lanseringen

I det här blogginlägget reder vi ut hur du får ut maximalt värde ur varje nedlagd utvecklingstimme i projektet. Att driva systemutvecklingsprojekt är utmanande men samtidigt fantastiskt inspirerande och värdeskapande när det fungerar som det ska. Vi hoppas kunna ge dig några bra tips längs vägen.

Från det förra blogginlägget i den här serien tar vi med oss en övergripande backlog innehållandes User Stories. Det är en bra grund för att komma igång med projektet.

Hantering av projekt: Planering, implementering, repeat

Det första vi gör är att göra planeringen för den första implementationsperioden. Vi kallar ofta en sådan period i ett projekt för en sprint. Kort beskrivet så innehåller en sprint först en planering följt av implementation och till sist en leverans inklusive en demonstration av resultatet. När en sprint är levererad så börjar man om igen med samma procedur. Det här sättet att arbeta kallas för ett agilt arbetssätt och finns i flera olika projektmodeller inkl. Scrum och Kanban.

“Dessa lärdomar är ofta värdefulla att kunna agera på i en senare projektfas”

Det är klokt att dela upp projektet i flera olika faser. Den första fasen bör vara en så kallad MVP (Engelska: Minimum viable product) vilket innebär att system byggs med minsta möjliga funktioner men som ändå uppfyller minimikraven. Det är en bra utgångspunkt eftersom man ofta lär sig mycket under projekttiden. Dessa lärdomar är ofta värdefulla att kunna agera på i en senare projektfas utan att budgeten redan är slut.

Att driva projekt på det här sättet underlättar ordentligt för den beställande parten då man alltid har full kontroll över prioriteringen i projektet men även ur det perspektivet att leveranser görs med jämna mellanrum. På så sätt är det enkelt att prioritera om eller ändra fokus längs vägen om det är så att vissa funktioner inte kommer att behövas eller fungera annorlunda än man först trott.

I varje IT-projekt: Testa, testa och testa

Ett framgångsrikt IT-projekt är ofta ett vältestat sådant. Det är viktigt att komma igång tidigt med testerna. Om det är möjligt bör tester genomföras av beställarorganisationen i samband med samtliga leveranser. Det har flera tydliga fördelar. Testningen skapar en tidig förståelse av systemets funktioner vilket leder till bättre förutsättningar för att prioritera uppgifter. Arbetet leder också till högre kvalitet då det alltid är bra att hitta fel eller feltolkningar tidigt snarare än sent i implementationen. Ju längre projektet kommit desto svårare blir det generellt att göra designförändringar.

“…och tänker du tanken ‘det löser sig säkert senare’ så är det en tydlig varningssignal.”

Under projektets gång: Om det inte finns i backlogen så finns det inte

När projektet rullat igång så förändras backlogen genom att uppgifter blir lösta, omprioriterade, tillkommer eller tas bort. Det är viktigt att den här listan av uppgifter hålls uppdaterad längs vägen då det är den som bestämmer vad projektteamet gör och i vilken ordning det görs. En vanligt fallgrop är att tänka att teamet har koll på uppgifter som känns självklara för beställaren. Det kan exempelvis handla om en funktion som man pratat om under införsäljningsfasen men som inte (av någon anledning) kommit med i backlogen. Sådana funktioner tenderar till att byggas alldeles för sent i projektet eftersom de oftast upptäcks som saknade när systemet ska testas inför leverans. Tänk istället på backlogen som den enda riktiga sanningen i projektet och tänker du tanken “det löser sig säkert senare” så är det en tydlig varningssignal att hantera.

Prioritera tiden med hjälp av 80/20-regeln

Det sägs ibland sarkastiskt att när man kommit 80% in i projektet så har man 80% kvar. Det beror ofta på att teamet börjar fokusera på detaljer i funktioner istället för att lösa de viktigaste funktionerna ur ett “gott nog”-perspektiv. Det tar oftast längre tid än man tror att göra systemet perfekt och det kostar betydligt mer att göra första versionen perfekt eftersom vissa funktioner kanske inte kommer att användas så mycket som man tror initialt. Vårt tips här är att försöka spara lite tid och pengar för justeringar istället för att få till den första lanseringen helt perfekt. Det kostar ofta 80% av budgeten att gör de sista 20 procenten och de är sällan de sista procenten av lösningen som skapas mest värde.

Vid projektets slut: Vad händer nu?

När projektet löper mot sitt slut börjar det bli dags att planera för lansering av projektet. Funktionerna är byggda, testade och endast finjustering återstår innan det är dags att trycka på startknappen.

I det sista inlägget i den här bloggserien kommer vi prata om vad som vi tycker är viktigt att tänka i den fasen.

Kontakta skribenten

Admin
Admin