Suksess med offentlige IT-prosjekter Suksess med offentlige IT-prosjekter. Hva er det og hvordan får vi det til? 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

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

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 (Undersøkelse av norske prosjekter fra 2014) 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 og effektivitet – som burde telle mer!

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

Før jeg går videre. En 5-minutters undersøkelse som vil bli oppsummert i løpet av seminaret (eller ettersendt i kveld): Bruk smartphone eller laptop, gå inn på linken nedenfor, og svar på to-tre spørsmål: tinyurl.com/ehelse

prosjektstørrelse

Tenk stort – start smått Jan Tore Sanner: Stortingsmelding 27 Digital agenda for Norge

Bør vi unngå de store prosjekter? < 10 mill 10-100 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.

kontrakter

Har kontrakttype noe å si Har kontrakttype noe å si? (% prosjekter med suksess på angitt faktor - noen anga mer enn en type kontrakt) Fastpris Per time ”Smidig” Risikodeling 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. Ingen store forskjeller i prosjektstørrelse eller prosjekttype for ulike kontraktstyper.

Tidligere undersøkelse (Små prosjekter, offshoring) Kontrakt-type Antall prosjekter Fiaskorate (kansellert eller med svært lav kundefornøydhet) Fastpris 408.491 12% Per time 2.338 2% ”Trialsourcing” + per time 1.133 0.1%

Oppsummering av 35 offentlige IT-prosjekter: Fastpris gir oftere oppførsel og kundestyring etter kravspesifikasjon (kontrakt), og mindre etter nytte FASTPRISOPPFØRSEL!!!

”Opplevd” kontraktsform vs prosjektutfall Fastprisoppførsel er skadelig! Gikk bra Problemer på minst ett område Store problemer/ stoppet Kommentar til ”store problemer” Per time 15 3 1 Intern-prosjekt. Teknologiproblemer Fastpris 4 Typisk: Målpris med ”cut” og underestimert Kombinert 6 Data fra SMIOS-prosjektet (dybdeanalyse av 35 offentlige IT-prosjekter): Per time-opplevelse: Enten ren per time eller målpris som i praksis ble oppfattet som nær en per-time betaling (fast % ved overskridelse + estimering av godt kjente leveranser med liten usikkerhet og/eller stor fleksibilitet). Fastpris-opplevelse: Enten en ren fastpris eller målpris som i praksis ble oppfattet som nær fastpris (trinnvis % og endringer utenfor). Gjerne i sammenheng med målpris med tak + sterk underestimering. Kombinert: Stor grad ytelsesbasert (3) eller fastpris (ofte på lite prosjekt) med store utvidelser betalt per time (3). Et eksempel på målpris uten tak som likevel ble oppfattet som fastpris er SPK-Min side medlem (Men scope ser ut til å være fleksibelt). Senere i prosjektet gått over til ren per time.

Fastpris gir dessuten mer administrasjon Ahonen, Jarmo J. , et al Fastpris gir dessuten mer administrasjon Ahonen, Jarmo J., et al. "Reported project management effort, project size, and contract type." Journal of Systems and Software 109 (2015): 205-213. 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 grad I liten grad/fraværende Nytte 67% (suksessrate) 21% Kvalitet 53% 13% Budsjett 47% 27% Tid 33% 25% Effektivitet 10% Endringer bør sees på som muligheter, planlegges for (smidig) og ikke anses som trussel (ref. ”scope creep”-holdning).

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.

Den gode kunde

Undersøkelser av 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 var tett involvert i å: 1) Prioritere krav og ta viktige avgjørelser underveis og 2) Fokusere på nyttestyring underveis i prosjektet, lyktes 66% av prosjektene svært godt. Der ingen av disse var tilstede i vesentlig grad, lyktes kun 14% av prosjektene svært godt.

viktigheten av å velge en kompetent leverandør - et eksperiment

Felt-eksperiment: Valg av seks leverandører som alle så ca 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.

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) Utprøving (trialsourcing, erfaringer fra tidligere prosjekt hos samme kunde, proof of concept) best egnet til å avdekke hvilke leverandører (og utviklere) som er kompetente. Referanser ikke valgt av leverandør også verdifullt. Resten - CV, tilbudsdokument, pris, selvoppgitte referanser, intervjuer - gir mye mindre verdi.

Nyttestyring

Noen nyttestyring-praksiser er mer viktige enn andre

Evidensbaserte tiltak for å lykkes Oppdeling av større satsninger i mindre prosjekter/leveranser. Hyppige leveranser til produksjon (i det minste til grundig evaluering og feedback). 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, f eks trialsourcing. Kontraktstyper som gir riktige insitamenter for leverandør. Unngå fastpris og målpris med øvre tak. Omfattende medvirkning og god kompetanse fra kunde-siden underveis i prosjektet. Gjelder særlig på underveis prioriteringer og nyttestyring. Utviklingsprosesser som planlegger for og ser endringer i krav og målsetninger som muligheter for økt nytte av IKT-leveransene. Vektlegging av risiko og usikkerhetsanalyser for å skape risikobevissthet hos involverte aktører, god risikostyring og sikre at ambisjonsnivå ikke legges for høyt

ekstra

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 2012. Hvorfor klarer vi ikke å lære av tidligere feil? Hva betyr faktorene? Og er det de riktige faktorene?

Noen IT-kunder lykkes oftere enn andre IT-Offshoring (undersøkelse av 785.000 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.

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