Erfaringer fra PERFORM -et av Norges største smidige prosjekt Onsdag 30/3-2011

Like dokumenter
Erfaringer med PS2000 kontrakt og kontraktsstyring i PERFORM. Mette Gjertsen Prosjektleder Statens Pensjonskasse

Kvalitet i smidige prosjekt Erfaringer PERFORM prosjektet i SPK. Mette Gjertsen Prosjektleder Statens Pensjonskasse mette.gjertsen@spk.

Kontrakter og prosjektstyring i store, smidige IT prosjekter. Mette Gjertsen Prosjektleder Statens Pensjonskasse mette.gjertsen@spk.

Hvordan PS2000 blir tilpasset til smidig gjennomføring

PERFORM et smidig prosjekt PERFORM. Flere usikkerhetsfaktorer vil påvirke PERFORM. 4 av SPKs endringsdrivere =>PERFORM. Kompetanse

Usikkerhet i omfang og kostnader hvordan håndtere dette i kontrakten? IT-kontraktsdagen 2015 Kjetil Strand, Promis AS

Metodevalg PERFORM PERFORM BLE INNGANGSPORT TIL SMIDIG

Prosjekteierrollen, krav og forventninger. Implementering av pensjonsreformen i Statens Pensjonskasse PERFORM

Valg av utviklingsmetode hva betyr dette for kontraktsutformingen

Smidig modell for moderniseringen av NAV

HYPPIGE LEVERANSER HVORDAN KOMMER SPK DIT? Ved Mette Gjertsen Statens pensjonskasse

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012

Kontrakter. INF1050: Gjennomgang, uke 12

Modernisering av IKT i NAV

Gevinstrealisering i Statens pensjonskasse

Smidig metodikk, erfaringer fra NAV Fagportal

Hvordan styre prosjekter frem til suksess Kontraktsformer og metodikk som fungerer Jørgen Petersen PROMIS AS 1

Inntjent verdi; estimering og planlegging PROMIS AS 1

Oppgave 2: Kontraktsutforming a) Refererer innledningsvis til følgende temaer i presentasjonen knyttet til særtrekkene i PS2000:

Smidig leveranseprosjekt en selvmotsigelse. Dataforeningen og Norsk Senter for Prosjektledelse Temadag 31. mai En lyntale av Jon Øgar

Prosjektledelse - fra innsiden

Gevinstrealisering i Statens pensjonskasse. Presentasjon NOKIOS 26. oktober 2010

Computas AS PS2000 PS2000. Bakgrunn: Systemmetodikk relatert til avtaleform Om PS2000 Erfaringer Spørsmål

Kvalitetssikring (KS2)

Ny kontraktsstandard: Fleksibel utviklingskontrakt

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Dårlige tider gir gode verktøy - visualisering av komplekse feilsituasjoner -

Testing tidlig i livssyklusen smidige prosjekter. Arne Erik Hurum Helsedirektoratet Bjørn Andersen - Steria

Computas AS PS2000 PS2000. Bakgrunn: Systemmetodikk relatert til avtaleform Om PS2000 Erfaringer Spørsmål

Prosjektledelse - fra innsiden av et utviklingsprosjekt. Presentasjon hos UiO Ida Lau Borch, prosjektleder i Bouvet ASA

Finansportalen Historiske bankdata

INNTJENT FORRETNINGSVERDI

INNTJENT FORRETNINGSVERDI

PÅ VEI MOT SMIDIGE KONTRAKTER. Ståle L Hagen IT-kontraktsdagen september

Neste generasjon ERP-prosjekter

Together. Free your energies Moden og modig! Ansvarsfull og fleksibel!

NYTTESTYRING GJENNOM HYPPIGE LEVERANSER OG TVERRFAGLIGE TEAM

Alminnelige bestemmelser Gjennomføring av Leveransen Endringer etter avtaleinngåelsen

Copyright 2010 Accenture All Rights Reserved. Smidig utvikling introduksjon og erfaringer

Bakgrunn: Systemmetodikk relatert til avtaleform

Kontrakt for oppdragsbasert smidig utvikling av programvare PS2000 SOL

Kunstner: Oddmund Mikkelsen

Verdien av god leverandørtesting i konstruksjonsfasen i smidige prosjekter

Statens pensjonskasse STYRING AV NYTTE GJENNOM FORTLØPENDE LEVERANSER OG TILBAKEMELDING FRA BRUKERE 3/7/18

Making IT your winning asset

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

Kunstner: Oddmund Mikkelsen

Agenda. Hvordan jobber Computas? Computas AS. Computas AS kunnskap system

Et IT-prosjekt = et prosjekt uten styring, er det virkelig slik det er?

Smidig utvikling NTNU Tor-Erik Mathisen

Testing i smidigavtalen (SSA-S) Seniorrådgiver Mari Vestre, Difi. Testdagen ODIN 24. september 2014.

GJENNOMGANG UKESOPPGAVER 13 KONTRAKTER

Test i smidig. Laila Sandbæk Testrådgiver og testleder Sogeti

Ny kontraktsstandard fra Dataforeningen: Fleksibel utviklingskontrakt

Computas AS kunnskap system

Bruk av Scrum i BI-prosjekter

UKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

KONTRAKTER FOR PROGRAMVAREUTVIKLING. Ståle L Hagen UiO 10 mai 2017

Verdimatrisen verktøy for nyttestyring i og på tvers av tiltak HIT frokostseminar Kjetil Strand, Promis AS

Saksframlegg. Møtedato Styret Helseforetakenes senter for pasientreiser ANS 10/06/2015

Teknisk gjeld - hvor mye er forsvarlig? Per Otto Bergum Christensen, Objectdesign 27 August, Smidig fagdag i SPK

LEVER OFTERE TEST SMARTERE

KLP IT LEAN «Stor og langsom anakonda ble til liten og rask mamba»

Nyttestyring og gode brukerhistorier. Stein Grimstad, 25.august, ITPP

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

SYSTEMUTVIKLINGSKONTRAKTER SMIDIG OG PS2000

Saksgang: Styret Helseforetakenes senter for pasientreiser ANS 31/10/2016

Integrasjon - fra strategi til vellykket implementering. Integrasjonsdagene Halden, august 2013 Ståle Hustad, TrønderEnergi Nett AS

Scrum. -nøkkelbegreper og noen personlige erfaringer

Hvordan jobber Computas?

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM

Smidig digitalisering 2017 Smidig forutsigbarhet: Kan man gå estimeringsveien? Trine Vabog og Jon Grov

1. Initiativ og prosjekter for systemutvikling

Statusrapportering DIPS Hovedprosjekt

Hvor smidig det er spørsmålet? Presentasjon på CIO Forum

Introduksjon. Prosjekt Arbeidslivsportalen. Benedicte Frydendal Line Melby Helene Mørne Marte Holhjem Martin Brændhaugen

Den gode kunde. Kompetanse, involvering og kultur. Magne Jørgensen Simula Research Laboratory

Smidig innføring og endringsledelse

Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt Motivasjon av kunder og Nyttige verktøy

Oppgave 1: Multiple choice (20 %)

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 9. mai 2016 Rapporteringsperiode April 2016

Jørgen Petersen PROMIS AS 1

Fra virksomhetsmål til prioritert produktkø

ERP-prosjekter Forsvarets erfaringer. SAP konferansen 27. oktober 2016 Brigader Arild Dregelid Sjef LOS-programmet i Forsvaret

SAFe. - Ny styringsmodell for innovasjon, IT-utvikling og forvaltning

Teknisk gjeld. Innhold. Hva er teknisk gjeld? NAVs tilnærming Dokumentasjon av teknisk gjeld Oppsummering

IT I PRAKSIS!!!!! IT i praksis 20XX

Bakgrunn. 1. Innledning. 2. Ulike kontraktsformer og standardkontrakter. 3. Anskaffelsesprosesser. 4. Bakgrunn og bruksområder for PS2000

Bakgrunn. IKT-avtaler og -kontrakter, INF1050 våren Innledning. 3. Anskaffelsesprosesser. 4. Bakgrunn og bruksområder for PS2000

Bilag 1: Kundens krav til leveranser

Utfordring, tiltak og status:

Styring av IT-prosjekter Kontraktstandard for IT-prosjekter med veiledning

Kontrakter. IT-Ledelse, 19.mars. Faglærer : Tom Røise. IMT1321 IT-Ledelse 1. Relevante avtaleformer innen IT. Dagens tema : Avtaler og kontrakter

Klarspråkledelse Hva skal til for å lykkes med

Dataforeningens kontraktsstandard for oppdragsbasert, smidig leveranse av programvare Veiledning for utarbeidelse og bruk av kontrakten

SCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG

Stein Grimstad. Konsulent i Scienta AS. Prosjekt hos Skatteetaten. Forsker hos Simula (deltid) 3/7/18

Kap 11 Planlegging og dokumentasjon s 310

K O N S U L E N T - I D : C U R R I C U L U M V I T A E

Kommende Trender Innenfor Test

Transkript:

Erfaringer fra PERFORM -et av Norges største smidige prosjekt Onsdag 30/3-2011 Mette Gjertsen Prosjektleder Statens Pensjonskasse mette.gjertsen@spk.no Dette er Statens pensjonskasse En av Norges beste pensjonsordninger Markedets beste boliglån? Forsikring fra dag én Tjenestepensjon for 950 000 medlemmer 310 000 yrkesaktive medlemmer (inkl. 23 000 med delvis pensjon), 432 000 arbeidstakere med opptjente rettigheter og 231 000 pensjonister Pensjonene er fordelt på 138 000 alderspensjonister, 58 000 uførepensjonister, 47 000 som mottar ektefellepensjon og 2 000 barn som mottar barnepensjon Gunstig boliglån til stadig flere Vi har 36 800 lånekunder som utgjør en låneportefølje på 27 milliarder kroner Forsikringsordninger Gruppelivsforsikring: ved død utbetales et engangsbeløp til etterlatte Yrkesskadeforsikring Bilansvarssaker for politiet og forsvaret og noen særordninger for forsvaret Vi forvalter pensjonsordningen for alle apotekene Fondsmidlene var på 4,7 milliarder per 31.12.2009 2

PERFORM er SPKs største og mest forretningskritiske prosjekt noensinne Varighet 2008-2011 Størrelse Ca 750.000 prosjekttimer 100-180 personer, maks i 2010 Ca 80 interne ressurser fra forretningsområder og IT Til sammen 12 scrumteam 2 rammeavtaleleverandører som hovedleverandør Ivaretar til sammen 6 scrumteam SPK også leverandør Ivaretar til sammen 6 scrumteam Tre rammeavtale leverandører på kundesiden i sentrale roller Alle på en flate Med en sterk involvering og forpliktelse fra SPKs toppledelse! 3 Agenda Leveranseplanlegging og leveransestyring Eller hvordan levere hyppige leveranser som henger sammen og gir høy forretningsverdi God produkteierorganisering er alfa og omega for suksess Rapportering i smidig prosjekt 4

Hvilke gevinster gir smidig utvikling? 1) Raskere i produksjon 2) Bygger det kunden trenger 5 LEVERANSEPLANLEGGING 6

Leveransestrategi i PERFORM Kjennetegn for SPKs regime for leveransestyrt produksjonssetting: - 3 hovedleveranser i året - Krav om felles akseptansetest før hver hovedleveranse - Krav om overleveringsnotat til ITO - Krav om forvaltningsgaranti ca 2 uker etter en leveranse Utover dette : Mulighet for delleveranser Mulighet for produksjonsfix er Målsetning at PERFORM skal levere til produksjon i hovedleveransene Dette gir konstruksjonsperioder på 15 uker til hver leveranse 7 Kontinuerlig i konstruksjon -funksjonell test og integrasjonstest er del av konstruksjon April 09 September 09 Desember 09 April 10 September10 Konstruksjon Godkjenning Produksjon Forvaltning Behov Løsning Konstruksjon Godkjenning ProduksjonForvaltning Behov Løsning Konstruksjon Godkjenning Produksjon Forvaltning Behov Løsning Konstruksjon Godkjenning Produksjon Forvaltning Behov Løsning Konstruksjon Godkjenning Produksjon Behov Løsning Konstruksjon 8

PERFORM er etablert for å møte fire svært kritiske forretningsmessige drivere 1. Arbeidsavklaringspenger Ikrafttredelse 01.03.10 Samordne midlertidige ytelser fra NAV 2. Pensjonsreform Ikrafttredelse 01.01.11 Nye regler for offentlig tjenestepensjon 3. Utdatert teknisk plattform SPKs pensjonssystem kjører på en teknisk plattform som er utdatert 4. NAV Pensjonsprogram NAV leverer nye systemer i des. 2008 og innfører nytt regelverk (pensjonsreform fra) sommeren 2009 2008 NAV integrasjon 2009 Forberede full prosjektoppbygging NAV integrasjon Forberedelse nytt saksbehandlersystem 2011 2010 Effektivisering og optimalisering av nytt Nytt regelverk saksbehandlersystem Videre på nytt saksbehandlersystem 9 Målene til prosjektet gir den løpende prioriteringen Samfunnsmål PERFORM Sikre korrekte rekte og rettidige ytelser til våre kunder og medlemmermer Sikre en kostnadseffektiv innføring av pensjonsreformen i SPK med tanke på investeringer og senere drift 10

Målene til prosjektet gir den løpende prioriteringen Utbetale rett pensjon til rett tid (i hele prosjektperioden og etter leveranse) Våre kunder skal få et forutsigbart produkt og en forutsigbar og korrekt premie under og etter implementering av Pensjonsreformen 85% av SPKs pensjonsytelser skal behandles maskinelt etter innføring av nytt regeverk pr 1.1.2011 PERFORM skal levere et fleksibelt saksbehandlersystem, hvor endringer raskt lar seg implementere SPK skal tilrettelegge for god informasjon om det nye regelverket til våre kunder og medlemmer SPK skal ha etablert en informasjons- og simuleringsløsning for nytt regelverk i løpet av 2010 Minimum 95 % av SPKs pensjonsytelser skal behandles maskinelt etter innføring av nytt regelverk pr 01.01.2012 Saksbehandlingstiden skal ikke øke utover dagens mål som følge av Pensjonsreformen 11 Masterplanen definerer omfanget til PERFORM Masterplan : 308 brukehistorier (epic,masterplanelementer) som definerer omfanget til PERFORM, disse er delt inn i 11 funksjonelle områder og prioritert etter viktighet i forhold tidspunkt for ikrafttredelse av regelverk. 1.1-2011 er en politisk styr dato som prosjektets suksess måles opp mot Hvert masterplanelement er grovestimert ved bruk av estimeringspoker slik at de har et størrelsesforhold til hverandre. Til en leveranseperiode har produkteier gjennomgått brukerhistoriene og definert hvilke som må leveres til en leveransen. Disse går da inn i behovs og løsningsbeskrivelsen for leveransen og danner grunnlag for målbildet for leveransen som kommuniseres til alle. 12

Utvalg av elementer til en leveranse Overordnet er rekkefølgen for hovedleveransene pri. 1 Fremdrift, kvalitet, Økonomi Teknisk og funksjonell rekkefølge Høy kost/nytte og høy brukerverdi for SPK og saksbehandlere Samsvar med avtalt målbilde for leveransen Helhetlige leveranser 2008 NAV integrasjon 2009 Forberede full prosjektoppbygging NAV integrasjon Forberedelse nytt saksbehandlersystem 2011 2010 Effektivisering og optimalisering av nytt Nytt regelverk saksbehandlersystem Videre på nytt saksbehandlersystem 13 Løsningsbeskrivelse og produktkø Gjennom Løsningsbeskrivelsesfase for hver leveranse brytes epos (masterplanelementer) ned til brukerhistorier (produktkøelementer) Produktkøelementene gir grunnlag for oppdragsavtaler for konstruksjon av løsning og får et omforent estimat som definerer målpris Produktkøelementene er prioritert i den rekkefølge produkteier mener de må utføres. Vurdert ut fra funksjonell viktighet Tekniske avhengigheter Teknisk viktighet Produkteier preplanlegger hver iterasjon og klargjør de neste produktkøelementene til teamet Innenfor en iterasjon deler teamet hvert produktkøelement opp i arbeidsoppgaver som vil utgjøre iterasjonskøen til teamet Produkteier kan reprioritere produktkø underveis i en leveranse 14

Ikke påbegynt Under arbeid Til test Ferdig Behovene endrer seg underveis! Funksjonalitet Pensjonsreform 1.1-2011 Overordnet produktkø Initiell produktkø Dynamisk produktkø Funksjonalitet rest sakssystem Funksjonalitet effektivisering 15 Vent med detaljering på det lengst unna i tid. Opprinnelig kø Levert 2010 Funksjonalitet Pensjonsreform 1.1-2011 Funksjonalitet rest sakssystem Nye og bedre effektiviserings tiltak i SPK ut fra 2 år mer erfaring Ny kø 2011 2012? Funksjonalitet effektivisering 16

Erfaringer fra PERFORM Gradvis innføring er verdifullt, vi blir helt ferdig med funksjonalitet underveis. Det er tidkrevende, vi er alltid i 3 leveranser samtidig. Konstruksjon pågår kontinuerlig Frustrerende for team i perioder når de har ressurser involvert i produktkøfase, konstruksjon og godkjenningsprøve samtidig. Klare prioriteringer fra prosjektledelsen er viktig Kapasitetsplanlegging - i noen iterasjoner er det mindre kapasitet enn andre Levert funksjonalitet vil bli endret igjen, viktig å ta høyde for i overordnet estimering. 17 Kontinuerlig produksjonssetting gir virkelig kvalitet - Mellom 30 000 90 000 prosjekttimer - Godkjenningsprøve med varighet 4-8 uker - Gradvis utrulling av ny funksjonalitet - Gradvis utrulling til nye brukere - Gradvis migrering fra SPK-MP (Klient-tjener basert C løsning) til PUMA (java og Flex basert tjenesteorientert løsning) - 2 faste produksjonsfix er planlagt fra PERFORM etter en hovedleveranse - Produksjonssettes i løpet av en helg (For enkelte av leveransene vurderes nedetid på 1 dag i tillegg) - Rettet opplæring av brukere - Superbrukere og funksjonelt ansvarlige fra PERFORM tilstede i forretning første uken etter produksjonssetting. - Inneholder 5-7 iterasjoner PERFORM leverer løsning i produksjon hver hovedleveranse 18

GOD PRODUKTEIER- ORGANISERING 20 PERFORM Prosjektdirektør Prosjektleder Produksjons setting Innføring ITO Bestiller Leverandør Delprosjekt forretning PL :SPK Delprosjekt Utvikling PL :SPK Delprosjekt arkitektur LBF Team App. Ark. Team Miljøteam Delprosjekt test Aksepttest kriterier Funksjonell test Godkjenningsprøve Regelverk PL: SPK Saksbehandlings system PL:Steria Innføring Forretning PL :Accenture 21

Prosjektgjennomføringen Vi jobber etter smidig metodikk i prosjektet SCRUM Utviklingsprosessen Godkjenning Behovsanalyse Løsningsbeskrivelse Konstruksjon Akseptansetest Produksjonssetting Driftsprøve (Eies av IT) 3 årlige leveranser Produktkøprosessen Mellom 5 og 7 iterasjoner DP forretning er kravstiller og DP utvikling leverer iht krav DP arkitektur og test jobber på tvers DP utvikling består av 3 hovedteam (leverandører) med 12 team Overordnet design og spesifikasjon gjøres i fellesskap for deretter å splittes i tre Produktkøen danner grunnlaget for utvikling Oppdragsavtaler opprettes med alle tre leverandører Målpris for konstruksjonsfasen Medgått tid på øvrige oppgaver Arkitektur defineres/utvikles både i forkant av og gjennom iterasjonene Vi bygger iterativt Starter med detaljert planlegging og inngåelse av en forpliktet kontrakt pr team Videre aktiviteter er detaljert design/ analyse, utvikling og test Avsluttes med et kontrollpunkt Godkjenningsprøve gjennomføres før overlevering 22 PERFORM Delprosjekt forretning (ca 30 årsverk SPK) Delprosjektleder Forretning Kommunikasjon Teamleder Behovsfase 1 4 Åv Teamleder Behovsfase 2 4 ÅV Produkteier SPK Produkteier Accenture Funksjonelle Arkitekter 3 interne og 1 pr leverandør Innføring og Opplæring 4 ÅV Produkteier Steria Funksjonelt ansvarlige og testere konstruksjon 6,5 ÅV Funksjonelle testere DP Test 3,5 ÅV 23

Produkteier i PERFORM Delprosjekt forretning Produkteier totalt Leverandørnivå Produkteier del 1 3 team Produkteier del 2 5 team Produkteier del 3 3 tea, Teamnivå Funksjonelt ansvarlig Team 1 Funksjonelt ansvarlig Team 2 Funksjonelt avsvarlig Team 5 Funksjonelt ansvarlig Team 6 Funksjonelt ansvarlig Team3 Funksjonelt ansvarlig Team 4 Produkteierteamet leverandørnivå Produkteier, forretningsarkitekt, funksjonell arkitekt, teknisk arkitekt 24 Teamet - Perform Teamarkitekt Funksjonelt ansvarlig Seniorutviklere Juniorutviklere Scrum master Tester Til sammen: 7-9 ressurser 25

Suksessfaktorer Produkteier og forretningsressurser allokeres i tilstrekkelig mengde Viktig at linjeledelse spiller på samme lag, omforent eierskap av produktkøen og prioriteringer Fokus på å få ut forventet forretningsverdi Samhandling Internt mellom produkteiere Mellom produkteier og linjeledelse Tett oppfølging av leverandører, produkteier bestemmer pri Kvalitetssikring av alt levert arbeid Meget god erfaring av Jira som verktøy Ledelsen/organisasjonen forstår behovet av tung intern kompetanse i prosjektet Forventingsstyring i forhold til leveranse Perform vs linjeorganisasjon VÅRE MÅL, ikke mitt og ditt DP Forretning et team, et mål 26 RAPPORTERING 27

Teorien om inntjent verdi Tenk deg et prosjekt med en produktkø som er estimert til 1000 timer, og som er planlagt levert til årsskiftet. Ved årsskiftet har prosjektet levert 9/10 av denne køen, dvs. elementer som til sammen er estimert til 900 timer. Prosjektet har brukt 1020 timer på å produsere dette Inntjent verdi (Earned Value, eller EV) blir definert som budsjettert kostnad for utført arbeid. I dette tilfellet tilsvarer dette 900 timer Faktisk forbruk (Actual Cost, eller AC) blir definert som faktisk forbruk for utført arbeid. I dette tilfellet tilsvarer dette 1020 timer Planlagt verdi (Planned Value, eller PV) blir definert som budsjettert kostnad for planlagt arbeid. I dette tilfellet tilsvarer dette 1000 timer 28 S-kurven Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Leveranse N Planlagt verdi 5 000 5 600 5 100 5 800 5 600 27 100 Inntjent verdi 3 800 5 100 5 000 5 900 6 200 26 000 Forbruk 5 200 5 800 5 400 5 800 5 800 28 000 30 000 25 000 20 000 15 000 10 000 Planlagt verdi Inntjent verdi Forbruk 5 000 0 1 2 3 4 5 29

Gjennomføringsmodellen og inncashing 1. Når eposet er klart for løsningsbeskrivelse (HMP0): 5% 2. Når målpris på brukerhistorien er signert (HMP1): 30% 3. Når brukerhistorien er godkjent i kontrollpunkt (HMP2): 86% 4. Når eposet er produksjonssatt (HMP3): 100% 5. Ingenting annet enn fremdrift Behovsfase på epos og brukerhistorier teller som inntjent verdi 6. Alle andre aktiviteter i prosjektet vurderes bare som nyttige i den grad de understøtter fremdriften på epos og brukerhistorier HMP 0 Kontraktsinngåelse Løsningsbes - krivelsesfase KPn Detaljplanlegging / Analyse og design KP2 HMP 1 Godkjent løsnings - beskrivelse KP1 Progresjon Iterativ konstruksjonsfase Testing Utvikling HMP 2 Leveranse klar til godkjenning Godkjennings - og avslutningsfase HMP 3 Godkjent leveranse EV = antall RV 1* måltall*5% + antall RV 2 * måltall* 30% + antall RV 3 * måltall*86% + antall RV 4 * måltall* 100% 30 Produkteiers rolle i demo og godkjenning av sprintleveransen Demo hver 3de fredag og kontrollpunkt påfølgende onsdag DP Forretning tester fortløpende lokalt på ferdige oppgaver mini demoer DP Forretning deltar aktivt i verifisering av alle oppgaver som leveres til kontrollpunktet Alt kan ikke testes Godkjente oppgaver (grønn) brennes ned. 31

Prognose: Estimert kostnad på å levere hele prosjektomfanget CPI = EV/AC (kostnadsindeksen) BAC = Prosjektbudsjettet Prognose1 = BAC / CPI Hvis vi mener at CPI hittil i prosjektet er utypisk, kan vi beregne prognosen ut fra en mer lokal CPIL (for eksempel CPIL fra sist kjente leveranse): Prognose2 = AC + ((BAC EV) / CPIL) 32 Prosjekter går sjelden i en rett linje Lokal CPI CPI akkumulert Prognose 1,06 909 692 020 1,72 1,07 905 239 418 1,24 1,08 900 386 434 0,97 1,07 908 533 357 1,06 1,07 907 062 519 0,80 1,06 910 828 360 1,07 1,06 908 928 974 0,84 1,05 912 736 258 0,76 1,04 918 163 248 0,55 1,01 931 881 303 0,52 0,99 939 354 719 0,25 0,97 953 541 642 1,49 0,99 934 825 418 1,27 1,00 929 130 556 I løpet av sprint 8 11 i tabellen til venstre, gikk den lokale CPI drastisk ned Dette var på grunn av en intensiv testperiode i den største leveransen i prosjektet Store variasjoner i lokal CPI (og dermed prognosen) kan være vanskelig å kommunisere til styringsgruppen 33

Fremdrift Økonomi Funksjonell fordeling av leverte punkter etter fjerde iterasjon i Mai-leveransen Risiko 34 Muntlig rapportering i prosjektet Prosjektledermøtet PL perform, PD perform, DPL utvikling, DPL forretning, DPL test, DPL leveranse, DPL Arkitektur Metascrum (DPL utvikling, PL leverandør, PL Perform, DPL Arkitektur, DPL Forretning, DPL test) Statusmøte DP forretning Dagligmøte DP test Dagligmøte DP arkitektur Scrum av scrum PL leverandør Scrummastre Testleder lev. Scrum av scrum PL leverandør Scrummastre Testleder lev. Dagligsscrum Scrummaster teamet Dagligsscrum Scrummaster teamet Dagligsscrum Scrummaster teamet Dagligsscrum Scrummaster teamet 35

KONTRAKT 36 PS2000 i PERFORM Kunden sitter i førersetet Prosjektledelse Løpende kravstilling gjennom delprosjekt forretning og delprosjekt arkitektur i behovs og løsningsbeskrivelsesfasen Løpende godkjenning gjennom kontrollpunkt i hver iterasjon Leverer utviklings og testmiljø og har ansvar for drift og vedlikehold av dette Gjør produksjonssetting Gjennomfører godkjenningsprøve Gjør systemintegrasjon Kundestyrt løsningsbeskrivelse Opptrer selv som leverandør med 6 scrumteam 37

PS2000 i PERFORM Desember 2008 inngikk SPK kontrakt med 2 leverandører om bidrag i PERFORM. Avtalene er formet som rammer av ressurspådrag i løpet av prosjektperioden. Løsningsbeskrivelsesfase gjennomføres for hver delleveranse dvs 3 ganger pr år. Løsningsbeskrivelsesfasen er styrt av kunden og kompensasjon er på løpende timer. Det inngås målprisavtale med hver leverandør for konstruksjonsfasen i hver leveranse. Feilretting i godkjenningsprøven kompenseres som et fastprispåslag på målprisavtalen. Til sammen 80 % av leverandørenes tid i prosjektet er på målpris/fastprispåslag. Til sammen 50% av all prosjektkost er på målpris/fastprispåslag. 38 Gjennomføringsmodell PS2000 R1 R2 R3 R4 Delleveranser (Release) Delsystemer Tid Trinn per Delleveranse Iterativ konstruksjonsfase Detaljplanlegging / Analyse og design KPn KP2 KP1 Behovsanalyse Løsningsbeskrivelse Testing Utvikling Godkjenning Prod.setting og innføring Kontraktsinngåelse HMP 0 HMP 1 Godkjent løsningsbeskrivelse HMP 2 Leveranse klar til godkjenning HMP 3 Godkjent leveranse 39

PS2000 kontraktsstandard Særtrekk Definert gjennomføringsmodell, basert på iterative prosesser Regulerte forpliktelser for begge parter Integrert samarbeid tilrettelagt i gjennomføringsmodellen Erfaringer basert på dokumentert beste praksis innebygd Håndtering av usikkerhet tilrettelagt Motiverende elementer i form av incentivordninger tilrettelagt Rutiner for konfliktløsning ved bruk av uavhengig ekspert inkludert Behovsfase Løsningsbeskrivelsesfase KPn Detaljplanlegging / Analyse og design KP2 KP1 Progresjon Iterativ konstruksjonsfase Testing Utvikling Godkjenningsog avslutningsfase HMP 0 Kontraktsinngåelse HMP 1 Godkjent løsningsbeskrivelse HMP 2 Leveranse klar til godkjenning HMP 3 Godkjent leveranse 40 Målpris - en mellomvei mellom fastpris og løpende timer Bruksområder Systemutvikling basert på relativt godt spesifisert behovsanalyse Godt nok grunnlag for realistiske estimater Erkjennelse av at krav og prioriteringer kan endre seg underveis Fordeler og ulemper Relativ forutsigbarhet mht. kostnader Klare leveranseavtaler mht. omfang og kalendertid Rom for erfaringsbaserte justeringer i iterasjoner Støtter integrert samarbeidsmodell Felles incentiver om å levere kvalitet til avtalt tid og kostnad 42

Erfaringer med PS2000 i PERFORM Første leveranseperiode ble kjørt på løpende timer Bidro til at leverandørene ble bedre kjent med SPK, hverandre og domenet. Andre leveranseperiode ble kjørt på målpris fastrealiseringslinje og separat produktkø for hver leverandør kundens godkjenningsprosess ble kjørt for første gang. Førte til mindre og vanskeligere samarbeid mellom leverandørene Separate produktkøer førte til subotimal løsningsrekkefølge Vanskelig å flytte produktkøelementer mellom leverandørene Tredje leveranseperiode ble kjørt på målpris med forventet realiseringslinje og felles produktkø. Produkteier og leverandør mer bevist på hva som er viktigst og har høyest prioritet Letter å flytte ting rundt i køene og agere på resultat av demoer underveis Bedre samarbeidsklima på tvers av leverandørene alle har gjensidige avhengigheter av hverandre 43 Scrumtavlene synlige arbeidsflater 44

45 Vi gjør mye for å få alle på en flate 46