1.500 gigantiske it-projekter undersøgt: Hvert sjette ender katastrofalt
Rejsekortet, Digital Tinglysning og Amanda er blandt de store it-skandaler, der har fået hug i medierne. Men den slags afsporede it-projekter er langt mere almindelige end tidligere antaget. Og det private erhvervsliv er ikke bedre end den offentlige sektor.
Et omfattende internationalt forskningsprojekt, med en dansk Oxford-professor i spidsen, viser nemlig, at et ud af seks it-projekter ender katastrofalt.
Resultatet for de mislykkede it-projekter er en tredobling af prisen og en forsinkelse på 70 procent. Den type projekter er 20 gange så sandsynlige at finde blandt it-projekter end forventet.
Bent Flyvbjerg er professor på University of Oxford i England og har stået for forskningen. Ifølge ham har fokus hidtil været på nettoresultatet af it-projekter på bundlinjen, men det er ifølge Bent Flyvbjerg en forkert tilgang:
»Vores undersøgelse viser for første gang, at det er de ekstreme projekter, dem, vi kalder black swans, man skal beskytte sig mod. Man skal ikke beskytte sig mod gennemsnitlige projekter, men mod variansen,« siger Bent Flyvbjerg til Version2.
Bent Flyvbjerg har i de seneste to år forsket på projektet, der inkluderer 1.500 verdensomspændende it-kæmpeprojekter, der har et gennemsnitsbudget på 170 millioner dollars, svarende til 900 millioner kroner. Den samlede værdi af projekterne er på 245 milliarder dollars, svarende til 1.300 milliarder kroner, og tæller projekter både fra det offentlige og private erhvervsliv.
It-fejl får bruttonationalproduktet til at falde
Nogle af katastrofeprojekterne, Bent Flyvbjerg har kigget på, har i flere tilfælde haft alvorlige konsekvenser:
»Vi har fundet firmaer, som er kollapsede, og administrerende direktører, it-direktører og finansdirektører, der har været nødt til at gå på grund af it-projekter, der er gået galt. Så det er virkelig noget, der gør ondt, når store it-projekter fejler.«
Nogle af de store firmaer, der er gået i knæ som følge af mislykkede it-projekter er Kmart, en amerikansk supermarkedskæde, og Auto Windscreens, der var Storbritanniens næststørste bilrudevirksomhed. Andre mislykkede it-projekter rammer på en helt anden skala end massefyringer. Nogle af projekterne er så store, at de påvirker et lands økonomi. Et af de helt grelle eksempler er et it-projekt i Hongkong:
»Bruttonationalproduktet gik ned i Hongkong, da man åbnede deres nye lufthavn for nogle år siden. It-systemerne på deres bagage- og flighthåndtering virkede ikke i flere måneder. Den flytrafik, der ellers havde været til Hongkong, udeblev, fordi der ikke var styr på noget i lufthavnen. Det havde så stor en effekt, at bruttonationalproduktet faldt.«
Gå efter produktet, ikke prisen
Ifølge Bent Flyvbjerg er der flere ting, man skal være opmærksom på, når det handler om it-projekter:
»Det er den endelige pris på projektet, der er afgørende. Det, der er billigt i udbud, ender med at være dyrt til sidst. Vi har eksempler på flere tusinde procents budgetoverskridelser,« siger Bent Flyvbjerg til Version2 og påpeger, at det ofte sker, at virksomheder bevidst underbudgetterer tilbud på opgaver, der er i udbud.
Kommentarer (10)
det interessante er så hvordan man undgår det. Hvordan kan man gennemføre et IT projekt hvor der er minimal risiko for leverandør går fallit, egen organisation kan levere kvalificeret mod- og medspil, beslutningstagere er bevidste om deres ansvar og 1000 andre ting som skal være på plads. Nogen tror på agile, andre på mere fokus på kravstyring m.m. Hvad der virker, er en langt mere interessant diskussion end netid er en fejl eller success
-
0 -
0
Dette spørgsmål behandles i
5 gode råd: Sådan undgår du projekt-katastrofen.
Link til denne artikel ses lidt oppe på denne side.
-
0
-
0
Jeg ville da synes, det var meget simpelt:
- Afgræns projektet så meget som muligt, evt. del det op i mindre dele, der kan opkøres 100% separat.
- Lad være med at hyre uduelige folk. Det gælder måde udviklere og projektmanagere.
- Lad være med at pille det gamle ned før det nye kører ordentligt.
Men jeg er også meget naiv.
-
3
-
0
Hold op med at antage at "IT" og "digitalisering" er en billig magisk sovs man hælder ud over en eller anden opgave eller funktion hvorefter den virker perfekt.
Der er ikke noget punkt 2.
-
7
-
2
Lokalt begrænset til Danmark kunne den åbenlyse lektion jo være: "Lad vær med at genopfinde den dybe tallerken igen og igen". Er der noget vi konstant gør herhjemme så er det at konkludere at vi kan gøre det meget bedre selv end de mange systemer der allerede findes og det holder stort set aldrig stik.
En anden lektion kunne være at stoppe med at bruge den samme håndfuld kæmpe leverandører som aldrig formår at levere indenfor den pris og deadline der er aftalt i en kontrakt.
Er der nogen der kan huske et offentlige IT projekt indenfor de sidste 3-5 år som ikke mindst én gang har overskredet pris og/eller tidsplan?
-
4
-
0
@Michael: Jeg syntes roligt du kan udvidde feltet til: "Nogensinde".
I bund og grund kunne jeg rigtig godt tænke mig at høre om det offentlige Danmark nogensinde er lykkedes med et stort IT projekt?
Michael rammer også et ømt punkt, som måske er den danske folkesjæl? "Vi kan gøre alting bedre selv"
Også Poul-Henning har en pointe i: "Hold op med at antage at "IT" og "digitalisering" er en billig magisk sovs man hælder ud over en eller anden opgave eller funktion hvorefter den virker perfekt"
-
1
-
0
Katastrofer er ikke til at undgå, men det er tankevækkende at IT projekter fejler 20 gange oftere end projekter end i brancher. Det noget mere end jeg havde troet. Løsningen har længe været at indføre Agile, Iterativt, lean hvilket er helt fint, men det er stadig kun tale om værktøjer og ikke den endelige løsning.
Jeg har selv været på bagsiden af et par af de mere uheldige IT projekter i de senere år og for mig at se er nogle af grundende til at de har fejlet følgende:
Man fokuserer hårdt på de oprindelige krav fra tilbuddet og glemmer, hvad det er for problemer man egentligt forsøger at løse. Der er ingen i større projekter der fra start kender løsningerne og som kan stille korrekte krav, men det er alligevel dem man arbejder ud fra.
Big bang udvikling. Alt på en gang, som allerede er sagt i artiklen. I stedet for at starte med en enklere version med mindre funktionalitet som man får til at fungere før man bygger resten på, satses på at leve det hele på een gang.
Mange arkitektur og tekniske beslutninger tages tidligt og af personer der ikke er kvalificerede til at tage beslutningerne. At en løsning skal være service enabled er ikke det samme som at man skal bruge alle integrations produkter en given leverandør har på hylden.
Alt for rigid tolkning af EU udbudsreglerne i forhold til andre lande, har medført at når først aftalen er i hus, ændrer man ikke et komma selvom man kan se at verden har ændret sig siden aftalen blev indgået.
Det at man skal tage den lavest bydende medfører ofte med til at de tilbuddene ikke er realistiske i hverken tid eller penge, hvorfor projekterne oftest bliver dyrere og tager længere tid. "Forventet efterbevilling" betyder at har man allerede brugt 50 millioner på et projekt så bruger man gerne 30 ekstra for at få det i hus (tabs aversion). Det er en kendt fremgangsmåde at byde for lavt og hente resten ind på ændringer (jurist drevet udvikling)
Man vælger leverandører ud fra et et økonomisk synspunkt. Det er oftest vigtigere at leverandøren kan overleve de dagbøder de pålægges ved forsinkelser end at de kan levere kvalificerede personer. Samtidigt betyder EU udbudsreglerne at mindre og nogle gange mere kvalificerede firmaer ikke har de økonomiske muskler til at være med om buddet.
Mistillid over tillid. Man bruger ofte mere tid på at forhandle bod, dagbøder osv. end at få en ordentlig projekt strikket sammen. Jeg har aldrig hørt en slutbruger der ikke hellere vil ha' noget der fungerer til aftalt tid end dagbøder fra leverandøren.
Mangel på automatisering af kedelige og repetitive opgaver. Der er mange opgaver i et IT projekt der kan automatiseres så man kan frigive ressourcer til mere forretnings rettede opgaver, men oftest gør man det ikke og vælger måske i stedet outsourcing.
Same procedure as last year. Det ser desværre ikke ud til at man lærer noget af de fejltagelser man gør.
-
6
-
0
Det er egentlig ret simpelt at undgå at projekter ender i katastrofer - ansæt kvalificerede projektledere - der IKKE skal deltage på detail udvikling - men kun skal være leder af det given projekt!
Lige så snart, at projektchef forventer at projektleder skal detailudvikle - så fjernes projektleders fokus fra de overordnede linier og dermed chancen for at bevare den "røde tråd"
Mvh Lars plbrake.dk
-
0
-
0
Henrik Wiwel har herover 9 gode råd. Specielt er nr.1 til 5 relevante for offentlige IT-projekter, hvor især punkt 4 er blevet en lokal, dansk "grundlov".
Der er et dilemma, som består i valget mellem "den sædvanlige leverandør" og en "ny leverandør efter udbud". EU har, for at fremme konkurrencen, fokus på udbud og på at stille alle leverandører lige. Konsekvensen, i den danske lokale fortolkning været det HW meget præcist beskriver i punkt 1.
Løsningen, som enhver offentlig ansat bureaukrat vil hade, handler om en erkendelse af NATUREN (SJÆLEN) i IT-projekter er knyttet til mennesker - dvs. målet er forandring. Det betyder, netop som HW beskriver, at et IT-projekt baseret på en rigid kravsspecifikation vil fejle. Derfor fejler næsten alle projekter som udføres i udbud.
Et IT-projekt lykkes KUN hvis muligheden for forandring (læs: læring under udviklingen) indbygges. Det er i sin natur i modstrid med den offentlige model for big-bang udbud.
Gennemføres projektet istedet iterativt (succcesivt opdaterede krav og specifikationer), så kan det lykkes. Det bliver ikke "dyrere", men det betyder at prisen ikke med sikkerhed kan fastlægges ved projektets start.
Der ER mindst eet eksempel på succes for et offfentligt projekt, nemlig Forsvarets DeMars projekt, som blev kontraheret og gennemført i et antal faser (udgaver, releases). Hver kontrakt opfyldte naturligvis EU-kravene, men rakte kun 12-18 måneder frem.
Som IT-projket var det en succes, på linie med Øresundsforbindelsen; der er dog ansatte i Forsvaret som er "utilfredse" - men det ses jo også hos dagplejen i kommunerne og andre steder (forandring er svær).
SÅ, KONKLUSION:
Det handler om "projektmodel" - dvs. successiv udvikling, hvor løsningen skydes ind på behovet.
Jan Heisterberg-Andersen
projektkvalitetschef emeritus
P.S.: Seks år uden nødlidende projekter.
-
1
-
0
For dem, der gerne vil grave ned i, hvorfor it-projekter så ofte trækker ud -- eller ender decideret galt -- kan jeg anbefale Scott Rosenbergs: Dreaming in Code.
-
0
-
0
Tilføj kommentar
