Statens Pensjonskasse mette.gjertsen@spk.no
Kontrakter og prosjektstyring i store, smidige IT prosjekter
Xxxxx Xxxxxxxx Prosjektleder
Statens Pensjonskasse xxxxx.xxxxxxxx@xxx.xx
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
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
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
• 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!
Perform: fire oppgaver over fire år
1. Arbeidsavklaringspenger (1.3. 10)
• 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 saksbehandler- system
2011
Effektivisere og optimalisere nytt saksbehandlersystem
Avvikle prosjekt Perform
Forberede nytt saksbehandlersystem
2008
”Kjempen”: integrasjon med NAV Forberede prosjektorganisasjonen
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
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
Risk
Cost
Scrum – styrker og svakheter i forhold til kunnskapsområdene i PM-Book
Scope
Time
Integration
Human Resource
Quality
Communication
Procurement
Kunnskapsområder i prosjektledelse
Scope
Risk
Cost
Time
Integration
Human Resource
Quality
Communication
Procurement
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
Gjennomføringsmodell – PS2000
Delsystemer
R1 R2 R3 R4
Delleveranser (Release)
Tid
Iterativ
Trinn per Delleveransekonstruksjonsfase
Detaljplanlegging / KPn Analyse og design
KP2
KP1
Testing Utvikling
Behovs- analyse
Løsnings- beskrivelse
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
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
KPn
Detaljplanlegging /
Analyse og design
KP2
Progresjon
KP1
Godkjennings- og avslutningsfase
Iterativ konstruksjonsfase
Behovsfase
Løsningsbes- krivelsesfase
Testing
Utvikling
HMP 0
Kontraktsinngåelse
HMP 1
Godkjent løsnings- beskrivelse
HMP 2
Leveranse klar til godkjenning
HMP 3
Godkjent leveranse
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
Eksempel på kompensasjons- modell 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 100 000 kr, AC er 100 000 kr. Kunden betaler 100 000 kr, gjennomsnittlig timerate er som spesifisert i kontrakten.
• Ved leveransetidspunkt, Earned Value (=målpris) er 100 000 kr, AC er 120 000 kr. Kunden betaler 110 000 kr, gjennomsnittlig timerate er redusert med 8,4% i forhold til kontrakt.
• Ved leveransetidspunkt, Earned Value (=målpris) is 100 000 kr, AC er 80 000 kr. Kunden betaler 90 000 kr, gjennomsnittlig timerate er økt med 12,5% i forhold til kontrakt.
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.
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
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
Godkjenn- ingsprøve
Regel- verk
Saks- behandlings system
PL: SPK
PL:Steria
PL :Accenture
Innføring ITO
Produksjons setting
Innføring Forretning
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.
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
Kunnskapsområder i prosjektledelse
Scope
Risk
Cost
Time
Integration
Human Resource
Quality
Communication
Procurement
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
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.
Kontinuerlig i konstruksjon
-funksjonell test og integrasjonstest er del av konstruksjon
April 09 September 09 Desember 09 April 10 Septe
Konstruksjon Godkjenning Produksjon Forvaltning
j
Forvaltning
Behov Løsning Konstruksjon Godkjenning Produks
Forvaltning
Behov Løsning Konstruksjon Godkjenning Produksjon
j
Forvaltning
Behov Løsning Konstruksjon Godkjen Produks
Behov Løsning Konstruksjon GodkjenProduksjo
Konstruksjon
Behov Løsning
• 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 2010 - masterplanelementer
PERFORM satt med 87 leverte kravpoeng ny rekord i siste iterasjon av konstruksjonsfasen for mai
• I iterasjon 6 ble det levert 43,4 kravpoeng på usikkerhet
• Totalt ble det dermed levert 30 kravpoeng mer enn i periodisert budsjett
Mai 2010 - usikkerhetselementer
*) kp = kravpoeng
Kunnskapsområder i prosjektledelse
Scope
Risk
Cost
Time
Integration
Human Resource
Quality
Communication
Procurement
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
Nytt regelverk Videre på nytt
2011
Effektivisering og optimalisering av nytt saksbehandlersystem
2009
NAV integrasjon
saksbehandlersystem
2008
Forberede nytt regelverk
Forberedelse nytt saksbehandlersystem
NAV integrasjon
Forberede full prosjektoppbygging
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.
• 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.
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
Produkteier i PERFORM
Delprosjekt
forretning
Produkteier totalt
Leverandør-
nivå
Produkteier del 1
3 team
Produkteier del 2
5 team
Produkteier del 3
3 tea,
Team-
nivå
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
Kontinuerlig refactoring er det mulig?
• Kjennetegn i PERFORM
– Arkitektur har utviklet seg underveis
– 100 utviklere – ”100 stammespråk ?”
– Funksjonalitet til 1.1.2011 – 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 1.1-2011 skal ryddes opp, første økt mot desember 2010
Kunnskapsområder i prosjektledelse
Scope
Risk
Cost
Time
Integration
Human Resource
Quality
Communication
Procurement
Testmodell/strategi i SPK/Perform
• Enhetstest (ET)
• Integrasjonstest (IT)
• Systemtest (ST)
• Systemintegrasjonstest (SIT)
• Godkjenningsprøve (GP)
• Akseptansetest (AT)
• Produksjonstest (PT)
SPKs
Testsenter
AT
Perform Godkjenningsprøve DP-test
GP
Leveranseapparatet SPK
DP leveranse
PT
ET/IT | ST/SIT | ||
Prosjekt Perform Konstruksjon DP-Utvikling | |||
Regresjonstest
Systemintegrasjonstest - SIT
Erfaringer fra SIT
• Xxxxxx 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
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
• …
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
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
Kontinuerlig produksjons- setting 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
Kunnskapsområder i prosjektledelse
Scope
Risk
Cost
Time
Integration
Human Resource
Quality
Communication
Procurement
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
Muntlig rapportering i prosjektet
Prosjektledermøtet
Dagligsscrum Scrummaster
teamet
Dagligsscrum Scrummaster teamet
Dagligsscrum
Scrummaster teamet
Dagligsscrum Scrummaster
PL perform, PD perform, DPL utvikling, DPL forretning, DPL test, DPL leveranse, DPL Arkitektur
(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.
Scrumtavlene synlige arbeidsflater
Skjermer som viser status på bygg
Open space hver iterasjon
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.
Utviklingsmiljø i
SPK
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 Xxxxxx som byggverktøy
• Kjører Subversion som versjonsstyring
• Kjører Crusible og fisheye som kodelesvektøy
• Kjører Maven for lokalt bygg
Testmiljø
• Utviklers testmiljø
• 2 teammiljø pr team
• Systemintegrasjonstest
• 3 stk Godkjenningsprøve
• Ytelsestestmiljø
• Driftstestmiljø
• Akseptansetestmiljø
SPKs
Testsenter
AT
Perform Godkjenningsprøve DP-test
GP
Leveranseapparatet SPK
DP leveranse
PT
ET/IT | ST/SIT | ||
Prosjekt Perform Konstruksjon DP-Utvikling | |||
Regresjonstest
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