Kontrakt for oppdragsbasert smidig utvikling av programvare PS2000 SOL IT-kontraktsdagen Dataforeningen, 10.09.13 v/ Jørgen Petersen, PROMIS AS DEN NORSKE DATAFORENING Vi engasjerer, påvirker og skaper fremtid!
Innhold 1. Bakgrunn og hensikt 2. Kontraktstruktur og innhold 3. Gjennomføringsmodell 4. Etablering og gjennomføring av leveranser 5. Ressurser, kapasitet og estimering 6. Risiko og prismodeller 7. Mislighold nr 2
1. Bakgrunn og hensikt Dataforeningens arbeidsgruppe Arbeidsgruppen ble nedsatt av Dataforeningens styre for Faggruppen for ITkontrakter høsten 2012, med tilnærmet lik representasjon fra både kunde-, leverandør- og rådgiversiden: Advokatfirmaet Haavind AS, ved Dag Thorstensen Advokatfirmaet Simonsen Vogt Wiig AS, ved Trine Vabog Arbeids- og velferdsetaten (NAV), representert ved en konsulent fra PROMIS AS, Odd Gunnar Alterhaug Bekk Consulting AS, ved Fritjof Frederiksen Capgemini Norge AS, ved Bodil Rabben Computas AS, ved Anne-Lise Ystebø Monsen Direktoratet for forvaltning og IKT (Difi), ved Bent J. Syversen PROMIS AS, ved Jørgen Petersen Statens lånekasse for utdanning, ved Kari Anne Støkken Timebox AS, ved Kathrine Breistøl nr 3
1. Bakgrunn og hensikt Dataforeningens kontraktshistorikk Forskningsprogrammet PS2000 var Europas største forskningsprogram innen prosjektledelse, under ledelse av NTNU og SINTEF Forskningsprogrammet PS2000 eget prosjekt spisset mot IT under ledelse av PROMIS Erfaringsinnsamling fra større IT-prosjekter Beskrivelse av en beste praksis og gjennomføringsmodell for ITprosjekter Den Norske Dataforening har forvaltningsansvaret for PS2000 kontraktsstandardene gjennom Faggruppe for IT-kontrakter Faggruppen forvalter PS2000, PS2000 Smidig og tilhørende kontraktsstandarder Den smidige kontraktsstandarden PS2000 SOL er et selvstendig alternativ nr 4
nr 5 1. Bakgrunn og hensikt Dataforeningens kontraktsmodell
1. Bakgrunn og hensikt PS2000 og PS2000 Smidig Alternative smidige kontrakter Forutsetter en behovsanalyse som danner grunnlag for en komplett leveranse med et definert omfang Endringshåndteringsprosessen i kontrakten må benyttes for senere avdekket endringsbehov knyttet til omfang Dataforeningens nye smidige utviklingsavtale: PS2000 SOL I mange smidige prosjekter er det i første omgang kun hensiktsmessig å definere mål og rammer for prosjektet samt innledningsvis å detaljere de høyest prioriterte behovene utfra nytteverdi Detaljering av øvrige funksjonelle og ikke-funksjonelle behov avventes til erfaringer med de første leveransene er vunnet Baseres på oppdragsbasert utvikling ut fra en gitt estimeringsmodell og forhåndsavtalt kapasitet Difi kommer også med en smidig avtale etter hvert Det antas at denne blir basert på mindre leveranser med kort horisont nr 6
1. Bakgrunn og hensikt Grunnleggende prinsipper Kontraktsstandarden er oppdragsbasert, dvs at det må inngås underliggende bistands- og oppdragsavtaler for alt som skal leveres Kontraktsstandarden kan benyttes for grunnutvikling av ny programvare og for videreutvikling av programvare over tid I tillegg kan utvikling av programvare omfatte systemintegrasjon og eventuelt konfigurering av standard programvare som er av betydelig omfang Kontraktsstandarden er utviklet for relativt langvarig kontraktsforhold med leverandør, med omfattende regulering både av: oppstartsaktiviteter kapasitet og ressursbruk estimeringsmodell og målinger knyttet til denne endringer og sanksjoner knyttet til mislighold nr 7
1. Bakgrunn og hensikt Hvorfor en kontraktsstandard for oppdragsbasert smidig utvikling? Målbildet Overordnet produktkø Effekt- og resultatmål Overordnede behov (Epos) Kontinuerlig prioritering av kundens behov for hver leveranse, og ved behov også for hver iterasjon Produktkø Brukerhistorie Brukerhistorie Ut fra definerte mål og rammer detaljeres kun de høyest prioriterte behovene Iterasjonskø Oppgave Oppgave Oppgave Oppgave Beslutninger kan tas så sent som mulig basert på evaluering og læring underveis nr 8
1. Bakgrunn og hensikt Hvorfor gjennomføre smidig utvikling basert på kontrakt? Deling av resultatansvar og økonomisk risiko med leverandør Tydelig og avtalt arbeidsdeling mellom kunde og leverandør Klare krav til både kundens og leverandørens forarbeid Fokus for leverandøroppfølging endres fra oppfølging av timer til oppfølging av kvalitetskrav for utviklingstjenester Forpliktelser til kapasitet og estimeringsmodell er regulert Lettere etterlevelse av krav til regelverk for offentlige anskaffelser nr 9
1. Bakgrunn og hensikt Når egner denne kontraktsstandarden seg? Behov for smidig gjennomføringsmodell med løpende prioritering av behov ut fra definerte mål og rammer Kunden har erfaring og god modenhet innenfor smidig systemutvikling ressurser med god innsikt i de aktuelle forretningsprosessene og erfaring fra produkteierrollen tilstrekkelig forutsigbarhet vedrørende leveransemilepæler og kapasitetsbehov Kunden er systemintegrator, ved egne ressurser eller ved kjøp av tjenester, med ansvar for Arkitekturstyring og overordnet virksomhetsarkitektur Produkteierskap og forberedelse av produktkøen Prosesser og metode for smidig gjennomføringsmodell Leveranse- og kapasitetsplanlegging Gjennomføring av kontrollpunkt og godkjenningsprøve Tilgang til utviklingsverktøy og eventuelle standardprodukter samt teknisk infrastruktur Samme leverandør utfører både utvikling og vedlikehold av programvaren nr 10
1. Bakgrunn og hensikt Er det en motsetning i forhold til andre kontraktsstandarder? Alle prosjekter styres i forhold til konkurrerende krav til omfang, tid og kostnader Alternativ smidig modell tilrettelegger for å endre den kontraktsmessige balansen mellom omfang, tid og kostnad slik at omfang kan justeres nr 11
2. Kontraktsstruktur Kontrakten består av følgende deler Del I Kontraktsdokument Del II Generelle kontraktsbestemmelser Partenes plikter Organisering av arbeidet og partenes sentrale roller Prosessene innenfor gjennomføringsmodellen og hvordan bistands- og oppdragsavtaler etableres Økonomiske vilkår Juridiske bestemmelser, herunder sikkerhet, rettigheter, mislighold, avbestilling og endringer Del III Bilag Beskrivelse av programvaren (ved grunnutvikling av ny programvare beskrives overordnede behov, løsningsmålbilder og krav til løsningsområdet/subsystem) Gjennomføring av oppstartsaktiviteter og kontraktsprosesser for konsulentbistand og systemutvikling samt etablering av bistandsavtaler og oppdragsavtaler Leverandørens kapasitet, ressurser og ansvar Faste møter og rapportering samt andre administrative forhold Priser, estimeringsmodell og vederlagsmodeller Mal for oppdragsavtaler, bistandsavtaler og oppdragslogg nr 12
2. Kontraktsstruktur Avtaledokumenter på ulike nivåer nr 13
3. Gjennomføringsmodell Smidig modell som består av fire hovedprosesser for en leveranse Behovsanalyse I behovsanalysen defineres og prioriteres kundens behov gjennom funksjonelle og ikke-funksjonelle brukerhistorier Løsningsbeskrivelse Løsningsbeskrivelsen er partenes detaljering og avklaring av behovsanalysen slik at løsningen som skal utvikles, er definert på et hensiktsmessig nivå for etterfølgende konstruksjon Konstruksjon Under konstruksjon utvikler leverandøren programvaren gjennom et avtalt antall iterasjoner i henhold til signerte og omforente brukerhistorier, løsningsbeskrivelser og estimater Godkjenningsprøve Godkjenningsprøven er kundens avsluttende verifikasjon og godkjenning av en leveranse Godkjenningsprøve Behovsanalyse Løsningsbeskrivelse Løsningsbeskrivelse Konstruksjon nr 14
4. Etablering og gjennomføring av leveranser Senere leveranser nr 15
4. Etablering og gjennomføring av leveranser Innhold i bistands- og oppdragsavtaler Bistandsavtalene omfatter all bistand fra leverandøren som ikke er direkte knyttet til utvikling av programvaren De består i hovedsak av leverandørens bistand til behovsanalyse og utarbeidelse av løsningsbeskrivelser, men kan også omfatte bistand til andre oppgaver knyttet til programvaren Bistandsavtalene regulerer kapasitet, ressurser, hovedmilepæler og rammebetingelser for bistand for en periode som normalt vil ligge innenfor to til seks måneder nr 16
4. Etablering og gjennomføring av leveranser (tillegg) Innhold i bistands- og oppdragsavtaler Oppdragsavtalene omfatter leverandørens arbeid med utvikling av programvaren under konstruksjon og feilretting i godkjenningsprøven Oppdragsavtalene består igjen av to deler: Statisk del: Gjelder oppdragsavtalen som helhet, og regulerer blant annet oppdragets bemanning, timeomfang, vederlagsmodell milepæler, antall iterasjoner og godkjenningskriterier for leveransene innenfor oppdragsavtalen Dynamisk del: Den delen av oppdragsavtalen som består av prioriterte brukerhistorier med tilhørende godkjente estimater og løsningsbeskrivelser Den dynamiske delen utarbeides normalt i flere versjoner underveis i leveransen der hver nye versjon inkluderer nye brukerhistorier som kunden prioriterer inn i neste eller senere iterasjoner nr 17
4. Etablering og gjennomføring av leveranser (tillegg) Kontrollpunktets betydning Kontrollpunktet er en kontraktuell milepæl Det er kunden som godkjenner/underkjenner brukerhistorier som er innlevert til kontrollpunktet De forholdene som man eksplisitt ikke tar stilling til i kontrollpunktene, vil kunne adresseres i senere iterasjoner, i leverandørens avsluttende systemtest eller i godkjenningsprøven Kunden kan ikke senere i leveransen kunne påberope seg mangler i forbindelse med forhold som allerede er godkjent i et kontrollpunkt Koordineringsgruppen, eller partenes prosjektledere, kommer sammen for å sikre en formell godkjenning Med produktkøen som del av kontraktsgrunnlaget, vil signert produktkø regulere endringer (dvs. forenkle endringsregimet) nr 18
5. Ressurser, kapasitet og estimering Mobilisering og opprettholdelse av kapasitet Mobiliseringsplan Partenes initielle oppbemanning skal foregå i henhold til definert mobiliseringsplan Mobiliseringsplanen inneholder også milepæler for inngåelse av initielle bistandsavtaler og den første oppdragsavtalen Gjensidig kapasitetsforpliktelse nr 19 Leverandøren skal i avtaleperioden ha tilgjengelig kapasitet som tilsvarer et definert antall fulltidsekvivalenter for å gjennomføre bistandsog oppdragsavtaler Kontrakten regulerer prosess og terskler for endringer av kapasitetsbehov innenfor en frist på et antall arbeidsdager og totalt i kontraktsperioden Kontrakten har regulering for midlertidig stans av avtaler, avbestilling av avtaler og eventuelle situasjoner der kunden ikke inngår avtaler med tilstrekkelig omfang for bruk av avtalt kapasitet
5. Ressurser, kapasitet og estimering Endringer av samlet avtalt kapasitet for bistand og oppdrag Kapasitet Maksimal samlet økning av avtalt kapasitet Kapasitet ved oppstart konstruksjon Endringer av avtalt kapasitet Maksimal samlet reduksjon av avtalt kapasitet Kunden kan kreve økning av avtalt kapasitet på inntil en prosentsats i forhold til avtalt kapasitet, totalt begrenset til en samlet prosentsats på en høyere prosentsats over kontraktsperioden. Tilsvarende ved ønske om reduksjon Avtaleperioden nr 20
5. Ressurser, kapasitet og estimering Estimeringsmodell og referanseestimater Estimeringsmodellen skal brukes for å utarbeide estimater for utvikling innenfor den enkelte oppdragsavtale Estimeringsmodellen skal omfatte referanseestimater for kjerneestimater Partene kan bli enige om endringer av påslagsfaktorene på kjerneestimatet innenfor definerte terskler Etter hvert som partene får erfaring fra konstruksjon, kan estimeringsmodellen gradvis erstattes av parvis sammenligning av brukerhistorier nr 21
5. Ressurser, kapasitet og estimering Endringer og avbestilling Endringsprosedyrer er kun knyttet til ressurser, kapasitet og estimering (beskrevet i det foregående) Andre endringer håndteres ved å utstede nye versjoner av bistands- og oppdragsavtalene Dersom kunden har behov for avbestilling av bistands- eller oppdragsavtaler, er betingelser for dette regulert i kontrakten Videre er det beskrevet en prosedyre som kan benyttes dersom det er behov for å avbestille hele kontrakten nr 22
6. Risiko og prismodeller Risiko må vurderes i forhold til ønske og mulighet til å ta risiko Risikovurdering for en leveranse legges til grunn for valg av prismekanisme (grunnrisiko) Målpris risikodeling mellom kunde og leverandør Preferert prismekanisme Avvik fra målprisen (under-/overforbruk) deles likt mellom kunde og leverandør Løpende timer kunden tar økonomisk risiko Fastpris leverandøren tar økonomisk risiko Ved målpris eller fastpris gjøres en vurdering av konkrete risikofaktorer som grunnlag for å definere usikkerhetspåslaget innenfor estimeringsmodellen Målpris er den prefererte modellen da det gir en balansert fordeling av risikoen mellom kunde og leverandør nr 23
7. Mislighold Misligholdsbestemmelser tilpasset smidig modell Leverandørens mislighold Mangler ved løsningsbeskrivelsen (når leverandøren har ansvaret) Forsinkelse i en oppdragsavtale (kun for godkjenningsprøven) Vesentlige avvik mellom estimat og faktisk forbruk i en leveranse Manglende bemanning i forhold til avtalt kapasitet Kundens mislighold Kundens betalingsplikt Medvirkning ved gjennomføring og andre plikter Leverandøren kan midlertidig ikke utnytte avtalt kapasitet Kunden ikke inngår tilstrekkelig omfang av bistands- og oppdragsavtaler nr 24
nr 25 Resultat Dataforeningens kontraktsmodell