Husk at gøre din organisation parat til agile projekter
Med Digitaliseringsstyrelsens introduktion af standardkontrakt K03 (Standardkontrakt for længerevarende it-projekt baseret på en agil metode) vil mange offentlige organisationer uden tvivl snart kaste sig over agile it-projekter.
Vejen til et succesfuldt agilt projekt er dog ikke snorlige. Én blandt mange praktiske udfordringer for kunderne vil være, at få organisationens projektledelses- og styringsmodeller til at passe med K03.
De eksisterende vandfaldskontrakter K01 og K02 er baseret på en traditionel styringsmodel, der passer godt til offentlige organisationer. Kontrakterne kan uden videre benyttes sammen med den fællesstatslige it-projektmodel og de projektroller, der er knyttet hertil.
K03 indeholder ligeledes elementer fra en traditionel styringsmodel, bl.a. med projektledere fra kunden og leverandøren som centrale aktører i projektforløbet. Men det praktiske link til det konkrete projekt er ikke adresseret. I kommissoriet for K03 er det anført, at kontrakten skal "(…) tage afsæt i principperne bag anerkendte og anvendte projektledelses- og udviklingsmetoder f.eks. Prince2, Atern og Scrum".
En række centrale elementer i kontrakten, herunder modellen for fastlåsning af tid og pris og opdeling i forskellige kravtyper ("Absolutte krav" og "Øvrige krav") viser dog tydeligt, at særligt DSDM Atern danner det metodemæssige inspirationsgrundlag for det agile forløb under kontrakten.
DSDM Atern er en metode til brug for styring af agile projekter. I modsætning til Scrum udgør DSDM Atern et veldefineret rammeværk, der konkret understøtter styringsniveauet i projekterne ved at adressere de organisatoriske rammer. Metoden har klare snitflader til PRINCE2 og er derfor på papiret mere egnet som projektmæssigt udgangspunkt for et offentligt it-projekt end f.eks. Scrum, der primært har karakter af en udviklingsmetode.
Mit indtryk er, at offentlige agile it-projekter og it-projekter med agile elementer næsten uden undtagelse er baseret på (varianter af) Scrum. Dette skyldes nok særligt, at Scrum udgør en enkel og overskuelig model med ganske få roller, som både kunde og leverandør let kan forholde sig til. Scrum har dog den åbenbare svaghed, at den ikke forklarer, hvordan metoden rent organisatorisk og styringsmæssigt skal fungere i et klassisk kunde- og leverandørforhold.
Anvendelse af agile metoder vil, uanset den konkrete model (eller kombination heraf), indebære klare udfordringer, når projektet gennemføres i offentlig regi, hvor en række foruddefinerede roller og beslutningsmæssige traditioner skal understøttes. I forbindelse med konkurrenceudsættelsen af de offentlige agile projekter jeg har deltaget i, har leverandørens konkrete agile metode været en del af konkurrencegrundlaget. Det vil sige, at der i vurderingen af leverandørens tilbud er indgået, i hvilket omfang, leverandøren har formået at præsentere en agil metode, der understøtter det konkrete projekt og den overordnede styringsmodel, som kunden har specificeret.
En række leverandører med erfaring i agile projektforløb har efter min vurdering formået at præsentere ganske anvendelige modeller, der sammenkobler kundens behov for styringsstruktur med brug af en agil metode. Men hos andre leverandører er sammenkoblingen ikke rigtig sket, hvilket i praksis kan give et uheldigt projektforløb. Dette skal ses i sammenhæng med, at en lang rækker kunder langt fra er bevidste om, hvad det konkret indebærer for organisationen og projektstyringen, når man beslutter sig for at gennemføre et it-projekt baseret på agile principper.
Hvis offentlige projekter skal undgå at ende i et styringsmæssigt limbo, hvor de traditionelle styringsredskaber afledt af den fællesstatslige it-projektmodel, ikke matcher den valgte agile projektmetode, er der efter min vurdering behov for et øget fokus på, hvordan man som offentlig myndighed konkret gennemfører agile projekter. Digitaliseringsstyrelsen bør i den forbindelse overveje om den fællesstatslige it-projektmodel i tilstrækkelig grad understøtter gennemførelse af agile projekter.
Udgangspunktet for K03 er, at der er metodefrihed i de enkelte projekter. Den agile metode skal (med respekt for kontraktens bestemmelser) fastlægges på baggrund af den løsning og det overordnede leveranceforløb, som kunden efterspørger. Valg af metode kan principielt både træffes af kunden og leverandøren. Hvis valg af model overlades til leverandøren, bør kunderne i forbindelse med planlægningen af projektet dog gøre sig klart, hvilke roller der er behov for at besætte og sikre sig, at de konkrete bemyndigelser til projektets deltagere kan understøtte udviklingsforløbet. Kunden skal afspejle dette i udbudsmaterialet, så det interne styringsbehov bliver understøttet.
Hvis ikke kunden har forberedt sig tilstrækkeligt, får man i bedste fald ikke fuldt udbytte af de muligheder, der er i et agilt forløb. I værste fald mister man koblingen mellem projekt og kundens organisation.
Anders er manager hos Rambøll Management og rådgiver om juridiske aspekter ved digitaliseringsprojekter og it-udbud i den offentlige sektor. Han blogger om emner mellem teknologi og jura med fokus på offentlige myndigheders gennemførelse af digitaliseringsprojekter.
Kommentarer (2)
Tak for en interessant artikel.
Hvis offentlige projekter skal undgå at ende i et styringsmæssigt limbo, hvor de traditionelle styringsredskaber afledt af den fællesstatslige it-projektmodel, ikke matcher den valgte agile projektmetode, er der efter min vurdering behov for et øget fokus på, hvordan man som offentlig myndighed konkret gennemfører agile projekter.
I forvejen er en del offentlige IT-projekter præget af svag ledelse. En ærlig og dygtig leverandør kan til nød afhjælpe dette problem. Desværre vælges der alt for ofte leverandører, der hverken er ærlige eller dygtige - med eklatante fiaskoer til følge.
Når der skal bygges en motorvej, har Vejdirektoratet nogle dygtige folk, der er vant til at styre den slags projekter. De fleste motorveje åbner før planlagt, og uden budgetoverskridelser.
Når der skal laves et IT-system, er det den enkelte myndighed, der tager sig af styringen - men de har ingen erfaring eller uddannelse i at styre IT-projekter. Jeg tvivler på, at dette vil ændre sig væsentligt. De enkelte myndigheder har slet ikke nok IT-projekter til at opnå erfaring.
Måske skulle man overveje at lave "IT-direktoratet" til at projektere og styre offentlige IT-projekter.
Kære Anders
Vi er helt enige i vigtigheden af, at den fællesstatslige it-projektmodel også skal understøtte et agilt udviklingsprojekt.
Vi vil derfor sørge for, at den agile standardkontrakt vil kunne anvendes i den fællesoffentlige it-projektmodel, hvor den vil være et væsentligt dokument i anskaffelses- og gennemførelsesfasen for de it-projekter, som ønskes afviklet agilt.
I vejledningen til kontrakten og it-projektmodellens tjeklister vil vi også fremhæve særlige opmærksomhedspunkter i forbindelse med agil udvikling.
Mvh
Morten Ellegaard, Digitaliseringsstyrelsen

