Kunsten at reducere risiko i IT-projekter: en trin-for-trin guide
Da Top-Toy gik konkurs, blev der peget fingre af et mangeårigt og budgetoverskridende IT-projekt, der ellers skulle have redet dem. Mens hardwaren stod klar på togstationerne rundt omkring i landet, gik der et par år og et par budgetoverskridelser, før softwaren til det famøse rejsekort endelig var klar. IT projekter har med tiden desværre fået et ry for at blive solgt for billigt og altid gå over tid.
De ovenstående IT-projekter var dog allerede dødsdømt fra starten. Mange IT-projekter hænger stadig i en gammeldags forståelse af projektledelse, der minder meget om byggebranchens konstante problematik med det, som Bent Flyvbjerg kalder strategiske løgne, hvor planlæggere bevidst underestimerer projektets omkostninger og overestimerer projektets potentielle gevinst. At scope et projekt rigtig, er et job der kræver dygtige mennesker der har prøvet det før, hvis integritet beror på præcisionen af deres estimater. Udviklingen af estimaterne og arkitekttegninger burde aldrig være en del af en salgsproces, hvor sandsynligheden for sådanne strategiske løgne er stor, for det er ofte her, hvor IT-projekter fejler. Arkitekttegninger bør udarbejdes af nogen, hvis arbejde rent faktisk er at sandsynliggøre risici, så de med integritet og en klar track record kan skabe ro omkring IT-projektet, ved konstant at “de-riske” i den indledende fase.
I Kvalifik har vi lavet en proces til at kortlægge så mange af projektets usikkerheder som muligt tidligt i processen og har lavet det som en fast SOP (Standard Operating Procedure) når vi opstarter et komplekst IT-projekt. Selvom Standard Operating Procedures måske lyder bureaukratiske og kedelige, er den rigtige proces være altafgørende for at sikre kvaliteten. Processen sikrer kort fortalt, at de rigtige spørgsmål bliver stillet og de rigtige kompetencer er involveret, for at producere nogle arkitekttegninger der rent faktisk kortlægger og minimerer risici, forbundet med et IT-projekt.
Vores SOP til risikominimering i IT-projekter
En af de største udfordringer ved at bygge ny software, er at tegne de rigtige arkitekttegninger, så man ikke spilder ressourcer på byggepladsen – for løber det løbsk på byggepladsen, bliver det først for alvor dyrt. Derfor har vi lavet en proces der sikrer at man tager de rigtige forholdsregler i den tidlige udviklingsproces, så man ikke spilder sine ressourcer.
Sådan udarbejder du de rigtige arkitekttegninger til dit nye platformsprojekt
Typisk har selv de mest simple IT-projekter en væsentlig grad af kompleksitet i sig, selvom det ikke ser sådan ud ved første øjekast. Kompleksiteterne er vanskelige at kortlægge og snakke om, fordi sproget ikke er det bedste medie til at snakke om f.eks. relationelle databaser, brugerflows eller nytænkte digitale features. Et IT-projekts succes afhænger i høj grad af at bygge med så lidt spild som muligt – altså med færrest mulige timer brugt på ting, vi alligevel ikke skulle bruge. Derfor er arkitekttegningerne til et IT-projekt også så ekstremt vigtige, da de giver et sprog hvorpå man kan snakke om kompleksiteterne, samt et sted hvor man konkret kan iterere over sin idé, så den udvikles i den rigtige retning. Gode arkitekttegninger gør processen billigere og hurtigere ved at formindske spild i processen. Derfor har vi også en helt konkret procesopskrift for hvad vi skal igennem, når en samarbejdspartner kontakter os omkring et platformsprojekt, så vi kan præsentere dem nogle gennemarbejdede arkitekttegninger. En proces der kort sagt sørger for at “de-riske” projektet.
Processen kræver:
- En account manager, der sørger for at facilitere en møderække, uddelegere roller, lave agendaer, tage noter, samt facilitere udarbejdelsen af User Stories, der skal bruges til at afdække platformens kompleksitet.
- En teknisk konsulent, der sparer omkring tekniske udfordringer og på baggrund heraf udarbejder modeller til at fremme forståelsen af platformens tekniske kompleksitet, såsom eksempelvis et ER-diagram og en initiel data-model.
- En designkonsulent, der sparer omkring UI og UX-indsigter og står for udarbejdelsen af modeller til forståelse af features eller brugerflows, mest af alt gennem low-fidelity sketches.
- En udvikler der er villig til at spille "planning poker" med den tekniske konsulent for på baggrund heraf at levere en budgetramme for projektet.
- Et kollaborativt whiteboardværktøj. I Kvalifik bruger vi Miro, men der findes mange lignende værktøjer.
Processen indeholder 6 faser, der gennem flere små leverancer faciliterer den rigtige læringsrejse, i vores tilfælde for både Kvalifik og vores samarbejdspartner.
1 Kortlægning af brugerbehov og user stories
Whiteboard-workshop med hovedformål at kortlægge platformens brugertype og så mange User Stories som muligt. Både Kvalifik og samarbejdspartneren deltager. En User Story er det perfekte pædagogiske værktøj, til at sørge for at alle forstår hinanden, samt arbejder softwarens brugere ind i funktionaliteterne fra dag ét. En User Story defineres ved at udfylde hullerne i sætningen: ”Som en {BRUGERTYPE}, vil jeg gerne {HANDLING}, så {ØNSKET RESULTAT}”.
Deltagere: Alle
Resultat: Fundament for at forstå platformens egentlige features, gennem første iteration af User Stories
2 Udbygning af user stories
Desk-research hvor account manageren, den tekniske konsulent og designkonsulenten gennemgår alle user stories, eventuelt kommer med på nye user stories og laver low-fidelity sketches på de User Stories, som vi kortlagde på første workshop.
Deltagere: Account manager, teknisk konsulent, design konsulent
Resultat: Low-fidelity sketches og anden iteration af User Stories
3 Gennemgang af brugerrejse
Whiteboard-workshop hvor vi gennemgår de sketches og User Stories der er blevet afdækket i fase 2, for at indsamle feedback. Sammen med kunden gennemgår vi platformen fra start til slut, kommer med nye User Stories og idéer til flows, samt genprioriterer alle platformens features ud fra de hypoteser vi har. Det sker næsten hver gang, at noget fundamentalt ved platformen gentænkes i denne fase, på en måde hvor projektet bliver simplere og mindre ressourcekrævende at bygge.
Deltagere: Alle
Resultat: Feedback på sketches og User Stories, samt revurdering af platformens hypoteser
4 Teknisk estimering
Desk-research hvor alle aktiviteterne fra fase 2 gentages. Derudover sætter den tekniske konsulent sig sammen med en udvikler og laver "planning poker" på baggrund af alle de kendte User Stories. Målet er at dissikere platformsudviklingen ned i epics og give et overordnet estimat af hver epic. En epic er en samling af opgaver der udgør en feature, der løser en eller flere user stories. På dette tidspunkt begynder platformens overordnede data-model også at danne sig, og den tekniske konsulent udvikler et såkaldt ER-diagram for at anskueliggøre den tekniske kompleksitet, der ellers kan være svær at snakke om.
Deltagere: Account manager, teknisk konsulent, design konsulent, samt udvikler
Resultat: Sidste iteration af User Stories og low-fidelity sketches af platformen samt et ER-diagram og epics med overordnede estimater, der gør det muligt at give en retvisende budgetramme for projektet.
5 Præsentation
Afslutningsmøde hvor vi sammen gennemgår de arkitekttegninger, der er blevet produceret undervejs. Dette inkluderer de epics, vi har udarbejdet og den resulterende budgetramme.
Deltagere: Alle
Resultat: Arkitekttegninger for platformsprojektet bestående af ovennævnte user stories, low-fidelity sketches, ER-diagram, samt epics med overordnede estimater. I forening sikrer disse arkitekttegninger, at et efterfølgende udviklingsprojekt af platformen vil bringe værdi ved at løse projektets hovedformål.
6 Retrospective
Retrospective-møde hvor vi internt i Kvalifik gennemgår processen og overvejer hvad vi med fordel kan gøre bedre næste gang.
Deltager: Alle undtagen kunden
Resultat: Konstant forbedring af vores SOP
Processen varer maks en måned og giver et overblik over de største usikkerheder, der er forbundet med digital platformsudvikling, ved at kortlægge de grundlæggende hypoteser man har omkring sit projekt. Når man har gennemgået de 6 trin, har man de rigtige arkitekttegninger og derved den nødvendige viden for at udvikle en større digital platform uden ressourcespild.
God IT de-risking!
