Viden og indsigter

Projekter: Traditionel eller agil tilgang?

Traditionel projektledelse

Når vi taler om traditionel projektledelse tænker vi på plandrevet projektledelse. Det er tit vandfaldsmodellen, der bliver brugt som eksempel på den traditionelle, plandrevne måde at håndtere projekter og større opgaver. Vandfaldsmodellen er en sekventiel fasedrevet model, hvor den næste fase ikke påbegyndes, før den foregående er afsluttet. Det er meget karakteristisk for den traditionelle tilgang, at alle krav fastlægges i detaljer før projektet startes og på den måde styres projektet af kravspecifikationen. Projektets fokus er på opfyldelse af kravspecifikationen. Ændringshåndtering er omfattende og tung, da ønsker om ændringer fra brugerne ofte afdækkes sent i forløbet.

Vandfaldsmodel

Agil projektledelse

I den agile tilgang arbejder man med flere korte gennemløb i projektets faser. Kunden inddrages aktivt allerede i starten af projektet, og prioriteringer samt overordnede mål er kendt for alle, der arbejder i projektet. Projektet leverer løbende små bidder af funktionalitet, så kunden hurtigt får udbytte af produktet. Detaljekrav fastlægges undervejs i samarbejde med kunden, efterhånden som det færdige produkt tager form, så der altid er fokus på brugernes behov. Man kan sige, at fremgangsmåden er forandringsdrevet.
Agil model

Med den agile tilgang ønsker man at gøre op med statisk plandrevne projekter, som ofte ender med at have overskredet budgetter, taget længere tid end estimeret og til slut have tilført mindre værdi til forretningen end forventet.

En af de største bekymringer for mange ledere ved at transformere en organisation fra plandreven til agil projektledelse er usikkerheden i forbindelse med at kunne bevare overblik over scope og omkostninger. Mange frygter, at agile projekter kan køre i en uendelighed. Det er en forkert antagelse.

Projektgrundlaget

Den traditionelle kontrakt for et projekt tager udgangspunkt i estimater baseret på scope, tid til rådighed og omkostninger (samt tilgængelig viden). Det er elementer som kan være svære at forholde sig til på forkant, men som er styrende for hele projektet.

En kontrakt, som skal understøtte et agilt projekt, fastlægger omkostninger og tid til rådighed fra start, mens scope styres i fællesskab af kunde og leverandør undervejs i projektet. Kravspecifikationen er erstattet af en estimeret backlog som danner rammen for, hvad der kan medtages i scope.

Den mest markante forskel, når man kigger på den overordnede rammesætning for projektet er således, at scope er fleksibelt i den agile tilgang. Det endelige produkt er direkte afhængigt af kundens input undervejs og kan således ende med at se helt anderledes ud, end man havde forestillet sig ved projektets start.
Traditionel versus agil tilgang

Hvordan viser forskellene sig i praksis?

Et konkret eksempel på de to forskellige tilgange kan tage udgangspunkt i et scenarie om udvikling af en it applikation (app). De to tilgange vil gribe opgaven forskelligt an:

Den traditionelle metode vil starte med at skabe projektdokumentation i form af projektgrundlag, en specifik kravspecifikation, lægge en detaljeret projektplan, nedsætte projektgruppe og styregruppe, få godkendt de mange dokumenter og beslutninger og endelig starte udviklingen. Den samlede proces kan tage lang tid.

Den agile tilgang vil fokusere på at finde en sponsor i virksomheden og, i samarbejde med kunden til appen (eller slutbrugerne), definere den overordnede vision for appen, i form af beskrivelse af, hvilke behov hos brugerne den skal løse. Udviklingen kan gå i gang hurtigt.

Der spares meget tid i opstartsfasen i den agile metode, som til gengæld kræver, at både sponsor og kunde:

  1. har den nødvendige beslutningskompetence
  2. er villige til (især for kundens vedkommende) at kaste tid og energi i løbende at deltage i udviklingsarbejdet for at sikre produktets relevans.

Hvis kunden (eller slutbrugerne) har ændringer til produktet undervejs i projektet vil den traditionelle metode kræve, at projektlederen håndterer en ændringsproces, der typisk består af mange trin i forhold til re-estimering, konsekvensberegning og omkostningsberegning – og efterfølgende justering af kravsspecifikation, testscenarier og projektplaner. Alle ændringerne skal endvidere godkendes af styregruppen for projektet samt projektejeren.

I den agile verden er løbende ændringer en del af ’gamet’ – og de er yderst velkomne. Kunden (eller slutbrugerne) er med til løbende at teste og evaluere alle delleverancer og kan justere retningen på udviklingen undervejs. Den overordnede vision for produktet, som blev beskrevet ved projektets start fortæller noget om de behov, som produktet skal dække og selve formen og funktionaliteten af produktet fastlægges undervejs. I virkeligheden kan man tale om, at der typisk ikke opstår krav om ændringer undervejs i et agilt projekt, men at der løbende sker tilpasninger.