Agile/iterative kontrakter Master Mind Class Embedded People Advokat Peter Lind Nielsen Februar 2014
Vandfald iterativ - konsulentydelser Vandfaldsmodel Kravspecifikation Totalleverancekontrakter K01 eller K02 Foranalyse/workshop GAP-analyse Fast pris, ydelse og tid Iterativ proces Behovsopgørelse/kravspecifikation? Valg af proces fx SCRUM e.l. udviklingsmodel Tid? Pris? Konsulentydelser Konsulentaftale køber alene timer Leveres til et agil projekt T&M timebetaling / fast pris Pas på med fast pris for hvad? Resultatansvar/arbejdsforpligtelse Side 2
TID YDELSE PRIS Side 3
Modsætninger - risici Side 4
Side 5
Side 6
Vandfald KRAV UDVIKLING AFLEVERING AFPRØVNING Side 7
Iterativ KRAV VURDERING ANALYSE TEST UDVIKLING Side 8
Forretningsprojekt eller it-projekt? ITST 10 arkitekturprincipper Nr. 1 Forretningsbehov bør drive og definere løsningerne Nr. 3 Processer bør optimeres i forbindelse med digitalisering Nr. 8 Udnyt mulighederne ved anskaffelser ITST 15 skarpe Nr. 4 Brug agile udviklingsmetoder og spis elefanten i små bidder Nr. 15 Del viden og samarbejd på tværs Side 9
IT- udredningen Indsatsområde 3: Bedre samarbejde med leverandører og rådgivere Mindre omfattende kravspecifikationer: Uddybende beskrivelse af initiativet Der igangsættes et antal pilotprojekter med henblik på at afprøve forskellige nye metoder for kravspecificering. Det undersøges bl.a., hvorvidt Vejledning til kravskabelon SL-07 fra behov til løsning, som professor på IT-universitetet Søren Lauesen har udviklet i dialog med Ministeriet for Videnskab, Teknologi og Udvikling, bør benyttes som et fælles værktøj for styrelsernes kravspecificering. Lauesens metode har som omdrejningspunkt, at en styrelse bør kravspecificere med udgangspunkt i, hvilke arbejdsopgaver it-løsningen skal understøtte, og ikke med udgangspunkt i en detaljeret opremsning af en lang række krav til, hvordan it-systemet teknisk skal opbygges. Ligesådan bør det klart formuleres, hvad der er de forretningsmæssige formål med den arbejdsproces, der skal it-understøttes, og hvilke forbedringer man ønsker at opnå set i forretningsperspektiv. Side 10
Indsatsområde 2: Fokus på de risikofyldte projekter: Etablering af fem principper for gennemførelse af it-projekter. 4. Projekterne skal opdeles i mindre og selvstændige værdiskabende dele, som besluttes og gennemføres uafhængigt af hinanden. Side 11
Agile manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right (rød), we value the items on the left (grøn) more. Ikke livretten for advokater! Side 12
Grundlæggende forskel Vandfaldsmodellen er baseret på tillid til kundens forberedende arbejde inden kontraktens indgåelse og mistillid til leverandørens kontraktopfyldelse Iterative modeller er baseret på tillid til parternes samarbejde ved kontraktens opfyldelse Side 13
Betydning af samarbejde Kernen i en iterativ proces er et tæt og dynamisk samarbejde mellem parterne, ofte via et fælles projektteam. Samarbejdet omfatter både forretningen og udviklere. Forretning og it arbejder sammen om at skabe forretningsværdi under styret risiko. Kontrakten skal samtidig styre risiko og understøtte samarbejde Side 14
ATERN Principles 1. Focus on the business needs The main criteria for acceptance of a "deliverable" is delivering a system that addresses the current business needs. Delivering a perfect system which addresses all possible business needs is less important than focusing on critical functionalities. 2. Deliver on time Timebox the work Focus on business priorities 3. Collaborate User involvement - users and developers share a workplace Involve the right stakeholders, at the right time, throughout the project Ensure that the members of the team are empowered to take decisions on behalf of those they represent without waiting for higher-level approval. Actively involve the business representatives Build one-team culture 4.Never compromise quality Set the level of quality at the outset Ensure that quality does not become a variable Design, document and test appropriately Build in quality by constant review Test early and continuously Side 15
ATERN Principles 5. Build incrementally from firm foundations Strive for early delivery of business benefit where possible Continually confirm the correct solution is being built Formally re-assess priorities and ongoing project viability with each delivered increment 7. Communicate continuously and clearly Communication and cooperation among all project stakeholders is required to be efficient and effective. Run daily team stand-up sessions Use facilitated workshops Use rich communication techniques such as modelling and prototyping Present iterations of the evolving solution early and often Keep documentation lean and timely Manage stakeholder expectations throughout the project Encourage informal, face to face communication at all levels 8. Demonstrate control Use an appropriate level of formality for tracking and reporting Make plans and progress visible to all Measure progress through focus on delivery of products rather than completed activities Manage proactively Evaluate continuing project viability based on the business objectives Side 16
Agile Vandfald Fokus Forretningsmæssigt: Understøttelse af behov og forretningsprocesser ved idriftsættelse og ikke ved projektinitiering Teknisk: Fokus på tekniske krav ved projektinitiering Funktionalitet Fastlægges endeligt i projektet. Kravspecifikation fastlægger Idriftsættelse Løbende afprøvning i drift Big bang = alt iværksættes og afprøves samlet Kravspecifikation Overtagelsesprøve Samarbejde Ydelser Fokus på forretningsprocesser, forretningsmæssige behov og fastlæggelse af mindstekrav. (Inspiration kan hentes i SL-07) Løbende test undervejs. Overtagelsesprøve tester understøttelse af forretningsprocesser samt at øvrige krav er opfyldt Dynamisk deltagelse fra begge parter, tillid til projektdeltagerne Projektledelse, rådgivning, metodekendskab, ressourcer Detaljeret angivelse af den funktionalitet, der skal etableres Kravspecifikation opfyldt Leverandøren udfører Etablering af funktionalitet Ændringshåndtering Processen og metoden håndterer Betydeligt ressourceforbrug, ændringer undgås helst Indsatsforpligtelse Resultatforpligtelse Side 17
Den iterative kontrakt Det er et valg overvej nøje Ikke alle projekter er egnede Ikke alle organisationer er egnede Regulere samarbejdet Parternes rettigheder og forpligtelser beskrives En vis grad af tillid (men heller ikke mere!) Men tilliden skal naturligvis være tilstede Risikoen og konsekvenser skal kunne overskues Risiko-allokering Tid, pris og ydelse Kræver fælles indsats af begge parter under hele projektet Projektstyring, projektstyring, projektstyring, projektstyring, projektstyring Side 18
Iterativ udviklingskontrakt Aftalte vilkår for anskaffelsen Procesregler/udviklingsmetode Enig om udviklingsproces/metode fx SCRUM Leverandøren indestår for kompetencer og erfaring med processen/metoden Krav fastsættes overordnet ved opstart Detailfastlægges løbende Evt. need-to-have/minimumskrav detaljeret beskrevet Der er en hovedtidsplan Detailtidsplan laves løbende Estimater for pris evt. med max Justeres løbende Der sker løbende aftestning og evt. afsluttende test Der kan forekomme tilbageløb Der er sanktioner ved misligholdelse Side 19
Udviklingsmodel - metode Beskrivelse af cyklus/sprints - iterationer Indhold af iterationer og kravene hertil Parternes deltagelse Godkendelse af dokumenter Krav/ydelse, pris og tidsplan Arbejdsfordeling og ansvarsfordeling Afslutning af hver iteration Kontrolpunkt/prøve/test/godkendelse Side 20
Faseopdeling Mulighed for opdeling af faser/delleverancer Uafhængige faser/udviklingsprojekter Afhængige faser/udviklingsprojekter Løbende tests og evalueringer Ændring af krav/specifikation/løsning Justering af ressourcer, tidsplan, vederlag Mulighed for at stoppe Alm. opsigelsesvarsel Stoppe ved milestones/faser Side 21
Betaling Fast pris money box Estimat Er estimat altid risikofrit for leverandøren? Estimat + risikotillæg = Max pris a la 02i Der skal leveres noget, der opfylder behovsopgørelsen Leverandørens forbehold - risikolog Gennemsigtighed Krav til opgørelse og dokumentation af tid Anvendt tid På opgaver I forhold til estimat I forhold til fremdriftsrapport Shared risk ved overforbrug Trappe hvor timeprisen efterhånden reduceres Pligt til reaktion hvis scope ændres! Side 22
Ydelsesbeskrivelsen Leverandøren må her styre hårdt Overordnede krav Business case Use cases Need-to-have Prioritering af kravene i hver fase/delleverance og hver sprint Ændring af overordnede krav eller beskrevne forudsætninger fx scope-creep Så skal der siges stop og evt. ændringshåndtering Leverandøren skal levere til tiden og inden for beløbsrammerne (hvis de findes) Brug af risikolog Side 23
Ændringshåndtering Ændring eller en del af det iterative projekt Fremad eller tilbage for allerede leverede ydelser? Færre ændringer end ved vandfald? Hvem kan fremsætte ændringsanmodninger Nedskæring/forøgelse af projektet Tidsfrister for anmodning Udarbejdelse af konsekvensanalyse Pris, tidsplan, øvrig funktionalitet Betaling for foretagelse af analyse Godkendelse før igangsætning Pas på håndhæv krav om godkendelse Side 24
Test og afhjælpning Side 25
Governance Visibility - Control Application Lifecycle Costs Incurred to Value Delivered - Desired Value Plan Define/ design Develop Test Launch Operate Time New deployment New Capability Fix/patch Minor release Fix/patch Minor release Fix/patch Maintenance Mode Go Live Costs Side 26
Prøver/tests Test op imod krav opfyldes de Test ofte Etablering af udviklings-/testmiljø Hvem gør hvad og har ansvaret for hvad Testscripts, testdata, testprocedurer Flere og løbende prøver/tests Deltest/funktionstest/unittest Regressionstest og automatiserede tests Integrationstests Overtagelsesprøve(r) Driftsprøve/pilottest testkunder Driftsprøve(r) Side 27
Prøver/tests Hvornår - indkaldelse, varsel, tidsplan Hvad testes Konsekvenser ved godkendelse Krav til godkendelse/nægtelse Meningen med visse tests kan netop være at finde fejl, og ikke at det er fejlfrit! Konsekvens ved manglende godkendelse sanktioner? Side 28
Kundens medvirken Deltagelse i møder, tests og andre aktiviteter - estimat Arbejdsforpligtelse i øvrigt Testdata, konvertering af data Hvad består kundens indsats i ved prøver/tests "Kravspecifikation" vedrørende kundeleverancen Layout, grafik, billeder, tekst Krav til format, afleveringsfrist Kompetencer/viden hos kunden der er nødvendig Beslutningskompetence Snitflade mellem kunde og leverandør bidrag Skal klarlægges med ansvarsfordeling Side 29
Projektorganisation Stærk ledelse med klar ansvarsplacering Løbende statusmøder Klar kompetencefordeling mellem de forskellige lag Nedsættelse af arbejdsgrupper m.v. Placering af initiativpligten Ikke det samme som leveranceansvar Eskaleringsprocedurer Projektstyringsværktøjer Status og fremdriftsrapport hver dag/7./14./måned Tag fat om problemet/tvisten med det samme! Side 30
Kort om rettigheder Udgangspunktet - Leverandøren har alle ophavsrettigheder, og kunden kun en brugsret Kunden kan ikke ændre og videreudvikle! Kunden bør sikre sig rettighederne enten alle ophavsrettigheder eller en udvidet brugsret med ret til fri brug, ændring og videreudvikling Tredjemandsrettigheder er de clearet? Biblioteker, run-time licens, open-source Kildekoden Udleveres evt. løbende Deponering? Brug af udviklingsværktøj Standard eller leverandørens eget udviklet Evt. ret til evaluering/kontrol ved tredjemand for at sikre god skik Dokumentationen Hvem skriver hvad Side 31
Forsinkelse Projektstyring med referater m.v. Løbende fremdriftsrapport Nedbrudt på iterationer Hvem skal bære risikoen Øvrige leverancer, sygdom m.v. Hvem er skyld i forsinkelsen Sanktioner Dagbod Reduceret timepris for tid anvendt efter aftalt afleveringsfrist Side 32
Mangler Mangelsvurderingen kan være vanskelig Fejl bør afhjælpes uden vederlag Programmeringsfejl dårligt håndværk Mangler i form af manglende udvikling? Fast pris afhjælpes uden betaling Medgået tid kræve betaling for afhjælpning Kan være vanskeligt at sondre Evt. betaling af reduceret timepris ved afhjælpning Side 33
Opsigelse/annullation Ikke misligholdelse Kan det laves færdigt eller er alle pengene spildt? Rettigheder, dokumentation etc. Opsigelse Fastlagte milestones Opsigelsesvarsel Betaling af opsigelsesgebyr? Følge af opsigelse Hvad skal der ske i opsigelsesvarslet Betaling for arbejdet indtil opsigelse Rettigheder til det der er leveret Leverandørens garantier mangelsafhjælpning? Side 34
K03 - grundlæggende Leverancen (Hele behovsopgørelsen kravlisten) Delleverancer Iterationer Delleverancer, der overtages hver for sig Med overtagelses- og driftsprøve pr. delleverance Hver Delleverance indeholder flere iterationer Planlægning, kravfastlæggelse, estimering og test pr. iteration Ingen juridiske sanktioner koblet til iterationer Vedligeholdelse og drift iværksættes pr. Delleverance Bod for forsinkelse pr. Delleverance Vederlag fast pr. Delleverance Tiden er fast pr. Delleverance Ydelsen er ikke fast Absolutte krav Øvrige krav Side 35
Resultat- ctr. indsatsforpligtelse Resultatforpligtelse Opfyldelse relateres til et på forhånd defineret resultat Ved en prøve kan kravopfyldelse verificeres krav for krav Mere sort/hvidt, hvorvidt et krav er opfyldt Selv en ringe opfyldelse kan være et mangelfrit resultat Fokus på kravopfyldelse Indsatsforpligtelse Kvalitetskrav til indsats fastlagt Overordnede krav til resultat fastlagt Opfyldelse relateres til viden på tidspunktet for levering af den pågældende indsats Vurdering ud fra et fagligt skøn, hvorvidt der foreligger en mangel ved indsatsforpligtelse Side 36
Resultat- ctr. indsatsforpligtelse K03 pkt. 3.2.2 Leverandøren er forpligtet til som minimum at levere sådanne leverancer, der opfylder de krav i Kravlisten (Bilag 3a.ii), som er angivet som Absolutte Krav, og skal bestræbe sig på at levere så mange af de Øvrige Krav som muligt. Absolutte Krav = Resultatforpligtelse Øvrige Krav = Indsatsforpligtelse Side 37
Absolutte krav ctr. øvrige krav Krav angives i en kravspecifikation/kravliste Absolutte Krav Krav (funktionelle og non-funktionelle) angivet i Kundens Kravliste (Bilag 3a.ii), som Kunden har angivet som uundværlige for opfyldelsen af Kundens Forretningsmæssige Mål og Behov og dermed som grundlæggende elementer i Leverancen. Øvrige Krav Krav (funktionelle og non-funktionelle) angivet i Kundens Kravliste (Bilag 3a.ii), som ikke udgør Absolutte Krav. Side 38
Absolutte krav og øvrige krav Væsentlig sondring Kun absolutte krav skal opfyldes Anbefales max 60 % som Absolutte Krav Prioriteringen vanskelig Anbefales at alt først prioriteres som øvrige krav og herefter opgraderes Side 39
Faseopdeling i K03 ophævelse og udtræden Væsentlig misligholdelse En samlet overskridelse af fristerne for godkendt overtagelsesprøve og driftsprøve for en Delleverance med mere end [40] Arbejdsdage Såfremt Leverandøren på et givent tidspunkt i to på hinanden følgende opgørelsesperioder pådrager sig maksimal bod for manglende overholdelse af servicemål, jf. pkt. 25.2.2. HR: Kun ophævelse for fremtiden. Ikke ophævelse for overtagne Delleverancer Leverandøren stilles bedre end ved brug af K02 U1: Regulering vedr. betinget overtagelse som følge af Indbyrdes afhængigheder mellem Absolutte Krav Mulighed for kunden at opsige aftalen Side 40
Indledende overvejelser Egner projektet sig til et agilt forløb Egner det sig til en K03 Har kunden fornødne kompetencer, ressourcer og modenhed Er kunden opmærksom på de relevante risici Har kunden den fornødne beslutningskompetence repræsenteret og kulturen Er de forretningsmæssige mål og absolutte krav beskrevet Kendskab til den agile metode Side 41
Farer Kundens overblik mistes Samlet løsning Fokus på business case og forretningsprocessor mistes Prioritering af krav Træffes de rigtige beslutninger Hvornår stoppes der? Opsigelse! Kundens våben Sikrer IPR og værktøjer Kan der skiftes leverandør? Side 42
Øvrigt materiale om agile kontrakter ITST s vejledning: Agile metoder i it-baserede forretningsprojekter 01i, 02i og 03i PS 2000 (norsk standardkontrakt) Almänna Bestämmelser Agile projekt version 2010 (svensk standardkontrakt) Side 43
Thank you Peter Lind Nielsen Advokat (H), partner peter.nielsen@twobirds.com Mobil 20 75 27 46 BIRD & BIRD ADVOKATPARTNERSELSKAB Bird & Bird Advokatpartnerselskab er et registreret selskab i Danmark under CVR-nr. 35 14 45 01. Alle vores advokater er medlem af Advokatsamfundet og underlagt de advokatetiske regler fra Advokatrådet. Reglerne er tilgængelige her: www.advokatsamfundet.dk. BIRD & BIRD Bird & Bird LLP, er et registreret partnerskab, registreret i England og Wales under registreringsnummer OC340318, der er autoriseret og underlagt Solicitors Regulation Authority, og dets regler og retningslinjer der er tilgængelige her: sra.org.uk/handbook/ For yderligere information om Bird & Bird internationalt, herunder Bird & Bird LLP, dets filialer og associerede selskaber (samlet benævnt Bird & Bird ), vores kontorer, ansatte, partnere og rådgivningsområder, brug af e-mails og regulatoriske forhold, se vores website på twobirds.com og navnlig Legal Notices.