Navne som Amanda og EFI får klokkerne til at ringe for de fleste. De repræsenterer nemlig nogle af de mange eksempler på kuldsejlede offentlige it-systemer til milliarder, der efterlader borgere uforstående og lamslåede overfor, hvordan det kunne gå så galt.
Vi har tidligere på OPS-indsigt skrevet om skat, hvordan næsten 100 it-projekter i staten er blevet 3,5 milliarder kroner dyrere på omkring fire år.
Men hvad er årsagen til, at den slags projekter ikke bliver skrottet, og hvad skal der egentlig til, før ledelsen trækker stikket på et problemramt it-projekt?
De spørgsmål Jens Schmidt, der er leder af IT Universitetets Forskningscenter for Offentlig IT dykket ned i.
I et interview med DigiTech konstaterer han:
”I store IT-projekter er der tit nogle ret høje træer at kravle op i, og man kan slå sig ret hårdt, når man skal ned igen og forklare aktionærer eller borgere, at pengene er spildt,” siger Jens Schmidt.
Han peger på, at når først projektet er besluttet og kontrakten underskrevet, så starter uret for “efterrationaliseringernes tidsalder”.
Det er interessant, fordi i et ud af fem it-projekter bruger man ifølge Flyvebjerg og Gardner over 4 gange det oprindelige budget på, at komme i mål og så er man end ikke sikker på, at man har opnået de gevinster man satte sig for, da projektet blev besluttet.
Varierende definition af it-projektsvigt giver misforståelser
I en forskningsartikel beskriver Jens Schmidt, at der er et hul i forskningslitteraturen med hensyn til at forklare, hvorfor nogle fejlslagne it-projekter får lov til at fortsætte i stedet for at blive afsluttet.
En del af problemet er et hul i forhold til en accepteret generel definition af it-projektfejl. Dette er væsentligt, skriver han, fordi varierende definition af it-projektsvigt giver anledning til misforståelser i forskning og praksis. Hertil kommer, at brugen af det nedsættende udtryk “fiasko” i sig selv er problematisk ifølge Jens Schmidt.
Han giver i artiklen fire perspektiver a) et overblik over, hvad der menes med it-projektfejl i litteraturen, b) et opdateret sæt af it-projektresultatkriterier forbundet med tilskrivningen af fiasko, og c) et nyt argument for den teoretiske forudsigelighed af it-projektafslutning. – marginalomkostningsfælden.
Artiklen præsenterer desuden d) en oversigt over, hvordan disse resultater kan bidrage til at forhindre it-projektsvigt
Seks fejl-parametre
Men hvad vil det sige, at et it-projekt fejler?
Her beskriver Jens Schmidt, ikke mindre end seks forskellige fejl-parametre, der spænder over alt fra økonomiske aspekter til funktionalitet og brugertilfredshed.
- – Projektet opnår ikke dets gevinster (enten økonomiske eller ikke-økonomiske)
- – Projektet indeholder ikke til den ønskede funktionalitet (når systemet er taget i brug)
- – Projektet lever ikke op til forventningerne hos de forskellige interessenter
- – Projektet lever ikke op til projektledelsestrekanten, som består af: Budget, tidsplan og Scope.
- – Projektet er ikke lønsomt for leverandøren
- – Projektet har problemer med styring og nedlukning
Jens Schmidt peger på, at de seks fejlkategorier altid bør være afspejlet i den risikolog man laver for et it-projekt. Gør man ikke det, vurderer han, at det ofte vil været udtryk for, at risikovurderingen ikke er i mål.
”Det sker tit, at man hellere vil tale om succes, end om ting der går galt. Projektstyring handler ikke kun om succeskriterier, men i lige så høj grad om at kortlægge og håndtere risici. Klare kriterier for, hvornår et projekt fejler er derfor meget vigtigt for risikohåndteringen i et it-projekt,” siger Jens Schmidt.
Den økonomiske logik ændrer sig
Det betyder, at selv om man i løbet af projektet finder, at projektet har fejlet på et eller flere af de seks områder, så er det ikke det samme som, at ledelsen lukker projektet ned.
Her peger Jens Schmidt på, at den økonomiske logik ofte ændrer sig, når først man går i gang at konstruerer et it-projekt, og der er skrevet under på kontrakt med en leverandør.
Jens Schmidt mener ikke, at man skal basere lukningen af et projekt de forventede totale omkostninger. Man skal i stedet holde de forventede gevinster ved ”det nye system” op mod, hvad det vil koste at gøre projektet færdigt på det tidspunkt man konstaterer fejlen og dermed revurderer om der er potentiale for at gå videre.
De løbende omkostninger i projektet til bl.a. leverandøren er jo indtil da forbrugt og dermed tabt, hvis ikke projektet bliver færdigt, men der sker ofte det, at man indregner dette driftstab.
”Derfor er det ofte økonomisk rationelt at give ekstrabevillinger, selvom den samlede projektøkonomi er negativ og “under vand”,” siger Jens Schmidt.
Han mener man skal likvidere it-projekter, hvis man befinder sig i en situation, hvor man kaster gode penge efter dårlige. Det sker ifølge forskningsartiklen først, hvis de udgifter der kræves for at får et fejlslagent projekt i mål, er højere end de gevinster, man kan forvente af projektet.
