Gæstebloggen

Hvorfor går IT-projekter ofte galt?

Vi hører hele tiden om IT-projekter der går galt, men ikke så meget om hvorfor og hvad man kan gøre ved det.

Søren Lauesen er professor på IT-Universitetet og forsker i i projekters dødsårsager og problem-orienterede kravspecifikationer. Illustration: IT-Universitetet

Forretningens ledere er mest optaget af hvad de kan se fra deres egen stol: Dårlig projektledelse, fejlvurdering af prisen, forsinkelse, leverandører der ikke leverer det vi forventede. Men ledelsen kigger ikke på hvorfor dette sker. Det er meget uheldigt, for hvis man ikke kender årsagen, kan man heller ikke finde en løsning.

Jeg har sammen med Rigsrevisionen og forskellige kolleger haft lejlighed til at finde årsagerne i flere store offentlige IT-projekter som "gik galt" på en eller anden måde, bl.a. Elektronisk Tinglysning (eTL), Rejsekortet (RK), Poliets sagsbehandlingssystem (PolSag), Skats gældsinddrivelse (EFI) og Sundhedsplatformen (EPIC).

Hvad vil det sige at et projekt går galt? Blandt de 5 er det kun PolSag som aldrig blev taget i brug. I luftfarten definerer man en katastrofe som en situation hvor der skete væsentlig skade på personer og/eller materiel.

På samme måde kan man definere en IT-katastrofe som et projekt der har væsentlige "skader" på leveringstid og/eller kundens udgifter, den forretningsmæssige værdi, brugertilfredsheden, leverandørens udgifter, eller hvor det aldrig blev afklaret om projektet var realiserbart.

De 5 projekter har meget forskellige skadesmønstre. Fx har EPIC (som det eneste) hverken skade på tid eller kundens udgifter. Til gengæld er der store skader på brugertilfredsheden. For PolSag og EFI blev det aldrig afklaret om de kunne realiseres. Dog kørte halvdelen af EFI i flere år.

Hvorfor skete disse skader så? Vi fundet frem til 36 skadesårsager. Hvert projekt er ramt af mellem 13 og 17 af årsagerne. De optræder i forskellige mønstre i de 5 projekter.

Lad os se på nogle af de hyppige årsager i de 5 projekter:

Årsag A1: Kunden identificerer ikke brugernes behov (ramte alle 5 projekter). Behovene burde fremgå af den kravspecifikation kunden og leverandøren skriver under på, men det gør de ikke. Man kan fx ikke se hvem der skal bruge det nye system, hvornår og til hvad.

Ofte har projektledelsen aldrig stillet sig selv det spørgsmål. I stedet beskriver man - ofte i detaljer - hvad systemet skal gøre. Det er ikke så smart, for leverandøren har måske en bedre løsning, der gør tingene på en anden måde end den kunden har beskrevet.

Årsag A7: Man vil have det hele på engang (ramte 4 projekter). I eTL ville man dække hele landet på engang. Systemet var meget svært at bruge, så ejendomsmæglere og advokater kom til at overbelaste tinglysningens hotline med spørgsmål, så tinglysningerne blev forsinket. Først for sent opdagede man den manglende brugervenlighed. Havde man sat det i drift i én retskreds først, havde man kunnet håndtere problemet.

I EPIC projektet satte man alle specialer i drift samtidig, ganske vist "kun" på to hospitaler. Medarbejderne var slet ikke uddannet til at betjene systemet og der var ikke sket den nødvendige tilpasning til hvert speciale, så man kunne arbejde lige så effektivt som før.

Årsag D2: Overraskelser ved system integration (ramte alle undtagen Rejsekortet). Som regel skal systemet udveksle data med 10 til 100 andre systemer. Det lyder let, men i praksis giver det masser af problemer fordi det er uklart hvad de andre systemer stiller til rådighed af dataudveksling. Og det de stiller til rådighed passer sjældent med det som det nye system har brug for. Så man må forhandle med den anden part, og hvem skal betale?

Bare det at få tilladelse til at forbinde systemerne kan tage måneder. Når forbindelsen så skal testes, kræver det deltagelse af den anden part. Det hele kan nemt komme til at koste en million pr. forbindelse, og da det tit er noget man gør sent i projektet, kan det give væsentlige forsinkelser.

Kan vi så gøre noget ved disse problemer? Faktisk har vi et bud på 20 metoder der kan forebygge eller reducere de fleste af årsagerne.

Eksempler: (1) Problemorienterede krav, hvor man ikke beskriver hvad systemet skal gøre, men hvad det skal bruges til. (2) Pilottest inden man går i fuld drift. (3) Tidlige test af at brugerne faktisk kan finde ud af at bruge systemet. (4) Re-planlægning ved forsinkelser i stedet for at tro man bare kan skynde sig mere med resten. Selvom ca. halvdelen af de 20 metoder er velkendte i IT-verdenen, bliver de ikke brugt, eller brugt helt forkert.

Som man kan se er skadesårsagerne ikke bare teknik man kan overlade til IT-eksperterne. Det er heller ikke noget man kan overlade til en ledelse, der ikke forstår det tekniske. Det handler om et indsigtsfuldt samarbejde mellem ledelsen og IT-folkene. Fx kunne man sammen studere årsager og metoder.

Man kan læse om alle projekterne, årsagerne og metoderne her

Relateret indhold

Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Petersen

Store projekter med mange brugere ligger jo i grænselandet mellem de bløde værdier (bruger venlighed, UX) og de tekniske (database, services mm.).
Via medierne får man det indtryk at den slags projekter er ledet efter budget-mæssige principper (altså djøf-ledet), hvor man overser de ingeniørmæssige principper.
Nu konflikter disse to principper jo normalt, fordi det er meget svært at finde leverandører der både kan lave et billigt system (1), der er ingeniørmæssigt forsvarligt (2) og som slut- brugerne er glade for at bruge (3).

Det er lidt "kvalitets-trekanten" der spøger, hvis man kun kigger på pris og leveringstid, så vil de tilbud der bliver leveret være optimeret til et minimalt accepteret kvalitsniveau (Minimal Viable Product).

Leverandørerne er ofte store konsulenthuse der efter de indledende kontrakt forhandlinger sætter en hær af nyuddannede og outsourcede i gang med at implementere det der er fastlagt i kontrakten. Virker som om at vandfalds-modellen stadig bliver anvendt i den slags komplekse projekter.

Det er jo Conways lov der spøger igen, at en organisation vil udvikle systemer der afspejler samme organisation, samt at organisationen skal ændres igennem hele forløbet så den afspejler den nye viden om projektet der løbende opstår.

Så ja, en krav specifikation der afspejler brugerens faktiske behov, herunder brugervenlighed (UX), så ja, masser af pilot-tests og masser af tests hvor slut-brugerne er inddraget.

Man kan lære noget af computerspil-branchen, her kan man ikke tillade sig at sige "test af om brugerne faktisk kan bruge systemet", et spil som brugerne ikke kan finde ud af vil der aldrig være nogen penge i.

Fokusen burde være på dem der skal bruge systemet, lidt synd at vi stadig har den enevældige tankegang, at undersotterne jo må finde sig i hvad "ledelsen" leverer.

Stil krav om en ansvarlig projekt-top-ledelse der afspejler kravene til sådanne systemer: budget (økonomi og tidsplan), brugerkrav (funktionalitet, test og UX), teknisk udvikling.
Set udefra virker det som om at de eneste krav der forsøges overholdt er de økonomiske, og det er der som artiklen så fint beskriver mange årsager til at de desværre heller ikke kan overholdes.

  • 7
  • 0
Mogens Lysemose

Rigtig god analyse og præsentation - og lige så beskæmmende er det at milliardprojekter falder i de samme nybegynder-faldgruber igen og igen! Tænk at man stadig skal diskutere om brugerkrav skal have noget med brugere at gøre, om brugere skal teste systemet, om man skal lave Pilottest for at finde fejl og ikke risikere hele produktionen/forretningen.
Jeg lærte det på få måneder på et universitetskursus og jeg arbejder ikke som projekleder, hvordan kan professionelle projektledere for milliard-projekter ikke kende basal projektledelse?

  • 4
  • 0
Jan Larsen

Fx har EPIC (som det eneste) hverken skade på tid eller kundens udgifter.

Mnjah, men det er vel fordi, alle/mange problemer i EPIC blev transformeret til "egenleverancer" og dermed skulle betales af regionernes egen kasse og ikke EPIC projektets kasse.

Egenleverancerne blev i øvrigt udviklet to gange - en for hver Region - fremfor kun en udvikling i EPIC projektet.

  • 1
  • 0
Jan Heisterberg

Blandt det fremhævede “metoder til forebyggelse og reduktion” mangler jeg især “beslutning- og ledelse” i lyset af offentlig forvaltning og kultur.
For eksempel er det indlysende, at Region Hovedstadens journalsystem (EPIC). Ifølge det oplyste, så var projektet åbenlyst nødlidende (anvendelighed) allerede efter kort tid på de første to (pilot) hospitaler.
En ansvarlig ledelse burde have lavet en timeout, som kunne være brugt til systemændringer og ny uddannelse.

Det politiske, resultatorienterethed, pres - og måske manglende reel information til det politiske regionsråd - medførte istedet fortsat udruldning (“go-live”), hvilket har medført at de velbeskrevne fejl, mangler, uhensigtsmæssigheder mv. fortsat eksisterer.

Årsagen er dels kultur, dels blandt andet Kammeradvokatens misforståede opfattelse af “tid og pris” som uforanderlige størrelser.
Udsættelse, forlængelse, merpris, er ikke acceptabelt i offentlig forvaltning.

Så med al respekt for de nævnte årsager, så vil jeg fremhæve, at en ændring af ledelseskulturen, beslutningskulturen, er helt afgørende.
Det nytter ikke med selv den bedste, største, mest omfatttende pilottest - hvis IKKE det kan have konsekvenser for tids- og idriftsætningsplanen.
DET er den største enkeltårsag til det syge EPIC-system.

  • 7
  • 0
Bjarne Nielsen

Årsagen er dels kultur, dels blandt andet Kammeradvokatens misforståede opfattelse af “tid og pris” som uforanderlige størrelser.

Det virker nu til, at leverandøren her havde mere end en stor finger med i spillet. F.eks. sagde Hjalte Aaberg (fra en position som regionsdirektør) flg. umiddelbart efter Riget var kommet med, trods de mange fejlmeldinger og dårlige erfaringer med bl.a Herlev:

»Vi mener, at den strategi, vi har lagt, som er udarbejdet på baggrund af Epics erfaringer, sådan set er rigtig.«

(https://www.version2.dk/artikel/loerdag-nat-kom-sundhedsplatformen-danma...)

Retorikken var vist den sædvanlige om brændende platform, undgå dobbeltdrift og hurtig høst af lovede effektiviseringsgevinster, men det er åbenlyst i en kommerciel leverandørs interesse hurtigst muligt at nå point-of-no-return, hvor kunden reelt ikke har andre muligheder end at bide tænderne sammen og kigge fremad.

Den erfarne leverandør snyder den uerfarne kunde.

  • 5
  • 0
Verner Langballe

Jeg savner en beskrivelse af hvilken type personer der sidder i ledelserne af projekterne, sammenholdt med hvor godt resultatet blev.

Jeg tænker på en opdeling som f. eks.:

  • Fagforeningsorinterede personer
  • IT og system uddannede personer
  • Politikere
  • 1
  • 0
Frithiof Andreas Jensen

.... hvordan kan professionelle projektledere for milliard-projekter ikke kende basal projektledelse?


Hvis man graver lidt i det, så finder man sandsynligvis at Incitament-strukturerne favoriserer den eksisterende måde at göre tingene på!

Vi ser den samme tilgang med "super"-sygehusene: Man bygger hurtigt 20 helt forskellige projekter til levering på den samme tid lige ind i en bygge-boble, naturligvis med de obligatoriske löbende ändringer og "besparelser".

I stedet for först at bygge Eet Enkelt "super"-sygehus, se hvor fejlene er i designet, og så bestille "19 stykker mere af den samme model" efter det opdaterede design!

  • 4
  • 0
Jan Heisterberg

Nu er Hjalte Aaberg absolut ikke et sandhedsvidne, men en part i sagen. Han har enten haft sin egen dagsorden eller fået en dagsorden af de politiske magthavere - som ihvertfald, for enhver pris (patienter og sundhedspersonale) IKKE ville have et Jysk system.

Det er rigtigt, at it-projekter for 40 år siden i høj grad var cash Cowi for it-firmaer, som slap af sted med at udskrive regninger for tillæg.
Det medførte Kammeradvokatens fokus på fast pris - men, som flere projekter viser, så er den model helt uegnet til systemer præget af sagsbehandling og brugervenlighed.
Den agile udviklingsmodel (iterativ udvikling) var derfor i mange år absolut ikke Kammeradvokatens yndling - selvom det beviseligt er den enestemåde at undgå fiaskoer som eg. PolSag på.

Bemærk her, at alle de “gode” løsninger, it-systemer, er lavet gennem multiple iterationer - i mange tilfælde med start i mørke kældre og dunkle garager. De store it-spil er mangefold mere komplicerede end de småløsninger offentlig forvaltning bruger.
Så det KAN lade sig gøre.

Jeg er af den faste overbevisning, EPIC kunne være blevet en succes, HVIS der var lavet en version 2 efter de første to hospitalers dårlige erfaringer. Det havde så udsat go-live med 12 måneder - og hvad så ? - lige bortset fra et regionsrådsvalg ....... !

  • 0
  • 0
Rune Juhl-Petersen

Når man kaster så mange milioner efter et projekt glemmer man at man har muligheden for at for ændre de underliggende processer. Man kunne for eksempel have gjort op med det komplekse zone og afregnings system vi har i Danmark, gjort det simplere og dermed ikke skulle have brugt så mange ressourcer på at implementere den del af systemet.
Man tror at man kan løse en dårlig og kringlet process ved bare at sætte strøm til den :(

  • 1
  • 0
Olav M.j. Christiansen Blogger

Hej Søren

Meget interessant læsning, selv om jeg ikke har fået læst hele din rapport endnu. Jeg vil nok følge op på min egen blog med nogle af dine konklusioner og anbefalinger på et senere tidspunkt.

Jeg ser at du bl.a. har analyseret Tinglysningsprojektet og langer ret meget ud efter ledelsen i projektet. Kunne din rapport ikke have været anvendt i den nylige retssag?
https://www.version2.dk/artikel/domstolsstyrelsen-frifundet-it-kaos-digi...

Olav

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize