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

Transkript

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

2 Agenda 1. Statens pensjonskasse 2. Kort om prosjektet 3. Kunnskapsområder som berøres 1. Procurement 2. Time 3. Scope 4. Quality 5. Communication 4. Utviklingsmiljø en utfordring

3 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

4 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 To hovedleverandører I tillegg behandles SPK også som en leverandør Til sammen 12 scrumteam Alle på en flate Med en sterk involvering fra SPKs toppledelse!

5 Perform: fire oppgaver over fire år 1. Arbeidsavklaringspenger ( ) Samordne ytelser med NAV 2. Pensjonsreformen (1.1.11) Implementere nye regler for offentlig tjenestepensjon 3. Utdatert teknisk plattform nytt saksbehandlingssystem (PUMA) 4. Samordne vårt system med NAVs 2009 Integrasjon med NAV 2010 Nytt regelverk Levere nytt saksbehandlersystem Forberede nytt saksbehandlersystem 2011 Effektivisere og optimalisere nytt saksbehandlersystem Avvikle prosjekt Perform 2008 Kjempen : integrasjon med NAV Forberede prosjektorganisasjonen

6 Flere usikkerhetsfaktorer vil påvirke PERFORM Usikkerhetsfaktorene er i hovedsak knyttet til implementering av nytt regelverk som følge av Pensjonsreformen, ettersom hoveddelen av reformen ikke er besluttet Dette betyr at vi vil få endringer underveis i forhold til Funksjonalitet Teknisk løsning Estimater. Vi må bygge en endringsrobust løsning for arbeidsprosesser og IT-systemer Hvis forutsetningene endres vil det påvirke PERFORM

7 Metode besluttes desember 2007 Vi benytter iterative metode i pensjonsprosjektet, fordi: Økt forretningsinvolvering ettersom kravene endres underveis (pensjonsreform). Hyppige interne (ikke produksjon) leveranser Bedre kobling mellom IT og forretning Samarbeid hele tiden! Risiko reduserende Synliggjør tidlig Vanskeligste først

8 Scrum styrker og svakheter i forhold til kunnskapsområdene i PM-Book Scope Risk Cost Time Integration Human Resource Quality Communication Procurement

9 Kunnskapsområder i prosjektledelse Scope Risk Cost Time Integration Human Resource Quality Communication Procurement

10 Gjennomføringsmodell PERFORM Gjentas 3 ganger i året Ca 5 sprinter a 3 uker Overordnede krav (CRV) og konsekvensanalyse Behovsanalyse Løsningsbeskrivelse Konstruksjon Godkjenning Produksjonssetting Forretning-/linjeressurser Arkitekter Utviklere Testressurser Leveranseledere

11 Delsystemer Gjennomføringsmodell PS2000 R1 R2 R3 R4 Delleveranser (Release) Tid Trinn per Delleveranse Iterativ konstruksjonsfase Detaljplanlegging / Analyse og design KPn KP2 KP1 Testing Utvikling Behovsanalyse Løsningsbeskrivelse 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

12 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 KP2 Detaljplanlegging / Analyse og design KP1 Testing Progresjon Iterativ konstruksjonsfase Utvikling Godkjenningsog avslutningsfase HMP 0 Kontraktsinngåelse HMP 1 Godkjent løsningsbeskrivelse HMP 2 Leveranse klar til godkjenning HMP 3 Godkjent leveranse

13 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

14 Eksempel på kompensasjonsmodell i PERFORM (EV + AC) / 2 (EV I kompensasjonsformelen er estimert kost på funksjonalitet som leveres og som er godkjent av kunden i kundens godkjenningsprosess. AC er leverandørens Actual cost ) Ved leveransetidspunkt, Earned Value (=målpris) er kr, AC er kr. Kunden betaler kr, gjennomsnittlig timerate er som spesifisert i kontrakten. Ved leveransetidspunkt, Earned Value (=målpris) er kr, AC er kr. Kunden betaler kr, gjennomsnittlig timerate er redusert med 8,4% i forhold til kontrakt. Ved leveransetidspunkt, Earned Value (=målpris) is kr, AC er kr. Kunden betaler kr, gjennomsnittlig timerate er økt med 12,5% i forhold til kontrakt.

15 Hvorfor målpriskontrakt med risikodeling? Risiko er likt fordelt mellom kunde og leverandør Leverandøren er med dette invitert til å forplikte seg til estimater som har en høyere grad av usikkerhet enn i tradisjonelle fastpriskontrakter. Dette er essensielt i smidige systemutviklingsprosjekt hvor et av hovedprinsippene er å unngå waste. Spesielt er det essensielt å redusere ressursbruk på initiell spesifikasjon, detaljert design og planlegging. Kunde kan produsere overordnede dokumenter med mer høynivå krav. Leverandøren kan produsere løsningsbeskrivelser, estimat med en høyere grad av usikkerhet. På denne måten kan begge sider redusere arbeidsbelastning i den initielle anbudsfasen av prosjektet.

16 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

17 PERFORM Prosjektdirektør Prosjektleder Bestiller Leverandør Delprosjekt forretning PL :SPK Delprosjekt Utvikling PL :SPK Delprosjekt kommunikasjon og innføring Delprosjekt arkitektur LBF Team App. Ark. Team Miljøteam Delprosjekt test Aksepttest kriterier Funksjonell test Godkjenningsprøve Regelverk PL: SPK Innføring ITO Saksbehandlings system PL:Steria PL :Accenture Produksjons setting Innføring Forretning

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

19 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

20 Kunnskapsområder i prosjektledelse Scope Risk Cost Time Integration Human Resource Quality Communication Procurement

21 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

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

23 Kontinuerlig i konstruksjon -funksjonell test og integrasjonstest er del av konstruksjon April 09 September 09 Desember 09 April 10 Septem 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

24 PERFORM satt med 87 leverte kravpoeng ny rekord i siste iterasjon av konstruksjonsfasen for mai Mai masterplanelementer I iterasjon 7 ble det levert 43,61 kravpoeng Dette gjør at prosjektet i konstruksjonsfasen for mai leverte ni kravpoeng mer enn i periodisert budsjett Mai usikkerhetselementer I iterasjon 6 ble det levert 43,4 kravpoeng på usikkerhet Totalt ble det dermed levert 30 kravpoeng mer enn i periodisert budsjett * ) kp = kravpoeng

25 Kunnskapsområder i prosjektledelse Scope Risk Cost Time Integration Human Resource Quality Communication Procurement

26 Våre overordnede målsettinger Samfunnsmålene er å innføre reformen på en måte som sikrer korrekte og rettidige ytelser til våre kunder og medlemmer sikrer en kostnadseffektiv innføring av reformen i SPK både med tanke på investering og senere drift Resultatmålene for Perform er, i prioritert rekkefølge: 1. Fremdrift 2. Kvalitet 3. Økonomi 2010 Videre på nytt 2009 saksbehandlersystem NAV integrasjon Forberede nytt regelverk Forberedelse nytt 2008 saksbehandlersystem NAV integrasjon Forberede full prosjektoppbygging Nytt regelverk 2011 Effektivisering og optimalisering av nytt saksbehandlersystem

27 Masterplanen definerer omfanget til PERFORM Masterplan : 310 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.

28 Løsningsbeskrivelse og produktkø Gjennom Løsningsbeskrivelsesfase for hver leveranse brytes brukerhistoriene ned til 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

29 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

30 Kontinuerlig refactoring er det mulig? Kjennetegn i PERFORM Arkitektur har utviklet seg underveis 100 utviklere 100 stammespråk? Funksjonalitet til viktigst Opparbeidet teknisk gjeld Hva gjør vi for å bedre dette? Fokus på arkitekturretningslinjer og hvor godt man følger disse i kontrollpunkt Satt opp regler for kodekvalitet i PMD følger utvikling pr. modul Moduleierskap med gitt oppgaver fordelt til alle team Kontrakt mellom prosjektledelse og driftsapparat at teknisk gjeld som opparbeides gjennom harde prioritering til skal ryddes opp, første økt mot desember 2010

31 Kunnskapsområder i prosjektledelse Scope Risk Cost Time Integration Human Resource Quality Communication Procurement

32 Testmodell/strategi i SPK/Perform Enhetstest (ET) Integrasjonstest (IT) Systemtest (ST) Systemintegrasjonstest (SIT) Godkjenningsprøve (GP) Akseptansetest (AT) Produksjonstest (PT) GP Perform Godkjenningsprøve DP-test ET/IT ST/SIT Prosjekt Perform Konstruksjon DP-Utvikling AT SPKs Testsenter Regresjonstest PT Leveranseapparatet SPK DP leveranse

33 Systemintegrasjonstest - SIT Erfaringer fra SIT Finner feil tidligere og får rettet dem i konstruksjon Kan gjøre gjennomløpende tester Oppdager miljø- og systemrelaterte utfordringer tidlig Sluttbrukere kan teste applikasjonen

34 Hva kontrollerer vi i kontrollpunktet.. Demo leverer man det som funksjonelt sett er bestilt? Har dette den funksjonelle kvaliteten som bestilt? Kodekvalitet Er koden forvaltbar Følger koden kodestandarder Utvikler kodekvaliteten seg korrekt Arkitekturretningslinjer Følger man standard for database Følger man standard for bruk av SPRING Følger man standard for oppdeling av moduler

35 Hva kontrollerer vi i kontrollpunktet.. Dokumentasjon Er systemdokumentasjon ok Er driftsdokumentasjon etablert Er brukerdokumentasjon laget Er leveransedokumentasjon laget Følger man retningslinjer for overlevering Testkvalitet Er testdekning god nok Er det nok negative tester Har man flyttet koden til systemintegrasjonstestmiljø Har man testet på teammiljø Har man sammenlignet PUMA <=> MP

36 Definisjon av ferdig DOD Definition of done sakset fra SPKs smidighåndbok Når er man ferdig? det er utviklet tilstrekkelige funksjonelle tester for punktet alle tilhørende utviklingsoppgaver er ferdige øvrige oppgaver knyttet til punktet er ferdigstilt dokumentasjon er utviklet i henhold til prosjektets krav, inkl krav SPK stiller til alle prosjekter funksjonelt ansvarlig har godkjent at punktet er ferdig punktet har passert kontrollpunkt

37 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

38 Kunnskapsområder i prosjektledelse Scope Risk Cost Time Integration Human Resource Quality Communication Procurement

39 Kommunikasjonsvirkemidler Kjørbar demonstrerbar kode hver iterasjon- interessenter og prosjektdeltakere kan møte på demo. Kjørbar kode i SIT miljø, interessenter kan benytte dette løpende Brukerdokumentasjon og systemdokumentasjon gjennomgås av interessenter hvert kontrollpunkt Scrumtavler med brenndiagram i prosjektlokalet Brukerhistorier er lette å forstå for alle Open space ved behov i forbindelse med iterasjonsavslutning Avhengighetsworkshop Brenndiagrammer i JIRA som følges opp på metascrum Prosjektwiki Målbilde gjennomganger og workshops med linjen Prosjektrapportering til styringsgruppe

40 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

41 Scrumtavlene synlige arbeidsflater

42 Skjermer som viser status på bygg

43 Open space hver iterasjon

44 Avhengigheter Avhengighetsworkshop hver sprint Ser hva som er foran oss i køen danner input til produkteierprioritering foran neste sprint. Avhengighetsstandup sent på planleggingsdag Arkitektur muntlig teamarkitektene møter å forteller hva de skal gjøre denne sprinten- 2 dager etter planlegging.

45 Utviklingsmiljø i SPK

46 Utviklingsmiljø Benytter tynnklienter med Citrix løsning hvor det igjen ligger en VDM løsning hvor hver utvikler får sin virtuelle maskin 3 versjoner Javautvikling Flexutvikling (MP) C -utvikling Kjører Hudson som byggverktøy Kjører Subversion som versjonsstyring Kjører Crusible og fisheye som kodelesvektøy Kjører Maven for lokalt bygg

47 Testmiljø Utviklers testmiljø 2 teammiljø pr team Systemintegrasjonstest 3 stk Godkjenningsprøve Ytelsestestmiljø Driftstestmiljø Akseptansetestmiljø GP Perform Godkjenningsprøve DP-test ET/IT ST/SIT Prosjekt Perform Konstruksjon DP-Utvikling AT SPKs Testsenter Regresjonstest PT Leveranseapparatet SPK DP leveranse

48 Utviklingsmiljø vedlikeholdes av et miljøteam Med 100 utviklere i PERFORM og ytterligere 30 i SPK sier det seg selv at utviklings og testmiljøene er kritiske. De første 9 mnd med leverandører i PERFORM opplevde vi svært mye ustabilitet og støy Opprettet miljøteam på tvers av IT-område i SPK og PERFORM Ansvar Utviklingsmiljøene er oppe Oppsett av testmiljø Tagging og branching Oppgraderinger av utviklingsmiljø Deploy og oppsett av de forskjellige testmiljøene Produksjonssetting