.svg)
.svg)
.svg)
Da Top-Toy gik konkurs, blev der peget fingre af et mangeårigt og budgetoverskredet IT-projekt, som skulle have været deres redning. På trods af at hardwaren stod klar på togstationer over hele landet, tog det flere år og budgetoverskridelser, før softwaren til det berygtede rejsekort var færdig. IT-projekter har desværre fået ry for at være underbudgetterede og konsekvent overskride budgettet.
Disse IT-projekter var dog dødsdømte fra starten. Mange IT-projekter hænger stadig fast i en forældet forståelse af projektledelse, der minder om byggebranchens evige problem med det, Bent Flyvbjerg kalder "strategisk misrepræsentation", hvor planlæggere med vilje undervurderer omkostningerne og overvurderer fordelene. Nøjagtig afgrænsning af et projekt kræver erfarne fagfolk, hvis integritet afhænger af præcisionen af deres estimater. Udviklingen af estimater og arkitektoniske planer bør aldrig være en del af en salgsproces, hvor sandsynligheden for sådanne misrepræsentationer er høj, da det ofte er her, at IT-projekter går i stå. Arkitekturplaner bør udarbejdes af dem, hvis job er realistisk at vurdere risici og derved skabe tillid til IT-projektet gennem konsekvent "de-risking" i den indledende fase.
Hos Kvalifik har vi udviklet en proces til at kortlægge så mange af projektets usikkerheder som muligt på et tidligt tidspunkt og gjort det til en standardprocedure (SOP) for igangsættelse af komplekse IT-projekter. SOP'er lyder måske bureaukratiske og kedelige, men den rigtige proces er afgørende for at sikre kvaliteten. Kort sagt sikrer processen, at de rigtige spørgsmål bliver stillet, og at de rigtige kompetencer bliver involveret for at producere arkitekturplaner, der virkelig kortlægger og minimerer de risici, der er forbundet med et IT-projekt.
En af de største udfordringer ved at bygge ny software er at skabe de rigtige arkitektoniske planer for at undgå ressourcespild på byggepladsen - hvor omkostningsoverskridelser kan være særligt kostbare. Derfor har vi en proces, der sikrer, at de rigtige forholdsregler bliver taget tidligt i udviklingsprocessen, så vi undgår ressourcespild.
Selv de simpleste IT-projekter indeholder typisk en betydelig kompleksitet, som ikke umiddelbart er synlig ved første øjekast. Denne kompleksitet er svær at kortlægge og diskutere, da sprog ikke er det bedste medie til emner som relationsdatabaser, brugerflows eller innovative digitale funktioner. Et IT-projekts succes afhænger i høj grad af, at man bygger med så lidt spild som muligt - det vil sige, at man bruger så få timer som muligt på unødvendige elementer. Derfor er arkitekturplaner for et IT-projekt afgørende, da de giver et sprog til at diskutere kompleksitet og en ramme til at iterere på en idé i den rigtige retning. Gode arkitekturplaner gør processen billigere og hurtigere ved at reducere spild. Vi har en specifik procesopskrift for, hvad vi gennemgår, når en partner kontakter os om et platformsprojekt, så vi kan præsentere dem for detaljerede arkitekturplaner. Denne proces er designet til at "de-risikere" projektet.
Processen kræver:
- En account manager til at facilitere møder, uddelegere roller, lave dagsordener, tage noter og facilitere udviklingen af User Stories for at afdække platformens kompleksitet.
- En teknisk konsulent til at diskutere tekniske udfordringer og skabe modeller til at forstå platformens tekniske kompleksitet, f.eks. et ER-diagram og en indledende datamodel.
- En designkonsulent, der diskuterer UI- og UX-indsigter og skaber modeller til forståelse af funktioner eller brugerflows, primært gennem low-fidelity-skitser.
- En bygherre, der er villig til at spille "planlægningspoker" med den tekniske konsulent for at skabe en budgetramme for projektet.
- Et whiteboard-værktøj til samarbejde. Hos Kvalifik bruger vi Miro, men der findes mange lignende værktøjer. Processen omfatter seks faser, som hver især letter den rigtige læringsrejse, i vores case, for både Kvalifik og vores partner.
A whiteboard workshop aimed at mapping the platform’s user types and as many User Stories as possible. Both Kvalifik and the partner participate. A User Story is an excellent educational tool to ensure everyone understands each other and incorporates the software's users into the functionalities from day one. A User Story is defined by filling in the blanks in the sentence: "As a {USER TYPE}, I want to {ACTION}, so that {DESIRED OUTCOME}".
Deltagere: Alle.
Outcome: Grundlaget for at forstå platformens faktiske funktioner gennem den første iteration af User Stories.
Desk-research, hvor account manager, teknisk konsulent og designkonsulent gennemgår alle User Stories, eventuelt tilføjer nye, og laver low-fidelity-skitser af de User Stories, der blev identificeret i den første workshop.
Deltagere: Account manager, teknisk konsulent, designkonsulent.
Outcome: Low-fidelity-skitser og anden iteration af User Stories.
Whiteboard-workshop, hvor vi gennemgår de skitser og User Stories, der blev afdækket i fase 2, og indsamler feedback. Sammen med kunden gennemgår vi platformen fra start til slut, finder på nye User Stories og ideer til flows og omprioriterer alle platformens funktioner baseret på vores hypoteser. Næsten hver gang bliver noget grundlæggende ved platformen gentænkt i denne fase, hvilket forenkler og reducerer de ressourcer, der er nødvendige for at bygge den.
Deltagere: Alle.
Outcome: Feedback på skitser og User Stories og revurdering af platformens hypoteser.
Desk-research, der gentager alle aktiviteter fra fase 2. Derudover sætter den tekniske konsulent sig ned med en udvikler for at spille "planlægningspoker" baseret på alle kendte User Stories. Målet er at dissekere platformsudviklingen i epics og give et samlet estimat for hvert epic. Et epic er en samling af opgaver, der udgør en funktion, som løser en eller flere User Stories. På dette tidspunkt begynder platformens overordnede datamodel at tage form, og den tekniske konsulent udvikler et ER-diagram for at visualisere den tekniske kompleksitet, som ellers kan være svær at diskutere.
Deltagere: Account manager, teknisk konsulent, designkonsulent og udvikler.
Outcome: Sidste iteration af User Stories og low-fidelity-skitser af platformen, et ER-diagram og epics med overordnede estimater, der giver mulighed for en præcis projektbudgetramme.
Et afsluttende møde, hvor vi gennemgår de arkitektoniske planer, vi har udviklet undervejs. Det omfatter de epics, vi har udviklet, og den deraf følgende budgetramme.
Deltagere: Alle.
Outcome: Arkitekturplaner for platformsprojektet, bestående af de ovennævnte User Stories, low-fidelity skitser, ER-diagram og epics med overordnede estimater. Tilsammen sikrer disse arkitekturplaner, at den efterfølgende udvikling af platformen vil levere værdi ved at opfylde projektets hovedmål.
Et retrospektivt møde, hvor vi internt i Kvalifik gennemgår processen og overvejer, hvad vi kan gøre bedre næste gang.
Deltagere: Alle undtagen klienten
Outcome: Løbende forbedring af vores SOP.
Processen tager maksimalt en måned og giver et overblik over de største usikkerheder, der er forbundet med udvikling af en digital platform, ved at kortlægge de grundlæggende hypoteser om projektet. Når de seks trin er gennemført, har du de rigtige arkitektoniske planer og den nødvendige viden til at udvikle en større digital platform uden at spilde ressourcer.
God fornøjelse med IT-de-risking!
