Back to blog

Seks konkrete trin til at minimere risiko i den tidlige fase af et IT-projekt

Written by August Kristian Gjede, Co-founder & Managing Partner23 August, 2021

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.

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.

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.

Fase 1: Whiteboard-workshop med hovedformĂ„let om 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

Fase 2: 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

Fase 3: 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

Fase 4: 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.

Fase 5: AfslutningsmÞde hvor vi sammen gennemgÄr de arkitekttegninger, der er blevet produceret undervejs. Dette inkluderer det 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.

Step 6: 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!