Flere offentlige IT-projekter har overskredet deres budgetter - igen...

Skrevet d. 20. august 2009 kl. 13.54 | (2)
Af: Partner Farzad Saber, Pactor A/S og tidligere kontorchef i Økonomistyrelsen




Men er budgetoverskridelser noget, der kun forekommer i den offentlige sektor?

Når man både har været kontorchef i den offentlige sektor med ansvar for større IT-projekter, og har arbejdet som konsulent i større private virksomheder, kan man se, at der er mange lighedspunkter, og at IT-budgetterne også engang imellem overskrides i den private sektor.

Efter min vurdering er der en række faktorer, der kendetegner budgetoverskridelserne i den offentlige sektor, som jeg vil prøve at uddybe:


Visionær i en nulfejlskultur?

Der er altid en risiko forbundet med at være visionær og være blandt de første. Når vi har det som målsætning at være blandt de førende lande i verden indenfor digital forvaltning, må vi også tage initiativer, der ikke er afprøvet tidligere. At være blandt de førende indenfor digital forvaltning stiller større krav til evnen til at indføre ny IT, men hænger dårligt sammen med den nulfejlskultur, der ofte præger offentlige arbejdspladser. Der skal også være plads til at fejle en gang imellem, men man skal naturligvis også lære af sine erfaringer og ikke begå den samme fejl igen. Succeser har mange faddere, mens fiaskoer er faderløse.


Budgetter fastsættes for tidligt.

Budgetter for selv større projekter og med høj kompleksitet, fastsættes ofte på et meget tidligt tidspunkt i forløbet, og dermed på et tidspunkt, hvor der er stor usikkerhed omkring projektet og de afledte konsekvenser - og dermed omkostningerne. Derfor er budgetoverskridelser på 20-50% ikke helt ualmindelige, og når man taler om store projekter, kan budgetoverskridelsen meget hurtigt komme op på 100 millioner kr. En af måderne at undgå disse budgetoverskridelser på, er at indføre fordomsfrie budgetreviews efter afslutning af hver hovedfase, således at man kan korrigere på et tidligt tidspunkt, og ikke når man nærmer sig afslutningen af projektet eller når pengene er brugt, og der er behov for ekstra finansiering.


Bygge nyt eller modernisere.

Mange af de IT-budgetter, vi ser i dag, medtager kun de direkte omkostninger til implementering af selve systemet, som f.eks. udgifter til hardware, software, systemudvikling, uddannelse mm. Men der er forskel på at indføre et helt nyt system, og så at modernisere eksisterende systemer. Det kan på mange måder sammenlignes med at bygge veje og broer: det er billigere at bygge en ny bro eller en ny vej, end at udvide en bro eller vej, der benyttes dagligt.

Vi ser ofte, at de afledte effekter ikke medtages eller undervurderes kraftigt i IT-projekterne. I takt med, at systemerne bliver mere og mere integrerede, stilles der stadigt større krav til, at systemmodernisering, opgradering eller udskiftning af dele af systemerne kan ske uden at påvirke dagligdagen. Det betyder, at der kan være behov for at bygge og teste midlertidige overgangsløsninger i takt med, at systemerne moderniseres eller udskiftes, og igen uden at medføre systemnedbrud eller lange svartider, når ændringerne implementeres. De indirekte omkostninger og testomkostningerne kan være svære at budgettere tidligt i projektet.


Forudsætningerne ændres.

Antallet af reformer og love mm. er steget kraftigt, og det medfører, at de systemer, der skal understøtte lovgivningen, skal lige ledes tilpasses i takt med at de nye love og reformer skal implementeres. På det tidspunkt, hvor et nyt projektbudget fastsættes, kender ingen de fremtidige ændringer, der skal indføres og testes i både eksisterende og det nye system. Og i takt med, at systemerne bliver stadigt mere komplekse og stadigt mere integrerede, tager det længere tid at indarbejde de løbende ændringer og teste dem, hvilket medfører en forsinkelse i projektet og højere omkostninger.

Udviklingen peger på, at antallet af reformer og løbende ændringer af love fortsat vil stige i fremtiden, hvilket betyder, at det bliver sværere at estimere udgifterne til IT-projekter, når rammen for projektet fastsættes. Der skal derfor være større fokus på ændringshåndtering og dermed også modeller for estimering af de økonomiske konsekvenser ved lovændringer. Bl.a. skal der være en klar adskillelse mellem hovedprojektets økonomi og finansieringen af de efterfølgende ændringer. Og ekstra bevillinger til ændringer skal både indeholde de direkte og indirekte omkostninger.

Det er min vurdering, at budgetoverskridelser er kommet for at blive, men vi kan blive bedre til at styre dem undervejs, således at vi ikke bliver overraskede, når regnskabet gøres op i slutningen af projektet eller når kassen er tom før tid.


Kommentarer til blogindlæg


Glimrende indlæg.

Jeg mener dog også, man i høj grad kan skyde en del af skylden på den ofte overbureaukratiserede udviklingsprocess, der ofte forudsættes i udbudsmaterialet fra offentlige virksomheder. Det forekommer mig, at man ofte forsøger at kompensere for en grundlæggende forkert indfaldsvinkel til IT-projekter ved at gå endog endnu længere ned ad samme blindgyde.

Det grundlæggende problem består oftest i behovet for, på et tidspunkt, hvor man kender aller mindst til projektet, er nødsaget til at udfærdige en kravspecfikation og dokumentation, der er så omfattende at det forudsætter langt større kendskab til projektet end muligt ved opstarten.

Nu vil jeg nødigt fremhæve forskellige agile tilgangsvinkler til projektgennemførsel, men i min verden er det utopi at tro at de store, tunge projektmodeller er svaret på problemerne eller på nogen som helst måde bidrager med andet end yderligere bureaukrati og specifikation af noget, man ikke har mulighed for at specificere.

Naturligvis er det lidt sat på en spids, men jeg føler mig overbevist om, at hvis man fra kundernes side forsøgsvis valgte at udstikke rammerne for arbejdet samt en række løst definerede målsætninger, og så undervejs lod styregruppe og projektgrupper arbejde med høj grad af kommunikation og løbende dialog mellem kunder og projektmedarbejdere, ja så ville man i 99 % af tilfældene sandsynligvis opleve et langt bedre produkt på langt kortere tid og med langt færre juridiske slagsmål om, i hvor høj grad nogen har opfyldt hvilke krav.

I særdeleshed på projekter, der løber over en årrække er det utopi at tro, at det, jeg ville have for 2 år siden, stadig er det, jeg har brug for i dag. I bedste fald lever systemerne fuldkommen op til mine krav for 2 år siden, men i værste fald lever de hverken op til kravene eller opfylder de reelle behov, jeg har i nutiden.
Du har ret, Casper. Som Dansk IT skriver i sin seneste rapport, "5 holdninger til statslige it-understøttede forretningsprojekter", ville det optimale være, hvis bevillingerne til projekterne blev givet fase for fase, så man ikke havde købt hele forløbet inden vejen mod målet er fuldt kendt.

Men et af problemerne er ofte, at opgaven - målet, om man vil - er givet på forhånd, f.eks. i kraft af lovgivning eller politiske udmeldinger, der binder organisationerne. Ofte er variationsmulighederne alene, om man skal vælge den ene eller anden vej gennem it-landskabet for at nå målet.

Et andet forhold, som er med til at nødvendiggøre et detaljeret billede af kravene til projekterne tidligt i forløbet, er både kundernes (myndighedernes) og leverandørernes modenhed, der i mange tilfælde er for lav til projekter af de størrelser, der sættes i søen.

En detaljeret kravspecifikation tvinger ofte organisationen til grundigt at gennemarbejde sine idéer og arbejdsprocesser, mens den på den anden side af hegnet tvinger leverandøren til at forholde sig til, om produkter og serviceydelser matcher kravene. Er det ikke skrevet klart ind i processen, hvilke former for ændringer, man vil acceptere siden hen, kan det blive en spændetrøje, men har man fod på ændringshåndteringen, kan det være et stærkt værktøj i projektgennemførelsen.
Kommentér

Ytringer på debatten er afsenders eget ansvar - læs debatreglerne







Mest læste seneste uge

Det lykkedes en pensioneret politimand at fravriste Microsoft-svindlere de penge, som de havde lokket ud af ham. Se her, hvordan han gjorde.

Det hidtil største malware-angreb på Android er i fuld gang. Millioner af Android-brugere kan være blevet ramt af ny trojaner.

Med 4G kommer du voldsomt hurtigt på nettet med mobilt bredbånd. Men hvilken udbyder skal du vælge?

Mens nogle virksomheder vil kunne lade et trådløst WiFi-netværk erstatte kablerne, kan det hurtigt give problemer i andre virksomheder. Her får du gode råd til at træffe den rette beslutning.

Politiet dropper det skandaleramte Polsag. Systemet har løbene været ramt af forsinkelser. For halvandet år siden var budgettet overskredet med omkring 100 procent. I dag er status ukendt.