Eksperter: Overmod har skylden for fejlslagne IT-projekter

Hvilke ting spiller ind, når tidsforløbet af IT-projekter skal estimeres? Og hvorfor ser vi så ofte at estimaterne skyder adskillige millioner kroner og flere år ved siden af, på trods af dygtige udviklere og projektledere og fornuftige økonomiske rammer? Tre eksperter giver deres bud på svarene.

Listen over fejlslagne eller groft fejlestimerede IT-projekter er lang, med Polsag, Amanda, den elektroniske patientjournal og rejsekortet som nogle af topscorerne.

I stedet for at fokusere på de konkrete fejlslagne projekter, vil SAMDATA Magasinet med hjælp fra to danske og en amerikansk IT-ekspert vende blikket indad, mod IT-projekters mange ubekendte faktorer, og de psykologiske faktorer der er forbundet med softwareudvikling og estimering. Men også udad mod den danske udbudsmodel, og den måde udvikling fungerer på i erhvervslivet.

I 2013 skrev programmør og IT-konsulent Dan Milstein fra det amerikanske firma Hut 8 Labs et blogindlæg, med titlen Coding, Fast and Slow. Indlægget handler om, hvorfor der gang på gang tages grueligt fejl, når det kommer til estimering af softwareprojekter. Milsteins inspiration til indlægget var bestsellerbogen Thinking, Fast and Slow af psykologen Daniel Kahnemann. Men mere om denne senere.

I første omgang gør Milstein os opmærksom på, at ethvert softwareudviklingsprojekt først og fremmest er netop det – et udviklingsprojekt. Når man laver IT-systemer, skal de beskrives i så mange detaljer, at man kan fortælle en computer, hvordan den skal afvikle dem. Udfordringen består i, at der skjult i de ting man ikke på forhånd ved om projektet, gemmer sig et eller flere problemer. Dette er nærmest en naturlov inden for programmering: Hvis man på forhånd vidste alt om, hvordan man ville komme i mål, havde man også allerede fundet en løsning. Og de problemer der viser sig, kan tage alt fra en dag til en evighed at løse.

Erik Bonnerup, der er tidligere administrerende direktør for Politiken og Danica Pension, samt stod i spidsen for den såkaldte Bonnerup-rapport, der undersøgte offentlige IT-projekter er enig:

”Store IT-systemer er svære at have med at gøre og komplekse, men man prøver at løse problemerne på en forkert måde, efter min mening. Der er tale om udviklingsprojekter, og derfor må man dele tingene op i mindre dele og tage sig af kernefunktionalitet først.”

Og udfordringerne stopper ikke her. For ud over ovenstående vedvarende problemstilling, er der også en psykologisk faktor, der spiller ind, mener Milstein: Overmod.

Vi lærer ikke af vores fejl

Overmodet er afgørende, når man spørger ’eksperter’ til råds. De vil altid være stensikre på deres forudsigelser, selv om de i mange tilfælde tager fejl. Når en ekspert tager fejl i forhold til et estimat, så vil det problem, der bliver overset – som vi kan læse i det ovenstående – tage alt fra en dag til en evighed at løse. Og hvad værre er, så lærer man som ekspert ikke nødvendigvis af sine fejltagelser.

Psykologen Daniel Kahnemann forklarer baggrunden for dette med en historie fra sin tid i det israelske militær. Her var han sat til at udvælge de soldater, der var bedst egnet som befalingsmænd. Det skete ud fra en øvelse, hvor en gruppe soldater i fællesskab skulle manøvrere en træstamme over en mur. På overfladen en udfordring, hvor man kan observere, hvem der træder frem og styrer gruppen, hvem der adlyder og hvem der giver op.

Problemet var, at dem, de udvalgte som ledere lige så godt kunne høre til den opgivende gruppe, når de blev observeret over længere tid. Og det på trods af, at Kahnemann og hans kollega var sikker på, at lederne fra træstammeøvelsen var udvalgt korrekt. Man kendte simpelthen ikke hele ligningen, nøjagtig som når man forsøger at estimere udviklingstiden på et helt IT-system, inden arbejdet påbegyndes.

Store IT-systemer er svære at have med at gøre og komplekse, men man prøver at løse problemerne på en forkert måde, efter min mening. Der er tale om udviklingsprojekter, og derfor må man dele tingene op i mindre dele og tage sig af kernefunktionalitet først.
ERIK BONNERUP

Enklere systemer

Nu nærmer vi os kernen i problematikken: Det er ligegyldigt, hvor grundigt man estimerer, fordi man vil altid kun måle på de elementer af udviklingen, som man allerede forventer.

”Man bruger tiden forkert. Der bliver brugt for lang tid på kravspecifikationer, og de er alligevel ikke dækkende. Så tager det lang tid at lave systemer, der bliver rigide. Derefter bruger man tid på at lave en kontrakt med kammeradvokaten, og så på at finde ud af, om man har fået, hvad man skulle have. Man burde lave nogen enklere systemer.” forklarer Erik Bonnerup.

Erik Bonnerup mener, at et enklere system kan baseres på overordnede mål:

”Et fornuftigt forløb kunne baseres på en beskrivelse af et overordnet sigte med projektet: Hvad vil man have med og hvad vil man vinde ved det. [Herefter kunne man] dele op, så man løser 90 procent af ønskerne, for det vil tilgodese langt størstedelen.”

Konkret kunne man forestille sig, at den meget omdiskuterede elektroniske patientjournal med denne tilgang ville være startet som en centralt udviklet kerneservice, der virkede på tværs af amterne. Ovenpå denne service kunne man derefter løbende udvikle ekstra services, i takt med at konkrete behov manifesterede sig.

Vejen frem

Udvikler og IT-kommentator Poul-Henning Kamp gør opmærksom på, at der også er en tendens til at overse, hvor komplekse IT-systemer er:

”Der er en million stumper i et hangarskib, men der er 12 millioner linjer kode i den billigste og simpleste smartphone. Og den typiske fejl-rate er cirka en fejl per 1000 linjer kode.” Selv om man starter med blot at udvikle kernefunktionalitet, så er der altså stadig en stor mængde kode, der skal skrives og dermed også mange ubekendte faktorer, som kan komplicere processen.

Tillige påpeger Poul Henning Kamp, at der er kan ligge en forklaring i den måde, vi har håndteret IT efter dot-com boblen.

”IT-branchen blev cirka 1000 gange større, målt i personer, i sidste halvdel af 1990erne, fordi enhver overløben sporvognsfører eller gymnasieelev pludselig var en ’fuldgyldig web-programmør’. Den viden, den erfaring, [den] metodik branchen havde udviklet op til cirka 1990 blev ignoreret som ’ligegyldig’ og ’uden relevans’, for langt de fleste IT-folk findes der simpelthen ikke noget før dot-com.” beskriver han, og fortsætter:

”Vejen frem er en professionalisering af IT-branchen, det vil sige, at der skal stilles krav, der skal opsamles erfaring, der skal holdes fast i ansvar og der skal rulle hoveder.”

Agil udvikling er ikke nok

En del af den professionalisering ligger måske i en bred anerkendelse af, at man ikke kan forudse alle elementer i udviklingen af IT-systemer. Det er et af de bærende argumenter for den agile udvikling af IT-systemer, der siden 2001 har vundet større og større indpas. Her foretages netop en opdeling af det store projekt i mindre bidder, som nemmere kan estimeres ud fra en (erfaren og dygtig) udviklers erfaringer. Og selv om man med agil udvikling kan overkomme usikkerheden ved at skulle definere et helt system på forhånd, så er det ikke en garanti for, at projektet overholder tidsplan og budget, mener Erik Bonnerup.

”Der er to grunde til at det ikke slutter med agil [udvikling]: Først må man se på den måde, man stiller det op, når man laver aftalen med leverandøren. Den bygger på, at man kan specificere tingene, nogle gange over flere tusind sider. Så kan man godt lave det agilt bagefter, men hvis rammerne er bundet op på kontrakten, så kan man ikke lave om løbende. Og så slår man for store brød op. Man vil have alt løst på en gang,” siger han.

Der er altså en afkobling i forhold til, hvordan man udvikler effektivt, og hvordan udbudsproceduren foregår i det offentlige.

”Det kan ikke nytte noget, at man snakker om, at det er udviklingsprojekter, hvis man ikke vil tage konsekvenserne af det. Det næste i det er, at man politisk og administrativt i de øverste led ikke accepterer, at det er udviklingsprojekter og konsekvenserne af det.” siger Erik Bonnerup.

Erhvervsmanden mener, at der i denne sammenhæng er en fordel, når man arbejder i det private erhvervsliv. I de projekter, han selv har ledet under sit arbejde i Danica Pension, var der en anderledes pragmatisk tilgang.

”I Danica [Pension] skulle vi have noget klar hvert halve år. Vi arbejdede i grupper, hvor halvdelen var brugere og halvdelen IT-folk. Højst 15 af hver og så to projektledere, en på brugersiden og en på udviklersiden. De 30 sad sammen om tingene – også rent fysisk[…]. Man tog det mest nødvendige først og opdagede, at man ikke havde brug for det andet. (det andet er det, der normalt udgør broderparten af kravspecifikationen, red.),” siger Erik Bonnerup.

Bedre forhold på vej for de offentlige udbud

Så hvad er løsningen, på det tilsyneladende uløselige problem? Hvis man skal prøve at kondensere pointerne fra teksten ovenfor, så handler det først og fremmest om at acceptere, at estimering af større IT-systemer er så godt som umuligt, før man er langt henne i udviklingen. Og hvad så?

Med den erkendelse gjort, vil man bedre være i stand til at fokusere på den ønskede værdi og den kernefunktionalitet, systemet skal have. Det resulterer i en væsentligt nedbarberet kravspecifikation og løbende dialog mellem leverandør og kunde, som det kendes fra den agile udvikling. Læg dertil behovet for en professionalisering af IT-branchen, hvilket vil afstedkomme en større viden om kompleksiteten og de enkelte elementer i IT-systemet.

Men det er kun en del af svaret, for selv om man overkommer ovenstående ret så massive udfordringer, så er der – i offentligt regi – behov for et opgør med udbudsmodellen og de kontrakter, der er en væsentlig del af den, som Erik Bonnerup påpeger ovenfor.

Og der er måske andre forhold på vej: Der er for nyligt fremsat en udbudslov, der blandt andet giver mulighed for såkaldte ’innovationspartnerskaber’ i de tilfælde hvor der arbejdes med nye typer løsninger. Herudover byder den på mere fleksible udbudsprocedurer og større forhandling og dialog i forbindelse med udbuddene.