Opsamling fra Statens Indkøbskonference: Hvad lærte vi om agile it-kontrakter?

Henrik Udsen satte fokus på agile it-kontrakter. I denne korte historie kan du både lære mere om mulighederne og faldgruberne ved denne samarbejdsform og læse hvad vi tog med fra oplægget i forhold til, hvordan vi opnår succesfulde it-udviklingsprojekter.

Til Statens Indkøbskonference 2024 havde vi inviteret professor Henrik Udsen til at sætte sejl på en agil it-rejse og belyse de muligheder og udfordringer, der er forbundet med agile it-kontrakter. Vi tog med fra oplægget, at udfordringerne ofte opstår, fordi der ikke altid er enighed om, hvad det vil sige at indgå en såkaldt agil it-kontrakt. Begrebet agile it-kontrakter er altså ikke blot en fortegnet illusion, men det kan også i sig selv ligefrem give anledning til både misforståelser og kuldsejlede agile it-udviklingsprojekter.

Der er en tendens til, at såkaldte agile it-kontrakter giver anledning til uenighed om ydelsens indhold og hvem af kontraktens parter, der har ansvaret for ydelsens præstation. Tidligere blev ydelsen i it-kontrakter kravspecificeret på et meget detaljeret niveau, hvilket gjorde det nemt at give leverandøren en resultatforpligtelse for det, leverandøren skulle udvikle under kontrakten. I traditionelle it-kontrakter, baseret på en vandfaldsmodel, gennemføres udvikling af software i en række på hinanden følgende og fra hinanden isolerede faser, typisk kravspecifikation, design, kodning, integration, afprøvning/fejlfinding, installation og vedligeholdelse. Det ligger således fra starten fast, hvilke leverancer leverandøren skal præstere. Fremgangsmåden giver dog ikke meget fleksibilitet, og for mange synes løsningen derfor at være at overgå til en agil udviklingsmetode. Offentlige ordregivere er samtidig blevet mere modne i forhold til at deltage i et integreret samarbejde med en it-leverandør, hvorfor agile it-projekter er blevet mulige.

Den agile udviklingsmetode passer dog ikke altid inden for de klassiske rammer for en offentlig kontrakt, hvor ordregiver så vidt som muligt forsøger at lægge risikoen for kontraktens opfyldelse i rette tid, rette kvalitet og til rette pris på leverandøren. Alt i alt kræver agile it-udviklingsprojekter en anden form for kontraktuel regulering end de traditionelle it-kontrakter, som er baseret på en vandfaldsmodel.

Henrik Udsen stillede det tankevækkende spørgsmål: "Er det rimeligt, at leverandøren får resultatforpligtelse, når leverancen detailspecificeres i de enkelte iterationer?" Ved indgåelsen af en agil it-kontrakt kender leverandøren typisk ikke omfanget af sin forpligtelse, da kravene til ydelsen først bliver stillet og tilpasset som led i samarbejdet. Spørgsmålet understreger behovet for en mere balanceret fordeling af risikoen for opfyldelse af kontrakten fra projektets start.

En opskrift på at opnå succes med agile it-udviklingsprojekter kunne derfor være, at offentlige ordregivere i højere grad må kigge på risikofordelingen i kontrakten og fokusere på, om agiliteten angår samarbejdsformen, projektarbejdet eller udviklingsmetoden. De kontraktuelle rammer skal så vidt som muligt understøtte denne agilitet og ikke være en forhindring. Ordregivere bør se på, hvordan de har specificeret det, der skal præsteres, samt på deres og leverandørens roller i udviklingsprojektet. Det kan godt være, at offentlige ordregivere bør vænne sig til selv at tage risikoen – eller i hvert fald en større del af risikoen – for at nå i mål til tiden med den rette it-løsning.

I Rådgivningsenheden vil vi derfor være mere opmærksomme på, om vi er med til at understøtte nogle kontraktuelle rammer, der afspejler de dynamikker og risici, der er forbundet med agile projekter. Når vi fremover skal understøtte gode it-udbud i vores rådgivning, er vi på baggrund af Henrik Udsens oplæg, blevet endnu skarpere på, hvordan vi sammen med kunderne skal fokusere på at tydeliggøre roller og ansvar samt sikre en mere balanceret risikofordeling. På den måde kan vi være med til at understøtte, at vi når i mål med succesfulde leverancer og samarbejder i fremtidige it-projekter.