Kontrakter og prosjektstyring i store, smidige IT prosjekter
Kontrakter og prosjektstyring i store, smidige IT prosjekter
Kontrakter og prosjektstyring i store, smidige IT prosjekter
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
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 <strong>og</strong> 231 000 pensjonisterPensjonene er fordelt på 138 000 alderspensjonister, 58 000 uførepensjonister,47 000 som mottar ektefellepensjon <strong>og</strong> 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 <strong>og</strong> forsvaret <strong>og</strong> 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 <strong>og</strong> <strong>IT</strong>-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 <strong>IT</strong> <strong>og</strong> forretning – Samarbeid hele tiden!• Risiko reduserende – Synliggjør tidlig – Vanskeligste først
Scrum – styrker <strong>og</strong> 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) <strong>og</strong>konsekvensanalyseBehovsanalyseLøsningsbeskrivelse Konstruksjon Godkjenning ProduksjonssettingForretning-/linjeressurserArkitekterUtviklereTestressurserLeveranseledere
DelsystemerGjennomføringsmodell – PS2000R1 R2 R3 R4Delleveranser (Release)TidTrinn per DelleveranseIterativkonstruksjonsfaseDetaljplanlegging /Analyse <strong>og</strong> designKPnKP2KP1TestingUtviklingBehovsanalyseLøsningsbeskrivelseGodkjenningProd.setting<strong>og</strong> 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 <strong>og</strong> designKP1TestingPr<strong>og</strong>resjonIterativkonstruksjonsfaseUtviklingGodkjennings<strong>og</strong>avslutningsfaseHMP 0KontraktsinngåelseHMP 1Godkjent løsningsbeskrivelseHMP 2Leveranse klartil godkjenningHMP 3Godkjentleveranse
Målpris - en mellomvei mellomfastpris <strong>og</strong> løpende timer• Bruksområder– Systemutvikling basert på relativt godt spesifisertbehovsanalyse– Godt nok grunnlag for realistiske estimater– Erkjennelse av at krav <strong>og</strong> prioriteringer kan endre segunderveis• Fordeler <strong>og</strong> ulemper– Relativ forutsigbarhet mht. kostnader– Klare leveranseavtaler mht. omfang <strong>og</strong> kalendertid– Rom for erfaringsbaserte justeringer i iterasjoner– Støtter integrert samarbeidsmodell– Felles incentiver om å levere kvalitet til avtalt tid <strong>og</strong>kostnad
Eksempel på kompensasjonsmodelli PERFORM (EV + AC) / 2(EV I kompensasjonsformelen er estimert kost på funksjonalitet som leveres <strong>og</strong> 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 <strong>og</strong> 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 <strong>smidige</strong> systemutviklingsprosjekt hvoret av hovedprinsippene er å unngå ”waste”.• Spesielt er det essensielt å redusere ressursbruk på initiellspesifikasjon, detaljert design <strong>og</strong> 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 <strong>og</strong>delprosjekt arkitektur i behovs <strong>og</strong> løsningsbeskrivelsesfasen– Løpende godkjenning gjennom kontrollpunkt i hver iterasjon– Leverer utviklings <strong>og</strong> testmiljø <strong>og</strong> har ansvar for drift <strong>og</strong>vedlikehold 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 <strong>og</strong>innføringDelprosjektarkitekturLBF TeamApp. Ark.TeamMiljøteamDelprosjekt testAksepttestkriterierFunksjonelltestGodkjenningsprøveRegelverkPL: SPKInnføring<strong>IT</strong>OSaksbehandlingssystemPL: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 <strong>og</strong> 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 <strong>og</strong> domenet.• Andre leveranseperiode ble kjørt på målpris fastrealiseringslinje <strong>og</strong> separatproduktkø for hver leverandør kundens godkjenningsprosess ble kjørt forførste gang.– Førte til mindre <strong>og</strong> 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<strong>og</strong> felles produktkø.– Produkteier <strong>og</strong> leverandør mer bevist på hva som er viktigst <strong>og</strong> har høyestprioritet– Letter å flytte ting rundt i køene <strong>og</strong> 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 <strong>IT</strong>O- 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 <strong>og</strong>godkjenningsprø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 <strong>og</strong> 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 <strong>og</strong> rettidige ytelser til våre kunder <strong>og</strong> medlemmer– sikrer en kostnadseffektiv innføring av reformen i SPK både med tankepå investering <strong>og</strong> 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 <strong>og</strong>optimalisering av nyttsaksbehandlersystem
Masterplanen definerer omfanget til PERFORMMasterplan :– 310 brukehistorier (epic,masterplanelementer) somdefinerer omfanget til PERFORM, disse er delt inn i 11funksjonelle områder <strong>og</strong> 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 <strong>og</strong> definert hvilke som må leveres til enleveransen. Disse går da inn i behovs <strong>og</strong>løsningsbeskrivelsen for leveransen <strong>og</strong> danner grunnlagfor målbildet for leveransen som kommuniseres til alle.
Løsningsbeskrivelse <strong>og</strong> produktkø– Gjennom Løsningsbeskrivelsesfase for hver leveranse brytesbrukerhistoriene ned til produktkøelementer.– Produktkøelementene gir grunnlag for oppdragsavtaler forkonstruksjon av løsning <strong>og</strong> 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 <strong>og</strong> 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 <strong>og</strong> 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 <strong>og</strong> 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 (<strong>IT</strong>)• Systemtest (ST)• Systemintegrasjonstest (S<strong>IT</strong>)• Godkjenningsprøve (GP)• Akseptansetest (AT)• Produksjonstest (PT)GPPerformGodkjenningsprøveDP-testET/<strong>IT</strong>ST/S<strong>IT</strong>Prosjekt PerformKonstruksjonDP-UtviklingATSPKsTestsenterRegresjonstestPTLeveranseapparatet SPKDP leveranse
Systemintegrasjonstest - S<strong>IT</strong>Erfaringer fra S<strong>IT</strong>• Finner feil tidligere <strong>og</strong> får rettet dem i konstruksjon• Kan gjøre gjennomløpende tester• Oppdager miljø- <strong>og</strong> 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 <strong>prosjekter</strong>– 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 <strong>og</strong>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 vurderesnedetid på 1 dag i tillegg)- Rettet opplæring av brukere- Superbrukere <strong>og</strong> 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 <strong>og</strong>prosjektdeltakere kan møte på demo.• Kjørbar kode i S<strong>IT</strong> miljø, interessenter kan benytte dette løpende• Brukerdokumentasjon <strong>og</strong> 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 <strong>og</strong> 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 <strong>og</strong> 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/<strong>IT</strong>ST/S<strong>IT</strong>Prosjekt PerformKonstruksjonDP-UtviklingATSPKsTestsenterRegresjonstestPTLeveranseapparatet SPKDP leveranse
Utviklingsmiljø vedlikeholdesav et miljøteam• Med 100 utviklere i PERFORM <strong>og</strong> ytterligere 30 i SPKsier det seg selv at utviklings <strong>og</strong> testmiljøene erkritiske.• De første 9 mnd med leverandører i PERFORMopplevde vi svært mye ustabilitet <strong>og</strong> støy– Opprettet miljøteam på tvers av <strong>IT</strong>-område i SPK <strong>og</strong>PERFORM– Ansvar• Utviklingsmiljøene er oppe• Oppsett av testmiljø• Tagging <strong>og</strong> branching• Oppgraderinger av utviklingsmiljø• Deploy <strong>og</strong> oppsett av de forskjellige testmiljøene• Produksjonssetting