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.
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
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
