Hvorfor flopper så mange statslige IT-projekter?

SIGMA, POLSAG, den digitale tinglysning og AMANDA er bare fire eksempler på statslige IT-projekter, som er løbet løbsk og er endt i fiasko.

Nu kan vi føje endnu et til rækken – nemlig Arbejdsskadesstyrelsens store it-satsning PROASK.

Projektet har været i gang siden 2008. Det har flere gange overskredet det planlagte budget og har indtil videre kostet styrelsen 164 millioner kroner og adskillige fyringsrunder. Og manglende orientering af Folketingets finansudvalg har nu bragt beskæftigelsesminister Mette Frederiksen (S) i fedtefadet.

Men hvorfor går det altid galt med de statslige IT-projekter? To IT-professorer Søren Lausen fra IT Universitetet og Jan Pries-Heje fra Roskilde Universitet siger, at det ofte handler om et eller flere af de følgende fire problemer:

1. Kriterierne for, hvad gevinsten skal være, er ikke klart nok defineret i kravsspecifikationen, som er den juridiske bindende beskrivelse, hvor det er fastlagt, hvad leverandøren skal levere for at få sine penge.
   
2. Kravsspecifikationen beskriver, hvordan systemet skal bygges, men ikke hvilke behov systemet skal opfylde.
   
3. Brugerne bliver ikke inddraget eller hørt.
   
4. IT-projekterne tager så lang tid at udvikle, at brugerne har fået andre behov undervejs.

Uklarhed om succeskriterierne for systemet

Professor på IT Universitetet Søren Lausen har som konsulent for Rigsrevisionen været med til at evaluere både POLSAG (se faktaboks), den digitale tinglysning og Rejsekortet.

»På et vist overordnet niveau er det de samme ting, der går galt. Og problemerne opstår allerede, når kunden skal definere sine krav til systemet. Man gør sig ikke klart, hvad man skal have ud af systemet. Hvad gevinsten skal være,« fortæller han.

Konsekvensen er enten, at kunden bare ønsker sig det samme, men lidt mere moderne. Eller at kundens krav til systemet bliver fuldstændigt urealistiske.

Beskriv behov i stedet for system

En anden udfordring er, at kunden i sin kravspecifikation kommer til at beskrive, hvordan de mener, systemet skal opbygges i stedet for at forklare, hvad det er for nogle behov, systemet skal opfylde.

»Lad os sammenligne det med, at jeg skulle have bygget et udhus. Jeg ved, at mit udhus skal have plads til så og så meget. Det skal være nemt at komme ind i, og det skal være nemt at få ting ud og ind. I stedet for at skrive det til håndværkerne, går jeg i gang med at beskrive, hvor lange brædderne i byggeriet skal være, og hvad for nogle skruer, der skal bruges. Ting jeg i virkeligheden ikke har forstand på,« forklarer professor i Informatik og Datalogi Jan Pries-Heje fra Roskilde Universitet.

Han har i sin forskning fokus på organisatoriske og ledelsesmæssige aspekter af IT-udvikling.

Manglende brugerinddragelse er typisk bommert

Ifølge Jan Pries-Heje er en typisk bommert ved større IT-projekter, at man glemmer at inddrage brugerne.

»Man ved fra mange års forskning og praksis, at det at inddrage medarbejdere i udviklingsprocessen gør en stor forskel. Store IT-projekter er ofte ramt af manglende systematisk brugerinddragelse,« siger han.

Brugerinddragelse kræver også, at kunden har gjort sig klart, hvem der er brugeren, og hvad systemet skal kunne gøre for brugeren. Og det kræver, at man inddrager brugeren på en klog måde, da eksempelvis en sagsbehandler ofte vil foretrække det eksisterende system og kan have svært ved at forestille sig, hvad et fremtidig system ville kunne tilbyde.

Byg systemet i mindre bidder

En anden udfordring er, ifølge de to professorer, at statslige institutioner ofte vil have store skræddersyede systemer, som bygges over flere år.

Den lange tidshorisont øger risikoen for, at systemet er forældet, når det endeligt er færdigt.

I Arbejdsskadestyrelsen kommer der for eksempel hele tiden ændringer til systemet. Det er meget svært at fryse eller fastholde en løsning på et behov i ret lang tid, før der kommer ændringer, som betyder, at det alligevel skal laves om.

Problemet er, at kravspecifikationerne beskriver en bestemt løsning på et bestemt problem fremfor at beskrive et behov, som skal opfyldes ved hjælp af det nye system.

Den juridisk bindende beskrivelse handler altså i højere grad om, hvor sømmene skal sidde i brædderne, fremfor at beskrive hvor meget plads kunden har brug for at have i udhuset.

Ny fremgangsmåde kan være løsningen

Løsningen kan være at vælge en såkaldt agil fremgangsmåde til at udvikle IT.

»Det betyder, at man arbejder i små korte iterationer (se faktaboks), for eksempel 2-4 uger, hvor man efter hver iteration leverer noget færdigt. Det betyder også, at man tillader ændringer og er klar til konstant forandring af behov og krav,« fortæller Jan Pries-Heje.

Køber ekspertise fremfor en løsning hugget i sten

Han har fulgt udviklingen af et system hos Arbejdsskadestyrelsens nabo nemlig Arbejdsmarkedsstyrelsen. Her bruger man en agil fremgangsmåde.

Projektet er organiseret sådan, at Arbejdsmarkedsstyrelsen har købt et fast antal personers ekspertise frem for et fast antal krav i en kontrakt.

Mellem IT-udviklerne står der tre skriveborde, som bliver besat af ansatte hos Arbejdsmarkedsstyrelsens medarbejdere, så IT-udviklerne løbende kan få feedback fra medarbejderne. Det er en sådan agil fremgangsmåde, som i højere grad vil kunne sikre, at budgetter og systemer ikke ender i en stor fiasko. Ofte slår man alt for stort brød op for hurtigt, forklarer Jan Pries Heje.

»Det virker som om, man altid vil bygge de her meget store systemer. I stedet skulle man sige, hvad er minimum, vi kan klare os med og så bygge det og efterfølgende bygge ovenpå. Og selvfølgelig hele tiden tjekke, at kerneydelsen, for eksempel korte svartider i systemet, er i orden,« siger Jan Pries-Heje.

Det har ikke været muligt at få en kommentar fra Arbejdsskadesstyrelsen eller Digitaliseringsstyrelsen.