Hvorfor er det offentlige så dårlig til IT-projekter?

Når man, som jeg, arbejder med offentlige IT-projekter, bliver man ofte mødt af spørgsmålet i overskriften, med det implicitte ”i forhold til det private” hægtet på. Det er et spørgsmål som er problematisk af flere grunde, men som også fortjener at blive taget alvorligt, så det vil jeg forsøge at gøre i dette indlæg.

For først lige at komme ind på det problematiske omkring spørgsmålet, så er spørgsmålet problematisk, fordi det, med eller uden det implicitte, baserer sig på nogle udokumenterede antagelser. Vi ved faktisk ikke om det offentlige er dårlig til IT-projekter, og slet ikke om det offentlige er værre end det private. Vi hører om store offentlige IT-projekter når de går galt, men sjældent om dem når de går godt, og vi hører ikke om alle de mindre projekter som bliver gennemført hver eneste dag.

I statslig sammenhæng betragtes et IT-projekt for større hvis det samlede budget overstiger 10 mio. kr. Dette er ikke kun kontraktsummen, men også interne udgifter i forbindelse med projektet, så som arbejdet med udbud, deltagelse i projekter og implementering i organisationen.

Der har siden 1. januar 2011 været pligt til at sådanne projekter skal rapportere til IT projektrådet, som følger op på status mv. IT projektrådet udgiver en rapport som angiver hvordan det går med projekterne, så offentligheden kan få et indblik i dette. Der er, så vidt jeg er orienteret, en ny rapport på vej, men indtil da, må vi nøjes med den sidste, som dækker status ved 1. halvår af 2013 (den kan hentes her).

Jf. den rapport er der 33 større IT-projekter som er startet siden starten af 2011, heraf er 7 afsluttet – 3 efter de er gennemført, og 4 er blevet stoppet før tid. Rapporten skriver følgende om de 4 som er stoppet før tid:

”Kørselsafgifter er lukket efter politisk beslutning, mens de øvrige tre er lukket efter dialog med IT-projektrådet og i en tidlig fase inden, der er afholdt større udgifter”

Af de igangværende større IT-projekter, er der for 17 af dem angivet en trafiklysmarkering (rød, gul eller grøn) af deres status i forhold til bl.a. tidsplan og pris. Her er 5 af projekterne røde, 3 er gule og 9 grønne.

Vi er alle enige om at det ville være bedst hvis disse projekter alle var grønne, men jeg tror også de fleste af os vil betragte dette som utopisk.

Der er desværre ikke tilsvarende tal fra det private, så det er ikke muligt at vurdere hvorvidt tilstanden af større IT-projekter i staten er værre eller bedre end hos det private. Anekdotisk kan jeg sige at jeg kender til adskillige private projekter til 2, 3, ja endda 4-ciffrede millionbeløb som ikke har været succesfulde, set i forhold til de erklærede målsætninger og planlagte gevinst realiseringer, så det er bestemt ikke alle som er succesfulde.

Mit postulat er derfor, at det offentlige ikke er værre til at lave store, komplekse IT-projekter end det private. Vi hører bare mere om det.

Hvad går der galt?

Selv om det offentlige formodentligt ikke er værre end det private til at lave større IT-projekter, er det stadigvæk værd at kigge på hvorfor der er så mange offentlige IT-projekter som går galt.

Som så mange andre ting, er der ikke et nemt, entydigt svar på dette, men der er dog en række faktorer som man bør kigge på:

• Projekternes størrelse
• Begrænsninger på offentlige projekter
• Typen af projekter
• Organisationernes størrelse

Hver af disse faktorer vil jeg gennemgå lidt mere i dybden med nedenfor, og det er i den forbindelse vigtigt at have for øje at disse faktorer hver især kan påvirke et projekt negativt, men at de også kan have en forstærkende effekt på de andre faktorer.

Projekternes størrelse

Der har siden Bonneruprapporten i 2001 (pdf) været adskillige rapporter omkring offentlige projekter og problemerne med disse, og de har stort set alle rådet til to ting: gør projekterne mindre, og udvikl agilt.

Jeg er, ikke overraskende, enige i disse anbefalinger, og mener de er tæt knyttet sammen. Størrelse af projektet har en indflydelse på hvor agilt det kan implementeres. Dermed ikke sagt at man ikke kan lave et stort projekt mere eller mindre agilt, men man skal være opmærksomt på begrænsningerne ved agilt, som skalerer forholdsvis dårligt (for mere om dette, se Dan Norths keynote tale “Why Agile doesn’t scale” til GOTO Aarhus 2013).

Der er ingen tvivl om at der er en række forfejlede offentlige IT-projekter som burde have været et IT-program indeholdende en gruppe af IT-projekter som implementeres hver for sig. Dette har også sine problemer, bl.a. skaber det afhængigheder mellem projekter som skal håndteres, men det giver mulighed for tidligere at se problemer, og rette op på dem.

Størrelsen på projekter har formodentlig noget at gøre med hvordan projekterne får deres bevillinger. Her vil tendensen være at man prøver at sikre sig at man har ”husket det hele”, da man ikke ønsker at skulle bede om flere bevillinger efter projekter med.

Hvis jeg skal pege på et indsatsområde for offentlige projekter, vil det være denne. Der er gjort meget igennem det seneste årti, men der er stadigvæk lang vej igen. Optimalt set vil der engang i fremtiden slet ikke være nogen projekter af den størrelse som IT projektrådet beskæftiger sig med nu, men derimod IT-programmer indeholdende en række mindre projekter. Disse IT-programmer burde stadigvæk være under opsyn, men vil kunne monitoreres tættere, med mulighed for tidligere indsatser for at rette op på evt. problemer.

Begrænsninger på offentlige projekter

Her forventer alle nok at jeg kommer ind på udbudsregler, og det er bestemt en vigtig begrænsning på offentlige projekter, men det er langt fra den eneste som er relevant i forhold til problemer med gennemførelse af dem.

Lad os dog alligevel starte med dem. Udbud i Danmark følger EU-udbudsreglerne forholdsvis restriktivt. Med forholdsvis mener jeg i forhold til hvordan de fortolkes i andre EU-lande. Dette giver nogle udfordringer i forhold til offentlige udbud, men har formodentligt en samfundsgavnlig effekt, da det forhindrer nepotisme og lign.

Udbudsreglerne betyder at udbud der udsendes, og de tilbud som returneres som reaktion på disse, er omfangsrige og ofte indeholder en række ufravigelige krav, som det er svært at tilpasse såfremt det senere viser sig at de ikke er korrekte eller fyldestgørende. Ikke overraskende er dette ikke fremmende for agilitet i projekterne.

Valg af leverandører i forbindelse med udbud sker på grundlag af kvalitet af løsningsbeskrivelse og af pris. Mange har det indtryk at prisen vejer tungest, men i de offentlige udbud jeg har været involveret i, har kvalitet af løsningsbeskrivelse faktisk vejret tungere. Pris er dog stadigvæk en vigtig faktor, og hvis en leverandør gerne vil ”købe” udbuddet ved at komme med en meget lav pris, er det som regel muligt. Dog skal pris-reduktionen ikke lede til at myndigheden mener at tilbuddet ikke udviser forståelse for projektets omfang.

Offentlige projekter er ofte baseret på standardkontrakterne K01, K02 og K03. K01 dækker kortvarige IT-projekter, K02 dækker længerevarende IT-projekter, mens K03 dækker agile IT-projekter. Kendetegnende for alle disse kontrakter (især de to første) er at de lægger en stor del af risiko over på leverandøren, hvilket gør at en leverandør vil holde sig forholdsvist stringent til det som står i dem.

Myndigheder har mulighed for at lave deres egne versioner af kontrakterne, som opbløder modsætningsforholdet mellem kunde og leverandør, og såfremt de gør dette, har det ofte en gavnlig effekt på samarbejdet.

Andre begrænsninger på offentlige projekter er den øvrige lovgivning. Forsimplet kan det siges at mens private personer og virksomheder kan gøre at det som ikke er eksplicit forbudt i loven, kan offentlige myndigheder kun gøre det som er eksplicit tilladt i loven.

Dette betyder at der nogle gange er nogle begrænsninger i forhold til hvordan systemer kan implementeres, herunder i forhold til integrationer med andre systemer. Det betyder også at systemerne nogle gange skal implementere lovgivning som er utidssvarende, men som endnu ikke er blevet ændret af politikerne.

Typen af projekter

Når man kigger på større offentlige projekter i Staten er de ofte kendetegnet ved at de implementerer IT-infrastruktur som bruges på tværs af en lang række systemer, og de er stort set alle kendetegnet ved at de skal supportere mange, ofte millioner af, brugere på spidsbelastningstidspunkter.

Begge disse kendetegn adskiller sig voldsomt fra hvad man ser i de fleste private projekter.

Organisationernes størrelse

Dette er et aspekt som jeg føler ofte bliver overset.

Offentlige myndigheder er ofte forholdsvis store, og det betyder at der er en del organisatoriske udfordringer ved indførelse af IT-systemer som ofte bliver overset. Det betyder også at der er mange parter der skal involveres i forbindelse med specifikationen og afgrænsningen af projektet, hvilket kan give anledning til intern suboptimering mv.

Denne faktor er også ofte i spil med større private projekter, og giver anledning til de samme typer af udfordringer. Derfor mener jeg også at denne faktor er et af de områder hvor offentlige IT-projekter og private IT-projekter bør lære af hinanden, og udveksle erfaringer, hvis muligt.

Opsummering

Selv om mit postulat er at det ikke er bevist at der er forskel på succesraten på store offentlige og private IT-projekter, er der nogle kendetegn ved store offentlige IT-projekter, som kan lede til at de fejler. Det væsentligste af dem er, efter min mening, størrelsen på projekterne, og det er nok her den nemmeste gevinst kan hentes. Når dette så er løst, bør man se på hvordan man håndtere de andre på en sådan måde at de ikke er hæmmende for projekterne, samtidig med at man ikke samtidig fjerner de tiltag som er foretaget for at sikre gennemsigtighed i udbud og afgrænsning af det offentliges virkeområde.