Kontrakter og prosjektstyring i store, smidige IT prosjekter

Dette er Statens pensjonskasseEn av Norges bestepensjonsordningerMarkedets besteboliglån?Forsikringfra dag énTjenestepensjon for 950 000 medlemmer310 000 yrkesaktive medlemmer (inkl. 23 000 med delvis pensjon), 432 000arbeidstakere med opptjente rettigheter og 231 000 pensjonisterPensjonene er fordelt på 138 000 alderspensjonister, 58 000 uførepensjonister,47 000 som mottar ektefellepensjon og 2 000 barn som mottar barnepensjonGunstig boliglån til stadig flereVi har 36 800 lånekunder som utgjør en låneportefølje på 27 milliarder kronerForsikringsordningerGruppelivsforsikring: ved død utbetales et engangsbeløp til etterlatteYrkesskadeforsikringBilansvarssaker for politiet og forsvaret og noen særordninger for forsvaretVi forvalter pensjonsordningen for alle apotekeneFondsmidlene var på 4,7 milliarder per 31.12.2009

Flere usikkerhetsfaktorer vil påvirkePERFORM• Usikkerhetsfaktorene er i hovedsak knyttet tilimplementering av nytt regelverk som følgeav Pensjonsreformen, ettersom hoveddelenav reformen ikke er besluttet• Dette betyr at vi vil få endringer underveis iforhold til– Funksjonalitet– Teknisk løsning– Estimater– ….• Vi må bygge en endringsrobust løsning forarbeidsprosesser og IT-systemerHvis 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

Scrum – styrker og svakheter i forhold tilkunnskapsområdene i PM-BookScopeRiskCostTimeIntegrationHuman ResourceQualityCommunicationProcurement

Kunnskapsområder i prosjektledelseScopeRiskCostTimeIntegrationHuman ResourceQualityCommunicationProcurement

Gjennomføringsmodell PERFORMGjentas 3 ganger i åretCa 5 sprinter a 3 ukerOverordnede krav(CRV) ogkonsekvensanalyseBehovsanalyseLøsningsbeskrivelse Konstruksjon Godkjenning ProduksjonssettingForretning-/linjeressurserArkitekterUtviklereTestressurserLeveranseledere

DelsystemerGjennomføringsmodell – PS2000R1 R2 R3 R4Delleveranser (Release)TidTrinn per DelleveranseIterativkonstruksjonsfaseDetaljplanlegging /Analyse og designKPnKP2KP1TestingUtviklingBehovsanalyseLøsningsbeskrivelseGodkjenningProd.settingog innføringKontraktsinngåelseHMP 0HMP 1GodkjentløsningsbeskrivelseHMP 2Leveranse klartil godkjenningHMP 3Godkjentleveranse

PS2000 kontraktsstandardSæ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 avincentivordninger tilrettelagt• Rutiner for konfliktløsning vedbruk av uavhengig ekspert inkludertBehovsfaseLøsningsbeskrivelsesfaseKPnKP2Detaljplanlegging /Analyse og designKP1TestingProgresjonIterativkonstruksjonsfaseUtviklingGodkjenningsogavslutningsfaseHMP 0KontraktsinngåelseHMP 1Godkjent løsningsbeskrivelseHMP 2Leveranse klartil godkjenningHMP 3Godkjentleveranse

Målpris - en mellomvei mellomfastpris og løpende timer• Bruksområder– Systemutvikling basert på relativt godt spesifisertbehovsanalyse– Godt nok grunnlag for realistiske estimater– Erkjennelse av at krav og prioriteringer kan endre segunderveis• 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 ogkostnad

Eksempel på kompensasjonsmodelli PERFORM (EV + AC) / 2(EV I kompensasjonsformelen er estimert kost på funksjonalitet som leveres og som ergodkjent 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 tilkontrakt.• 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 tilkontrakt.

Hvorfor målpriskontrakt medrisikodeling?• Risiko er likt fordelt mellom kunde og leverandør• Leverandøren er med dette invitert til å forplikte seg tilestimater som har en høyere grad av usikkerhet enn itradisjonelle fastpriskontrakter.• Dette er essensielt i smidige systemutviklingsprosjekt hvoret av hovedprinsippene er å unngå ”waste”.• Spesielt er det essensielt å redusere ressursbruk på initiellspesifikasjon, detaljert design og planlegging.• Kunde kan produsere overordnede dokumenter med merhøynivå krav.• Leverandøren kan produsere løsningsbeskrivelser, estimatmed en høyere grad av usikkerhet.• På denne måten kan begge sider redusere arbeidsbelastningi den initielle anbudsfasen av prosjektet.

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

PERFORMProsjektdirektørProsjektlederBestillerLeverandørDelprosjektforretningPL :SPKDelprosjekt UtviklingPL :SPKDelprosjektkommunikasjon oginnføringDelprosjektarkitekturLBF TeamApp. Ark.TeamMiljøteamDelprosjekt testAksepttestkriterierFunksjonelltestGodkjenningsprøveRegelverkPL: SPKInnføringITOSaksbehandlingssystemPL:SteriaPL :AccentureProduksjonssettingInnføringForretning

PS2000 i PERFORM• Desember 2008 inngikk SPK kontrakt med 2 leverandørerom bidrag i PERFORM. Avtalene er formet som rammer avressurspådrag i løpet av prosjektperioden.• Løsningsbeskrivelsesfase gjennomføres for hver delleveranse– dvs 3 ganger pr år. Løsningsbeskrivelsesfasen er styrt avkunden og kompensasjon er på løpende timer.• Det inngås målprisavtale med hver leverandør forkonstruksjonsfasen i hver leveranse. Feilretting igodkjenningsprø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 separatproduktkø for hver leverandør kundens godkjenningsprosess ble kjørt forfø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 realiseringslinjeog felles produktkø.– Produkteier og leverandør mer bevist på hva som er viktigst og har høyestprioritet– Letter å flytte ting rundt i køene og agere på resultat av demoer underveis– Bedre samarbeidsklima på tvers av leverandørene – alle har gjensidigeavhengigheter av hverandre

Kunnskapsområder i prosjektledelseScopeRiskCostTimeIntegrationHuman ResourceQuality Communication Procurement

Leveransestrategi i PERFORMKjennetegn 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 leveranseUtover dette :Mulighet for delleveranserMulighet for produksjonsfix’erMålsetning at PERFORM skal levere til produksjon ihovedleveranseneDette gir konstruksjonsperioder på 15 uker til hver leveranse

Erfaringer fra PERFORM• Gradvis innføring er verdifullt, vi blir ”helt” ferdig medfunksjonalitet 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 ressurserinvolvert i produktkøfase, konstruksjon oggodkjenningsprøve samtidig.– Klare prioriteringer fra prosjektledelsen er viktig– Kapasitetsplanlegging - i noen iterasjoner er det mindrekapasitet enn andre• Levert funksjonalitet vil bli endret igjen, viktig å tahøyde for i overordnet estimering.

Kontinuerlig i konstruksjon-funksjonell test og integrasjonstest er del av konstruksjonApril 09 September 09 Desember 09April 10SeptemKonstruksjon Godkjenning ProduksjonForvaltningBehov Løsning Konstruksjon Godkjenning ProduksjonForvaltningBehov Løsning Konstruksjon Godkjenning ProduksjonForvaltningBehov Løsning Konstruksjon Godkjenning ProduksjonForvaltningBehov Løsning Konstruksjon Godkjenning ProduksjonBehov Løsning Konstruksjon

PERFORM satt med 87 leverte kravpoengny rekord i siste iterasjon avkonstruksjonsfasen for maiMai 2010 - masterplanelementer• I iterasjon 7 ble det levert 43,61kravpoeng• Dette gjør at prosjektet i konstruksjonsfasen formai leverte ni kravpoeng mer enn i periodisertbudsjettMai 2010 - usikkerhetselementer• I iterasjon 6 ble det levert 43,4 kravpoengpå usikkerhet• Totalt ble det dermed levert 30 kravpoeng mer enni periodisert budsjett* ) kp = kravpoeng

Kunnskapsområder i prosjektledelseScopeRiskCostTimeIntegrationHuman ResourceQuality 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 tankepå investering og senere drift• Resultatmålene for Perform er, i prioritert rekkefølge:1. Fremdrift2. Kvalitet3. Økonomi2010Videre på nytt2009saksbehandlersystemNAV integrasjonForberede nytt regelverkForberedelse nytt2008 saksbehandlersystemNAV integrasjonForberede full prosjektoppbyggingNytt regelverk2011Effektivisering ogoptimalisering av nyttsaksbehandlersystem

Masterplanen definerer omfanget til PERFORMMasterplan :– 310 brukehistorier (epic,masterplanelementer) somdefinerer omfanget til PERFORM, disse er delt inn i 11funksjonelle områder og prioritert etter viktighet i forholdtidspunkt for ikrafttredelse av regelverk.• 1.1-2011 er en politisk styr dato som prosjektets suksessmåles opp mot– Hvert masterplanelement er grovestimert ved bruk avestimeringspoker slik at de har et størrelsesforhold tilhverandre.– Til en leveranseperiode har produkteier gjennomgåttbrukerhistoriene og definert hvilke som må leveres til enleveransen. Disse går da inn i behovs ogløsningsbeskrivelsen for leveransen og danner grunnlagfor målbildet for leveransen som kommuniseres til alle.

Løsningsbeskrivelse og produktkø– Gjennom Løsningsbeskrivelsesfase for hver leveranse brytesbrukerhistoriene ned til produktkøelementer.– Produktkøelementene gir grunnlag for oppdragsavtaler forkonstruksjon av løsning og får et omforent estimat somdefinerer målpris.– Produktkøelementene er prioritert i den rekkefølge produkteiermener de må utføres.• Vurdert ut fra funksjonell viktighet• Tekniske avhengigheter• Teknisk viktighet– Produkteier preplanlegger hver iterasjon og klargjør de nesteproduktkøelementene til teamet.– Innenfor en iterasjon deler teamet hvert produktkøelement oppi arbeidsoppgaver som vil utgjøre iterasjonskøen til teamet– Produkteier kan reprioritere produktkø underveis i en leveranse

Produkteier i PERFORMDelprosjektforretningProdukteiertotaltLeverandørnivåProdukteierdel 13 teamProdukteierdel 25 teamProdukteierdel 33 tea,TeamnivåFunksjoneltansvarligTeam 1FunksjoneltansvarligTeam 2FunksjoneltavsvarligTeam 5FunksjoneltansvarligTeam 6FunksjoneltansvarligTeam3FunksjoneltansvarligTeam 4Produkteierteamet leverandørnivå– Produkteier, forretningsarkitekt, funksjonell arkitekt, teknisk arkitekt

Kontinuerlig refactoring er detmulig?• 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ølgerdisse i kontrollpunkt– Satt opp regler for kodekvalitet i PMD – følger utviklingpr. modul– Moduleierskap med gitt oppgaver fordelt til alle team– Kontrakt mellom prosjektledelse og driftsapparat atteknisk gjeld som opparbeides gjennom harde prioriteringtil 1.1-2011 skal ryddes opp, første økt mot desember2010

Kunnskapsområder i prosjektledelseScopeRiskCostTimeIntegrationHuman ResourceQuality Communication Procurement

Testmodell/strategi i SPK/Perform• Enhetstest (ET)• Integrasjonstest (IT)• Systemtest (ST)• Systemintegrasjonstest (SIT)• Godkjenningsprøve (GP)• Akseptansetest (AT)• Produksjonstest (PT)GPPerformGodkjenningsprøveDP-testET/ITST/SITProsjekt PerformKonstruksjonDP-UtviklingATSPKsTestsenterRegresjonstestPTLeveranseapparatet SPKDP leveranse

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

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 ferdigDOD ”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 SPKstiller til alle prosjekter– funksjonelt ansvarlig har godkjent at punktet er ferdig– punktet har passert kontrollpunkt

Kontinuerlig produksjonssettinggir 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 ogFlex 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 vurderesnedetid på 1 dag i tillegg)- Rettet opplæring av brukere- Superbrukere og funksjonelt ansvarlige fra PERFORM tilstede i forretning førsteuken etter produksjonssetting.- Inneholder 5 - 7 iterasjonerPERFORM leverer løsning i produksjon hver hovedleveranse

Kunnskapsområder i prosjektledelseScopeRiskCostTimeIntegrationHuman ResourceQuality Communication Procurement

Kommunikasjonsvirkemidler• Kjørbar – demonstrerbar kode hver iterasjon- interessenter ogprosjektdeltakere kan møte på demo.• Kjørbar kode i SIT miljø, interessenter kan benytte dette løpende• Brukerdokumentasjon og systemdokumentasjon gjennomgås avinteressenter 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 prosjektetProsjektledermøtetPL perform, PD perform, DPL utvikling, DPL forretning, DPL test,DPL leveranse, DPL ArkitekturMetascrum(DPL utvikling, PL leverandør, PL Perform, DPLArkitektur, DPL Forretning, DPL test)StatusmøteDPforretningDagligmøteDP testDagligmøteDParkitekturScrum av scrumPL leverandørScrummastreTestleder lev.Scrum av scrumPL leverandørScrummastreTestleder lev.DagligsscrumScrummasterteametDagligsscrumScrummasterteametDagligsscrumScrummasterteametDagligsscrumScrummasterteamet

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 tilprodukteierprioritering foran neste sprint.– Avhengighetsstandup sent på planleggingsdag– Arkitektur”muntlig” – teamarkitektene møter å fortellerhva de skal gjøre denne sprinten- 2 dager etterplanlegging.

UtviklingsmiljøiSPK

Utviklingsmiljø• Benytter tynnklienter med Citrix løsning hvor det igjenligger 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

Testmiljø• Utviklers testmiljø• 2 teammiljø pr team• Systemintegrasjonstest• 3 stk Godkjenningsprøve• Ytelsestestmiljø• Driftstestmiljø• AkseptansetestmiljøGPPerformGodkjenningsprøveDP-testET/ITST/SITProsjekt PerformKonstruksjonDP-UtviklingATSPKsTestsenterRegresjonstestPTLeveranseapparatet SPKDP leveranse

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