Maleri av: Carrie Jackson

Presentasjon om: "Maleri av: Carrie Jackson"— Utskrift av presentasjonen:

1 Maleri av: Carrie Jackson
Hva skiller IT-prosjekter som lykkes fra de som mislykkes? Hva vil det si å lykkes? Suksess med IT-prosjekter. Hva er det og hvordan får vi det? Tekst: Et prosjekt som er på tid, budsjett og med leverer avtalt funksjonalitet er ikke nødvendigvis vellykket. De to viktigste faktorene mangler: Nytte for kunde/brukere og effektivitet i arbeidet. I denne presentasjonen går jeg gjennom hvor godt norske og andre IT-prosjekter presterer på ulike suksessfaktorer, hva som er indikatorer på om et prosjekt lykkes eller ikke, samt hvilke evidensbaserte tiltak vi har for å bedre gjennomføringsevnen. Magne Jørgensen Simula og Scienta

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

3 Hva vil det si å lykkes? Historien er ikke der, men skrives … Dersom man ikke er villig til å feile, så lykkes man heller ikke med noe viktig ... Alle disse (kanskje også Nav-modernisering etterhvert) kan sees på som suksesser.

4 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)

5 Korrelasjon mellom suksessdimensjoner (Studie fra 2014: 80 norske prosjekter)
Skala: 1: Suksess - 2: Akseptabelt - 3: Lav suksess - 4: Svært lav suksess/fiasko Nytte Kvalitet Budsjett Tid 0.6 0.2 0.3 0.5 Effektivitet 0.4 0.8 Budsjettoverskridelse får ofte mest fokus, men korrelerer lite med nytte!

6 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).

7 Når er det vi feiler mest? Oppsummert fra mange undersøkelser
Vi gjør noe vi ikke har gjort før (større, ny teknologi, …) Mange grensesnitt til andre systemer og/eller mange interessenter Innebærer mye prosessendring hos brukere Komplekse problemer skal løses Svært høyt ambisjonsnivå (f eks at man bruker en stor IT-investering til også å endre plattform, arkitektur og masse ny funksjonalitet) Estimeringssituasjon stimulerer til over-optimisme (ankere, ønsketenkning, ”halo-effekt” m.m.) Lav kompetanse til kunde/bestiller Lav kompetanse til utviklingsteam Valg av leverandør og kontraktsform fører til ”winner’s curse” og ”adverse selection” Valg av utviklingsmodell/kontrakt som medfører at endringer anses som trusler og ikke som muligheter

8 To typiske undersøkelser om årsaker til at IT prosjekter mislykkes
Gotterer 1967 Oxford-McKinsey 2012 Lack of support from top management Lack of competent software professionals Changing technology Changing user requirements Insufficient project management 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? Hva betyr faktorene? Og er det de riktige faktorene?

9 Indikatorer på prosjekter med særlig høy risiko for å få problemer
Vi gjør noe vi ikke har gjort før (større, ny teknologi, …). For hver nytt element, eksponensielt høyere risiko. Mange grensesnitt til andre systemer og/eller mange interessenter Innebærer mye prosessendring hos brukere Høyt ambisjonsnivå (mega-prosjekter, løsninger ingen andre har forsøkt/lykkes med tidligere) Komplekse tekniske problemer må løses Estimeringssituasjon stimulerer til over-optimisme (ankere, ønsketenkning, ”halo-effekt” m.m.) Lav kompetanse til kunde/bestiller Lav kompetanse til utviklingsteam Valg av leverandør/prosjekt fører til ”winner’s curse” og ”adverse selection” Valg av utviklingsmodell/kontrakt som ser endringer som trusler og ikke som muligheter

10 prosjektstørrelse

11 Bør vi unngå de store prosjekter?
< 10 mill mill > 100 mill Nytte 31% 47% 35% Kvalitet 24% 28% 25% Budsjett Tid 29% Effektivitet 12% 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. Går jeg litt i egen felle nå – siden jeg bruker budsjettet som variabel.

12 kontrakter

13 Har kontrakttype noe å si? (noen anga mer enn en type kontrakt)
Fastpris Per time ”Smidig” Målpris Nytte 0% 59% 29% 22% Kvalitet 24% 43% Budsjett 33% 31% 71% Tid 11% 44% Effektivitet 19% Andel 18% 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.

14 Tidligere undersøkelse (data fra mer enn 400.000 små prosjekter)
Kontrakt-type Antall prosjekter Fiaskorate (kansellert eller med svært lav kundefornøydhet) Fastpris 12% Per time 2.338 2% ”Trialsourcing” + per time 1.133 0.1%

15 Hvorfor går det så mye dårligere med fastprisprosjektene
Hvorfor går det så mye dårligere med fastprisprosjektene? (Forskjeller mhp seleksjon, kundeoppførsel og leverandøroppførsel)

16 Foreløpig oppsummering av 30+ offentlige IT-prosjekter:
Fastpris gir oftere styring etter kravspesifikasjon (kontrakt), og mindre etter nytte

17 Fastpris gir mer administrasjon … Ahonen, Jarmo J. , et al
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

18 kravhåndtering

19 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 grad I liten grad/fraværende Nytte 67% (suksessrate) 21% Kvalitet 53% 13% Budsjett 47% 27% Tid 33% 25% Effektivitet 10% Endringer som muligheter, ikke som trussel. Korrelerer med god bruk av smidig. Vanskeligere å få til med fastpris.

20 Hjelper det å jobbe smidig?
Interestingly, when projects claimed to be based on an agile method, but did not have a flexible scope, the success rate on client benefit was as low as 25%, i.e., lower than the average success rate of the projects. In comparison, the agile projects with flexible scope had a success rate of 42%. Similarly, when projects claimed to follow an agile method, but did not have frequent deliveries to client, the success rate on client benefit was as low as 22%, again lower than the total average. In comparison, the agile project with frequent delivery to client had a success rate of 45%. 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.

21 Den gode kunde

22 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.

23 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.

24 leverandørkompetanse

25 Et felt-eksperiment: Valg av seks leverandører som alle så ca
Et felt-eksperiment: Valg av seks leverandører som alle så ca. like bra ut på CV, referanser og tilbudsdokumenter. Kjempeforskjeller i pris. Comp. A Comp. B Comp. C Comp. D Comp. E Comp. F Price Very low Low (2x) Medium (3x) High (5x) Very high (12x) Very high (14x) Est. effort Low (1.5x) High (8x) Medium (4x) Very high (8x) CV OK Good Refs. Very good Proposal Country Finland Malaysia India Canada US NB: You can still work agile.

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

27 Nyttestyring

28 Noen nyttestyring-praksiser er mer viktige enn andre

29 Evidensbaserte tiltak for å lykkes
Reduksjon i prosjektstørrelse, og dermed ambisjonsnivå per prosjekt, gjennom oppdeling av større satsninger i mindre prosjekter/leveranser. Hyppige leveranser (helst som kan settes i produksjon, men i det minste evalueres) underveis i prosjektene. Gjennomgående nyttestyring, fra konseptanalyse, gjennom prosjektet og hos mottager av leveransene. Særlig viktig: Plan for og underveis nyttestyring. Bedre, utprøvingsbaserte, evalueringer og valg av leverandører. Trialsourcing. 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. Omfattende medvirkning og god kompetanse fra kunde-siden underveis i prosjektet. Gjelder særlig på underveis prioritering og nyttestyring. Utviklingsprosesser som ser endringer i krav og målsetninger som muligheter for økt nytte av IKT-leveransene. Dette omfatter bruk av ”smidige” utviklingsprosesser. Vektlegging av risiko og usikkerhetsanalyser for å skape risikobevissthet hos involverte aktører, god risikostyring og sikre at ambisjonsnivå ikke legges for høyt