26/04/16 Maleri av: Carrie Jackson SMIOS-prosjektet: Magne Jørgensen Parastoo Mohagheghi Stein Grimstad Hva kjennetegner ITprosjekter som lykkes? SMIOS-prosjektets oppgave Finne kjennetegn til de IT-prosjekter (IT-utvikling) som lykkes best: Finnes det klare, ikke-trivielle sammenhenger? I hvilke kontekster gjelder sammenhengene? Gi evidens-baserte råd Styrke evnen til å gjennomføre IT-prosjekter i offentlig sektor Publisere/spre kunnskap: For presentasjoner (inkludert denne), publikasjoner og vitenskapelige artikler se: hitledelse.com/smios/publikasjoner/ 1
26/04/16 SMIOS-prosjektets faser Plan (faser): Fase 1: April 2015-April 2016: Innsamling av data for å generere hypoteser om sammenhenger Fase 2: April 2016 Høst 2017: Undersøkelse av utvalgte sammenhenger Fase 3: Høst 2017 April 2018: Spredning av kunnskap (løpende aktivitet med ekstra fokus i siste fase) Resultatene fra SMIOS/HIT har allerede påvirket! Jan Tore Sanner: Stortingsmelding 27 Digital agenda for Norge 2
Agenda for i dag Gjennomgang av funn i undersøkelsen Diskusjoner/innspill/spørsmål tas underveis Veien videre Hvilke tema/sammenhenger bør vi fokusere på? Hvem er interessert i å delta på hvilke tema? Hvem kan/vil bidra med erfaringer/prosjektdata/undersøkelser/ eksperimenter på hvilke tema? Tilbud til alle partnerne i SMIOS: Vi tar gjerne presentasjon av resultatene fra undersøkelse, med råd om hvordan lykkes med IT-prosjekter, lokalt hos dere (fagmøter m.m.). Frokostseminar 31. mai om Hvordan identifisere og redde et prosjekt i nød, blant annet med presentasjon av den internasjonalt ledende forskeren på området (Mark Keil) og erfaringer fra Lånekassen. Undersøkelsen: 35 1 IT-prosjekter/leveranser Prosjekter fra: Lånekassen Statens Pensjonskasse Skatteetaten NAV NSB Posten Difi Oslo Kommune Asker kommune Sykehuspartner UDI 1: Ett prosjekt ikke evaluert ennå, dvs 34 prosjekter i analysen av hvordan det gikk. For hvert prosjekt har vi intervjuet representanter fra rollene: Bestiller Prosjekt-ledelse Mottager Gått gjennom annen informasjon: Erfaringsrapporter Evalueringer Estimeringsmodeller Kost-nytteanalyser m.m. Utgangspunkt: 2-4 siste prosjekter 3
Resultater må tolkes med forsiktighet Kontekstavhengighet For få data til å trekke sterke konklusjoner Probabilistiske sammenhenger Ofte vanskelig å vite hva som er korrelasjon og hva som er årsak-virkning Vi trodde analysen kom til å bli vanskelig. Og det ble den! Om prosjektene Prosjekttyper (basert på hvor hovedvekt av arbeidet lå) Nytt system: 17 Videreutvikling: 6 Innføring/tilpasning av hyllevare : 6 Nytt system og videreutvikling: 5 Annet (innføringsprosjekt): 1 Prosjektformål (ett prosjekt kan ha flere formål): Modernisering og effektivisering (27) Regelendring og lovkrav (12) Nye produkter (3) 4
Om prosjektene Kontraktstyper: Fastpris: 4 Hoveddel fastpris: 1 Liten del fastpris, store utvidelser per time betalt: 3 Målpris: 16 Med øvre grense: 9 Uten øvre grense: 7 Per time: 12 Ytelsesbasert/annet: 3 Prosjektmodell: Vannfalls: 2 Fast omfang/smidig konstruksjon: 12 Fleksibelt omfang/ smidig konstruksjon: 15 Inkrementell: 6 Om prosjektene Produksjonssetting i løpet av prosjektet: Én leveranse: 13 To til fire leveranser: 9 Hyppige/kontinuerlige leveranser: 13 Stor variasjon i kompleksitet i IT-utviklingen mhp: Koordineringsbehov (antall interessenter) Antall parallelle initiativ i organisasjonen (prioritet) Antall mennesker involvert Antall systemer involvert Kundekompetanse og involvering 5
Om prosjektene: Hvordan gikk de? Nytte: Mer nytte enn planlagt: 7 Nytte omtrent som planlagt: 18 Mindre nytte enn planlagt: 4 Uten nytte (kansellert): 2 Vet ikke ennå: 3 Kostnadskontroll Litt under budsjett: 7 Ca. på budsjett: 13 Litt over budsjett: 5 Mye over budsjett: 7 Kansellert: 2 Kostnad Gjennomsnitt: ca. 170 mill. (Median: ca 40 mill.) Interninnsats (av total arbeidsmengde): Typisk over 50% (varierer fra 20-100%) Om prosjektene: Hvordan gikk de? Tidskontroll: Ca som planlagt: 22 Senere enn planlagt: 7 Mye senere enn planlagt 3 Kansellert: 2 Varighet: Median varighet ca. 1.5 år (mellom 0.5 og 4 år) Omfang levert: Mye mer enn planlagt: 2 Mer enn planlagt: 9 Som planlagt: 14 Mindre enn planlagt: 6 2 av disse var problemprosjekter, der også nytte ble redusert 4 av disse gikk bra. Annen funksjonalitet kom inn i stedet og nytte ble beholdt Kansellert: 2 Vet ikke: 2 6
Om prosjektene: Hvordan gikk de? Kvalitet: Ingen eller få kvalitetsproblemer: 25 Kvalitetsproblemer eller vesentlig teknisk gjeld: 7 Kansellert: 2 Ulik grundighet i hvordan kvalitet ble evaluert Produktivitet: Absolutt produktivitet ikke målt av noen prosjekter Flere (minst to) initiativ på gang i offentlig sektor for å bli bedre på dette viktige feltet! Flere har underveisevaluering av leveranser i forhold til plan ( earned value, burndown charts ) og måling av produktivitetsendringer underveis i prosjektet (f eks velocity ) Totalt: Bra score på alle fem kriteriene (nytte, kost, tid, funksjonalitet og kvalitet): 16 Problemer med med minst ett av kriteriene: 18 Forbløffende mye suksesser! Kan det være noe med utvalget vårt/ analysen vår, eller er dette representativt? Om prosjektene: Hvordan gikk de? Totalt sett gikk ca. 70% av prosjektene bra! Bra : 25 Prosjektet har lykkes med å levere planlagt nytte og ikke hatt store problemer på noen av de andre suksessdimensjonene (tid, kost, kvalitet, omfang) Problemer : 5 Prosjektet har hatt vesentlig problemer på minst en av suksessdimensjonene Store problemer/stoppet : 5 Prosjektet har hatt meget store problemer på minst en av suksessdimensjonene 7
Temaer for resten av presentasjonen Suksessfaktorer, utfordringer og læring Kontraktstyper Ressursstyring, leverandørvalg, involvering, kompetanse Utviklingsprosessen (inklusiv nyttestyring) Overlevering til linje/forvaltning SUKSESSFAKTORER, UTFORDRINGER OG LÆRING 8
Hva oppleves å være viktig for å lykkes? 216 suksessfaktorer ble nevnt Fem på topp type suksessfaktorer var: Involvering/samarbeid/dialog (26%) Kompetanse bestiller (12%) Kompetanse leverandør (12%) Prioritet til prosjektet (12%) Ressursstyring (12%) Nyttestyring, oppstartsfasen (estimering, risikoanalyse, konseptfase) og egenskaper ved utviklingsprosessen (smidig, test, m.m.) var hakk i hæl. Mye fokus på organisering og kommunikasjon, lite fokus på teknologiske og arkitektur-messige valg. Faktorene er trolig påvirket av at vi i større grad har spurt kundesiden (bestiller-prosjektet) enn leverandørsiden, og avhenger av om prosjektet har vært vellykket ( vi lykkes pga oss ) eller ikke ( vi mislykkes pga dem ) Utvalgte, typiske suksessfaktorer Realistiske ambisjoner og sa nei til ting Dyktige mennesker særlig viktig med dyktige utviklere Prosjektet har fått høyeste prioritet i virksomheten Endret ressurs-modellen fra en-leverandør, der ressursene tilhørte leverandøren, til fler-leverandør, der ressursene tilhørte prosjektet Klarte å ta ut noe man egentlig ikke behøvde [og fikk dermed bedre tid og kontroll] Var en attraktiv kunde som fikk tak i de beste ressursene Samlokalisering [eksterne, interne, fagsiden, drift,..] Kompetent test-team på tvers av IT, prosjekt og linje Åpenhet mellom kunde og leverandør [tillitt, tett på, god styring av ressurser] Smidig utvikling med hyppige leveranse Mye ressurser fra linjen [fagsiden, bestillersiden] Tidlig involvering av både IT og fagpersoner [linje], beslutninger tas av de som blir involvert til slutt 9
Hva opplevdes som utfordrende? 125 utfordringer ble nevnt Fem på topp type utfordringer var: Problemer med utviklingsarbeidet, særlig tekniske problemer og overføring til drift/forvaltning (30%) Involvering/samarbeid/dialog (22%) Problemer relatert til oppstartsfasen: Ambisjonsnivå, spesifikasjon, estimering (19%) Kompetanse til bestiller eller leverandør (14%) Nyttestyring (7%) I utgangspunktet burde utfordringer og suksessfaktorer følge hverandre, men vi ser at utviklingsarbeid og oppstartsfase er mer hyppig nevnt som utfordringer enn som suksessfaktor Kanskje også delvis et resultat av at vi lykkes, de feilet, eller en tendens til å undervurdere hvor viktig oppstartfase og utviklingsarbeid (teknologiske valg, prosess for overlevering,...) er for å lykkes. Utvalgte, typiske utfordringer Klarte ikke å sette av nok tid som kunde Vanskelig å estimere, gir urealistiske rammer Komplisert samarbeid mellom etatene Overføring til drift/linje undervurdert/komplisert [Kanskje den mest vanlige kommentaren!] Skjønne at dette er et utviklingsprosjekt [prosessendring], ikke primært et IT-prosjekt Brukte ikke nok tid på konseptfasen For lite myndighet til å involvere linje, brukere Leverandør tapte penger og ble vanskelig [winner s curse = client s curse] Ikke-optimale arkitekturavgjørelser, problematisk involvering av arkitektene Test ble komplisert Mangler teknisk kompetanse til å se konsekvenser av valg - som kunde For lite fokus på å trekke ut gevinster Kompleks integrasjon med andre systemer 10
Hva oppleves å være viktigste forbedringsområder (læring)? 107 forhold man ville gjort annerledes/bedre ble nevnt Fem på topp lærings/forbedrings-områder var: Bedre på utviklingsprosess (særlig test) (28%) Bedre i oppstartsfasen (særlig estimering) (24%) Bedre på involvering (16%) Bedre på å sikre god kompetanse (9%) Bedre på nyttestyring (7%) Ikke overraskende så gjenspeiler dette hva som er de opplevde utfordringene, og ikke så mye det som er suksessfaktorene (man føler seg kanskje god nok der). Test og estimering utmerket seg som områder der man særlig følte behov for forbedring. Utvalgte, typiske forbedringsområder Innføre et regime for gevinstrealisering [prioriteringer, nyttestyring] Beregne mer tid til integrasjon og prosessendringer [utrulling] Involvere bedre - tidligere og mer underveis Mer ressurser og tid på overlevering/innføring Trenger mer effektiv testing Trenger mer intern IT-kompetanse Skille på behov og krav Bedre estimeringsmetoder Bedre vurdering av risiko Bevisstgjøring av hva som er absolutte deadlines Sikre kompetente ressurser fra leverandør Begrense antall prosjekter som går i parallell Bedre verktøy for administrasjon av regler [database] Bedre topplederforankring - sikres tidligere Bedre pilotering, med kompliserte brukere først Tydeliggjøre gevinster tidligere 11
STØRRELSE OG AMBISJONER Størrelse vs suksess Stor (over 100 mill), Middels 10-100 mill, liten under ca. 10 mill. Sammenhenger (ingen svært sterke): De minste hadde størst hyppighet av problemer (5 av 13), men kun ett med store problemer/kansellert. De største med størst hyppighet av store problemer (3 av 13) men også med størst hyppighet av bra utfall (10 av 13). Litt enten eller, ser det ut som. Middels store prosjekter gjorde det kanskje best. 7 av 9 med bra utfall og kun ett med store problemer. Små prosjekter lider oftere under lav prioritet og korrelerer med lavere bestiller-kompetanse. De største prosjektene lider oftere under stor organisasjonsmessig kompleksitet hos kunde, leverandør og mottager/bruker. Selv med smidig organisering, oppdelte og hyppige leveranser, så blir ikke denne typen organisasjonskompleksitet borte. Stemmer med tidligere (HIT-seminar) undersøkelse (neste slide) 12
HIT/SMIOS-undersøkelse: Prosjektstørrelse vs. andel suksessfulle (score bedre enn akseptabelt ) prosjekter < 10 mill 10-100 mill > 100 mill Nytte 31% 47% 35% Kvalitet 24% 28% 25% Budsjett 24% 47% 47% Tid 29% 35% 35% Effektivitet 24% 12% 24% Ingen klar sammenheng mellom budsjett-størrelse og andel prosjekter som er suksessfulle. MEN, de store (> 100 mill) var sterkt overrepresentert i gruppen av fiaskoprosjekter! (2-3 ganger hyppighet) I en annen studie (offshoringsprosjekter) finner jeg at en tidobling av størrelsen dobler risikoen for fiasko. Effekt av størrelse er sterkt kontekst-avhengig. For noen er 10-100 mill svært store prosjekter man mangler erfaring med. Ambisjonsnivå Mange av prosjektene kommenterer at det sette riktig (= ikke for høyt) ambisjonsnivå har vært essensielt for å lykkes. Analyse av prosjektene gir noe støtte til dette. Formål (grovinndeling): Modernisering (erstatte samme funksjonalitet, ny teknologi/ utseende), Implementering av regelendring Effektivisering (forbedringer og nye tjenester) Nytt produkt Prosjekter med ett formål: 10 av 17 med score bra Prosjekter med to formål: 13 av 13 med score bra Prosjekter med tre formål: 2 av 5 med score bra Erfaringene fra intervjuene, sammen med analysen, støtter at et høyt ambisjonsnivå (ofte sammenfallende med stort prosjekt) øker risiko for prosjektproblemer. 13
KONTRAKTER Kontraktsform vs prosjektutfall Kontrakttype Problemer Suksess Fastpris 1 3 1 Målpris: Risikodeling med tak 5 4 Målpris: Risikodeling uten tak 1 6 Per time 3 9 Ytelsesbasert 0 3 1: Alle disse tre var små fastpris-prosjekter med mye utvidelser. Stemmer bra med HIT-undersøkelse (se neste slide) Hvor mye er valg av kontrakt og hvor mye er bakenforliggende årsaker? Type prosjekt Kundemodenhet Vi tror at kontraktsform er en del av problemet -> Fastprisoppførsel (mer om dette) 14
HIT-undersøkelse Fastpris Per time Smidig Risikodeling Nytte 0% 59% 29% 22% Kvalitet 22% 24% 43% 22% Budsjett 33% 31% 71% 22% Tid 11% 29% 43% 44% Effektivitet 0% 19% 29% 33% Andel 18% 37% 14% 41% Opplevd kontraktsform vs prosjektutfall Opplevd kontrakt Gikk bra Problemer på minst ett område Store problemer/ stoppet Kommentar til store problemer Per time 15 3 1 Intern-prosjekt med teknologiproblemer Fastpris 4 2 4 Typisk situasjon: Målpris med tak og underestimert Kombinasjon 6 0 0 Per time-opplevelse: Enten ren per time kontrakt eller målpris som i praksis ble oppfattet som nær en per-time betaling (fast % risikodeling - typisk 50-50 ved overskridelse, løpende estimering av godt kjente leveranser med liten usikkerhet, eller stor fleksibilitet i leveransene). Fastpris-opplevelse: Enten en ren fastpris eller målpris som i praksis ble oppfattet som nær fastpris. Gjerne i sammenheng med målpris med tak + sterk underestimering av leverandør. Kombinasjon: Stor grad ytelsesbasert (3) eller fastpris (ofte på lite prosjekt) med store utvidelser betalt per time (3). 15
Fastprisoppførsel Timebaserte kontrakter, eller målpriskontrakter som lå nært opp til per time-betaling, var de som ga best resultat og lavest risiko for store prosjektproblemer. Fastpris og fastpris-lignende kontrakter (målpris med grense for risikodeling) gikk bra når prosjektet hadde realistiske estimater, eller når det var mye per-time betalt i tillegg. Fastpris-lignende avtaler, særlig ved under-estimering, endret ikke bare leverandørens, men også i enkelt tilfelle kundenes oppførsel, til fastprisoppførsel : Leverandør: Ble (ihht kunden) ofte mer opptatt av kontrakten enn nytten. Kunden: Ble (ihht leverandør) i enkelte tilfelle mindre fleksibel. Alt som var spesifisert skulle leveres 100%, selv om det ga liten nytte. Mer fokus på pris (ved valg av leverandør) og spesifikasjon enn nytte. LEVERANDØRVALG OG RESSURSSTYRING 16
Leverandørvalg og ressursstyring (suksessfaktorer, utfordringer og læring) Suksessfaktor (11) Utfordringer (3) Læring (12) Seleksjon av ressurser (4) Ny leverandør (1) Seleksjon av ressurser (6) Styring av ressurser (3) Prosess for leverandørvalg (1) Ressurstilgang (4) Godt samarbeid (2) Komplisert leverandørstruktur (1) Samlokalisering (2) Ressursstyring er antakelig viktigere enn det som resultatene indikerer Flertallet av de som har nevnt ressursstyring som viktig faktor har selv opplevd problemer, og tatt grep De som traff godt fra starten, reflekterer kanskje ikke over viktigheten av ressursstyring Kompetanse (hos enkeltpersoner) er en av de viktigste suksessfaktorene Styre selv, eller la leverandøren styre utviklingsressursene? Mangelfull kompetanse hos utviklingsressursene er en hyppig nevnt utfordring. Store forskjeller i kompetanse hos utviklere og prosjektledere Flere eksempler ipå at en eller få [navngitte] svært dyktige enkeltpersoner har vært avgjørende for prosjektets suksess. Ca ⅓ av prosjektene styrte bemanningen på ressursnivå selv. De beste prosjektene styrer i stor grad ressursene selv og finner selv de mest kompetente hodene. Krevende, men oppleves å være lønnsomt Styre selv korrelerer med at prosjektene har: De mest kompetente og involverte kundene Mer bruk av per time-baserte kontrakter (målpris og fastpris begrenser styringsmulighetene for kunde) Målpris og fastpris oppleves ofte å være slik at man som kunde ikke bør legge seg opp i hvordan leverandøren bemanner prosjektet. 17
En eller flere leverandører per prosjekt? Alle seks prosjektene der kunde valgte enkeltressurser fra flere leverandører gikk bra. Mer variasjon i hvordan en-leverandør-modeller fungerer Noen prosjekter hadde en fast leverandør som leverte per time. Disse gikk stort sett bra (8 av 10 gikk bra), særlig i de tilfellene med intern prosjektledelse. Prosjekter som hadde én dominerende leverandør og en kontrakt i retning av fastpris fikk oftere problemer (6 av 9 fikk problemer). Noen leverandører (to av de største) i en-leverandør-modell hadde overhyppighet av prosjekter med store problemer (tre av tre prosjekter med store problemer). Store leverandører i enleverandør-modell var forbundet med: Fastprisaktige kontrakter og underprising. Mindre erfaring på kundeside. NB: Lite data. Bør være forsiktig med å trekke konklusjoner. Hvordan velge leverandører/ressurser? Nesten alle brukte tradisjonelle prosesser for valg av leverandør og ressurser: CV, tilbudsdokument, angitte referanser (få eller ingen sjekker referanser utenfor de angitte, mange sjekker ikke referanser i det hele tatt) To prosjektene brukte Proof of Concept og ett (til en viss grad) testing av utviklere. Alle disse tre prosjektene gikk det svært bra med. Prosjektene der interne ressurser hadde god kunnskap om enkeltressurser hos eksterne leverandører (ekspert-evaluering basert på tidligere ytelse) gikk det også bra med. Konsekvenser: Realistisk evaluering av leverandør og utviklere er sentralt for å lykkes. Bruk av proof of concept, trialsourcing, og testing av enkeltpersoners kompetanse. Uavhengige referanser: I Danmark vurderer man nå et offentlig register over hvor godt/dårlig IT-leverandører lykkes med å levere nytte. Kunne vært svært nyttig for offentlig sektor. 18
Produktivitetsmålinger Ingen målte produktivitet Et fåtall gjør subjektive evalueringer av produktivitet, og da i form av: Vurderinger av enkeltpersoner underveis i prosjektet Sammenligning av leveranser fra ulike leverandør-team Vanlige substitutter som en del benytter (og noen kaller målinger): Faktisk forbruk mot estimert forbruk og earned value. Dette sier noe om nøyaktigheten til estimater og planer og ikke så mye annet. Velocity: Utvikling i story points per sprint. Dette måler relativ produktivitet i løpet av prosjektet, men ikke om hvor produktivt arbeidet blir gjort. Minst to offentlige organisasjoner har startet arbeidet med å kunne måle produktivitet. 19
Produktivitet lite vektlagt? Undersøkelse på HIT-seminar (mars 2016) ga at produktivitet i IT-prosjekter var middels vektlagt ved vurdering av suksess og i liten grad målt. (NB: Målingene som er utført er trolig underveis endring av produktivitet innen et prosjekt, ikke hvor effektivt prosjektet var målt mot andre prosjekter.) Generell viktighet Viktighet siste prosjekt Tallfestet (målt) i siste prosjekt Nytte 1 1 28% Brukerfornøydhet 2 2 20% Teknisk kvalitet 3 6 25% Budsjettkontroll 4 5 73% Produktivitet 5 6 27% Tidskontroll 6 3 67% I henhold til kravspesifikasjon 7 4 40% Drift og forvaltning fornøyd 8 8 15% Læring 9 9 5% Stort potensiale ved å kunne måle og velge ressurser basert på produktivitetsmålinger Hyppigst nevnte årsak til både suksess og utfordringer i undersøkelsen Oppsummering av utviklerproduktivitet fra 61 eksperimenter (5-36 personer) (Prechelt, 1999) Typisk forskjell på beste og dårligste var 1:15 Typisk forskjell på en av de 25% tregeste vs. 25% raskeste 1:5 Fire norske firma utviklet det samme IT-systemet (Anda, m.fl., 2009) Forskjell i arbeidsmengde var ca. 1:3 Seks offshoringsfirma utviklet det samme IT-systemet (Jørgensen, 2016) Forskjell i arbeidsmengde 1:16 Vanskelig å vite i forkant en leverandørs/utviklers produktivitet Lave estimater: Lav kompetanse eller høy produktivitet? CV og prosjekterfaring: Alle har gode CV-er Referanser: Velges av leverandør Uten egen erfaring (og selv da) vil kanskje viktigste faktor for prosjektsuksess ikke være mulig å styre! 20
LEVERANSEMODELL Leveransehyppighet Nesten alle hadde hyppige leveranser (33 av 35)! Få hadde hyppige leveranser til produksjon (7 av 35). Alle disse gikk det bra med! Fem av disse hadde per-time kontrakter og to hadde kombinert De som leverte hyppig, og noen få ganger til produksjon gikk det også stort sett bra med (10 av 14 bra). De som leverte hyppig, men ikke til prod. gikk det dårligere med (6 av 12 gikk bra, 2 hadde problemer, og 4 hadde store problemer) Samsvarer med tidligere undersøkelse (se neste slide). 21
Hjelper det å jobbe smidig? Fleksibilitet i omfang Forskjell på smidig utvikling med og uten fleksibilitet i omfang: Fleksibelt omfang/smidig konstruksjon: 13 av 15 gikk bra Fast omfang/ smidig konstruksjon: 7 av 12 gikk bra Erfaringsnivået til kunden, prosjekt-kompleksitet, kontraktsform og synes å være ca. likt for de to variantene - og forklarer ikke forskjellen. Men, mer vanlig med hyppig leveranser til produksjon for prosjekter med fleksibelt omfang 22
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 33% 10% Endringer som muligheter, ikke som trussel. Korrelerer med god bruk av smidig. Vanskeligere å få til med fastpris-avtaler. TEST 23
Testing Prosjekter med problemer anga ofte test som en sentral utfordring: Kontrollpunkttesting var for overfladisk Testet ikke det vanskeligste Burde gjort grundigere testing Problemer avdekket for sent under akseptansetesting God testing er forutsetning for hyppige leveranser til produksjon Og bidro til at det gikk bra med alle prosjektene med hyppige leveranser til produksjon. NYTTESTYRING 24
Nyttestyring Business case ved oppstart Ja: 8 av 26 (31%) med problemer Nei/vet ikke: 2 av 9 (22%) med problemer Plan for nyttestyring: Ja: 5 av 17 (29%) med problemer Nei/vet ikke: 5 av 18 (28%) med problemer Ansvarlig for gevinstrealisering (uthenting av nytte): Ja: 5 av 18 (28%) med problemer Nei/vet ikke: 5 av 17 (29%) med problemer Underveis styring av nytte: Ja: 3 av 15 (20%) med problemer Nei/vet ikke: 7 av 20 (35%) med problemer Faktoren som slår positivt ut her er underveisstyring av nytte. Under halvparten av prosjektene inkluderte denne aktiviteten! Fra HIT-undersøkelse om nyttestyring: Her slo både planlegging og underveis nyttestyring ut på suksess mhp levert nytte 25
ESTIMERING Estimering ved oppstart Nesten alle (31 av 35) estimerer med en eller annen for for WBS (bottom-up) estimeringmetode. Få har erfaringsdata, og da stort sett om påslagsfaktorer. Kun 2 prosjekter triangulerer (mer enn en metode): Det ene av disse var likevel betydelig underestimert. Ett prosjekt brukte Wideband Delphi. Mange bruker underveisestimering vha Planning Poker, Flere organisasjoner har standardiserte estimeringsmodeller. Noen pålegger leverandørene å bruke denne. Det er så å si kun innen KS2 at grundige usikkerhetsanalyser gjøres. Ellers gjøres svært enkel usikkerhetsanalyse med risikopåslag - typisk mellom 10 og 30% - eller ikke i det hele tatt. Ingen identifiserte sammenhenger mellom hvor godt prosjektet lykkes (heller ikke estimeringsnøyaktighet!) og estimeringsprosess eller usikkerhetsanalyse. 26
INVOLVERING AV LINJEN (fagsiden, drift, forvaltning) Linjens deltakelse Linjens ansvar: Prosjektstyring, delta i utvikling (inkludert spesifisering av krav og prioritering), produksjonsetting av leveranser, innføring og opplæring, drift og realisering av gevinster. God involvering av linje/fagpersoner og god forankring var hyppig nevnte suksessfaktorer. 27
Utfordringer Tre av prosjektene som hadde problemer angir mangelfull involvering av linje som en av utfordringene. Flere av prosjekter som gikk bra mente også at innføring og opplæring var blant utfordringene: Eksempler: Mange skal læres opp, spredt geografisk, Regelverk kommer sent, Mangler opplæringsmateriell Seks prosjekter hadde konkrete problemer med overlevering til drift Seks prosjekter klarte overleveringen bra, men opplevde likevel overlevering til drift som en utfordring Utfordringer fra prosjekter som hadde problemer: Oppdaget [for sent] at folk [brukerne] jobbet forskjellig Burde involvert flere ressurser på forvaltningsiden Læring Prosjekter som gikk bra angir under læring: Mer/bedre deltakelse underveis og bedre kompetanseoverføring (7 prosjekter) Mer involvering av drift underveis (2) Bedre overlevering til drift (3) 28
Eierskap og forankring Sterkt eierskap i linjen og god forankring er en kritisk suksessfaktor. Det å trekke folk ut fra linje har en kostnad, er utfordrende for driften og setter andre oppgaver på vent men fører til overføring av kompetanse Innføringsaktiviteter krever betydelig planlegging, organisering og involvering fra linjens side og må ikke undervurderes. Må finne riktige midler: Forankre beslutninger i linja Involvere riktige ressurser fra linja (driftsarkitekt / delprosjektleder fra drift) Bedre rolleavklaring (prosjekt vs forvaltning) Hyppige demo for mottakere Planlegge driftsorganisasjon Planlegge opplæring i god tid Levere hyppig til linje Dele informasjon underveis DET SUKSESSFULLE OG DET PROBLEMATISKE PROSJEKT 29
Kjennetegn ved det suksessfulle prosjektet God kontroll på ambisjonsnivå. Unngår for mye på en gang og sier nei til tillegg som vil øke risiko. Bruker kontrakter som unngår fastpris-oppførsel for leverandør (og kunde) De mest suksessfulle har timeprisbaserte kontrakter Har en kunde med kompetanse til å velge og styre kompetente leverandører og enkeltressurser (og som har mindre fokus på pris). Har fleksibilitet i omfang (ikke bare må-funksjonalitet) Har en kunde som (minimum) er sterkt involvert i planlegging av nytte og nyttestyring underveis Bruker smidig utvikling med hyppige leveranser til produksjon (eller i det minste til realistisk evaluering) Støttes av gode prosesser for effektiv testing Tenker tidlig på (og involverer) overlevering til linje, brukere og drift Kjennetegn ved det problematiske prosjektet Har for høyt ambisjonsnivå. Bruker muligheten et stort prosjekt gir til å gjøre mer. Bruker kontrakter med høy risiko for fastpris-oppførsel for leverandør (og kunde) Derunder anbudsrunder som leder til under-prising Har kunde uten god kompetanse til å velge kompetente leverandører og enkeltressurser, og sterkt fokus på pris. Lar leverandører styre ressursene uten innblanding Ingen eller liten fleksibilitet i omfang og ser på endringer ( scope creep ) som trussel Liten eller ingen fokus på nyttestyring, utenom å lage business case ved oppstart Bruker smidig utvikling med hyppige leveranser, men leveransene går ikke til produksjon eller blir evaluert av linje/brukere Overlevering til linje, brukere og drift tenkes på kun i siste fase, eller når prosjektet leverer. 30
Hvem vil være med på hva videre? På hvilken måte? TEMA: Anbuds og planleggings-prosess Valg av leverandør/ressurser Kontraktsform Estimering Register over prosjekter med erfaringer Nytte og ressursstyring Produktivitetevalueringer Nyttestyring underveis Smidige metoder Kunderollen Kompetanse Involvering Overlevering UNDERSØKELSESFORM: Samle erfaringer fra/følge prosjekter Tilgang på data som allerede lagres Utprøving/eksperimentering Annet? VALG AV TEMA BASERT PÅ: Gode praksiser dere har som andre kan lære fra Områder dere ønsker å bli bedre på BØR VI TA MØTER MED DERE ENKELTVIS? 31