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

Transkript

1 Erfaringer fra PERFORM -et av Norges største smidige prosjekt Onsdag 30/ Mette Gjertsen Prosjektleder Statens Pensjonskasse Dette er Statens pensjonskasse En av Norges beste pensjonsordninger Markedets beste boliglån? Forsikring fra dag én Tjenestepensjon for medlemmer yrkesaktive medlemmer (inkl med delvis pensjon), arbeidstakere med opptjente rettigheter og pensjonister Pensjonene er fordelt på alderspensjonister, uførepensjonister, som mottar ektefellepensjon og barn som mottar barnepensjon Gunstig boliglån til stadig flere Vi har 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

2 PERFORM er SPKs største og mest forretningskritiske prosjekt noensinne Varighet Størrelse Ca prosjekttimer 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

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

4 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

5 PERFORM er etablert for å møte fire svært kritiske forretningsmessige drivere 1. Arbeidsavklaringspenger Ikrafttredelse Samordne midlertidige ytelser fra NAV 2. Pensjonsreform Ikrafttredelse 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 og innfører nytt regelverk (pensjonsreform fra) sommeren NAV integrasjon 2009 Forberede full prosjektoppbygging NAV integrasjon Forberedelse nytt saksbehandlersystem 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

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

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

8 Ikke påbegynt Under arbeid Til test Ferdig Behovene endrer seg underveis! Funksjonalitet Pensjonsreform 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 Funksjonalitet rest sakssystem Nye og bedre effektiviserings tiltak i SPK ut fra 2 år mer erfaring Ny kø ? Funksjonalitet effektivisering 16

9 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 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

10 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

11 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

12 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

13 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

14 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 Inntjent verdi Forbruk Planlagt verdi Inntjent verdi Forbruk

15 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

16 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, ,72 1, ,24 1, ,97 1, ,06 1, ,80 1, ,07 1, ,84 1, ,76 1, ,55 1, ,52 0, ,25 0, ,49 0, ,27 1, 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

17 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

18 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

19 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

20 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

21 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

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