Claus F. Sørensen
KONTRAKTUNDERSTØTTELSE AF ITERATIVE PROJEKTMODELLER Advokat (L), cand.merc. Claus F. Sørensen AGENDA 13:30 – 14:00 Registrering 14:00 – 14:10 Velkomst og introduktion til emnet 14:10 – 14:30 Generel introduktion til den juridiske vinkling af iterative projekter og agil programudvikling 14:30 – 15:00 Kontraktretlige temaer i den iterative it-kontrakt med særlig focus på emnerne leverancebeskrivelse, prismodeller, kontrakt/projektstyring 15:00 – 15:15 Pause 15:15 – 16:00 Fortsat gennemgang af kontraktretlige emner 16:00 – 16:15 Pause 16:15 – 16:30 Iterative projekter og udbudsreglerne 16:30 – 17:00 Tak for i dag / spørgsmål (buffer) VELKOMST OG INTRODUKTION TIL EMNET VELKOMST OG INTRODUKTION TIL EMNET Advokater og de interne juridiske afdelinger må nødvendigvis se på kontraktgrundlaget for iterative projekter med nye og innovative øje og holdninger. VELKOMST OG INTRODUKTION TIL EMNET “Recently, I attended a talk by an excellent lawyer on software contracts. Her message was quite clear: write a sound and detailed specification and contract the vendor based on this document. Seems simple enough, but I raised my hand and asked her how to deal with the fact that projects are much more efficient and have fewer risks when done iteratively and in an agile way as compared to the waterfall style she had laid out. "Well, these are business problems, and I'm not a business expert" was her reply.” “She was right: the life of a lawyer would be much easier, if perfect specifications were written right from the beginning - and the life of a project manager would be easier, too. But project managers have tried this path for 20 years without any significant success. And some "experts" claim that the method we use is not right, and we only need to use/buy their great tool or process to solve any problems. But they have been telling us this for 20 years, and their claims resemble Jerry Weinberg's first law of bad management: "If what you're doing isn't working, do more of it“. Kilde: Cutter Consortium GENEREL INTRODUKTION TIL DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Traditionelle vs. Iterative kontrakter Den traditionelle kontraktopfattelse • forventning om, at kontrakten kan placere og definerer parternes ansvar, medvirken og roller i projektet • Kontrakten bør fordele ansvar på en “fair” måde, så enhver kun er ansvarlig for det kontraktparten faktisk har indflydelse på. • disse antagelser hviler på en forudsætning om, at målet for projektet er kendt. Den agile kontrakts udfordring • Agile projekter kræver i højere grad, at projekterne er baseret på sharedprofit kontrakter. (mål-pris, fleksible tidsplaner fleksibelt scope) • Dvs. et ”skæbnefællesskab”, som ikke er særligt populært i de afdelinger der tager sig af indkøb, jura og styring. DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Traditionelle vs. Iterative kontrakter DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Traditionelle vs. Iterative kontrakter Vandfaldsmodellen er baseret på tillid til kundens forberedende arbejde inden kontraktens indgåelse og mistillid til leverandørens kontraktopfyldelse. Iterative kontrakter er baseret på tillid til parternes samarbejde ved kontraktens opfyldelse. DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Traditionelle vs. Iterative kontrakter • Samarbejde er omdrejningspunkt i iterative kontrakter. Kernen i en iterativ proces er et tæt og dynamisk samarbejde mellem parterne – ofte via fælles projektteam. • Samarbejdet omfatter både ”projektet” og udviklere. Forretning og IT skal arbejde sammen om at skabe forretningsværdi under styret risiko. • Kontrakten skal derfor styre risiko og facilitere samarbejdet. DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Traditionelle vs. Iterative kontrakter • Implementering af iterative projekter kræver i høj grad, at fokus flyttes fra kontraktstyring til projektstyring. … hvilket stiller krav til kontraktens fokus. DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Den procesorienterede aftale • I stedet for alene at basere kontrakten på et resultat, baserer man den på en proces, der skaber dette resultat. • Og derfor bliver kontrakten som styringsredskab for processen helt afgørende. • Kontrakten skal have særlig fokus på reguleringen af processen og styringen af processen. • Den skal i (endnu) højere grad styre projekts gennemførelse end en traditionel vandfaldsbaseret kontrakt DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Den procesorienterede aftale • Kontrakten skal navnlig have fokus på • Samarbejdsrelation mellem parterne • Bemanding af projektet • Den iterative metode • Projektledelse og projektstyrelse • Prioritering af krav og ønsker • Fremdriftsrapportering og risklogs • Styring af økonomi og tid DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Den procesorienterede aftale • 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 samarbejde på tværs DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING IT udredning 2010 • Indsatsområde 1: Kompetenceløft og fælles metoder: Fælles projektmodel i staten – skal skaleres i forhold til projektets størrelse og risikoprofil, og der udarbejdes en ”light-model” for mindre it-projekter • 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. Indsatsområde 3: Bedre samarbejde med leverandører og rådgivere Mindre omfattende kravspecifikationer DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Grundlæggende vilkår for den iterative proces Kontrakten skal fortsat respektere, at iterative projekter er hverken rendyrket anarki eller et tag-selv bord for leverandøren DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING Grundlæggende vilkår for den iterative proces Agile kontrakter bør derfor hvile på følgende hovedregler: • Ændringer er gratis på ikke påbegyndt funktionalitet • Ændringer i prioritet er gratis, forudsat totalen ikke ændre sig • Nye funktioner/krav kan lægges ind undervejs – så længe funktionaliteter/krav af tilsvarende størrelse tages ud • Kunden kan opsige/afbryde samarbejdet når som helst mod betaling af forud defineret udtrædelsesvederlag • Kunden skal være i stand til at prioritere alle sine krav indbyrdes • Kunden er ansvarlig for, at relevante og kompetente brugere følger og deltager i projektet og at disse er udstyret med tilstrækkeligt ansvar og beslutningskompetence for at kunne give leverandøren nyttigt feedback og i øvrigt bidrage uden at forsinke projektet DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING På vej til den iterative kontrakt • Juli 2008: SKI 02:18 • April 2009: SKI vejledning til udformning af kontrakter under 02.18 med brug af iterative forløb • Efterår 2009: 01i, 02i, 03i (BvHD – DAHL) • Marts 2010: ITST redegørelse • Ultimo 2012:K03 DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING På vej til den iterative kontrakt • 01i, 02i og 03i • Mindre projekter kan anvende 01i eller 03i • Større projekter kan anvende 02i • 01i er baseret på K01, 02i er baseret på K02 • 03i er formuleret mere frit i forhold til K-kontrakterne DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL PROGRAMUDVIKLING På vej til den iterative kontrakt Fællestræk ved 01i, 02i og 03i • Krav til modenhed • Business case • T&M/Maksimalpris • Metodeneutral • Fokus på samarbejde, ressourcestyring og prioritering • Fleksibel udtrædelsesadgang for kunden KONTRAKTRETLIGE TEMAER I DEN ITERATIVE IT-KONTRAKT MED SÆRLIG FOCUS PÅ EMNERNE LEVERANCEBESKRIVELSE, PRISMODELLER, KONTRAKT/PROJEKTSTYRING LEVERANCEBESKRIVELSE OG PROJEKTGENNEMFØRELSE KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Leverancebeskrivelsen er ikke slutproduktet • Ydelser - Leverandørens ydelser er andet end blot etablering af forud fastlagt funktionalitet • Metodeanvendelse • Projektledelse • Ressourcestyring • Rådgivning • (SKI vejledning pkt. 2.4 – s. 10) • Procedure og samarbejde - Større krav til forankring i kontrakten af projektledelse, beslutningskompetence og procedurer. • Krav - Kravspecifikationen får en anden rolle. Virker som ramme for samarbejdet og prioriteringsoversigt, mens de konkrete funktionalitetskrav fastlægges undervejs KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Håndtering i K01 og K02 • Kunden udarbejder kravspecifikation, og denne danner grundlag for leverandørens besvarelse. • HR: Kravspecifikation forventes at være udtømmende oplistning. • U. ”Hvad kunden med føje kan forvente” • Kunden er hovedansvarlig for, at kravene er formuleret entydigt. • Leverandøren er primært ansvarlig for opfyldelsen KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Håndtering i iterative kontrakter • Kunden udarbejder en Behovsopgørelse, som skal indeholde: (i) beskrivelse af Kundens Business Case, (ii) de forretningsgange, Leverancen skal understøtte, samt (iii) overordnet beskrivelse af ønsket funktionalitet • Dette dokument danner grundlag for leverandørens tilbud KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Håndtering i iterative kontrakter • Indhold af business case • • • • • • • • • • • Forretningsmæssige mål Baggrund for valg af projekt model Interessenter Beskrivelse af løsning Delprojekter Specifikke ”constraints” Kunderessourcer til rådighed Afhængigheder Risici Opfølgning Etc. • Den Digitale Taskforce, Videnskabsministeriet, KL og Danske Regioner: ”Business case for digitaliseringsprojekter” http://modernisering.dk/da/projekter/business_case/ • KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Håndtering i iterative kontrakter • Brug af business case • Planlægning • Dialogværktøj i forholdet kunde – leverandør • Grundlag for leverandørens udarbejdelse af tilbud • Leverandørens tilbud kan eventuelt kræves relateret direkte til kundens business case • Afklaringsfasens forløb kan styres af business case • enyttes af kunden til efterfølgende intern evaluering af projektets forløb KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Løsningsbeskrivelse • På baggrund af kundens behovsopgørelse udarbejder leverandøren en Løsningsbeskrivelse forud for aftalens indgåelse. ”Leverandørens overordnede besvarelse af Kundens Behovsopgørelse ved Kontraktens indgåelse. Løsningsbeskrivelsen udgør en del af Leverancebeskrivelsen og vil – som den øvrige del af Leverancebeskrivelsen – løbende undergå ændringer undervejs i Projektet.” KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Løsningsbeskrivelse - detailspecifikation • Under de efterfølgende iterationer frembringes løbende en række detailspecifikationer. • Når detailspecifikationerne er godkendt af Kunden, udgør disse en del af Leverancebeskrivelsen sammen med Behovsopgørelsen og Løsningsbeskrivelsen. KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Leverancebeskrivelse • Leverancebeskrivelsen = Behovsopgørelse+Løsningsbeskrivelse+detailspecifikationer • Leverandøren skal holde Leverancebeskrivelsen løbende ajour med godkendte detailspecifikationer samt foretage de fornødne konsekvensrettelser af Behovsopgørelsen og Løsningsbeskrivelsen, som den enkelte Iteration giver anledning til, og indhente Kundens godkendelse heraf ved Iterationens afslutning. • Den gældende udgave af Leverancebeskrivelsen skal til enhver tid være elektronisk tilgængelig for Kunden på et Projektsite eller lignende. KONTRAKTRETLIGE TEMAER LEVERANCEBESKRIVELSE Leverancebeskrivelse – alternativ model uden behovsopgørelse Kunne baseres på ”sure step” metoden. I den forbindelse gennemføres en diagnose og analysefase. • Diagnosefasen • tilvejebringelse af overordnet løsningsbeskrivelse • Analysefasen • definere og fastlægge de aktiviteter, der er nødvendige med henblik på at få defineret og planlagt hele projektet Denne model er velegnet til mindre projekter, men kræver stor parathed hos Leverandøren og er baseret på en grundlæggende forudsætning om, at Kunden ønsker en standardløsning i så vid udstrækning som muligt. KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel - iterativt KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel – i01 og i02 • De overordnede faser i i01 og i02 • Afklaring • Design, udvikling og test • Godkendelse og overtagelse KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel – i01 og i02 • De overordnede faser i i01 og i02 • Afklaring • Fortsat behov for grundlæggende drøftelser af kundens behovsopgørelse og belysning af risikofaktorer i projektet KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel – i01 og i02 • De overordnede faser i i01 og i02 • Design, udvikling og test • Etablering af udviklingsmiljø og testmiljø • Design og udvikling baseres på den valgte iterative model • definition og beskrivelse af trin • Kontrolpunkter • Testprocesser • Delovertagelse og ibrugtagning KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel – i01 og i02 • De overordnede faser i i01 og i02 • Godkendelse og overtagelse • Projektet godkendes og overtages samlet …. men reduceret betydning KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel – i01 og i02 Aktiviteterne i en fase (vil afhænge af den valgte iterative model) KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel – sure step Bruges sure step metoden gennemløbes følgende faser: • Diagnose • Analysefase • Designfasen • Udviklingsfasen • Udrulningsfasen • Drift I dette forløb arbejdes der iterativt. Men projekterne er baseret på en tidsplan og en projektøkonomi. Udfordringen består i håndteringen af dette. KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Leverancemodel – sure step KONTRAKTRETLIGE TEMAER LEVERANCEGENNEMFØRELSE Centrale elementer • Projektledelse og projektstyring • Metode, kvalitetssikring og risikostyring • Styring på tid frem for funktionalitet (”time boxing”) • Fokus på styring af parternes personale • Samarbejds- og beslutningsprocedurer • Styring af økonomi – v/ fast pris/maksimal pris og/eller stramme krav til rapportering af tidsforbrug • Krav til fremdriftsrapportering og risikolog PAUSE PRISMODELLER PRISMODELLER Prisregulering • I den ideelle agile verden fraviges udgangspunktet om fast pris, identificeret leveringstidspunkt og klart definerede krav. • De tre parametre må behandles ”alternativt” i den agile kontrakt. • Graden af fleksibilitet på de tre områder er givetvis ikke identisk • Offentlige kunder operere med bevillinger og private kunder arbejder under budgetter, og det er derfor ofte ikke muligt at arbejde uden en fast defineret økonomisk ramme. • Risikoen for budgetoverskridelser er alt andet lige ofte mindre i et iterativt end i et vandfaldsprojekt(!) PRISMODELLER Graden af fleksibilitet (udtrykt gennem cirklernes størrelse) Pr i sen Pris Dette billede kan ikke vises i øjeblikket. Specifikationer Spec i fikationer Leveringstid Lev er ingstid Systemet PRISMODELLER Principper • Prismodeller • Forbrugsafregning • Forbrugsafregning med shared risk (målpris) • Forbrugsafregning med maksimal pris (maksimalpris) • Fast pris • Bemærk at omfanget af funktionalitet ikke er fast i et iterativt forløb. Det endelige omfang fastlægges undervejs i projektet, og er delvis bestemt af de ressourcer, der er til rådighed for projektet • Forbrugsafregning forudsætter fastlæggelse af krav til registrering af forbrug, rapportering samt bestemmelser om opfølgning i forhold til økonomi PRISMODELLER Målpris Anvendelsen af målpris forudsætter at kunden er villig til at give afkald på den sikkerhed der ligger i det loft maksimalprisen er udtryk for. Fra IT- og Telestyrelsens vejledning PRISMODELLER Målpris i norske kontrakter PRISMODELLER Målpris i norske kontrakter PRISMODELLER Maksimalpris • Leverandøren angiver en maksimalpris bestående af; a) En fast pris for de leverancer, hvor prissætningen af disse er uafhængig af omfanget af Leverandørens ydelser. b) En forventet pris på de dele af Leverancen, som skal udføres efter medgået tid. c) Et usikkerhedstillæg. • Maksimalprisen må ikke overskrides. • Maksimalprisen omfatter ikke vederlag for vedligeholdelse og support, og løbende betalinger for anvendelse af Programmel. PRISMODELLER Maksimalpris KONTRAKTSTYRING/PROJEKTSTYRING KONTRAKTSTYRING/PROJEKTSTYRING Krav til kontraktstyring uanset prismodel • Jo større fleksibilitet i prismodellen – des større krav til styringen • Opgaverne i kontraktstyringen • Styringen af udviklingen i risiko-loggen og indflydelsen på prisrammen • Udvidelser af projekt-scope kontra påregnelig fleksibilitet og betydningen for prisrammen – en udvidelse eller indskrænkning af projektet skal således også håndteres i forhold til en eventuel ændring i prisrammerne • Oplysningspligten i forhold til timebaseret afregning KONTRAKTSTYRING/PROJEKTSTYRING Styring af timebaserede vederlag • Specifikationskrav med hensyn til ydelser, der vederlægges på grundlag af medgået tidsforbrug. • Det er Leverandørens ansvar til stadighed at give Kunden et retvisende og fyldestgørende billede af projektets økonomi baseret på Projektets status. • Leverandøren skal senest hver den 5. i en måned sende Kunden en detaljeret opgørelse af tidsforbruget i den forgangne måned og om nødvendigt maksimalpris (i) Leverandørens eventuelle forslag til ændret prioritering, (ii) aftalte ændringer eller udvidelser af Projektet og (iii) en opdatering af Risikologgen. • Maksimalprisen må ikke overskrides uden Kundens forudgående godkendelse. KONTRAKTSTYRING/PROJEKTSTYRING Styring af timebaserede vederlag • Der skal være balance mellem sikkerhed og fleksibilitet Eksempel på uheldig kontraktformulering (kundevenlig): Leverandørens vederlagsestimat er baseret på en grundig gennemgang af kundens krav og forventninger til projektet og er således udtryk for et ansvarligt estimat. Det er i enhver henseende leverandørens ansvar, at prisestimatet er forsvarligt. Leverandøren kan ikke kræve større vederlag end estimeret, medmindre fravigelsen skyldes omstændigheder, som leverandøren ikke kunne have forudset ved meddelelsen af prisestimatet.” KONTRAKTSTYRING/PROJEKTSTYRING Styring af timebaserede vederlag • Der skal være balance mellem sikkerhed og fleksibilitet Eksempel på uheldig kontraktformulering (leverandørvenlig): ”Såfremt en opgave ikke udføres på fast tid, kan der fastsættes et estimat. Et sådant estimat er baseret på Kundens ønsker og Leverandørens viden om projektet på aftaletidspunktet og er ikke bindende for Leverandøren. Såfremt et estimat overskrides væsentligt, skal Kunden informeres herom, således at Parterne i fællesskab kan aftale de nødvendige konsekvensrettelser. Medmindre overskridelserne kan tilregnes Leverandørens væsentlige misligholdelse, fritages Leverandøren for resultatansvaret, såfremt Kunden ved overskridelse af estimatet ikke ønsker arbejdet fortsat. Kunden betaler Leverandøren for de timer, der er erlagt, forinden Kundens anmodning om afslutning af arbejdet er modtaget.” KONTRAKTSTYRING/PROJEKTSTYRING Hvor går projektstyringen typisk galt? Det kan også gå galt i iterative projekter. Årsagerne kan være: • Ofte ”glemmer” Leverandøren at gøre opmærksom på, hvad det vil sige at arbejde agilt. • Kunden er ikke klar til at arbejde agilt, og omkostninger/tid løber løbsk. • Manglende fokus på de omkringliggende behov (samspillet med andre dele af kundens IT-miljø) • Leverandøren får ikke dokumenteret ændringer og udviklinger i projekter og der opstår et ”gab” mellem det beskrevne og det realiserede projekt? KONTRAKTSTYRING/PROJEKTSTYRING Projektorganisation • Kvalifikationer hos kundens projektdeltagere • Kundens deltagere! • Leverandøren skal være opmærksom på, at der ikke kan forventes bedre kvalifikationer end angivet af kunden, og leverandøren skal indrette sine ydelser efter disse oplysninger • Kundens beslutningstagere i projektet • Skal sikre at forretningsmæssig viden er tilrådighed • Skal træffe beslutninger • Formidle behov og forretningsmæssig viden • Hurtig og umiddelbar eskalationsvej TIDSPLAN OG AFPRØVNING TIDSPLAN OG AFPRØVNING Tidsplan • Ved Kontraktens indgåelse angives alene en overordnet hovedtidsplan, der • Fastlægger projektets overordnede rammer, • Fastlægger de enkelte trin (funktionelle testbare område og kontrolpunkter) • Fastlægger opdelingen i Delleverancer og tidspunktet for levering heraf. • Aktiviteterne i afklaringsfasen bør dog være detaljeret beskrevet • Udarbejdelse af detaljeret tidsplan • Løbende opdatering af hovedtidsplan TIDSPLAN OG AFPRØVNING Afprøvning • Den iterative metode indebærer ofte løbende tests af de det leverede i hver enkelt iteration. • De tests, der er en del af den iterative metode, er beskrevet i bilaget, der indeholder den iterative metode. • De kontraktuelle tests er beskrevet i prøvebilaget. • Inden idriftsættelsen af den enkelte delleverance skal der være gennemført en delleveranceprøve. • Behov for ændringer i bilaget om afprøvning? MISLIGHOLDELSESBEFØJELSER MISLIGHOLDELSESBEFØJELSER Forsinkelse • Frister angives som ved vandfaldsmodel-kontrakter • Bod for forsinkelse • Reduktion af vederlag indtil milepæl er opfyldt • ”Klassisk” beregning MISLIGHOLDELSESBEFØJELSER Mangler • Begrebet mangel vil afhænge af prismodel og kravspecifikationen • • mangelsbegrebet er i højere grad relevant i forhold til ”processen og leverandørens evne til at skabe ”value for money” En række mangelsvurderinger vil ikke være ”sort/hvide” men derimod afhænge af et fagligt skøn. MISLIGHOLDELSESBEFØJELSER Mangler – forslag til sanktion • Reducerede timesatser • ”For arbejde med afhjælpning af Mangler i garantiperioden og andre garantiarbejder, som ikke er omfattet af en eventuel vedligeholdelsesaftale, hvor der er aftalt en fast pris, er Leverandøren berettiget til at fakturere Kunden dette arbejde i henhold til de aftalte timesatser med fradrag af 25%.” MISLIGHOLDELSESBEFØJELSER Ophævelse • Fortsat nødvendigt med mulighed for hel eller delvis ophævelse. • Bør kun være en mulighed for ophævelse ”ex nunc” (fremadrettet). • Skal ses i lyset af den løbende opsigelsesadgang og ”working software”. • Opfyldelse af vedligeholdelses- og driftsaftaler ingen afsmittende virkning. • Erstatningskravet ved ophævelse. UDTRÆDELSESADGANG UDTRÆDELSESADGANG Kunden kan altid udtræde • Den iterative tankegang bygger på forudsætning om fuldstændig fleksibilitet • Derfor skal kunden også have mulighed for at stoppe undervejs; • Når som helst – men varsel skal indbygges • Forpligtelser bortfalder • Frembragt materiale – ret til efterfølgende brug • Betaling af vederlag • Allerede gennemførte leverancer • Allerede bestilte leverancer • Kompensation? UDTRÆDELSESADGANG Særlige problemstillinger • Garantier for allerede foretagne leverancer • Support- og vedligeholdelse • Udlevering af oplysninger UDTRÆDELSESADGANG Udtrædelsesvederlag • Vederlaget kan opgøres som: a. Det beløb som Leverandøren har til gode for den del af Projektet, som allerede er gennemført, b. Dokumenterede direkte udlæg og direkte omkostninger i tilknytning til Projektet, som Leverandøren har pådraget sig, inden Leverandørens modtagelse af Kundens Meddelelse om at ville udtræde, og som ikke er dækket af Leverandørens krav på vederlag i henhold til punkt a). Leverandøren er i forbindelse med opgørelsen af punkt (b) ovenfor forpligtet til at søge at begrænse udgifterne mest muligt. PAUSE ITERATIVE PROJEKTER OG UDBUDSREGLERNE ITERATIVE PROJEKTER OG UDBUDSREGLERNE IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor ITERATIVE PROJEKTER OG UDBUDSREGLERNE IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor ITERATIVE PROJEKTER OG UDBUDSREGLERNE IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor • Udgangspunktet for udbud af kontrakten er den samme som ”almindelige projekter” • Den udbudte genstand er ikke et detaljeret beskrevet slutprodukt • Leverandørens ydelser er andet end etablering af forud fastsat funktionalitet • Metodeanvendelse / Projektledelse • Ressourcestyring • Rådgivning • Kontrakten er opbygget om andet end slutresultatet • Projektledelse, metoder og procedurer • Kravspecifikationen får en anden betydning end i vandfaldsprojekter • Konkret funktionalitet fastlægges undervejs i projektet ITERATIVE PROJEKTER OG UDBUDSREGLERNE Gennemsigtighedsprincippet og ligebehandlingsprincippet Gennemsigtighedsprincippet • Kontrakten skal give en klar og præcis beskrivelse af den opgave leverandøren skal løse og ydelseskategorier beskrevet. Beskrivelsen af funktionelle krav eller funktionsdygtighed skal være så præcis, at tilbudsgiver kan identificere kontraktens genstand. Ligebehandlingsprincippet • Fortsat forbud mod at ”skræddersy” kravspecifikation og mod at anvende diskriminerende standarder eller krav. ITERATIVE PROJEKTER OG UDBUDSREGLERNE Gennemsigtighed kan bl.a. opnås ved at • Kontrakten er med i udbudsmaterialet og den er udformet specifikt for et agilt projektforløb • Kravspecifikation og kontrakten giver et klart billede af den opgave, der skal løses (men ikke af slutproduktet) • Kundens business case indgår i kontrakten (kravspecifikationen) • Leverandørens ydelser omkring projektledelse, ressourcestyring og rådgivning beskrives i kontrakten (kravspecifikationen) • Udbudsmaterialet angiver tydeligt kundens fastlagte rammer for økonomi, tidsrammer, overholdelse af standarder, integrationer m.v. ITERATIVE PROJEKTER OG UDBUDSREGLERNE Ligebehandling kan bl.a. opnås ved at • Undgå bilateral dialog med tilbudsgiver omkring udbudsmaterialet • Sikre gennemsigtighed og klarhed i forhold til evaluering ITERATIVE PROJEKTER OG UDBUDSREGLERNE Evaluering ITERATIVE PROJEKTER OG UDBUDSREGLERNE Evaluering ITERATIVE PROJEKTER OG UDBUDSREGLERNE Evaluering ITERATIVE PROJEKTER OG UDBUDSREGLERNE Ændring af projekt under udbudsreglerne TAK FOR I DAG / SPØRGSMÅL (BUFFER) KONTAKTOPLYSNINGER Claus F. Sørensen E-mail: [email protected] Telefon: 20250599
© Copyright 2024