Staten arbejder også agilt – men ingen beviser for at det er bedre end ’vandfald’

I England har statens it-projekter igennem de seneste par år været igennem en massiv omstilling, så enorme projekter og tommetykke kravspecifikationer til en leverandør blev afløst af små og mere fleksible projekter, hvor statens selv har styringen og it-kompetencerne, og så køber resten ind i mindre bidder.

Sådan en omvæltning er ikke på programmet i Danmark, men statens it-projekter har faktisk i halvandet år kunne køre på en kontrakt, som tillader agil udvikling undervejs, i stedet for den klassiske vandfaldsmodel, hvor alt er skrevet ned på forhånd, når udviklingen går i gang.

»I nogle tilfælde giver det rigtig god mening at arbejde agilt, så efter arbejdet med standardkontrakt K02 valgte vi at prioritere en standardkontrakt til agile projekter, for det var den lavest hængende frugt, som myndighederne havde mest brug for,« fortæller Morten Ellegaard, kontorchef i Ministeriernes Projektkontor i Digitaliseringsstyrelsen.

Kontrakt K03, som den blev døbt, var klar til brug i december 2012, efter en tæt dialog med branchen, og den er siden blevet brugt, også i nogle store projekter. Hvor mange i staten, som har valgt et agilt projekt, er der ikke tal på, for det bliver ikke målt.

»Der er ikke indberetningspligt, så vi har ikke en oversigt, men jeg kender til en del myndigheder, som arbejder agilt eller semi-agilt,« fortæller Morten Ellegaard til Version2.

Skal stadig have fast pris og tidsplan

Statens agile projekter kan dog ikke give los og være helt fleksibelt på alle parametre. Der er et krav om en fast pris og en fast tidsplan, når man indgår en kontrakt med en leverandør, fordi pengene til et større it-projekt skal bevilges på forhånd i det politiske system.

»Tid og pris betyder meget i staten, så her lægger K03-kontrakten ikke op til fuld agilitet. Men vi er relativt agile på ydelsen, så det er her, man kan finde frem til løsninger i samarbejde med leverandøren,« siger Morten Ellegaard.

Der er også indsat et krav om en minimumsleverance, som leverandøren skal kunne levere for den aftalte sum. I kontrakten skal man således have en række ’absolutte krav’, som så bliver suppleret med alt det, der er ’nice to have’, og som man så undervejs kan forsøge at nå med de resurser, der er til rådighed.

Desuden rummer kontrakten en leveranceforpligtelse inden for de forskellige delleverancer. Det er lidt konservativt, men det understøtter den måde, staten fungerer på. Vi ønsker ikke at forpligte os til at betale for en vare, man måske slet ikke får,« forklarer kontorchefen.

Det måske mest banebrydende i den agile kontrakt i staten er, at man som kunde kan afbryde samarbejdet undervejs, hvis det ikke fungerer.

»Det er ikke nødvendigvis gratis at udtræde af samarbejdet, og man skal tænke sig rigtig meget om, før man gør det. Men oplever man store problemer i de første uger, ser man ofte, at problemerne fortsætter. Så bør man ikke lade som ingenting og tro, at det løser sig, for det gør det meget sjældent,« siger Morten Ellegaard, som endnu ikke har hørt om en kontrakt, der blev droppet på den måde.

Ingen klare beviser for bedre projekter med agil kontrakt

At skifte vandfaldsmodellen ud med en agil tilgang, så det bliver muligt at ændre projektet løbende, i takt med at udviklingen skrider frem, er i nogle kredse blevet udråbt som løsningen på mange af de problemer, som it-projekter bliver ramt af.

Men faktisk er der ikke sikre tegn på, at agile projekter generelt klarer sig bedre end ikke-agile-projekter, fortæller Morten Ellegaard, blandt andet med henvisning til den kendte Oxford-professor Bent Flyvbjerg, som forsker i fejlslagne projekter.

»At arbejde agilt er ikke nøglen til at lykkes med sit it-projekt. Der er mange parametre, som afgør, om et it-projekt bliver en succes eller ej, men ser man isoleret på agile projekter i forhold til vandfalds-projekter, så er der ingen signifikante forskelle på, hvordan projekterne overholder tid og budget,« siger han.

I stedet handler det om at bruge de agile metoder i de projekter, hvor det giver mest mening. Det er typisk i de projekter, hvor man fra starten ikke med sikkerhed ved, hvordan man bedst skruer løsningen sammen. Altså når man har svært ved at skrive en færdig kravspecifikation før en udbudsrunde.

Til gengæld er der også mange situationer, hvor det agile koncept, med tæt samarbejde mellem kunde og leverandør hele vejen, kan give problemer, hvis kunden ikke er klar til den ’belastning’.

»Man skal være dygtig som kunde, før det giver mening at kaste sig ud i et større agilt projekt. Man skal for det første have en projektleder, som reelt kan træffe dag-til-dag-beslutninger. Og så skal man have en projektgruppe, der reelt kan arbejde på fuld tid med leverandøren. Det er ikke alle, der har det til rådighed, og det er heller ikke altid hensigtsmæssigt,« siger Morten Ellegaard.