Martin Koksrud Bekkelund

Etter snart 15 år i IT-bransjen har jeg hatt min dose IT-prosjekter. Noen har gått bra. Noen har gått dårlig. Erfaringene har vært mange, og her deler jeg dem med deg.

Verdien av å feile

Alle bør oppleve IT-prosjekter som feiler. Det gir oss verdifull erfaring som vi kan ta med inn i neste prosjekt. Jeg tør påstå at de som har opplevd et prosjekt som har feilet, leverer bedre prosjekter enn dem som aldri har fått slik erfaring. Ikke bare lærer du hvordan ting skal gjøres, du lærer også hvordan ting ikke skal gjøres. Har du aldri feilet, har du aldri fått denne erfaringen. Er du for forsiktig utnytter du aldri potensialet.

Hva er problemet?

Man kan ikke peke på ett konkret problem som årsaken til at IT-prosjekter feiler. Det er mange forskjellige problemer som ligger bak. Dette er ingen uttømmende liste, men basert på min erfaring skyldes problemene ofte en kombinasjon av følgende.

• Man planlegger seg ihjel. Også kjent som «den norske modellen», hvor man fokuserer for mye på planlegging istedet for gjennomføring. Når planene skal realiseres har verden endret seg så mye at man bommer på målet. Eller at man, planleggingen til tross, allikevel ikke klarer å følge planen, og prosjektet av den grunn kategoriseres som feilet (til tross for at det kanskje fra et teknisk perspektiv var vellykket).
• Mangel på erfaring fra IT-prosjekter. Mange IT-prosjekter bemannes med ressurser uten kompetanse i gjennomføring av nettopp IT-prosjekter. Du er et råskinn til å gjennomføre byggeprosjekter, javel. Men det gjør deg ikke til en dyktig prosjektleder innen IT.
• Mangel på teknologikompetanse. Valg av feil teknologi hjemsøker mange IT-prosjekter. Det kan være teknologi som ikke klarer å skalere til ytelsesbehov, teknologi som vanskeliggjør realisering av forretningskrav eller andre begrensninger den valgte teknologien legger. Hvilket bringer oss inn på neste punkt.
• Alle egg i samme kurv. Bytte ERP-system, sier du? Snakkes om noen år! Før eller siden må all teknologi byttes ut. Da er det greit om du ikke trenger å skifte ut alt på én gang. Det har selvfølgelig sine fordeler og ulemper, som du bør veie mot hverandre når teknologivalg tas.
• For mye i ett system. Helsejournalfaktureringsøkonomilogistikkgruppevaresaksbehandlingssystem? Man må ikke løse alt i samme system, ref. forrige punkt.
• Mangel på fagkompetanse. Du er et råskinn på .NET, javel. Men hva kan du om tredjepartslogistikk? Et prosjekt trenger flere typer kompetanse.
• Mangel på styring. Når det brenner på dass, og du blir tvunget til å prioritere knallhardt, hvem sikrer retningen på prosjektet? At riktige beslutninger tas?
• Mangel på smidige metodikker. Prosjektmetodikken alene kan være årsaken til et fiaskoprosjekt. Se gjerne en lyntale om temaet.
• Overadministrasjon. Jasså, du sliter med å levere? Det spiller ingen rolle så lenge du kamuflerer den dårlige fremdriften i kilovis med rapporter og utredninger. Riktignok ikke et IT-prosjekt, men syndromet kjenner vi fra ubåtsaken på Fedje. Liker du ikke utredningen? Be om en ny!
• Byråkratisering av IT-prosjekter. I visse sektorer er økt byråkratisering i ferd med å bli et problem som smitter over på IT-prosjektene de kjører. I frykt for å gjøre feil, planlegger de seg ihjel med det resultat at man aldri kommer til mål. Innføring av e-journal i helsevesenet er et slikt eksempel: 13 års planlegging, 1 milliard kroner, ingen løsning i sikte.
• Mangel på endringskultur. «Sånn har vi alltid gjort det hos oss!» Hørt det før? IT-prosjekter betyr endringer. Alltid. Er man ikke villig til å benytte anledningen til å endre seg til det bedre vil man feile. Alltid.
• For mye på én gang. Ditt verdensbilde om den perfekte IT-løsning må ikke realiseres i ett og samme prosjekt. Del det opp!
• Manglende evne til å gjøre forbedringer. Går noe galt er man ofte blinde for å gjøre justeringer. Har man dårlig fremdrift bør man evaluere prosjektmetodikken. Har man mye feil bør man gå over kvalitetssikringen. Og så videre.
• Troen på at mer ressurser gir bedre resultat. Hva gjorde Trond Giske da Altinn opplevde sin berømte Kenneth-skandale i 2012? Han kastet 100 millioner kroner etter prosjektet. I 2013 gjentok problemet seg. Mer penger, mer mennesker, mer tid løser ikke nødvendigvis problemene dine.
• Den menneskelige faktor. Si at du har et team som leverer et bra prosjekt. Sett dem på et nytt prosjekt, hos en ny kunde, og det kan feile. Suksess handler også om mellommenneskelige relasjoner.
• Valg av løsning før behovet kartlegges. «Vi bygger det på SharePoint», «Jeg har god erfaring med Amazon EC2» eller «Windows Server har stor utbredelse i markedet». Man definerer løsningen før behovet er beskrevet. Definer behovet først, velg deretter verktøy som dekker behovet og skalerer for endringer i overskuelig fremtid.
• Manglende håndtering av risiko. Alle IT-prosjekter bør ha et forhold til risiko. Hvor tåler du feil? Hvor tåler du ikke feil? Ha et rasjonelt og realistisk forhold til hva som kan og vil inntreffe, og ta det med i prioriteringen av ditt arbeid.
• For dårlig testing. Er du ikke god nok til å teste, finner du ikke feil. Banalt, men enkelt. Testing er et eget fag. Sørg for riktig kompetanse og et godt testregime.
• Når godt nok ikke er godt nok. «Det beste er det godes fiende», skal Francois de Voltaire ha sagt. Det kan være greit å ha kontroll på når godt nok er godt nok. Hvis ikke ender du opp med å bruke 90 % av tiden på de siste 10 % av arbeidet.
• For komplekse organisasjoner Det finnes store organisasjoner med så spesielle behov at utvikling blir vanskelig. Om ikke organisasjonen lar seg bryte ned, bør i hvert fall utviklingen av nye IT-løsninger gjøre det.

Listen er som nevnt ikke uttømmende. Legg gjerne til flere eksempler på hvorfor IT-prosjekter feiler.

Det er også helt sikker at også undertegnede kommer til å feile i fremtiden. Tror du jeg klarer å kjøre slalåm mellom alle punktene over? «Fail Early, Fail Fast, Fail Often», heter det. Det prøver jeg å være bevisst på. Om jeg lykkes får vi se om nye 15 år, med nye erfaringer.

Generelt