Hva skal til for lykkes i ITprosjekter Hvor

Hva skal til for å lykkes i IT-prosjekter? Hvor mye og hvordan kan man lære av andres suksesser og fiaskoer? Magne Jørgensen Simula Research Laboratory Universitetet i Oslo Scienta “Skarru forstå dagens Oslo, så mårru forstå “What we learn from history is that gårsdagens Oslo. … Nåtida står på skulderne til fortida. people don’t learn from history. ” Støtta opp med noen stag…” (Kjell Aronsen (George Bernard Shaw) Oslolosen)

Et typisk IT-prosjekt … • Overskrider estimert timebruk med 20 -30%. • Har ca. 10% sannsynlighet for å bruke mer enn dobbelt så mange timeverk som estimert (mange black swans). • Har ca. 10% sannsynlighet for å bli stoppet eller å levere svært liten nytte for kunde (fiasko). • 5% sannsynlighet for å være svært vellykket på både nytte, teknisk kvalitet, budsjettkontroll og effektivitet. • 50% sannsynlighet for å være tilfredsstillende på både nytte, teknisk kvalitet, budsjettkontroll og effektivitet.

Den første årsaksanalyse ble til ansvarsfraskrivelse … Gud: “Har du ett av det tre som jeg forbød dig å ete av? ” Adam: “Kvinnen som du gav mig til å være hos mig, hun gav mig av treet, og jeg åt. ”

Årsaksanalyse er vanskelig, noen ganger svært vanskelig … • Fra NAV-høring om problemårsaker og risiko for Moderniseringsprosjektet • Mc. Kinsey: – “…. Det er ekstremt viktig at man ikke begynner å programmere eller iverksette dyrt utviklingsarbeid før man har helt klart for seg hva det er man skal løse. …. . Og hvis man ikke kan se hvordan IKT-systemene veldig klart og tydelig fører til at virksomheten blir bedre, må man for guds skyld ikke sette i gang. …. ” – “Vi har gjennomført forskning i samarbeid med Oxford-universitetet for å forstå hva som kjennetegner både mer og mindre vellykkede IKT-prosjekter. ” • Accenture: “…. kunden satt med et ansvar for å lage løsningsspesifikasjoner. …. I moderniseringsprogrammet var det ikke god kvalitet på dem …. ikke grunnlaget for å starte en effektiv produksjon av programvare til stede. ” • Oppsummert: – Journalist: – “Du som har sittet i utallige høringer før, har du noen gang vært så utrygg og forvirret før? ” – Martin Kolberg (leder for kontrollkomiteen): “Nei. ”

Hva er egentlig et årsak-virkning forhold? A er årsak til B dersom forekomsten av A (i kontekst C) øker sannsynligheten for å observere B, og det finnes mekanismer som kobler A og B (i kontekst C). Essens: Læring mhp årsaker til sukksess of fiasko bør være basert på forståelse av sannsynligheter (A fører ikke alltid til B), betinger en kontekst, og må støttes av forståelse av underliggende mekanismer.

EKSEMPEL PÅ LISTER AV HVA VI TYPISK ANGIR SOM ÅRSAKER TIL AT IT-PROSJEKTER FEILER

Min egen kolleksjon av fiaskofaktorer… • Overambisiøse mål – Forsøker å gjøre mange ting på en gang (erstatte mange systemer, ny arkitektur, mye ny funksjonalitet, …) • Prosjektet innebærer arbeid som er betydelig annerledes enn det aktørene har gjort før, f eks at det er mye større – Tidobling av størrelse ser ut til å doble risiko for fiasko • Problemet som skal løses er komplekst og/eller dårlig forstått • Lite fokus på nyttestyring (ikke minst underveis i prosjektet) • Mange interessenter og mange grensesnitt til andre systemer • Betydelig prosessendring er involvert • Kunde med liten/ingen IT-kompetanse • Lite relevant kompetanse hos leverandør • Tro på at hyllevare løser dine behov uten at du trenger å tilpasse deg til hyllevaren

Resultater fra seminar om nyttestyring • Størrelse (budsjett) og sektor (offentlig eller privat) var ikke viktig for oppnådd grad av nytte. • Prosjekter som (i stor grad) utarbeidet plan for realisering av nytte hadde dobbelt så høy andel av prosjekter som var svært vellykket mhp nytte enn andre prosjekter. • Prosjekter der IT-kompetanse hos kunde var høy, hadde neste dobbelt så høy suksessrate som andre prosjekter. Samme for prosjekter der andel av prosjekttimene utført av kunde var høy. • Ingen (!) fastprisprosjekter var svært vellykket mhp levert nytte, mens totalt sett ca. 35% av prosjektene var svært vellykket på nytte. – Prosjekter betalt per time gjorde det best, med ca. 55% av prosjektene som vellykket mhp nytte. Det var ingen store forskjeller i størrelse, type, aktør mellom prosjekter på fastpris, betalt per time eller andre avtaleformer.

Resultater fra seminar om nyttestyring • Prosjekter der kunde vektet lav pris ved valg av leverandør med minst 30% gjorde det dårligere (ca. 30% vellykket mhp nytte) enn prosjekter som vektla lav pris mindre enn 30% (ca. 50% vellykket mhp nytte). • Prosjekter som ble offshoret (det var ikke så mange, så tallmaterialet er tynt her) var i mindre grad vellykket enn prosjekter der alt arbeid ble utført i Norge (ca. 20% vs ca. 40% vellykket mhp nytte). • Prosjekter som brukte Scrum eller andre smidige metoder hadde ikke en større andel prosjekter som var vellykket mhp nytte. De hadde derimot en større andel som var vellykket mhp prosjektkontroll og prosjekteffektivitet. (Også her er datamaterialet noe tynt. ). • Hyppige leveranser (til kunde) og fleksibilitet i hva som leveres (som resultat av læring, endrede betingelser etc. ) var de to faktorene som var sterkest forbundet med høy grad av suksess på levert nytte.

Mc. Kinsey – Suksessfaktorer (Hva betyr faktorene, hva er kontekst? )

Svakheter med denne typen analyser og årsaksforklaringer • Mange av årsakene/rådene blir vage og/eller selvoppfyllende – Eksempel: Prosjektet bør ikke ha urealistiske mål. • Årsakene mangler kontekst og sannsynligheter – Når er de viktige og hvor viktige? – Mange prosjekter har gjort svært mye feil, og likevel lykkes. Hvorfor? • Mange årsaker mangler god forståelse av underliggende mekanismer • Noen av risikofaktorene er også suksessfaktorer (uten å “speilvende” de) – Krav/behovsforståelse som endrer seg undervis er for eksempel både trussel og mulighet • Verden er et nettverk av årsaker – Hvor meningsfullt er det å trekke ut en og en faktor? – Klarer vi å beskrive årsaksnettverk?

MER PROBLEMER …. . VI ER IKKE VELDIG GODE TIL Å AVDEKKE KOMPLEKSE ÅRSAKSSAMMENHENGER

Tilfeldighet kan være vanskelig å avdekke ”. . . glow worms are gluttonous and inclined to eat anything that comes within snatching distance, so they keep their distance from each other and end up relatively evenly spaced i. e. non-randomly. ” (Hentet fra: Steven Pinker, The better angels of our nature: why violence has declined. Observations reported in Gould, 1991)

ORGOL (ORGanizational Over. Learning) • Et sterkt ønske om å lære fra (f eks smertefull) erfaring går ikke alltid sammen med gode muligheter for læring. – F. I. Steele: Organizational overlearning, Journal of Management Studies, 1971. • Eksempel: Store offentlige utredninger/høringer om IT-prosjekter som har feilet. – Tolkninger trekkes med svært ufullstendig argumentasjon. Lite sammenligning med prosjekter som lykkes, som også gjør mye feil. – Uklart hvor mye det er å lære fra store fiaskoprosjekter, siden konteksten vil endre seg mye fra gang til gang. – Ikke minst vil en del mennesker ha lært fra smertefull erfaring og samme risikofaktor vil håndteres bedre.

Vi ser de mønstrene vi forventer å se … • To undersøkelser: 1. Tilfeldige data om utfallet av “tradisjonelle” og “smidige” prosjekter. 2. Tilfeldige data om utfallet av “fastpris” og “per time”-betalte prosjekter. • Steg 1: “Hva tror du er effekten av …. . ”? • Steg 2: “I hvilken grad gir prosjektdata støtte for …? ” • Resultat: Sterk tendens til å finne støtte for det man tror vil være effekten, selv når data er tilfeldige og uten mønster. – Effekten trolig enda større i realistiske situasjoner med mer rom for tolkning og subjektivt utvalg av variable.

Andre læringsproblemer • Årsaker til fiasko finnes hos andre (ref. årsaken til at Adam og Eva måtte flykte fra Paradis), suksess skyldes egen kompetanse. • Vi tror vi visste mer og ting så annerledes ut enn det som faktisk var tilfelle når vi ser oss tilbake (etterpåklokskap).

De fleste årsaksanalyser vi presenteres er basert på subjektive, lokale vurderinger og svært utsatt for bekreftelsesskjevhet • Påstand i IT-firma: Viktig årsak til overskridelser og lav kundefornøydhet er uklare og ustabile krav fra kunden. – Mekanismer som IT-firmaet observerte var: Re-work, scope creep, mye arbeid til avklaringer, …. • Vi fant imidlertid det stikk motsatte da vi gikk gjennom prosjektene! Det var de best spesifiserte systemene som typisk hadde de største overskridelsene! • Uklare og ustabile krav ga noen problemer, men syntes i enda større grad å gi fleksibilitet i hva som ble levert og mulighet til å endre innhold i henhold til ny forståelse og prioriteter etterhvert. – Undersøkelser tyder på at en del fleksibilitet i krav (med god nyttestyring) gir størst nytte for kunde • Noe av problemet er å se hele konteksten og alle årsakene under ett, samt å vite hvordan noe hadde vært dersom noe annet hadde vært tilfelle (kontrafaktuell tenkning).

Men helt håpløst er det ikke … HVA KAN VI GJØRE FOR Å BLI BEDRE TIL Å LÆRE AV ERFARING?

Ingen enkle grep, men vi trenger … • Mer prosjektdata for å se sammenhenger. Sammenligninger bør omfatte prosjekter som lykkes og ikke lykkes. • Mer kontekst for å se gyldighetsområde. Ikke minst bør ulike typer av kompetanse vektlegges tungt for å forstå sammenhenger. • Mer dybdeanalyse for å forstå mekanismene. Mer fokus på kjerneårsaker og ikke kun de direkte årsakene. • Mer respekt for kompleksiteten i årsakssammenhenger I IT-prosjekter. Av og til er det svært lite å lære, eller det som kan læres har liten overføringsverdi til andre prosjekter. • Bedre kunnskap om innhenting av praksisbaserte erfaringer. Alle påstander om årsakssammenhenger bør følges opp av spørsmål om hva påstanden bygger på (evidensbasert tenkning).

Et eksempel … • Forskning som sammenligner IT-prosjekter som har lykkes godt med de som har lykkes dårligere tyder på at: – Fastpris gir lavere nytte til leveransene – Utviklingsmetode som legger opp til fleksibilitet i prioriteter og krav gir økt nytte – Fokus på lav pris ved valg av leverandør gir høyere risiko for prosjektfiasko – Lav kundekompetanse gir risiko for prosjektfiasko • Dette gir et bra utgangspunkt for å se på: – Hvilke kontekster dette gjelder i. Ser for eksempel ut som om noen prosjekter klarer å lykkes gjennom å ha svært god kompetanse på ledelse og svært gode systemutviklere. – Hva de underliggende mekanismene er. Eksempel: Mekanismer som forklarer årsak-virkning mellom kundens fokus på lav pris og økt risiko for prosjektproblemer (se neste slide).

Eksempel: Årsaksmekanismer som kan forklare sammenhengen mellom fokus på lav pris ved valg av leverandør og prosjektproblemer Kontekst: Særlig stor risikoøkning når kunde ikke er god på evaluere leverandørkompetanse, når kunde ikke er god på spesifisere/evaluere kvalitet og i mer kortsiktige kunde/lev. -forhold.

Oppsummert • Mye lite innsiktsfull og lite nyttig oppsummering av suksess og fiaskofaktorer. Svært mye synsing. Sterk bekreftelsestendens. • Viktig å innse at det ofte er lite å lære fra enkeltstående fiaskoer og suksesser. • Årsak-virkning må baseres på økning/reduksjon i sannsynlighet for å lykkes, årsaks-nettverk (med fokus på kjerneårsaker), samt forståelse av underliggende mekanismer. • Vi trenger større sammenligninger av IT-prosjekter som lykkes og de som ikke lykkes OG dybdeanalyser av årsaksmekanismer (OG sunn fornuft) for å få god læring fra erfaring. (Både Oslolosens ”gårsdagens Oslo” og Bernhard Shaw’s skepsis til erfaringslæring. )

Root Cause Analysis Hvis årsakvirkning analyse og læring fra erfaring bare hadde vært så enkelt som her ….

Håndtering av all risiko gir suksess? (fra Difis veileder for risikostyring) ? Suksess

Mc. Kinsey’s Oxford research (Hvor mye kan vi lære av spørreundersøkelser? )

Noen variable er viktigere enn andre, men er likevel ofte ikke del av årsaksanalysen … • Diskusjonen om årsaker går ofte på metoder, kontrakttyper, kvalitet på kravanalyse og andre relativt “upersonlige” faktorer • Vi vet imidlertid at faktoren som virkelig teller er kompetansen til leverandør og kunde. – Jo vanskeligere et prosjekt er, jo mer teller slik kompetanse. – Kompetanse til kunde synes å telle så å si like mye som kompetanse til leverandør • Prosjekter med dyktige mennesker kompenserer for mange mangler i metode og utgangspunkt, men neppe alle. • Hvordan modellere/beskrive/forstå disse sammenhengene?