Ny undersøgelse fra ITU går i dybden med facts og findings omkring de store kuldsejlede projekter. Og her kommer en del utvetydige sandheder frem.

Det fremgår bl.a., at grundlæggende fejl i analysefasen ligger til grund for over halvdelen af problemerne ved større fejlslagne offentligt it-projekter.

Alt for ofte hører vi om stærkt fejlbehæftede, fordyrende og forsinkede offentlige IT-projekter, til stor frustration for både borgere, brugere og leverandører.

Mange af disse fejl stammer fra analysefasen samt fra den efterfølgende håndtering af disse fejl. Det viser en ny undersøgelse fra Søren Lauesen, professor fra ITU, der er dykket ned i de fejlslagne offentlige it-projekter og deres årsager.

Forkert fokus allerede i analysefasen
Søren Lauesens gennemgang viser, at det ofte er dyrt indkøbte konsulenter, der ender med at skrive så indviklede og omstændige kravspecifikationer, at både kunde og leverandør mister overblikket over, hvad systemet reelt skal løse af problemer.

Alligevel omfatter disse kravspecifikationer ofte ikke hele virkeligheden, men udelader at beskrive vigtige og vanskelige elementer af løsninger. Eller endnu værre: Kravspecifikationen indeholder til tider fordyrende og unødvendige krav, som ikke er en følge af de reelle forretningsmæssige behov, men snarere er en følge af en teoretisk tilgang til problemstillingen.

”Der bliver ofte fokuseret alt for meget på at opfylde forkerte eller mangelfulde specifikationer, og for lidt på at løse de reelle forretningsmæssige behov. Kommer man skævt fra start, er det svært at rette op efterfølgende, og fokus ender desværre ofte med at placere skyld frem for at redde projektet,” siger Birgitte Hass, adm. direktør i IT-Branchen.

Både IT-Branchen og professor Søren Lauesen peger på, at der skal skabes mere rum, til at leverandører sammen med kunden allerede i analysefasen kan fokusere på, hvordan it-løsningen skal styrke kundes forretning.

I rapporten fra ITU bliver det også slået fast, at en anden væsentlig årsag til de fejlslagne it-projekter er, at man ikke allerede i analysefasen tager højde for de ændrede arbejdsprocesser, der følger af et nyt system, men blot anser projektet for en ren it-implementering.

Dermed tager man ikke højde for, at de store it-projekter måske i højere grad er et forandringsprojekt end et it-projekt.

Succes kræver bedre samarbejde
For at komme i mål med de store projekter, skal man kunne håndtere de ændringer, der opstår løbende i projektet, som følge af dybere forståelse for løsningen samt forandringer i miljøet omkring løsningen.

Det kan kun lade sig gøre, hvis ledelsen hos både leverandører og kunder kan samarbejde, hvilket er helt i tråd med det nye projektkodeks.

Professor Søren Lauesen understreger i sin rapport netop vigtigheden af, at ledelsen ved, hvornår der er brug for agil styring og ekspertinddragelse, så arbejdsprocessen ikke drukner i detaljekrav eller frygt for at tale om projektets reelle problemer.

Vi skal også kigge indad
Rapporten peger på en del fejl både hos kunden og de tilknyttede konsulenter, men også it-leverandørerne bærer deres del af skylden.

Søren Lauesen anklager i sin rapport leverandørerne for alt ofte at oversælge sig selv, og for at være for optimistiske i forhold til, hvordan de kan løse opgaven. Ligeledes gør it-leverandørerne sig ifølge Lauesen skyldig i at acceptere urimelige kravsspecifikationer uden indsigelser.

”Vi har som leverandører også et ansvar, og vi skal blive langt bedre til at indgå i dialog med det offentlige. Det er vigtigt, at vi grundlæggende forstår, hvad det reelt er, der skal løses, og at vi har modet og muligheden for at udfordre løsningen under hele forløbet. Ellers kommer vi ikke i mål,” fastslår Birgitte Hass.

Sådan sikres de gode projekter
Følger man anbefalingerne i rapporten, tegner der sig et gennemgående mønster, hvis man vil sikre bedre offentlige it-projekter:

  • Der opfordres til en arbejdskultur, hvor en klar og tydelig kommunikation og et større fokus på brugernes faktiske behov er noget, der skal prioriteres højere.
  • Det tydelige ledelsesmæssige fokus bør være på de forretningsmæssige krav, hvor man hele tiden tager udgangspunkt i brugernes virkelighed og i, hvilke problemer det nye it-system helt konkret skal løse.
  • Det anbefales at lave pilottests og prototyper tidligt i forløbet, så man hurtigt kan justere løsningen, ressourcer og tidsplaner. Derfor er det også vigtigt, at opfølgende analyser og bedre overvågning af projektet er en del af løsningen.
  • Ved store og komplekse projekter anbefales det at erstatte fastprisprojekter forankret i detaljerede kravspecifikationer med indkøb af agil kapacitet, hvor leverandør og kunde i fællesskab specificerer og løbende prioriterer de mest relevante krav

IT-Branchen opfordrer desuden til at følge de fem gode råd om dialog.

Om analysen
Professor Søren Lauesen fra ITU har gået i dybden med 5 større offentlige IT-projekter, og de typiske årsager til fejl er blevet listet i 36 punkter, hvoraf mange af dem også er konkluderet af Bonnerup rapporten fra 2001.

Præsentation af undersøgelsens konklusioner kan findes på dette link.
 

 

Kommentarer

Jesper15. jun
Helt enig i Sørens betragtninger. Men der mangler lige den vigtige vinkel, at alle store offentlige projekter leveres på baggrund af EU udbud, hvor kunden (eller kundens indkøbte konsulenter) dikterer alle krav og løsning. Leverandøren skal svare JA til alle krav - ellers kommer man ikke i betragtning. tidligere kunne man skrive sine ændringsforslag eller forbehold, men det er ikke ønsket mere af kunderne. Samtidig er der kun meget begrænset mulighed for dialog i udbudsfasen - fordi det er fælles spørgerunder og man ikke vil give konkurrenterne gode ideer. Efter min mening er EU udbud - i den form den har i dag - årsag til en mindst en fordobling af udgifterne til de enkelte projekter, samtidig med de giver dårligere løsninger: - Kunden bruger lang tid og dyre konsulenter på at skrive rigide og ofte dårlige kravspecifikationer (Løsningsspecifikationer!) - ofte med udgangspunkt i den hverdag de kender i dag. (hvem har ikke været med til at "sætte strøm" til papir-processer) - Leverandørerne svarer Ja til alle krav og ligger en pæn margin oven i estimaterne, fordi mange krav er uforståelige. - Leverandøren kender ofte nye teknologier og muligheder, der kunne reducere udviklingsomkostninger og understøtte mere effektive arbejdsgange - men implementerer det, der er beskrevet i kravspecifikationen. - Kunden får det system de troede de ville have - men får "mod forventning" ikke de gevinster man havde håbet. Hmmm.

Nyheder fra IT-Branchen

Få styr på de offentlige it-projekter

På IT-Paratskibet var der under Folkemødet heftig...

Det offentlige skal tage ansvar for Persondataforordningen

Om under et år træder de nye regler for behandling af...

5 UX udfordringer du skal mestre

IT-Branchens medlemmer og Digitaliseringsstyrelsen...