Styrelse: Agil er ikke altid løsningen

Agile metoder i store it-projekter er ikke en mirakelkur, lyder det fra Sundhedsstyrelsen efter dårlige erfaringer i Dahlia-projektet. Kunden skal først og fremmest være moden, og forholdet til leverandøren være godt.

I stedet for de tommetykke kravspecifikationer og minimal dialog mellem kunde og leverandør, skal it-projekterne i den offentlige sektor gøres mere fleksible med agile metoder.

Sådan lyder et mantra, som skyller igennem den danske it-verden lige nu - men agile metoder er ikke lykken hver gang, lød det fra Sundhedsstyrelsen, oven på erfaringerne med it-projektet Dahlia til 204 millioner kroner, som dog holdt både budget og tidsplan.

»Vi har primært dårlige erfaringer med agil udvikling, så det her oplæg er måske noget andet, end I forventer,« indledte Mikael Bay Skilbreid, udviklingschef hos Sundhedsstyrelsen, da han skulle fortælle om nogle af delprojekterne i Dahlia-programmet under overskriften ’Agile metoder med fast grund’ på konferencen Digitaliser Danmark.

Dahlia er et ESDH-system til Lægemiddelstyrelsen - som nu er lagt sammen med Sundhedsstyrelsen - og projektet rummede meget arbejde med at gennemtænke digitaliseringen af arbejdsgangene, før det kunne omsættes i en it-løsning. Det bestod af mange underprojekter, hvor Mikael Bay Skilbreid fortalte om tre af dem, hvor man havde arbejdet med en agil tilgang.

Styrelsen gik i konkurrencepræget dialog med tre leverandører, hvor man så i fællesskab kunne arbejde sig frem til den bedste løsning, og først efter det meste af et år med dialog kom opgaven i udbud. Det blev vundet af IBM, efter én leverandør trak sig, og en anden havde fejl i udbuddet.

Spøjs dialog fik tilliden til at forsvinde

Lægemiddelstyrelsen var altså igennem en mere løs, diskuterende indledende fase, hvorefter standardkontrakten K02 blev taget i brug for at sende opgaven i udbud med ret faste rammer.

Forsøget på at løsne op på de normalt meget faste udbud var altså ikke en stor succes, ifølge udviklingschefen, som dog også placerede en hel del af skylden hos styrelsen selv.

»Rigtig meget ligger hos os selv, hos kunden. Hvis vi ikke selv kan formulere, hvad vi vil have, hvordan kan vi så forvente, at andre kan lave det?« sagde han.

Læs også: Mirakel-moppedreng? Agil K03-kontrakt skal redde offentlige it-projekter

Det havde ført til en spøjs dialog på et af delprojekterne, hvor leverandøren bare ville vide, hvad kunden ville have, mens Lægemiddelstyrelsen spurgte tilbage, hvad der var muligt.

»’Så vil vi gerne have det her’, sagde vi så, men så var svaret, at ’det kan løsningen ikke’. Vi var meget langt fra hinanden, og vi havde mistet tilliden til hinanden på det tidspunkt. Der gik noget tid, før vi igen var på rette spor,« sagde Mikael Bay Skilbreid.

Slut med de kreative løsninger

Et af problemerne var, at styrelsen ikke selv havde erfaring med den slags samarbejde.

»Vi havde ingen ide om, hvordan delprojektet omkring processer skulle forløbe. Vi havde heller ikke de rigtige personer på plads på det delprojekt,« sagde udviklingschefen.

Lægemiddelstyrelsen, der i sagens natur er domineret af lægefaglighed, er også et svært miljø at få taget hurtige beslutninger i.

»Det var dælme vanskeligt at sætte det rigtige team. Hos os er der et stort faghierarki, og når der skal tages en beslutning om et passende kvalitetsniveau, skal det igennem mange mennesker. Når man er vant til at se verden gennem et mikroskop, er man også god til at finde fejl,« sagde Mikael Bay Skilbreid.

Omvendt fornemmede han heller ikke nogen særlig vilje hos IBM til at fortsætte den agil-inspirerede dialog, efter kontrakten var blevet skrevet under, og en fast pris var aftalt.

»Vi oplevede også på et andet delprojekt, at det hurtigt var slut med de kreative løsninger, og at leverandøren på det delprojekt mest var interesseret i at få det til at passe til prisen,« lød hans vurdering.

Det eneste del-system, der var gået glat, var en løsning til at opkræve gebyrer. Her var opgaven mere konkret, og Lægemiddelstyrelsen kunne også levere hurtige beslutninger, når det var påkrævet.

»Det var veldefineret og struktureret, og der var systemafhængighed til et stort Navision-system i staten. Meget er finansieret af gebyrer hos os, så der var ikke råd til, at det ikke virkede, og derfor var der beslutningsstyrke,« sagde udviklingschefen.

Så hans råd til tilhørerne, der næsten alle var fra den offentlige sektor, var at sikre det rette politiske mandat i organisationen, før man gik i gang med et agilt projekt.

Vil gerne slippe for agile metoder

Valget af leverandør er måske den mest afgørende beslutning, når der skal være et så tæt samarbejde, og her kunne han kun anbefale, at man brugte et firma, man i forvejen har tillid til.

»Leverandøren skal synes, at det er sjovt, og skal have viljen til det. Den eneste måde, jeg har fundet ud af, om leverandøren har den vilje, er ved at prøve et lille projekt først. Den tillid, der skal være, er enormt svær at opbygge, og det tager tid,« sagde han.

Samlet set er der ingen skam i at holde fast i de vante metoder, hvis situationen egner sig bedst til det, lød rådet.

»Vandfaldsmodellen er rar, hvis vi ved, hvad vi vil have, så lad os holde fast i den i de tilfælde. Men når vi ikke ved det, er vandfaldsmodellen ikke så god, og så er det godt, at der er noget andet på vej,« sagde Mikael Bay Skilbreid med henvisning til den nye, agilvenlige K03-standardkontrakt, der er på vej til den offentlige sektor.

Selv var han stadig mest lun på den klassiske model, hvor leverandøren får en opgave og så afleverer den færdige løsning, når den er blevet klar.

»Jeg har ikke set endnu, at en agil metode alene kan gøre det for projekterne. Når det er udviklingsprojekter, og når der kommer en ny type kontrakt til agile projekter, kan det være en fordel. Men kan vi slippe - så lad os da bare bruge en almindelig kontrakt,« sluttede udviklingschefen.

Se oplægget på video

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Christensen

... men her er der da nogle kæmpestore røde flag: En styrelse, der ikke har prøvet agile metoder før. Et projekt til 204 millioner (200 mandeår). En hvis trebogstavsleverandør. Kun tre tilbud, hvor to ikke er konditionsmæssige tyder på, at udbudsmaterialet har været unødigt komplekst.

Det virker ikke som om styrelsen har fået ordentlig rådgivning her. De skulle have startet med et meget mindre setup. Ét team med supportfunktioner, altså i alt ca. 10 mand fra leverandøren (så var der også budget til 20 år), hvilket efter min erfaring kræver mindst 5 (næsten) fuldtidsdedikerede mand fra kundesiden. Og så masser af fokus på processen. Gerne med en ekstern coach. Og så er det helt centralt i agile projekter, at kunden kan og vil stoppe samarbejdet, hvis det ikke fungerer.

Historien om udskiftning af nøglemedarbejdere lyder heller ikke godt. Jeg har erfaringer med at indføre bod ved udskiftning af medarbejdere kombineret med begrænset honorar for nye medarbejdere i den første tid. Det understreger, at udskiftning af medarbejdere er en alvorlig og omkostningstung sag, der skal håndteres professionelt af leverandøren og kunden i samarbejde.

Det er trist, at digitaliseringskonferencen hiver dette eksempel frem, når der findes vellykkede agile projekter i det offentlige.

  • 4
  • 0
Kurt Frederichsen

Det er nu lidt sjovt at se - forudsætningerne for et godt projekt var ikke tilstede - uanset hvilken model der så havde været brugt. Men det er pludselig modellen, der er forkert!? ;-)
Om vi vælger det ene eller andet, så er forkert brug og utilstrækkelige forudsætninger altid forhindrene!
Når Agile metoder understreger at samarbejde kræver et vist niveau af tillid mellem parterne, har det ikke noget med agil at gøre - det er helt generelt en forudsætning for komplekst samarbejde!

Eller har jeg totalt misforstået noget??

I stedet for at slå ud efter metode ét eller to - så lad os høre hvordan forudsætningerne for gode projekter kan skabes i det offentlige?
Hvorfor går det nogen gange godt - i forhold til sammenlignelige projekter der ikke gik godt?
Kan det f.eks. udfordre når stærke interessenter har andre dagsordener før, under og efter projektet, end de, der står i kontrakten!?

Modenhed omkring forståelse og udførende kompetencer på kompleks produktudvikling må være en forudsætning - ellers forstår man slet ikke hvad man gør! Men det er vel ikke nok ... ??

  • 3
  • 0
Svante Jørgensen

Der bliver besluttet at bruge en agil metode til udvikling.
Sundhedsstyrelsen sætter ikke de rigtige folk på projektet og har ingen erfaring.
IBM er ikke interesserede i at køre projektet agilt efter kontrakten er underskrevet.
Ingen af parterne kan finde ud af at kommunikere i den agile process.

Og konklusionen er at den agile metode har et problem???

  • 2
  • 0
Svante Jørgensen
  1. Gør det klart hvor stor erfaring du som kunde har med agile projektmetoder. Jo mindre erfaring, desto vigtigere er det at finde konsulenter hos leverandøren eller ansætte projektledere med forstand på dette.

  2. Vær sikker på at leverandøren har erfaring med agil udvikling! Det kan ikke understreges nok. De store IT leverandører (skal nok lade være med at nævne nogen navne) har typisk meget få folk der er dygtige til agil udvikling. Lad dem evt. bevise at netop det hold de stiller med kan udvikle agilt ved at lave et mini testprojekt som en del af udbudsprocessen. Og find en uvildig ekspert der kan vurdere deres præstation.

  3. Bestem hvor hurtigt i som kunde kan træffe beslutninger og revidere krav når forudsætninger for projektet ændre sig. Jo hurtigere desto bedre, fordi jo længere tid det tager desto mere bliver i nød til at være forud med analyse og kravspecifikation. Hvis forudsætningerne ændre sig og det tager en måned at fastsætte de nye krav samt at man ikke har andre krav klar til at blive implementeret, så har i et udviklingsteam der triller tommelfingre og brænder penge af i en måned!

  • Der er mange flere, men disse problemer er dem jeg har set oftest.
  • 0
  • 0
Log ind eller Opret konto for at kommentere