Hva skiller IT- prosjekter som lykkes fra de som mislykkes? Hva vil det si å lykkes? Magne Jørgensen Simula og Scienta Maleri av: Carrie Jackson

92% av alle IT- prosjekter er mislykkede … eller hvilken som helst annen prosentandel avhengig av hvordan vi definerer mislykket.

Hva vil det si å lykkes?

Suksess er kontekstavhengig, men ofte en prioritert kombinasjon av: Levert nytte (gevinster, måloppnåelse, ROI) Prosjekteffektivitet Funksjonalitet Kostnadskontroll Tidskontroll Tekniske produktegenskaper (kvalitet, utvidbar, bærekraftig)

Korrelasjon mellom suksessdimensjoner (Studie fra 2014: 80 norske prosjekter) NytteKvalitetBudsjettTid Kvalitet0.6 Budsjett0.2 Tid Effektivitet Budsjettoverskridelse får ofte mest fokus, men korrelerer lite med nytte! Skala: 1: Suksess - 2: Akseptabelt - 3: Lav suksess - 4: Svært lav suksess/fiasko

Hvor gode er vi til å levere nyttige løsninger? Ca. 10% av IT-prosjektene fører til ingen eller svært liten nytte (Nasjonale og internasjonale tall fra flere kilder) Ca. 15% av IT-prosjektene oppfattes å levere mye mindre nytte enn planlagt. (Nasjonal undersøkelse) Ca. 50% leverer oppfattes å levere bra mhp nytte. (Nasjonal undersøkelse) Ca. 25% av IT-prosjektene har ikke noe klart nytte/mål-bilde å måle opp mot. (Nasjonal undersøkelse) I gjennomsnitt leveres ca. 30% mindre nytte enn planlagt (internasjonale tall fra Oxford-undersøkelse).

To typiske undersøkelser om årsaker til at IT prosjekter mislykkes Gotterer 1967 Lack of support from top management Lack of competent software professionals Changing technology Changing user requirements Insufficient project management Oxford-McKinsey 2012 Unclear objectives Lack of business focus Shifting requirements Technical complexity Unaligned team Lack of skill Unrealistic schedule Mye av de samme faktorene i 1967 som i Hvorfor klarer vi ikke å lære av tidligere feil? Og er det de riktige faktorene?

prosjektstørrelse

Bør vi unngå de store prosjekter? < 10 mill mill> 100 mill Nytte31%47%35% Kvalitet24%28%25% Budsjett24%47% Tid29%35% Effektivitet24%12%24% Ingen klar sammenheng mellom budsjett-størrelse og andel prosjekter som er suksessfulle. MEN, de store (> 100 mill) er sterkt overrepresentert i gruppen av fiaskoprosjekter! (2-3 ganger hyppighet) I en annen studie finner jeg at en tidobling av størrelsen dobler risikoen for fiasko.

KONTRAKTER

Har kontrakttype noe å si? (noen anga mer enn en type kontrakt) FastprisPer time”Smidig”Risikodeling Nytte0%59%29%22% Kvalitet22%24%43%22% Budsjett33%31%71%22% Tid11%29%43%44% Effektivitet0%19%29%33% Andel18%37%14%41% NB: Lite data om noen av kontraktstypene. Fastpris gjør det svært dårlig. Stemmer med annen studie jeg har gjort. Ingen store forskjeller i prosjektstørrelse eller type for ulike kontraktstyper.

Tidligere undersøkelse (data fra mer enn små prosjekter) Kontrakt-typeAntall prosjekter Fiaskorate (kansellert eller med svært lav kundefornøydhet) Fastpris % Per time2.3382% ”Trialsourcing” + per time %

Hvorfor går det så mye dårligere med fasprisprosjektene?

FASTPRIS GIR OFTERE STYRING ETTER KRAVSPESIFIKASJON (KONTRAKT), OG MINDRE ETTER NYTTE Foreløpig oppsummering av 30+ offentlige IT-prosjekter:

Fastpris gir mer administrasjon … Ahonen, Jarmo J., et al. "Reported project management effort, project size, and contract type." Journal of Systems and Software 109 (2015): Fixed price Per hour

kravhåndtering

Endringshåndtering og suksessrate I hvilken grad ble behov, krav eller løsninger endret underveis i prosjektet som et resultat av eksterne endringer eller læring innad i prosjektet? I stor gradI liten grad/fraværende Nytte67% (suksessrate)21% Kvalitet53%13% Budsjett47%27% Tid33%25% Effektivitet33%10% Endringer som muligheter, ikke som trussel. Korrelerer med god bruk av smidig.

Hjelper det å jobbe smidig? NB: Dersom et prosjekt var ”smidig” men IKKE hadde fleksible leveranser, eller IKKE hadde hyppig leveranse til kunde, gikk det dårligere enn i ikke-smidige prosjekter.

DEN GODE KUNDE

Noen IT-kunder lykkes oftere enn andre IT-Offshoring (undersøkelse av småprosjekter): –Den halvparten av kundene som hadde lykkes best med tidligere prosjekter, hadde ca. 50% lavere risiko for å feile i neste prosjekt. –Den halvparten av leverandørene som hadde lykkes best med tidligere prosjekter, hadde også ca. 50% lavere risiko for å feile i neste prosjekt. –Kundeegenskaper like viktige som leverandøregenskaper? Stor ulikhet mellom hvor ofte kunder fra ulike land/kulturer feiler (data fra samme offshoring-undersøkelse) –Leverandør i Ukraina: Prosjekter med indisk kunde feilet mer enn dobbelt så ofte som prosjekter med norsk kunde (30% vs 13%) –Leverandør i India: Prosjekter med indisk kunde feilet ca. 25% oftere som prosjekter med norsk kunde (37% vs 29%) – til tross for ”samme” nasjonale kultur. –India-India kombinasjonen var den 122. verste av 127 kunde- leverandørkombinasjoner (mellom land med mer enn 100 prosjekter). Verste var kunde fra Malaysia og leverandør fra India.

Undersøkelser i HIT-regi (norske prosjekter) Undersøkelse 1: Lite kundekompetanse eller involvering ga mye høyere sannsynlighet for å feile –Alle de mislykkede prosjektene hadde en kunde uten særlig grad av egen IT-kompetanse og/eller en kunde som i liten grad hadde involvert seg i prosjektet. (Flere andre lignende resultater) –Men, høy kompetanse og involvering var i seg selv ingen god indikator på prosjektsuksess! Undersøkelse 2: Type kompetanse og involvering (mer enn omfang av kompetanse og involvering) telte mest for å forklare hvilke kunder som hadde svært vellykkede prosjekter: –Dersom kunden hadde vært i stand til å: 1) Prioritere krav, 2) Ta viktige avgjørelser, og 3) Fokusere på nyttestyring underveis i prosjektet lyktes 66% av prosjektene svært godt. –Der ingen av disse var tilstede, lyktes kun 14% av prosjektene svært godt.

leverandørkompetanse

Et felt-eksperiment: Valg av seks leverandører som alle så ca. like bra ut på CV, referanser og tilbudsdokumenter. Kjempeforskjeller i pris. Comp. AComp. BComp. CComp. DComp. EComp. F PriceVery lowLow (2x)Medium (3x) High (5x)Very high (12x) Very high (14x) Est. effortVery lowLow (1.5x) Medium (3x) High (8x)Medium (4x) Very high (8x) CVOK Good OK Refs.Very good ProposalOK GoodOK CountryFinlandMalaysiaIndia CanadaUS

Svært store forskjeller i praksis… Comp. A Comp. B Comp. CComp. DComp. EComp. F Actual effortVery low Low (3x) High (6x)High (8x)Very high (18x) Very high (16x) Error fixing effort Very low High (4x) Medium (2.5x) High (4x)Very high (8x) Extr. high (20x) Maintenanc e effort Very low High (6x) Very high (11 x) High (8x)Extr. high (26x) Extr. high (20x) Lines of code Very low Low (2x) Low (1.5x) Medium (3x) High (4x)Low (1.5x) Trolig kun utprøving (trialsourcing) som kan avdekke hvilke leverandører (og utviklere) som er kompetente.

NYTTESTYRING

Noen nyttestyring-praksiser er mer viktige enn andre

Evidensbaserte tiltak for å lykkes 1.Reduksjon i prosjektstørrelse, og dermed ambisjonsnivå per prosjekt, gjennom oppdeling av større satsninger i mindre prosjekter/leveranser. 2.Hyppige leveranser (helst som kan settes i produksjon, men i det minste evalueres) underveis i prosjektene. 3.Gjennomgående nyttestyring, fra konseptanalyse, gjennom prosjektet og hos mottager av leveransene. Særlig viktig: Plan for og underveis nyttestyring. 4.Bedre, utprøvingsbaserte, evalueringer og valg av leverandører. Trialsourcing. 5.Kontraktstyper som gir riktige insitamenter for leverandør. I særlig grad synes fastprisprosjekter i mange sammenhenger å være uegnet og føre til mindre grad av levert nytte i IKT-prosjekter. Fastpris eller smidige kontrakter best. 6.Omfattende medvirkning og god kompetanse fra kunde-siden underveis i prosjektet. Gjelder særlig på underveis prioritering og nyttestyring. 7.Utviklingsprosesser som ser endringer i krav og målsetninger som muligheter for økt nytte av IKT-leveransene. Dette omfatter bruk av ”smidige” utviklingsprosesser. 8.Vektlegging av risiko og usikkerhetsanalyser for å skape risikobevissthet hos involverte aktører, god risikostyring og sikre at ambisjonsnivå ikke legges for høyt