Iterative projekter og kontraktgrundlaget

Transkript

1

2 Iterative projekter og kontraktgrundlaget Claus Sørensen og Michael Lemvig

3 AGENDA Kontraktens rolle generelt og i iterative projekter Vandfaldsmodel contra iterativ model Den generelle holdning til iterative projekter Den iterative kontrakt Arbejdet i IT- og telestyrelsen

4 Kontraktens rolle i projektstyringen generelt og i iterative projekter

5 KONTRAKTSTYRING AF OFFENTLIGE KONTRAKTER Offentlige kontrakter er stadig på kravlestadiet, det er bagt ind i kontrakterne, at det går galt og det afspejler sig i deres kontrakter og alle bruger derfor energien på at dække sig ind i stedet for at komme i mål med det, kunden i virkeligheden havde brug for og havde fundet ud af undervejs i udviklingsforløbet. Leverandøren er ikke interesseret i at afvige fra det aftalte. Når det er sagt er et paradigmeskift undervejs i det offentlige, og om nogle år er vi sikkert der, hvor vi gerne skulle være med successfulde offentlige IT-projekter (Kilde: CMS-leverandør i Computerworld) 5

6 KONTRAKTSTYRING AF OFFENTLIGE KONTRAKTER 9 ud af 10 offentlige IT-projekter afvikles på den traditionelle vandfaldsmodel med krav om omfattende og detaljerede kravspecifikationer, før der kodes en eneste linie. Men en mere tidssvarende udviklingsmodel repræsenteret ved de agile metoder og principper synes at være en langt mere farbar vej for netop de ofte store og komplekse offentlige udviklingsprojekter. Men udfordringen er måske ikke engang valg af metode, men snarere definitionen af, hvad succeskriteriet for et IT-projekt i det offentlige egentlig er? Er det vigtigste, at det kontraktuelt aftalte leveres i tide og på budget (som Rigsrevisionen synes at foretrække), eller om de forretningsmæssige mål med projektet bliver nået? Eller med andre ord: Operationen lykkedes, men patienten døde eller om Patienten blev rask? (Kilde: CW, Hvorfor fejler offentlige IT-projekter igen og igen? Af adm. direktør Carsten Brogaard Jensen, Valtech A/S) 6

7 KONTRAKTSTYRING Kontraktstyring contra projektstyring Rammebetingelser for offentlige kontrakter i form af EU s udbudsregler og det bevillingsmæssige system udgør et problem i relation til smidig og hensigtsmæssig projektstyring. De statslige standardkontrakter (K18, K01, K33 og nu også K02) er i vidt omfang indrettet til at fastholde leverandøren på et totalansvar, således at fokus ofte lægges på kontraktstyring frem for projektstyring. Vandfaldsmodellen og K-kontrakternes udgangspunkt om fast tid, fast pris og fast ydelse er ikke altid det bedste valg for kunden. 7

8 KONTRAKTSTYRING Kontrakten skal sikre kunden relevante juridiske håndtag, som gør det forsvarligt at indgå leveringsaftaler baseret på brug af iterative forløb Kontrakten skal ikke presse vandfaldsmodellens juridiske tankegang ned over fundamentalt anderledes ydelser og processer. 8

9 KONTRAKTSTYRING Bonnerup Rapporten Side af 34:.Erfaringerne fra de undersøgte projekter viser klart, at offentlige købere helt fra starten bør tage det udgangspunkt, at ikke alle krav til systemet kan fastlægges på forhånd. Der skal gøres plads til fleksibilitet og ændringer undervejs i projektforløbet. Detaljerede kontrakter bør derfor erstattes af mere åbne kontraktformer, der kan motivere køber og leverandør til et løbende samarbejde om de mest optimale løsninger. 9

10 KONTRAKTSTYRING I ITERATIVE PROJEKTER Iterative projekter er hverken rendyrket anarki eller et tag-selv bord for leverandøren Brug af en iterativ metode i stedet for vandfaldsmodellen øger ofte sandsynligheden for et projekt inden for den aftalte tid og pris og med et godt resultat. Men: Det kræver en god kontrakt med gode styringsredskaber, en stærk projektledelse og en stor indsats og beslutningskraft hos navnlig kunden! 10

11 KONTRAKTENS ROLLE I DET ITERATIVE PROJEKT Kontrakten skal navnlig have fokus på - samarbejdsrelationen mellem parterne - parternes bemanding af projektet - den iterative metode - projektledelse og styring - prioritering af krav og ønsker - fremdriftsrapportering og risikolog - styring af økonomi og tid 11

12 DEN PROCESORIENTEREDE KONTRAKT 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

13 Vandfaldsmodellen contra iterativ model

14 Kunden Hardware Konsulentassistance Licenser Uddannelse Vandfaldsmodellen Systemleverance baseret på fast pris, fast tid og fast definerede krav. Adskilte og sekventielt ordnede faser Alle krav fastlægges i detaljer før kontraktens indgåelse kravspecifikationen styrer Alt designes før udvikling Alt udvikles inden testning Alt afprøves, testes og overtages samlet Fokus på funktionelle krav i kravspecifikationen Systemleverance Drift Vedligeholdelse Support Pris Tid Ydelse 14

15 Fokus Agile Forretningsmæssigt: Understøttelse af behov og forretningsprocesser ved idriftsættelse og ikke ved projektinitiering Vandfald 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 Fokus på forretningsprocesser, Detaljeret angivelse af den forretningsmæssige behov og funktionalitet, der skal etableres fastlæggelse af mindstekrav. (Inspiration kan hentes i SL-07) Overtagelsesprøve Samarbejde 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 Kravspecifikation opfyldt Leverandøren udfører Ydelser Projektledelse, rådgivning, metodekendskab, ressourcer Etablering af funktionalitet Ændringshåndtering Processen og metoden håndterer Betydeligt ressourceforbrug, ændringer undgås helst 15

16 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 16

17 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 17

18 Den generelle holdning til iterative projekter

19 ANBEFALINGER 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 19

20 IT- UDREDNINGEN 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 20

21 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. 21

22 UDGANGSPUNKTER FOR DEBATTEN Kontrakten skal sikre kunden relevante juridiske håndtag, som gør det forsvarligt at indgå leveringsaftaler baseret på brug af iterative forløb Kontrakten skal ikke presse vandfaldsmodellens juridiske tankegang ned over fundamentalt anderledes ydelser og processer. 22

23 HVORNÅR SKAL DET ITERATIVE PROJEKT VÆLGES Ønske om hurtig idriftsættelse Ønske om fokus på behov ved idriftsættelse og ikke ved projektinitiering Krav til løsningen skifter ofte Læring og innovation i projektet Forretningsanalyse i projektet Forandringsprojekt Større sikkerhed for projektøkonomi end ved Vandfaldsmodellen 23

24 PÅ VEJ MOD DEN ITERATIVE PROJEKTMODEL På vej med den iterative projektmodel Juli 2008: SKI April 2009: SKI vejledning til udformning af kontrakter under med brug af iterative forløb Efterår 2009: 01i, 02i, 03i (BvHD Dahl) Marts 2010: ITST vejledning 24

25 Kontrakten til understøttelse af iterative projekter

26 LEVERANCENS GENSTAND

27 LEVERANCENS GENSTAND Leverancens genstand 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) Procedurer 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. 27

28 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. Modsat er leverandøren primært ansvarlig for opfyldelsen.

29 HÅNDTERING I DEN ITERATIVE KONTRAKT Leverancebeskrivelsen (behovsopgørelsen) Kunden udarbejder Behovsopgørelse indeholdende; (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 Inspiration kan hentes i SL-07

30 BUSINESS CASEN Indhold 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 ** Den Digitale Taskforce, Videnskabsministeriet, KL og Danske Regioner: Business case for digitaliseringsprojekter Realisering af it-udredningen 30

31 BUSINESS CASEN Brug Planlægning Dialogværktøj i forhold 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 Benyttes af kunden til efterfølgende intern evaluering af projektets forløb 31

32 LØSNINGSBESKRIVELSEN Leverancebeskrivelsen (Løsningsbeskrivelsen) 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.

33 DETAILSPECIFIKATIONER UNDER ITERATIONER Leverancebeskrivelsen (Detailspecifikationerne) 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, jf. punkt 5.3.

34 LEVERANCEGRUNDLAGET I DEN ITERATIVE KONTRAKT Leverancebeskrivelsen 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.

35 LEVERANCENS GENNEMFØRELSE

36 HVORDAN GENNEMFØRES PROJEKTET De overordnede faser Afklaring Design, udvikling og test Godkendelse og overtagelse

37 HVORDAN GENNEMFØRES PROJEKTET Afklaringsfasen Fortsat behov for grundlæggende drøftelser af kundens behovsopgørelse og belysning af risikofaktorer i projektet

38 HVORDAN GENNEMFØRES PROJEKTET Udviklingsfasen Etablering af udviklingsmiljø Design og udvikling baseres på den valgte iterative model definition og beskrivelse af trin Kontrolpunkter Testprocesser Delovertagelse og ibrugtagning

39 HVORDAN GENNEMFØRES PROJEKTET Godkendelse og overtagelse Projektet godkendes og overtages samlet. men reduceret betydning

40 LEVERANCEFORLØBET (01I OG 02I) Aktiviteterne i en fase (vil afhænge af den valgte iterative model)

41 PROJEKTLEDELSE, MODENHED OG RÅDGIVNING

42 HVORDAN GENNEMFØRES PROJEKTET Centrale elementer i kontrakt om iterativ udvikling 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

43 TEMAER TIL REGULERING Følgende områder bør reguleres/behandles Rådgivning metoder, teknologi, arkitektur Koordineringsansvar Projektledelse Prioritering og omprioritering Styring af ressourceforbrug Styring af og opfølgning på økonomi Kvalitetssikring Kundens interesser Kundens ret til at øge sin medvirken Underretningspligt Risikolog

44 SÆRLIGT OM PROJEKTORGANISATION Kvalifikationer hos kundens projektdeltagere Kundens deltagere!!!! Bør understreges, at Leverandøren ikke kan forvente bedre kvalifikationer end angivet og skal indrette sine ydelser efter det oplyste Kundens beslutningstagere i projektet Sikre at forretningsmæssig viden er til rådighed Træffe beslutninger tilpasse beslutningsgange Sondre alm. projektbeslutninger og ændringer af kontrakten Formidle behov og forretningsmæssig viden Relateret til tidsplan / faser / aktiviteter Hurtig/umiddelbar eskalationsvej 44

45 PROJEKTLEDELSEN I ITERATIVE PROJEKTER Fortsat krav om projektledelse fra leverandørens side Metoden angives i bilag Styring af det fælles team Rapportering og opfølgning Kvalitetssikring af alle bidrag Koordinering af aktiviteter Beslutninger i projektteams Sammenhæng i system Løbende idriftsættelse Koordinering Feedback fra brugere 45

46 BEHOV FOR FOKUS PÅ KUNDENS MEDVIRKEN Overordnede krav til kundens medvirken; Sørge for at forudsætningerne for kontraktsindgåelse er opfyldt Deltage i arbejdsgrupper for at gennemgå og uddybe specifikationerne Deltage med beslutningskompetence på funktion/tid/pris Bidrage med prioriteringer og løbende funktionelle afklaringer Evaluering og gennemgang under udvikling Sørge for rettidig færdigstillelse af eventuelle egne leverancer Testning og afprøving af udviklede dele af Leverancen Informationsudvikling mod egen organisation og eksternt Fremskaffe testdata og testbeskrivelser (inkluderet brugerscenarier) i henhold til de forudsætninger og frister som er beskrevet i øvrige bilag

47 UDTRÆDELSESADGANG

48 UDTRÆDELSESADGANG Udtræden under Afklaring Når som helst Forpligtelser bortfalder Frembragt materiale ret til efterfølgende brug Betaling af vederlag 48

49 UDTRÆDELSESADGANG Udtræden efterfølgende Bør til hver en tid kunne ske med et varsel på mindst 20 Arbejdsdage. Begge Parters forpligtelser til videre opfyldelse af Kontrakten i relation til de(n) omfattede Delleverance(r) bortfalder. Men hvad med forpligtelser for allerede gennemførte Delleverancer? Suspension af forpligtelser. 49

50 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. 50

51 PRISMODELLER

52 PRISREGULERINGEN I ET ITERATIVT PROJEKT I den ideelle agile verden fraviges udgangspunktet om fast pris, identificeret leveringstidspunkt og klart definerede krav. Men disse tre parametre må behandles forskelligt i den agile kontrakt. Graden af fleksibilitet på de tre områder givetvis ikke identisk; Offentlige kunder operere med bevillinger og private kunder arbejder under budgetter Det er 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(!) 52

53 GRADEN AF FLEKSIBILITET (GRADEN AF FLEKSIBILITET UDTRYKKES GENNEM CIRKLERNES STØRRELSE) Vandfaldsmodel Iterativt projekt Prisen Pris Specifikationer Specifikationer Leveringstid Systemet Leveringstid

54 PRISMODELLER 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 54

55 PRISMODEL I KONTRAKTERNE 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. 55

56 MAKSIMALPRIS Maksimalpris

57 ET ALTERNATIV - MÅLPRIS Forudsætter kunden er villig til at give afkald på den sikkerhed der ligger i det loft maksimalprisen er udtryk for. Fra IT- og Telestyrelsens vejledning

58 MÅLPRIS ANVENDES I NORSKE KONTRAKTER

59 MÅLPRIS

60 KRAV TIL KONTRAKTSTYRINGEN UANSET PRISMODEL Jo større fleksibilitet i prismodellen jo større krav til styringen Opgaverne i kontraktstyringen Styringen af udviklingen i risiko-loggen og indflydelsen på prisrammen Udvidelser af projektscope 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 60

61 KRAV TIL KONTRAKTSTYRINGEN UANSET PRISMODEL Styringen af det timebaseret 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. 61

62 BEHOVET FOR FLEKSIBILITET CONTRA SIKKERHED SKAL VÆRE I BALANCE Hvad duer ikke; Den kundevenlige udgave. 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. 62

63 BEHOVET FOR FLEKSIBILITET CONTRA SIKKERHED SKAL VÆRE I BALANCE Hvad duer ikke; Den leverandørvenlige udgave. 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. 63

64 TIDSPLAN OG AFPRØVNING

65 TIDSPLAN Ved Kontraktens indgåelse alene en overordnet hovedtidsplan, der fastlægger Projektets overordnede rammer, de enkelte trin (funktionelle testbare område og kontrolpunkter) 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

66 AFPRØVNING Den iterative metode indebærer ofte løbende tests af de udviklede iterationer. De tests, der er en del af den iterative metode, er beskrevet i bilaget indeholdende 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?

67 MISLIGHOLDELSESBEFØJELSER

68 FORSINKELSE Frister angives som ved vandfaldsmodel-kontrakter Bod for forsinkelse Reduktion af vederlag indtil milepæl er opfyldt Klassisk beregning 68

69 MANGLER Begrebet mangel vil afhænge af prismodel og kravspecifikationen mangelsbegrebet 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 69

70 MANGLER FORSLAG TIL SANKTIONER 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%. 70

71 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. Opfyldelse af vedligeholdelses- og driftsaftaler ingen afsmittende virkning. Erstatningskravet ved ophævelse. 71

72 TILGÆNGELIGE SKABELONER

73 01I, 02I, 03I SKRÆDDERSYET TIL AGILE FORLØB Mindre projekter 01i eller 03i Større projekter 02i 01 er baseret på K01, 02i er baseret på K02 03i er formuleret mere frit i forhold til K-kontrakterne 73

74 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 74

75 SKI RAMMEAFTALER SKI Leverandøren driver processen Projekter og vedligeholdelse Vejledning om agile forløb SKI konsulentydelser Kunden driver processen 75

76 ITB S KONTRAKT TIL ITERATIVE PROJEKTER Kontraktskabelon bliver tilgængelig på Fokus på overskuelighed og forenelighed med praktikken Bilagsskabeloner på vej indtil kan hjælp rekvireres hos Dahl. 76

77 KONTAKTOPLYSNINGER Claus F. Sørensen Mobil telefon: Michael Lemvig Telefon:

78