Vejledning. Til samspil mellem standardkontrakter og den fællesstatslige it-projektmodel

Vejledning Til samspil mellem standardkontrakter og den fællesstatslige it-projektmodel Januar 2014

Indhold 1 INDLEDNING... 1 1.1 FORMÅL... 1 1.2 LÆSEVEJLEDNING... 1 1.3 SAMMENHÆNG TIL DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 2 2 DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 3 2.1 FASEMODELLEN... 3 2.2 LEDELSESFASER... 4 2.3 FASEOVERGANGE... 4 2.4 LEDELSESPRODUKTER... 5 2.5 ROLLER OG ANSVAR... 5 3 STANDARDKONTRAKTERNE... 6 3.1 K01 STANDARDKONTRAKT FOR KORTVARIGT IT-PROJEKT... 6 3.2 K02 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT... 7 3.3 K03 STANDARDKONTRAKT FOR LÆNGEREVARENDE IT-PROJEKT BASERET PÅ EN AGIL METODE 8 3.4 SAMMENLIGNING AF STANDARDKONTRAKTER... 8 4 UDBUD OG DIALOG... 9 4.1 UDBUDSREGLERNES BETYDNING FOR KONTRAKTERNE OG IT-PROJEKTMODELLEN... 9 4.2 OM SKI-RAMMEAFTALER... 10 4.3 TEKNISK DIALOG MED MARKEDET... 10 5 PROJEKTLEDERENS OVERBLIK... 11 6 PROJEKTETS HOVEDFASER... 12 6.1 IDÉFASEN... 12 6.2 ANALYSEFASEN... 13 6.3 ANSKAFFELSESFASEN... 14 6.4 GENNEMFØRELSESFASEN... 17 6.5 STRATEGISKE OVERVEJELSER... 17 6.6 REALISERINGSFASEN... 18

BILAG 1 SAMMENLIGNING MELLEM STANDARDKONTRAKTERNE... 20 STANDARDKONTRAKTERNE... 20 VEDERLAGS OG RETTIGHEDSMODEL... 21 VÆSENTLIGE KONTRAKTLIGE HÅNDTAG... 22 DRIFTSMODEL... 24 BILAGSHÅNDTERING OG UDARBEJDELSE AF DISSE... 24 KONTRAKTENS GENERELLE KOMPLEKSITETS NIVEAU... 25 BILAG 2: OVERSIGTSMODEL SAMSPIL MELLEM KONTRAKT OG IT-PROJEKTMODEL... 26 BILAG 3 - BILAGSOVERSIGT K01, K02 OG K03... 27

1 Indledning Dette afsnit præsenterer indholdet af vejledningen, som er de overvejelser, som en projektleder og styregruppen med fordel kan gøre sig i forbindelse med valg og brug af kontraktmodeller i it-projekter i regi af den fællesstatslige it-projektmodel. 1.1 Formål Formålet med denne vejledning er at skabe et overblik over sammenhængen mellem den fællesstatslige it-projektmodel og anvendelsen af statens standardkontrakter for itanskaffelser (K01, K02 & K03) i et konkret it-projekt. Vejledningen er dels et supplement til de mere juridiske vejledninger, der findes om statens standardkontrakter, dels et supplement til de vejledninger og tjekskemaer, som hører til it-projektmodellen. Det er vejledningens grundfilosofi, at overvejelserne om kontrakt og valg heraf er et strategisk element i it-projektet, som projektlederen og styregruppen skal tage ansvar for i alle faser af projektet. Denne vejledning vil derfor i et helikopterperspektiv hjælpe projektlederen til allerede fra idéfasen at have fokus på, hvad valget af kontrakt betyder for projektet, og hvad projektet betyder for valget af kontrakt. Vejledningen vil kort præsentere hovedelementerne i Statens it-projektmodel og standardkontrakterne. Den fungerer på denne baggrund også som introduktion til Statens itprojektmodel og de underliggende værktøjer samt som introduktion til Statens standardkontrakter for it-anskaffelser. 1.2 Læsevejledning Vejledningen er opbygget af: En introduktionsdel - med præsentation af Statens it-projektmodel. En præsentation af it-standardkontrakterne, suppleret af en tværgående beskrivelse af kontrakternes regulering og anvendelsesområde. En præsentation af rammerne for udbud og dialog. En opslagsdel opdelt efter projektmodellens faser. I vejledningens bilag 1 er desuden indsat en sammenstilling af de tre standardkontrakter, inden for en række centrale temaer. Yderligere vejledningsmateriale om projektmodellen kan findes på: http://www.digst.dk/da/styring/statens-projektmodel/ministeriernes-projektkontor Skabeloner og bilag til standardkontrakterne kan findes på: http://www.digst.dk/da/styring/standardkontrakter Vejledningen opstiller en række anbefalinger til myndighederne og deres projektledere, den giver et overblik over det samlede it-projekt og dermed også et overblik over sammenhængen mellem Statens it-projektmodel og Statens standardkontrakter. [1]

1.3 Sammenhæng til den fællesstatslige it-projektmodel Som led i planlægningen af et it-projekt er det vigtigt, at kunden er opmærksom på tre faktorer, der skal bringes i samspil: EU's udbudsregler, it-projektmodellen og kontrakten til itanskaffelsen. Figur 1.Tre faktorer i planlægningen af et it-projekt. It-projektmodellens faser og ledelsesprodukterne danner den overordnede ramme for hele itprojektet, fra idé, over etablering af it-system, til drift og realisering af gevinster. EU s udbudsregler fastlægger de nærmere regler for kundens konkurrenceudsættelse af it-systemet og i et vist omfang det efterfølgende samarbejde med den valgte leverandør. Kontrakten regulerer det direkte samarbejde mellem kunden og leverandøren. Fokus for vejledningen er at beskrive samspillet mellem projektmodellen og kontrakten til itanskaffelsen, og den vil alene kortfattet beskrive rammerne for udbud og dialog.

2 Den fællesstatslige itprojektmodel I dette kapitel gives en overordnet introduktion til indholdet af den fællesstatslige itprojektmodel. Den fællesstatslige it-projektmodel er en one-size-fits-all projektmodel, beregnet for anvendelse på alle statslige it-projekter. Modellen omfatter overordnet set: - En model for faseopdeling af projektforløbet - Principper for overgang fra en fase til næste fase - Et antal ledelsesprodukter og skabeloner hertil (også kaldet produkter) - Beskrivelser af roller og ansvar Endelig er der udarbejdet en række værktøjer og vejledninger til understøttelse af projektforløb og anvendelse af produkterne. Produkter, værktøjer og vejledninger er tilgængeligt på Digitaliseringsstyrelsens hjemmeside. 2.1 Fasemodellen It-projektmodellen indeholder en fasemodel hvor resultatet af hver fase er produkter, som støtter styringen af projektet hen imod projektets samlede leverancer. Faseopdelingen består af hovedfaser og ledelsesfaser og understøtter princip 4 om minimering af kompleksitet og omfang. Figur 2. Den fællesstatslige it-projektmodel. Idé Analyse Ledelsesfase > Ledelsesfase Anskaffelse Specificering > Udbud Gennemførelse Ledelsesfase > Ledelsesfase Realisering It-projektmodellen indeholder fem hovedfaser: - Idéfase: Ideen kvalificeres og udmøntes i et projektgrundlag. - Analysefase: Projektet defineres og beskrives i PID en med tilhørende business case og evt. risikotjekliste fra IT-projektrådet. - Anskaffelsesfase: Specificering af krav og behov samt gennemførelse af anskaffelsesproces typisk via udbud. - Gennemførselsfase: Kontrakter underskrives, og projektets leverancer realiseres. Fasen løber frem til systemet er idriftsat og implementeret organisatorisk. - Realiseringsfase: Business casen realiseres, og gevinsterne hjemtages. Den fællesstatslige it-projektmodel skal bidrage til bedre og mere ensartet planlægning, styring og gennemførelse af statslige it-projekter. Alle it-projekter opdeles i udgangspunktet i disse fem hovedfaser. Det anbefales at opdele projektet i ledelsesfaser, hvis faserne strækker sig over lang tid, eller indeholder store, udgiftstunge aktiviteter. For det enkelte projekt skal styregruppen tage stilling til, om den konkrete tilpasning af modellen, herunder projektets faseinddeling, er hensigtsmæssig og giver den nødvendige styring. Den endelige anvendelse af faser for det aktuelle projekt dokumenteres i PID en.

Idéfasen og realiseringsfasen drives primært af forretningen, hvilket er vist i figuren ved den mørkere farve af faserne. De mellemliggende faser drives af projektet af projektlederen og styregruppen. For at sikre beslutningspunkter og styregruppens stillingtagen til kritiske milepæle i projektet må hovedfaserne ikke overlappe hinanden. Såfremt der er tale om sekventielle delprojekter, opgøres hovedfaserne som et gennemsnit ift. aktiviteterne og delprojekterne beskrives i større detailgrad i PID en. Den fællesstatslige it-projektmodel er en generisk one-size-fits-all model for statslige itprojekter. En af projektlederens fremmeste opgaver er derfor at tilpasse modellen til det aktuelle projekt, så brugen af modellen er hensigtsmæssig og giver den nødvendige styring. Inden igangsættelse af anskaffelsesfasen skal projektet, hvis projektbudgettet inkl. interne lønomkostninger er over 10 mio. kr. forelægges for IT-projektrådet. Se mere om risikovurdering hos IT-projektrådet. Alle it-projekter over 10 mio. kr. skal endvidere hvert halve år, indtil overgangen til drift, statusrapportere på fremdrift til IT-projektrådet. IT-projektrådet udarbejder herefter en samlet oversigt over alle større statslige it-projekter. Oversigten offentliggøres på rådets hjemmeside. Når projekterne afsluttes sendes projektafslutningsrapport til rådet. Enhver hovedfase i it-projektmodellen kan inddeles i flere faser, kaldet ledelsesfaser. 2.2 Ledelsesfaser En ledelsesfase er en sammenhængende og styrbar delmængde af aktiviteter og leverancer inden for en hovedfase. Den indledes og afsluttes med en styregruppebeslutning. For projekter med et budget over 60 mio. kr. er det obligatorisk at inddele anskaffelsesfasen i to ledelsesfaser, nemlig i en specificerings- og en udbudsfase. Formålet med en ledelsesfase er at sikre styringsgrundlaget og at opnå klare beslutningspunkter. Et projekts ledelsesfaser fastlægges ved projektets start, og de må ikke gå på tværs af hovedfaserne i den fællesstatslige it-projektmodel. Der kan være forskellige årsager til, at det giver mening at inddele én eller flere af modellens fem faser i flere ledelsesfaser, eksempelvis: - Et skift i projektets karakter: Fx mellem udvikling og test i gennemførelsesfasen. - Udstrækning i tid: En fase bør ikke have en udstrækning på mere end 3-6 måneder, defineret som et antal sprint i en agil udviklingsmodel. - Organisatoriske: Implementering i forskellige dele af organisationen. Faseovergange mellem ledelsesfaser følger som nævnt ovenfor de generelle regler for faseovergange (se følgende afsnit). 2.3 Faseovergange En faseovergang markerer et skift i projektets tilstand. Det gælder også for overgangen mellem to ledelsesfaser. Figur 3. Faseovergange i den fællesstatslige it-projektmodel. Faseovergang: - Projektgrundlag - Evt. faseovergangsrapport Faseovergang: - PID & business case - Evt. faseovergangsrapport Faseovergang: - PID & business case - Evt. faseovergangsrapport Faseovergang: - Projektafslutningsrapport - Evt. faseovergangsrapport Realiseringsrapport Idé Analyse Ledelsesfase > Ledelsesfase Anskaffelse Specificering > Udbud Gennemførelse Ledelsesfase > Ledelsesfase Realisering

Det er styregruppens ansvar at godkende grundlaget for faseovergangen og beslutte, om projektet er klar til at gå til næste fase. For at projektet kan fortsætte til næste fase skal PID og business case foreligge i opdateret og godkendt tilstand. For overgangen mellem gennemførelsesfasen til realiseringsfasen, skal projektafslutningsrapporten foreligge på samme vis. Udover de godkendte ledelsesprodukter skal projektlederen overfor styregruppen dokumentere aktiviteterne i den forgangne fase, præsentere en plan og leveranceoversigt for den kommende fase, samt give et opdateret indblik i projektets samlede økonomi. Styringsværktøjet faseovergangsrapport kan anvendes. Værktøjet indeholder en plan for den kommende fase og oversigt over resultaterne af den aktuelt afsluttede fase. 2.4 Ledelsesprodukter Et ledelsesprodukt i it-projektmodellen understøtter styring og beslutninger i projektforløbet. Der er knyttet en række ledelsesprodukter til it-projektmodellen, som produceres undervejs i projektforløbet, se figuren nedenfor. Figur 4. Den fællesstatslige it-projektmodel inkl. ledelsesprodukter. Idé Analyse Ledelsesfase > Ledelsesfase Anskaffelse Specificering > Udbud Gennemførelse Ledelsesfase > Ledelsesfase Realisering Projektgrundlag Projektinitieringsdokument (PID) Projektafslutningsrapport Gevinstrealiseringsrapport Business case I den fællesstatslige it-projektmodel findes to bærende ledelsesprodukter: PID og business case. Disse to produkter indeholder den væsentligste information om projektet og bruges igennem hele projektforløbet. For projekter med budget over 10 mio. kr. skal ledelsesprodukterne PID og business case samt værktøjet risikotjekliste og IT-projektrådets cover anvendes ved risikovurdering hos ITprojektrådet. Udover ledelsesprodukterne anbefales det, at projektet gør brug af en række andre værktøjer undervej i projektforløbet. Eksempelvis kan det give stor værdi at udarbejde en interessentanalyse eller en kommunikationsplan. Disse vil generelt styrke planlægningen og styringen af projektet. Ministeriernes projektkontor i Digitaliseringsstyrelsen udarbejder værktøjer, der understøtter dette arbejde, og som kan hentes via Digitaliseringsstyrelsens hjemmeside. Ledelsesprodukter og værktøjer er yderligere beskrevet i vejledning om den fællesstatslige it-projektmodel. 2.5 Roller og ansvar Ansvaret for ledelse og styring i de fem hovedfaser er forankret forskellige steder i organisationen. For at sikre, at ansvaret for beslutninger, ledelse og styring er forankret de rigtige steder, indeholder it-projektmodellen et sæt standardroller og ansvarsbeskrivelse. Projektleder og styregruppe kan tage udgangspunkt i standardrollerne ved design af projektorganisationen og bemanding af projektet, se Digitaliseringsstyrelsens hjemmeside.

3 Standardkontrakterne I det følgende er der foretaget en kort introduktion til Statens standardkontrakter for itanskaffelser. Statens standardkontrakter for it-anskaffelser er følgende: K01 Standardkontrakt til kortvarigt it-projekt K02 Standardkontrakt for længerevarende it-projekt K03 Standardkontrakt for længerevarende it-projekt baseret på en agil metode K01 og K02 har karakter af "agreed documents" og er således forhandlede standarder mellem staten og forskellige interesseorganisationer, der repræsenterer både kunde- og leverandørside. Standardkontrakternes enkelte bestemmelser er udtryk for en nøje overvejet balancering af rettigheder og forpligtelser mellem parterne. Eventuelle tilpasninger og ændringer i kontrakten i forhold til et konkret projekt, bør derfor grundigt gennemtænkes i forhold til eventuelle utilsigtede forskydninger i kontraktens regulering. Dette gælder også i forhold til de bilag, der hører til kontrakten. De enkelte bestemmelser og bilag kan i den sammenhæng ikke betragtes isoleret, da der ofte vil være betydelige indbyrdes afhængigheder. K01 og K02 baserer sig på en klassisk vandfaldsmodel, med en detaljeret kravspecifikation, hvor tid, pris og leverancer er fastlagt ved kontraktens indgåelse. K03 understøtter agile udviklingsmetoder, hvor kundens krav er overordnet beskrevet og knyttet til kundens forretningsmæssige mål og behov. Der foreligger således ikke i en K03 kontrakt en detaljeret kravspecifikation fra projektets start, hvilket giver kunden og leverandøren mulighed for i fællesskab at fastlægge løsningen. Pris og tid ligger som udgangspunkt fast, idet fleksibiliteten i kontrakten ligger i leverancerne. K-kontrakterne beskrives nærmere nedenfor, og en sammenligning af udvalgte områder/temaer i kontrakterne kan ses i vejledningens bilag 1. 3.1 K01 standardkontrakt for kortvarigt it-projekt K01 blev introduceret i 2004 og er målrettet mindre komplekse systemanskaffelser til offentlige myndigheder, baseret på standardsystemer med ingen eller kun få tilpasninger og tilretninger. Implementeringsforløbet sker typisk over en kortere periode og forventes som udgangspunkt at have en tidshorisont på under 6 måneder. Kontrakten understøtter således ikke større systemleverancer, hvori der indgår et større omfang af systemudviklingsarbejder. Kontraktens anvendelsesområde baserer sig på følgende hovedprincipper: K01 Anskaffelsen sker på grundlag af en fyldestgørende kravspecifikation. Anskaffelse dækker køb af et it-system bestående af udstyr, standardprogrammel og dokumentation. Anskaffelsen forudsætter, at der kun i begrænset omfang er behov for specialtilpasninger og tilretninger til det leverede standardprogrammel. Anskaffelsen sker som en samlet levering og en overtagelsesprøve. Anskaffelsen sker til fast tid og til fast pris. Anskaffelsen indeholder som udgangspunkt vedligeholdelse af alle dele af it-systemet fra overtagelsesdagen. Hvis systemanskaffelser sker på baggrund af leverancer, der alene indeholder programmel og øvrige tjenesteydelser, skal kontrakten rettes til i overensstemmelse hermed.

Kontrakten forudsætter, at der anskaffes et system, som kunden selv, eller tredjemand, kan driftsafvikle. Hvis kunden samtidig med systemanskaffelsen ønsker, at leverandøren skal forestå driftsafvikling, skal kontrakten suppleres med en selvstændig driftskontrakt. Kontrakten kan ikke, uden omfattende tilretninger, benyttes til servicebureau-/aspleverancer eller tilsvarende, hvor leverancen leveres som en serviceydelse fra leverandøren. Ved anvendelse af K01, kan der tages udgangspunkt i de bilagsskabeloner, der indgår som en del af den samlede kontraktpakke. Bilagene fungerer i vidt omfang som en konkret udmøntning af den overordnede regulering i kontrakten. Bilagene danner et godt grundlag for arbejdet, men de skal dog nøje udfyldes og tilrettes, så de afspejler de specifikke forretningsmæssige behov i projektet. I vejledningens bilag 3 er indsat en samlet oversigt over bilagene i K01. 3.2 K02 standardkontrakt for længerevarende it-projekt K02 blev introduceret i 2007 og er målrettet større systemanskaffelser af mere kompleks karakter, hvor udviklings- og implementeringsdelen er af en betydelig størrelse. K02 understøtter i modsætning til K01 en faseopdelt leverance, hvor levering af løsningen sker i flere delleverancer. Hvis systemanskaffelser sker på baggrund af leverancer, der alene indeholder programmel og øvrige tjenesteydelser, skal kontrakten rettes til i overensstemmelse hermed. Kontraktens anvendelsesområde baserer sig på følgende hovedprincipper: K02 Anskaffelsen sker på baggrund af en fyldestgørende kravspecifikation, der sammen med leverandørens løsningsbeskrivelse udgør leverancebeskrivelsen. Leveringen sker i faseopdelte leverancer med særskilt afprøvning og en samlet overtagelsesprøve efter gennemførelse af den sidste delleverance. Leverandøren har et samlet projektansvar og er totalleverandør. Anskaffelsen sker til fast tid og til fast pris. Anskaffelsen forudsætter, at både kunden og leverandøren angiver deres modenhedsniveau opgjort efter nærmere angivne retningslinjer. Anskaffelsen indeholder levering af vedligeholdelse og support af alle dele af leverancen fra tidspunktet for kundens ibrugtagning. Kontrakten forudsætter, at der anskaffes et it-system, som kunden selv eller tredjemand kan driftsafvikle. Hvis kunden samtidig med systemanskaffelsen ønsker, at leverandøren skal forestå driftsafvikling, skal kontrakten suppleres med en selvstændig driftskontrakt/driftsvilkår. Kontrakten kan ikke, uden omfattende tilretninger, benyttes til servicebureau/asp-leverancer eller tilsvarende, hvor leverancen leveres som en serviceydelse fra leverandøren. Ved anvendelse af K02 kan der tages udgangspunkt i de bilag, der indgår som en del af den samlede kontraktpakke. Bilagene er ikke tiltænkt at være egentlige skabeloner for bilag som i K01. De forudsættes i højere grad at være et rammeværk for de centrale forhold, som en kunde og leverandør skal sikre, er adresseret i de respektive bilagsområder. Der forestår således et mere omfattende bilagsarbejde for kunden, ved anvendelse af K02 i forhold til K01. Dette arbejde kræver både tekniske, kommercielle og juridiske kompetencer hos kunden eller dennes rådgivere. I vejledningens bilag 3 er indsat en samlet oversigt over bilagene i K02.

3.3 K03 standardkontrakt for længerevarende it-projekt baseret på en agil metode K03 blev introduceret i december 2012 og er målrettet større projekter af mere kompleks karakter, hvor udviklings- og implementeringsprojekter er af en vis størrelse, og hvor man enten ikke ønsker eller ikke kan lægge sig fast på en fuldstændig foruddefineret løsning. K03 understøtter gennemførelse af agile it-projekter under anvendelse af en agil metode, der giver mulighed for, at kunden kan gennemføre et it-projekt, selv om alle krav endnu ikke er kendt. K03 fokuserer derfor i høj grad på samarbejdet mellem parterne og den proces, som kunden og leverandøren skal gennemløbe for at definere den endelige leverance. Leverancen leveres i flere delleverancer, der som udgangspunkt overtages løbende og kan ibrugtages særskilt. Kontraktens anvendelsesområde baserer sig på følgende hovedprincipper: K03 Anskaffelsen sker på grundlag af kundens behovsopgørelse, som angiver kundens særlige forretningsmæssige mål og behov på et overordnet niveau. Kundens krav er opdelt i Absolutte Krav og Øvrige Krav. Den endelige leverance fastlægges af parterne i fællesskab på baggrund af kundens behovsopgørelse, kundens kravliste og leverandørens overordnede løsningsbeskrivelse. Anskaffelsen sker som udgangspunkt til fast tid og inden for en fast prisramme. Hver delleverance er nedbrudt i en række iterationer, hvor kunden og leverandøren i fællesskab fastlægger en prioritering og detaljering af den leverance, der skal leveres. Leverandøren har et overordnet projektansvar, men kunden har et medansvar for projektets gennemførelse. Anskaffelsen forudsætter, at begge parter har den fornødne indsigt og erfaring med den anvendte agile metode. Anskaffelsen omfatter som udgangspunkt vedligeholdelse og support af alle delleverancer fra kundens overtagelse heraf. Hvis systemanskaffelser sker på baggrund af leverancer, der alene indeholder programmel og øvrige tjenesteydelser, skal kontrakten rettes til i overensstemmelse hermed. Kontrakten forudsætter, at der anskaffes en løsning, som kunden selv eller tredjemand kan driftsafvikle. Hvis kunden samtidig med anskaffelsen ønsker, at leverandøren skal forestå driftsafvikling, skal kontrakten suppleres med en selvstændig driftskontrakt/driftsvilkår. Driftskontrakt/driftsvilkår skal indsættes i kontraktens bilag 12. Kontrakten kan ikke benyttes til servicebureau/asp-leverancer eller tilsvarende, hvor leverancen leveres som en serviceydelse fra leverandøren. Gennemførelse af et succesfuldt agilt projekt forudsætter, at kunden og kundens organisation afsætter væsentlige ressourcer til projektgennemførelsen. Samtidig skal kunden sikre, at der etableres en decentraliseret beslutningskompetence hos projektleder og de øvrige nøglepersoner, der har det løbende samarbejde med leverandøren. Ved brug af K03 bør der tages udgangspunkt i de bilag, der indgår som en del af den samlede kontraktpakke. Bilagene er ikke tiltænkt som egentlige skabeloner til bilag, som i K01, men forudsættes i højere grad at være et rammeværk for de centrale forhold, som kunde og leverandør skal sikre er adresseret i de respektive bilagsområder. Der forestår således et mere omfattende bilagsarbejde for kunden ved anvendelse af K03 end i forhold til K01. Dette arbejde kræver både tekniske, kommercielle og juridiske kompetencer hos kunden eller dennes rådgivere. I vejledningens bilag 3 er indsat en samlet oversigt over bilagene i K03. 3.4 Sammenligning af standardkontrakter I bilag 1 sammenstilles de tre standardkontrakter inden for en række centrale temaer. Projektlederen og styregruppen kan i kombination med gennemgangen i afsnit 3.1 til 3.3 benytte denne sammenstilling i analyserne og overvejelserne vedrørende valg af kontrakt.

4 Udbud og dialog Følgende beskrivelse af reglerne om konkurrenceudsættelse udgør derfor en kortfattet gennemgang af de forhold, som projektlederen skal være opmærksom på. 4.1 Udbudsreglernes betydning for kontrakterne og it-projektmodellen Fokus for denne vejledning er at beskrive samspillet mellem projektmodellen og kontrakten til itanskaffelsen. Nedenstående beskrivelse af reglerne om konkurrenceudsættelse udgør derfor alene en kortfattet gennemgang af de forhold, som projektlederen skal være opmærksom på. Det anbefales, at projektlederen parallelt med overvejelserne om valg af kontrakt overvejer hvilken udbudsproces, som kontrakten skal indgå i. Mindre it-projekter med en værdi på mellem 500.000 kr. og EU s tærskelværdi (ca. 1 mio. kr. for statslige myndigheder) skal konkurrenceudsættes efter tilbudslovens regler, et såkaldt nationalt udbud. Der skal ske en annoncering på udbud.dk (http://www.udbud.dk). Statslige projekter med en værdi over EU s tærskelværdi, skal konkurrenceudsættes efter EU s udbudsregler, hvilket betyder, at en række detaljerede krav skal følges. Der skal ske en annoncering i EU-tidende (http://ted.europa.eu). Som alternativ til udbud efter tilbudslovens regler eller EU-udbudsregler vil det i visse tilfælde være muligt at anvende SKI s rammeaftaler. Disse behandles særskilt nedenfor i afsnit 4.2. I det følgende vil beskrivelsen af projektmodellen og konkurrenceudsættelsen tage udgangspunkt i en EU-udbudsproces. Statens standardkontrakter for it-anskaffelser er alle udarbejdet under hensyntagen til principperne i EU's udbudsregler. Ordregiver er naturligvis forpligtet til at anvende kontrakterne i overensstemmelse med disse principper. De mest udbredte udbudsformer Udbud Offentligt udbud: Alle interesserede kan som udgangspunkt afgive et tilbud Begrænset udbud: På baggrund af en prækvalifikationsfase udvælges et mindre antal leverandører til at afgive tilbud Konkurrencepræget dialog: På baggrund af en prækvalifikationsfase udvælges et mindre antal leverandører til en dialogrunde, hvorefter der afgives et endeligt tilbud Kunden kan som udgangspunkt frit vælge mellem offentligt udbud og begrænset udbud. Hvis it-projektet har en vis kompleksitet og derfor må forventes at medføre en væsentlig arbejdsbyrde hos tilbudsgiverne 1, bør udbudsformen begrænset udbud benyttes. Hvis projektet har en høj kompleksitet, og kunden ikke (i tilstrækkeligt omfang) kan beskrive de tekniske eller finansielle krav, bør det overvejes at afklare mulighederne for at gennemføre en konkurrencepræget dialog. Denne udbudsform har indbygget én eller flere 1 Ligeledes kan ordregivers arbejdsbyrde i forbindelse med at evaluere et meget højt antal tilbud være væsentlig.

dialogfaser, hvor kunden og de udvalgte tilbudsgivere har mulighed for at drøfte den efterspurgte ydelse og de nærmere vilkår for levering heraf. 4.2 Om SKI-rammeaftaler Som alternativ til gennemførelse af et EU-udbud kan det overvejes at benytte SKI's rammeaftaler, hvis der findes relevante aftaler til at dække ordregivers konkrete behov. Om en SKI-aftale er relevant bør vurderes ud fra følgende parametre: Er den ønskede løsning omfattet af den pågældende aftale? Matcher leveringsvilkårene 2 /leveringsmodellen ordregivers ønsker? Er de relevante leverandører på aftalen? De fleste SKI aftaler forudsætter, at der gennemføres et miniudbud blandt de leverandører, der er på den pågældende aftale. Miniudbud har store ligheder med et EU-udbud med den undtagelse, at der ikke skal gennemføres en prækvalifikation, da leverandørerne allerede er udvalgt af SKI. SKI s aftaler har en lighed, omfang og kompleksitet, der minder om traditionelle itkontrakter, herunder bl.a. K02, men de vil ofte dække et snævert leveranceområde, der kan betyde, at kunden skal foretage konkurrenceudsættelse på flere aftaler for at få opfyldt det samlede forretningsmæssige behov. F.eks. kræver systemanskaffelse og efterfølgende drift anvendelse af to separate aftaler. Anvendelsen af flere aftaler må forventes at betyde, at kunden skal indgå aftaler med flere forskellige leverandører. De styringsmæssige udfordringer i den samlede aftale/leverandørkonstruktion skal derfor nøje overvejes, inden en SKI-aftale vælges. 4.3 Teknisk dialog med markedet Som led i planlægning af et projekt vil det ofte være relevant og anbefalelsesværdigt at tage en dialog med udvalgte leverandører på markedet. En dialog kan bl.a. være med til at afklare: Hvilke leverandører, der er på markedet? Hvilke krav markedet kan honorere? Om der er særlige forhold vedr. vilkår, som ordregiver skal være opmærksom på? Har lignende løsninger været udviklet før? Hvilken udbudsstrategi vil det være fornuftigt at vælge? Dialogen med leverandørerne betegnes "teknisk dialog", og skal naturligvis gennemføres på en sådan måde, at de udvalgte leverandører ikke får en fordel frem for andre. Udvælgelsen af deltagere til dialogen skal derfor ske på sagligt grundlag. Der bør ligeledes etableres en høj grad af åbenhed om dialogen og dens resultater, f.eks. ved at offentliggøre referater eller konklusioner fra dialogen. Den tekniske dialog bør ske tidligt i processen, dvs. førend ordregiver påbegynder specificeringsarbejdet. Dette giver dels den største værdi og skaber også en vis tidsmæssig luft til selve udbudsprocessen, hvilket er med til at understøtte ligebehandling af tilbudsgiverne. Ordregiver bør gennemføre dialogen i idéfasen eller tidligt i analysefasen. Læs mere om teknisk dialog i udbudsrådets vejledning om teknisk dialog, Dialog ved udbud - hvad er muligt? (www.udbudsraadet.dk). 2 SKI s aftaler er kendetegnende ved, at ordregiver som udgangspunkt ikke kan ændre i de fastlagte vilkår for levering af leverancen.

5 Projektlederens overblik Følgende beskrivelser hvad og hvornår vedr. kontrakter i forhold til faserne i et projekt. Det er vejledningens primære formål at sætte it-projektlederen i stand til i alle projektets faser at overskue og vurdere sit valg og brug af kontrakt. Denne oversigtsmodel viser, hvor kontraktforløbets/leverandørsamarbejdets milepæle placerer sig i forhold til projektmodellens fasemodel. Dette kontraktforløb har især betydning for projektlederens tidsplan og planlægning af aktiviteter. Modellen er i større format vedlagt vejledningen i bilag 2. Milepælsfiguren illustrerer, at der i projektets levetid er en række milepæle, som er defineret og styret af udbudsprocessen, valg af kontrakt og det efterfølgende samarbejde med leverandøren. Disse aktiviteter har et momentum, der i vidt omfang er uafhængigt af projektets og organisationens aktiviteter og tidsplan. Det er derfor vigtigt allerede i idéfasen og analysen at etablere et solidt grundlag for de centrale beslutninger i projektet, eksempelvis kontraktvalg.

6 Projektets hovedfaser I de følgende afsnit gennemgås for hver hovedfase i den fællesstatslige it-projektmodel de strategiske overvejelser, projektlederen og styregruppen med fordel kan gøre sig med hensyn til enten valg eller brug af kontrakten i it-projektet. 6.1 Idéfasen I idéfasen skal der samles viden, der kan kvalificere projektideen og gøre det muligt at udarbejde et projektoplæg, der kan danne grundlag for beslutningen om at etablere et egentlig projekt. 6.1.1 Strategiske overvejelser Som en del af dataindsamlingen i idéfasen kan man med fordel begynde med en indledende dialog med brugere og markedet, jf. afsnit 4.3, for herigennem at blive bedre i stand til at vurdere behovet for evt. udbud og arten af dette samt vurdering af leverancemodel og kontrakt. Selv om ikke alle oplysninger foreligger på dette tidspunkt, giver en tidlig analyse af projektet mulighed for og ny viden til at sætte konkrete aktiviteter i gang. En tidlig analyse sætter desuden fokus på den senere kontraktudfyldelse og kan derfor minimere de efterfølgende risici ved dette arbejde. 6.1.2 Analyse til brug for udbuds- og kontraktovervejelser Allerede i idéfasen kan man med fordel få undersøgt forudsætningerne for udbuds- og kontraktvalg. En kontraktanalyse bør omfatte følgende forhold: Projektets karakter: Hvilken karakter har den forventede it-leverance (standardløsning eller specialtilpasset løsning)? Er organisationens forretningsmæssige mål kendte? Kan organisationen udtrykke sine behov i klare krav, der kan understøttes af et itsystem? Hvordan hænger tid/pris/funktionalitet på it-anskaffelsen sammen med projektets gevinster? Hvad er vigtigst: tid/pris/kvalitet? Forventer organisationen, at ønsker til løsningen er stabile i projektperioden eller dynamiske? Typen af organisation - hvem er myndigheden selv?: Har organisationen/projektlederen erfaring med tilsvarende projekter? Har projektet/organisationen kompetencer til at beskrive de arbejdsgange og systemunderstøttelse, som er ønsket? Hvilke erfaringer/kompetencer har projektet/organisationen til at styre/samarbejde med leverandøren? Hvordan tager projektet/organisationen beslutninger? Hvilke beslutninger kan uddelegeres? Markedssituationen På hvilket marked kan projektet købe den it-leverance, som organisationen ønsker sig? Er markedet velfungerende? Har projektet/organisationen hentet referencer fra andre myndigheder med lignende projekter? Er leverandørerne inden for dette felt modne/umodne? Har projektet/organisationen hentet referencer fra andre myndigheder, der har gennemført lignende projekter? Er der standardløsninger, som ligner den løsning, som organisationen ønsker sig? Er der mange generelle leverandører eller få specifikke leverandører til den ønskede ydelse?

Kig på oversigten over kontraktmodellerne samt bilag 1 og få et første bud på hvilke kontrakttyper, der er bedst egnede. Punkt 1-3 skal sammenholdes, og der skal kunne peges på en foreløbig kontraktmodel, der herefter anføres i ledelsesproduktet "Projektoplægget". Der vil i de fleste situationer være hensyn/ønsker, som peger i flere retninger på samme tid. Det er på dette tidlige tidspunkt ikke et problem, men blot en vigtig viden for projektlederen/styregruppen. Pointen er, at der fortsat er tid til at reagere på denne viden og evt. iværksætte kompenserende foranstaltninger. Den erhvervede viden kan påvirke de indledende risici-overvejelser og f.eks. medføre ændringer i projektoplægget eller nedlukning af projektideen. Idéfasen afsluttes med udarbejdelsen af et projektoplæg og udpegning af projektets sponsor. Denne skal findes iblandt medarbejderne fra organisationens direktionsniveau. FASETJEKLISTE for kontraktfokus Idefasen Har projektlederen viden nok til at berige projektoplægget med et indledende tentativt valg af udbudsform og kontrakt? Hvis nej, kan styregruppen godkende yderligere afdækning? Opbygning af kapacitet i organisationen til at understøtte valget af udbudsform og kontrakt Er det gjort/godkendt af styregruppen? Har projektet/organisationen haft teknisk dialog med markedet? Har projektet/organisationen foretaget en markedsanalyse? Har projektet/organisationen været i kontakt med brugerne af en kommende løsning Afspejler projektets risici analysen af kontraktvalget? 6.2 Analysefasen Analysefasen påbegyndes efter idéfasen, der har dannet projektoplægget. Der foreligger nu et formelt godkendt projekt. I denne fase dannes ledelsesprodukterne (PID, BC). Disse produkter dokumenterer således hele beslutningsgrundlaget for projektet. I analysefasen vil rammerne for projektet for alvor blive undersøgt og fastsat. Dette inkluderer de strategiske overvejelser om kontraktvalg og hvilke aktiviteter, dette valg giver anledning til, blandt andet i forhold til udfyldelse af kontraktens bilag. 6.2.1 Strategiske overvejelser På baggrund af den viden, som projektlederen har nu, skal det afklares, om det indledende kontraktvalg beskrevet i projektoplægget fra idéfasen (som et resultat af den gennemførte kontraktanalyse) kan blive opdateret og uddybet. Hvis enkelte punkter fra de strategiske overvejelser fra idéfasen ikke er blevet gennemført, påbegyndes disse først. Hvis der ikke allerede i idéfasen har været dialog med markedet, bør det tidligt i analysefasen afklares, om det er relevant. I givet fald bør den tekniske dialog gennemføres nu, jf. afsnit 4.3 og afsnit 6.1.1. Når der sker en yderligere kvalificering af kontraktvalget, bør dette afspejle sig i en opdatering af projektets ledelsesprodukter. Kontraktvalget bør basere sig på de vurderinger om projektet og organisationen, som også er afspejlet i projektets øvrige analyser og ledelsesprodukter. Projektlederen kan i forbindelse med det konkrete kontraktvalg med fordel være opmærksom på: Hvordan valg af kontrakt påvirker projektets risici o Er risici aftaget/steget? o Er der kommet nye risici til?

Projektets tidsplan o Den valgte kontraktform har en indre tidsplan, som skal kunne rummes i projektets tids- og ressourceplan. Projektets business case o Valg af kontrakt skaber forskellige sandsynligheder for tid og pris og leveret ydelse. Særligt risikovurderingerne for anskaffelsessummen bør afspejle den risiko for prisen, som kontrakten lægger op til. PID skal eventuelt revideres med oplysninger om, hvorvidt der iværksættes kompetenceudvikling i projektet, hentes bistand indefra/udefra, trækkes på erfaringer fra andre myndigheder og lignende. Projektets kvalitetsplan bør afspejle, hvordan den valgte kontrakt giver muligheder for test og accept af leverancen. Når konsekvenserne af kontraktvalget kombineres med udbudsovervejelserne, kan ledelsesproduktet "udbudsstrategi" udfyldes. Analysefasen afsluttes med en godkendelse af ledelsesprodukterne. Ved projekter på en størrelse over 10 mio. kr., skal der ydermere foreligge en gennemført risikovurdering hos IT-projektrådet før overgang til anskaffelsesfasen. Arbejdet med kontrakten og bilag begynder i analysefasen: Der vil typisk være et betydeligt tidspres på centrale ressourcer i projektet i anskaffelsesfasen, hvilket kan medføre utilsigtede forsinkelser. Projektlederen og styregruppen kan derfor med fordel på baggrund af det tentative valg af kontraktform iværksætte en række af de forberedende aktiviteter til kravspecificering og udfyldelse af kontraktens bilag, jf. nærmere beskrivelse heraf i afsnit, herunder inddrage de relevante ressourcer fra forretningen eller rådgivere allerede i den sidste del af analysefasen. Spørgsmålet om, hvornår yderligere aktiviteter til forberedelse af anskaffelsesfasen iværksættes, må bero på en konkret vurdering i projektet/styregruppen. Projektlederen kan dog med fordel orientere sig i afsnit 6.3.1 samt i anskaffelsesfasens fasetjekliste, mens den endelige godkendelse af projektet udestår. 6.3 Anskaffelsesfasen Efter afslutning af analysefasen, hvor projektets ledelsesprodukter er godkendt og der foreligger en evt. gennemført risikovurdering fra IT-projektrådet, kan anskaffelsesfasen påbe- FASETJEKLISTE for kontraktfokus Analysefasen Er overvejelserne/tjeklisten fra idéfasen gennemført/yderligere detaljeret? Er projektets risici ajourført efter, at valg af kontrakt (fordele/ulemper) er analyseret? Er der igangsat aktiviteter, som forbereder projektet/organisationen på de arbejdsopgaver, som kontraktarbejdet vil medføre i anskaffelsesfasen (her tænkes især på evnen til, at kunne udfylde kontraktbilag på tilfredsstillende vis)? Har projektlederen/organisationen adgang til inspirationsmateriale fra tidligere projekter Er der overblik over, hvad der kan genbruges? Har projektet adgang til de nødvendige ressourcer og beslutningstagere i forretningen til at udforme servicemål og indhold i support/vedligehold?

gyndes. I anskaffelsesfasen vil projektets strategiske overvejelser og beslutninger om kontrakten skifte fra at handle om hvilken kontrakt, som skal anvendes, til hvordan kontraktens bestemmelser og værktøjer (bilag) skal udformes og benyttes. 6.3.1 Strategiske overvejelser Anskaffelsesfasen vil i sig selv typisk være opdelt i en række mindre (ledelses-) faser. Disse faser omfatter specificering af ydelsen, udformningen af kontraktens bilag samt gennemførelse af udbudsforretningen, efterfulgt af kontraktindgåelse med den valgte leverandør. Hvis ikke styregruppen i den foregående fase har besluttet hvilken kontrakt, der skal anvendes, skal dette ske i indledningen af anskaffelsesfasen. Derefter begynder projektlederens arbejde med at levere data til såvel hovedkontrakten som dens bilag. Projektlederen vil typisk få intern eller ekstern juridisk bistand til udformning og tilpasning af kontraktens bestemmelser. Hvis organisationen har opbygget en vidensbank af tidligere kontraktvarianter med forskelligt sigte, kan der bygges videre på disse. Der bør dog være opmærksomhed på hvor og hvorfor, der er sket tilpasninger til standardkontrakternes formuleringer. Ændringer i kontrakterne skal altid være konkret begrundende og skal ske under hensyntagen til det foreliggende projekt. Projektlederen vil typisk få ansvaret for at udarbejde kontraktens bilag, mens den juridisk ansvarlige vil håndtere udformningen af hovedkontrakten. Både projektleder og styregruppe bør i denne fase være opmærksomme på, at netop bestemmelserne i kontraktens bilag ofte er omdrejningspunktet for eventuelle senere vanskeligheder, i samarbejdet med leverandøren. Der bør derfor både afsættes tid til og være ledelsesmæssig bevågenhed omkring udformningen af betingelserne i kontraktens bilag. Særligt skal projektlederen være opmærksom på, at bilagenes regulering vedr. servicemål, vedligeholdelse og support har en direkte påvirkning på forretningen/basisorganisationen, når systemet idriftsættes. Endeligt skal projektlederen sikre sig, at kontrakt og bilag har den fornødne sammenhæng, så konfliktende regulering eller løse ender undgås. 6.3.2 Kontraktens samlede udtryk Ved udfyldelsen af hovedkontrakt og bilag skal projektlederen og styregruppen være opmærksom på, hvordan den samlede regulering i kontrakten fremstår. Alle valg af konkret regulering har fordele og ulemper for kunden. En lavere risiko og bedre vilkår hos kunden vil som udgangspunkt påføre leverandøren både øget risiko og mindre attraktive vilkår. En øget risiko hos leverandøren vil typisk have konsekvenser for prisen på leverancen, antallet af forbehold til kontrakten eller i yderste konsekvens færre/manglende tilbud fra relevante leverandører. Valget af den samlede regulering bør derfor afbalanceres i forhold til det konkrete projekt og organisationens profil. Dette betyder ikke, at der altid er behov for afvigelser i forhold til udgangspunktet i standardkontrakterne, men at der er behov for refleksion over det konkrete valg. Projektlederen bør i dialog med projektets juridiske kompetencer særligt være opmærksom på følgende: Er den overordnede fordeling af risiko i den valgte kontraktmodel mellem kunden/leverandøren passende i forhold til den ønskede ydelse og det pågældende marked? Relevante i denne forbindelse er bl.a. bestemmelser om drift, bod, ansvar og rettigheder, samt udbudsretlige mindstekrav.

Afspejler den valgte vederlagsmodel den efterspurgte leverance, kundens ønsker, og stemmer modellen overens med den praksis, der eksisterer på markedet? Afspejler kontraktens bestemmelser om kundens deltagelse og ansvar organisationens forventninger, og er dette passende i forhold til den leverance/det projektforløb, der efterspørges? Er der særlige forretningsmæssige eller organisatoriske forhold, der bør afspejles i specifik regulering, f.eks.: - Ekstraordinær mulighed for opsigelse/udtræden? - Særlige misligholdelsesbeføjelser, f.eks. ved leverandørens forsinkelse? 6.3.3 Kontraktens bilag Kontraktens bilag indeholder den operationelle regulering af leverancen, og hvordan denne leveres til kunden. Projektlederen bør særligt have fokus på følgende elementer: Kravspecifikationen/behovsopgørelse: Afspejler de opstillede krav kundens forretningsmæssige behov, og er specifikationen udtryk for en målrettet opgørelse heraf? Matcher specifikationen det leverandørmarked, der forventes at byde på opgaven? Fremstår evt. mindstekrav tydelige, og er disse entydigt afgrænset i kravspecifikationen? Vedligehold, support og drift: Hvilken type af support og vedligehold skal leverandører levere, når projektet/ systemet er overgået til drift? Hvilke supporttyper er der behov for (1./2. level)? Det konkrete indhold af vedligeholdelsen (nye versioner/releases, forskellige typer fejlrettelser?) Hvilke typer driftsydelser leverandøren skal levere/leverancens sammenhæng til kundens egne driftsydelser. Servicemål for leverandør: Reaktionstider på support/vedligehold? o Er hurtig respons fra leverandøren til fejlsager vigtig for organisationen? o Er organisationen opmærksom på, at responstiderne som udgangspunkt omhandler påbegyndt fejlrettelse ikke gennemført fejlrettelse? Systemets performance med hensyn til driftseffektivitet og svartider? o Modsvarer kravet til performance, kundens forretningsmæssige behov og det itmiljø, som systemet skal være en del af? o Fremtidige forventninger til ændringer i behovet for kapacitet og skalering af systemet? Projektorganisationen: Har projektet/org. krav til den fælles projektorganisation og samarbejdsstruktur? Styring af leverancen og dens indhold: Hvad er betingelser og forudsætninger for test og afprøvning? Kriterierne for godkendelse af prøver. Tidsmæssig placering af prøver. Fælles for alle ovenstående punkter er, at kravene til leverandøren bør afspejle et konkret forretningsmæssigt behov. Kunden bør være særligt opmærksom på omkostningsdrivende krav, f.eks. krav til fejlretning uden for normal arbejdstid, hvis der ikke er et konkret behov herfor. Projektlederen kan også finde inspiration til det fremtidige samarbejde med leverandøren i guide til godt kunde-leverandørsamarbejde.

En central del af anskaffelsesfasen er gennemførelse af udbudsforretningen, der i sidste ende leder frem til den valgte leverandør. Se afsnit Fejl! Henvisningskilde ikke fundet. for en kort introduktion til relevante udbudsformer. Anskaffelsesfasen afsluttes, når kontrakten er klar til at blive indgået. De egentlige projektaktiviteter mellem kunden og leverandøren fortsætter herefter i gennemførelsesfasen. FASETJEKLISTE for kontraktfokus Anskaffelsesfasen Er punkterne fra idé- og analysefasens tjeklister gennemført? Er de rette ressourcer for fasen tilgængelige? Har projektet adgang til de nødvendige ressourcer og beslutningstagere i forretningen til at udforme servicemål og indhold i support/vedligehold? Har styregruppen forholdt sig til fordeling af rettigheder og pligter i den valgte kontraktmodel? Er der en klar arbejdsdeling mellem projektleder, projektgruppe, juridisk bistand og styregruppen om udformning af kontraktens indhold? Har projektlederen/organisationen adgang til inspirationsmateriale fra tidligere projekters kontrakter, og er der overblik over, hvad der kan genbruges? 6.4 Gennemførelsesfasen Efter afslutning af anskaffelsesfasen, der har resulteret i et leverandørvalg og en indgået kontrakt, påbegyndes gennemførelsesfasen. I gennemførelsesfasen vil projektets strategiske overvejelser og beslutninger vedrørende kontrakten handle om, hvordan kontraktens bestemmelser og værktøjer til projekt- og leverandørstyring bedst anvendes. 6.5 Strategiske overvejelser IT-projektrådet har udarbejdet en guide til godt kunde- og leverandørsamarbejde, guide til godt kunde-leverandørsamarbejde, der kan hentes på rådets hjemmeside http://www.itprojektraad.dk. Formålet med guiden er at inspirere kunder og leverandører til at opbygge et tillidsfuldt samarbejde i statslige it-projekter. Med et godt samarbejde kan opståede udfordringer og behovet for ændringer håndteres, uden at parterne kommer for langt fra hinanden, så juridisk konflikthåndtering undgås. Projektlederen bør i sit leverandørsamarbejde være opmærksom på nøje at overholde de forpligtelser, der efter kontrakten, påhviler kunden. Selv om leverandøren har hovedansvaret for levering af leverancen, er det væsentligt både for projektets succes og for kundens retsstilling, at kunden leverer sine ydelser som aftalt. Projektlederen skal derfor løbende sikre, at alle kundens forpligtelser opfyldes. Dette er særlig vigtigt, hvis projektet baserer sig på et agilt samarbejde mellem kunde og leverandør. Leverandøren er i gennemførelsesfasen forpligtet til i forbindelse med centrale milepæle og forskellige former for afprøvning at dokumentere, at projektet har den rette fremdrift. Det er væsentligt, at projektlederen på disse tidspunkter sikrer sig, at de aftalte leverancer er til stede, og at manglende levering påtales. Projektlederen skal i den forbindelse også sikre, at de formelle samarbejdsprocedurer (regelmæssige møder, referat, skriftlig dokumentation på aftaler, ændringer m.m.) følges, også i de perioder hvor samarbejdet fungerer upåklageligt. I forbindelse med afslutningen af gennemførelsesfasen gennemføres en endelig afprøvning ved en overtagelsesprøve og en driftsprøve. Det er i denne forbindelse særlig vigtigt, at projektlederen sikrer sig, at alle formelle krav til gennemførelse af prøverne følges.

Selv om det er vigtigt for organisationen at kunne godkende leverancen, for at denne kan tages i brug til løsning af de forretningsmæssige opgaver, skal man som projektleder være opmærksom på, at det indbyggede pres for at afslutte udviklingsforløbet ikke samtidig betyder, at kravene til godkendelse sænkes. Hvis leverancen godkendes, uanset at der foreligger fejl, skal projektlederen sikre sig, at der i overensstemmelse med kontraktens bestemmelser udarbejdes klare aftaler for udbedring. En basal samarbejdsstruktur og dokumentation for denne betyder, at kunden udviser rettidig omhu, således at en ureguleret samarbejdsform ikke vinder hævd. Det betyder også, at der i en eventuel senere juridisk kontekst eksisterer den nødvendige dokumentation for en argumentation om bod, erstatning eller misligholdelse. Kontraktens værktøjer til sanktioner over for leverandøren knytter sig til bod, erstatning og misligholdelse. Der henvises til skemaet i bilag 1, hvor de enkelte sanktioner er beskrevet. 6.5.1 Overdragelse af projektet til forretningen I forbindelse med projektafslutningen bør projektet sikre, at der overføres tilstrækkelig viden om kontraktens bestemmelser til forretningen. Denne overdragelse er yderst vigtig for at sikre gode rammer for det kommende leverandørsamarbejde og kan i praksis håndteres på flere måder i organisationen, f.eks. ved personsammenfald, overdragelsesmøder eller erfanetvæk. Overdragelsen af viden om kontraktens bestemmelser til forretningen er en vigtig del af projektets nedlukning, idet mangel på overdragelse af viden om kontraktens bestemmelser udgør en væsentlig risiko for gevinstrealiseringen. De fleste it-kontrakter med vedligehold og evt. drift har en samlet løbetid på 5-7 år. Typisk vil projektperioden alene udgøre 1-2 år af denne periode. Hovedparten af samarbejdet med leverandøren varetages derfor af forretningens systemansvarlige/systemejere i forbindelse med den løbende drift. Organisationen kan potentielt tabe en større eller mindre del af sin retsstilling, hvis forretningen ikke er klar til at bruge kontraktens værktøjer til at understøtte leverandørsamarbejdet. Forretningen skal således være forberedt på og blandt andet have kendskab til hvilke servicemål og konkrete vedligeholdelsesydelser, kontrakten giver ret til. I den forbindelse er det også vigtigt at kende til de kontraktlige redskaber for at håndhæve disse, f.eks. ved at pålægge bod og afslag i løbende vederlag. Efter at projektet er idriftsat og overdraget til forretningen skal det sikres, at alle relevante projektaktiviteter er gennemført, herunder f.eks. uddannelse. Når dette er sket, kan projektorganisationen formelt lukkes ned, hvorefter gennemførelsesfasen ligeledes afsluttes. FASETJEKLISTE for kontraktfokus Gennemførelsesfasen Bliver aftaler og ændringer mellem kunde og leverandør skriftligt dokumenteret? Holdes strukturen i samarbejdsorganisationen? Har projektet/kunden fulgt op på 1.1 at projektet har den aftalte fremdrift? 1.2 afvigelser fra tidsplanen? 1.3 afviklingen af prøver? Har projektet overholdt egne forpligtigelser i kontrakten? Har projektlederen ved fasens afslutning overdraget viden om kontraktens værktøjer til leverandørsamarbejde til en ansvarlig i forretningen? 6.6 Realiseringsfasen Efter afslutning af gennemførelsesfasen, der har resulteret i et idriftsat system, påbegyndes realiseringsfasen. Realiseringsfasen er medtaget i denne vejledning af hensyn til de itprojekter, hvor kontrakten har et element af vedligehold, support og evt. drift.

6.6.1 Strategiske overvejelser I realiseringsfasen findes projektorganisationen ikke længere, og der bør som sidste del af den foregående fase være sket en overdragelse fra projektet til forretningen. En del af denne overdragelse vedrører de strategiske overvejelser og beslutninger om, hvordan myndigheden fremadrettet vil håndtere kontrakten, og hvordan myndigheden efter overtagelsen af leverancen vil foretage en dokumenteret leverandørstyringsproces i form af contract management. Myndigheden indhøster alene den fulde værdi af kontrakten, hvis organisationen løbende og aktivt bruger kontrakten og dens værktøjer i leverandørsamarbejdet. De fleste it-kontrakter med vedligehold og evt. drift har en samlet løbetid på 5-7 år. Typisk vil projektperioden alene udgøre 1-2 år af denne periode. Hovedparten af samarbejde med leverandøren varetages derfor af forretningens systemansvarlige/systemejere i forbindelse med den løbende drift. Forretningen skal til brug for den løbende contract management proces derfor have det fornødne kendskab til kontrakten. Dette skal sikre, at der som minimum kan følges op på følgende forhold: Kontraktens betalingsmekanismer og faktureringsbestemmelser De fastlagte servicemål og rapportering herom De grundlæggende juridiske værktøjer til at håndhæve servicemål og andre leverandørforpligtigelser Regler for ændringer og tilpasning af leverancen samt tilknyttet dokumentation herfor. Endelig bør forretningen i de sidste år af kontraktens løbetid forberede, hvad der skal ske ved kontraktens ophør. En vigtig del af organisationens opgaver er at forberede en hel eller delvis overgang til nyt system eller ny leverandør. Dette vil typisk ske som resultat af et nyt udbud. Den nuværende leverandør skal i den forbindelse typisk medvirke til at sikre, at det rette dokumentationsniveau for den nuværende løsning er til stede. Forretningen skal sikre, at leverandøren lever op til sine forpligtelser. FASETJEKLISTE for kontraktfokus Realiseringsfasen Kender forretningen kontraktens servicemål? Er der ansvarlige i forretningen, som systematisk følger op på leverandørens leverancer? Opretholdes samarbejdsorganisationen med leverandøren? Dokumenteres samarbejdet (særligt i forhold til aftaler om ændringer) fortsat?

Side 20 af 30 Bilag 1 Sammenligning mellem standardkontrakterne Standardkontrakterne Formålet med nedenstående skema er at give et overordnet overblik over de forskellige standardkontrakter og sammenligne reguleringen af udvalgte temaområder i kontrakterne. Det må altid bero på en konkret vurdering, hvilken kontraktstype man vælger for det enkelte projekt. Dette hovedtema beskriver standardkontrakternes anvendelsesområde, herunder krav til specificering af kundens behov, samt leverancens gennemførelse som en samlet levering eller ved en trinvis idriftsættelse. Endelig fremgår den valgte kontrakts ansvarsfordeling mellem parterne, som organisationen skal vurdere i forhold til den ønskede risikoprofil. Emne K01 K02 K03 It-projektets karakter og kontraktens anvendelsesområde Leveranceform og kravspecifikation Bruges til mindre systemanskaffelser baseret på køb af standardprodukter, med ingen, eller kun mindre, tilpasninger og tilretninger. Bruges ofte til kortvarige projekter med systemleverancer, som ikke skal udrulles til mange institutioner, og hvor der ikke er behov for en trinvis afprøvning og idriftsættelse. Traditionel vandfaldsmodel-leverance. Kunden skal udarbejde en detaljeret og udtømmende kravspecifikation. Bruges til større komplekse systemanskaffelser, baseret på standardprodukter med omfattende tilretninger og specialudvikling. Leverancen har en stor økonomisk og forretningsmæssig værdi for kunden, og leveres over et længerevarende tidsforløb. Herudover er der ofte en høj teknisk og organisatorisk kompleksitet. Traditionel vandfaldsmodel med en udrulning i faser. Kunden skal udarbejde en detaljeret og udtømmende kravspecifikation. Bruges til gennemførelse af it-projekter udviklet efter en agil metode, hvor der ikke opereres med en detaljeret kravspecifikation, og som forudsætter indsigt i, og kendskab til, agile metoder. Kunden skal have særlige styringsmæssige kompetencer, der adskiller sig fra den traditionelle projekttilgang. Det skal vurderes, om organisationen har de nødvendige kompetencer og evner til at træffe de beslutninger løbende, som et agilt projekt kræver, uden at skulle inddrage ledelsen i de daglige beslutninger om leverancens indhold og planlægning. Et agilt leveranceforløb, hvor leverancen endelig aftales og planlægges i de enkelte iterationer og delleverancer. Kunden skal udarbejde en behovsopgørelse, hvor kunden beskriver sine forretningsmæssige mål, behov og overordnede krav til leverancen. Kravlisten detaljeres i en løbende proces med leverandøren, der muliggør at løsningen fastlægges undervejs. Delleverancer / trinvis idriftsættelse Der er ingen opdeling i delleverancer, eller trinvis ibrugtagning, men alene en samlet levering i én leverance. Kontrakten er således ikke velegnet til længerevarende projektforløb, eller projektforløb med mange udrulninger, eller implementeringer, i forskellige forvaltningsområder. I sådanne projektforløb, vil kunden have både leverancemæssig og økonomisk fordel af at bruge K02, eller tilpasse K01 kontrakten. Mulighed for opdeling i flere delleverancer med særskilt afprøvning og ibrugtagning. Faseopdelingen af leveranceforløbet har til formål, at give en større sikkerhed for levering af leverancen, samtidig med, at kunden, hvis det giver forretningsmæssig værdi, kan vælge at idriftsætte de godkendte delleverancer. Opdeling i flere delleverancer. Særskilt afprøvning, overtagelse og ibrugtagning af de enkelte delleverancer.

Side 21 af 30 Leveranceansvar Kunden ønsker endvidere at sikre sig, at leverandøren har et totalansvar for gennemførelse og levering af den aftalte leverance, jf. i modsætning her til K03. Kundens deltagelse i projektet - Kunden godtgør løbende leverandørens dokumenterede meromkostninger, forårsaget af kundens manglende medvirken. Angivelser af krav om kundens deltagelse skal opfattes som estimater. Der kan under forløbet opstå behov for justeringer heri, både hvad angår omfang og indhold. Ingen af disse justeringer må påføre kunden væsentligt forøgede omkostninger. Kunden ønsker endvidere at sikre sig, at leverandøren har et totalansvar for gennemførelse og levering af den aftalte leverance, jf. i modsætning her til K03. Kundens manglende medvirken medfører, under visse forudsætninger, at leverandøren har krav på erstatning for leverandørens dokumenterede tab. Angivelsen af krav om kundens deltagelse, skal opfattes som estimater for kundens medvirken. Der kan under forløbet opstå behov for justeringer heri. Hvis justeringer påfører kunden væsentligt forøgede omkostninger, skal sådanne omkostninger godtgøres af leverandøren. Leverandøren ikke har et totalansvar, men alene det overordnede leveranceansvar, og kunden har et medansvar for projektets gennemførelse. Kunden påtager sig således et større ansvar, og dermed også risiko, for projektet og dets succes, i forhold til K01 og K02. Leverandøren er under visse forudsætninger berettiget til, i sit vederlag, at medtage omkostninger til dækning af direkte, dokumenterede merudgifter, som leverandøren påføres som følge af forsinkelse, forårsaget af kundens manglende deltagelse forsinkelsen. Hvis kundens manglende deltagelse mv., udgør en væsentlig misligholdelse af kundens forpligtelser efter kontrakten, er leverandøren endvidere berettiget til at opsige kontrakten, for så vidt angår den konkrete delleverance, som er forsinket som følge af kundens manglende deltagelse, samt fremtidige delleverancer. Angivelserne af krav til kundens deltagelse, skal opfattes som forventninger til kundens deltagelse. Under forløbet kan der opstå behov for justeringer heri. Kunden har et medansvar for projektets gennemførelse, og kunden er forpligtet til at deltage aktivt i projektet. Kunden har ansvaret for specifikke opgaver og skal have et faslagt kompetenceniveau. Angivelserne om estimater for kundens deltagelse, skal alene opfattes som forventninger til kundens deltagelse. Kunden skal acceptere justeringer i kundens deltagelse, både angående omfang og indhold, herunder i form af en udvidelse af omfanget af kundens deltagelse uden krav på godtgørelse. Vederlags og rettighedsmodel Dette hovedtema beskriver den overordnede vederlagsmodel, som de enkelte standardkontrakter anvender. Endvidere beskrives den principielle regulering af kundens rettigheder til de typer af programmel, som kunder anskaffer. Emne K01 K02 K03 Vederlagsmodel Fast pris for systemet. Fast pris for vedligeholdelse. Fast pris for leverancen. Fast pris for vedligeholdelse. Som udgangspunkt fast pris for leverancen. Mulighed for forskellige vederlagsmodeller, herunder timebetaling med en makismal øvre grænse. Fast pris for vedligeholdelse.

Side 22 af 30 Levering af programmel Rettigheder til programmel Understøtter og forudsætter leverance af standardprogrammel som en del af systemet. Alene meget begrænset regulering af specialudviklet/specialtilpasset programmel (kundespecifikt programmel). Brugsret til standardprogrammel og specialtilpasset programmel. Ret til at videreudvikle, vedligeholde og ændre, med mindre andet følger af bilag. Tidsubegrænset brugsret til specialudviklet programmel, med mindre andet følger af leverandørens licensvilkår. Ingen regulering af andre myndigheders brugsret. Understøtter og forudsætter både standardprogrammel og specialudviklet programmel (kundespecifik programmel) som en del af leverancen. Brugsret til standardprogrammel og kundespecifikt programmel. Ret til at videreudvikle, videreudvikle og ændre, med mindre andet følger af bilag. Tidsubegrænset brugsret til specialudviklet (kundespecifikt) programmel, med mindre andet følger af bilag Med mindre andet følger af bilag, kan andre offentlige myndigheder få visse brugsrettigheder til det kundespecifikke programmel. Aftalen skal indgås med leverandøren på samme vilkår som dem, der følger af Kontrakten Leverandøren har ingen forpligtelser over for andre offentlige institutioner, til at udføre ændringer af det kundespecifikke programmel. Understøtter og forudsætter både standardprogrammel og specialudviklet programmel (kundespecifik programmel) som en del af leverancen. Brugsret til standardprogrammel og kundespecifikt programmel. Ret til at videreudvikle, vedligeholde og ændre, med mindre andet følger af bilag Tidsubegrænset brugsret til specialudviklet (kundespecifikt) programmel, med mindre andet følger af leverandørens licensvilkår. Ret til at ændre, videreudvikle og vedligeholde kundespecifikt programmel. Den tidsmæssige udstrækning af brugsretten reguleres i bilag. Andre offentlige myndigheder kan få visse brugsrettigheder til det kundespecifikke programmel, med mindre andet følger af bilag. Bonus/ incitamenter Incitamentsmodel er understøttet, men ingen eksempler. Incitamentsmodel er understøttet. Dedikeret bilag med få konkrete eksempler på incitamentsmodeller. Incitaments-model er understøttet. Dedikeret bilag med eksempler på modeller Væsentlige kontraktlige håndtag Dette hovedtema beskriver de væsentligste kontraktprincipper i forhold til de juridiske håndtag, som kunden har brug for i forhold til eksempelvis servicemål, opsigelse/ophævelse samt en misligholdelsessituation. Emne K01 K02 K03 Servicemål Rammen for servicemålene er specificeret i kontraktens modelbilag. Bilagene opererer med svartider, driftseffektivitet (tilgængelighed) og afhjælpning. Bodsmekanismer Bod ved forsinket levering af system. Reduktion i vederlag for vedligeholdelse, ved manglende overholdelse af servicemål i perioden efter overtagelse. Rammen for servicemålene er specificeret i kontraktens eksempler på bilag. Servicemålene har til formål, at opstille krav til svartid og reaktionstid, i forhold til afhjælpning og tilgængelighed. Bod ved forsinket levering (både delleverancer og leverancen samlet). Bod for manglende overholdelse af servicemål ved ibrugtagning af en godkendt delleverance/ leverancen. Rammen for servicemålene er specificeret i kontraktens eksempler på bilag. Servicemålene har til formål, at opstille krav til svartid og reaktionstid i forhold til afhjælpning og tilgængelighed. Bod ved forsinket levering (både delleverancer og leverancen samlet). Bod for manglende overholdelse af servicemål efter overtagelse af delleverancer.

Side 23 af 30 Ophør, herunder mulighed for udtræden af kontrakt samt generelle muligheder for opsigelse Kontraktens løbetid er ikke fastlagt, men reguleres alene af parternes muligheder for opsigelse: Mulighed for kunden til at udtræde ved afslutning af afklaringsfasen, herudover ingen mulighed for udtræden i perioden indtil overtagelsesdagen. Kunden kan med et skriftligt varsel på 6 måneder, til den første i en måned, opsige vedligeholdelses-ordningen, dog tidligst til udløb 1 år efter overtagelsesdagen. Kontraktens løbetid er ikke fastlagt. Mulighed for kunden til at udtræde ved afslutning af afklaringsfasen, herudover ingen mulighed for udtræden i perioden indtil overtagelsesdagen. Kunden kan efter overtagelsesdagen opsige vedligeholdelse og support, med et varsel på 6 måneder, til den første i en måned, dog tidligst til udløb ét år efter overtagelsesdagen. Leverandøren kan ved meddelelse opsige vedligeholdelse og support for hele leverancen med et varsel på 12 måneder, til den første i en måned, dog tidligst til udløb 4 år efter overtagelsesdagen. Kontraktens løbetid er ikke fastlagt. Forud for overtagelse af den sidste delleverance kan kunden udtræde af kontrakten med et varsel på mindst [20] arbejdsdage med virkning for fremtidige leverancer. Kunden kan ved meddelelse opsige vedligeholdelse og support for hele leverancen, med et varsel på 6 måneder, til den første i en måned, dog tidligst til udløb ét år efter overtagelse af den sidste delleverance. Leverandøren kan ved meddelelse opsige vedligeholdelse og support for hele leverancen, med et varsel på 12 måneder, til den første i en måned, dog tidligst til udløb 4 år efter overtagelse af sidste delleverance. Misligholdelse Kunden kan under visse forudsætninger, hæve kontrakten, hvis der i garantiperioden konstateres væsentlige mangler. Hvis leverandøren væsentligt misligholder vedligeholdelsesforpligtelserne i garantiperioden, er kunden berettiget til, at ophæve kontrakten helt eller delvist. Efter garantiperiodens udløb, omfatter hævebeføjelsen alene vedligeholdelsesordningen eller dele heraf. - - - Erstatning Der er erstatningspligtige efter dansk rets almindelige regler. For forhold, der udløser betaling af bod, kan erstatning kun kræves, i det omfang kunden dokumenterer et tab ud over bodsbeløbet. Erstatning og eventuelt bodsbeløb tilsammen, Kunden kan under visse forudsætninger hæve kontrakten, hvis der i garantiperioden konstateres væsentlige mangler. Kunden kan hæve kontrakten, hvis der foreligger en samlet overskridelse af fristerne for godkendt overtagelsesprøve eller driftsprøve med mere end 40 arbejdsdage Hvis leverandørens manglende opfyldelse af modenhedsniveauet har væsentlig betydning for leverandørens forsinkelser eller mangelfulde leverancer. Ved leverandøren væsentligt misligholder vedligeholdelsesforpligtelserne i garantiperioden, er kunden berettiget til at ophæve kontrakten helt eller delvist. Efter garantiperioden, kan misligholdelse af vedligeholdelsesforpligtelserne kun medføre ophævelse af kontraktens øvrige ydelser, hvis vedligeholdelsen har afgørende betydning for kundens fortsat nytte af leverancen. - Der er erstatningspligtige efter dansk rets almindelige regler. Erstatning og eventuelt bodsbeløb eller reduktion af vederlag tilsammen er dog under alle omstændigheder begrænset til leverancevederlaget. Hvis en uvildig sagkyndig ved audit, har truffet afgørel- Kunden kan under visse forudsætninger hæve kontrakten, hvis der i garantiperioden konstateres væsentlige mangler. En samlet overskridelse af fristerne for overtagelse og godkendt driftsprøve, for en delleverance med mere end [40] Arbejdsdage. Hvis leverandørens manglende opfyldelse af indsigtsniveauet har væsentlig betydning for leverandørens forsinkelser eller mangelfulde leverancer. Hvis 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. Hvis leverandøren væsentligt misligholder vedligeholdelsesforpligtelserne i garantiperioden, er kunden berettiget til at ophæve kontrakten, helt eller delvist. Efter garantiperiodens udløb omfatter hævebeføjelsen alene vedligeholdelsesordningen eller dele heraf. Der er erstatningspligtige efter dansk rets almindelige regler. Erstatning og eventuelt bodsbeløb, eller reduktion af vederlag tilsammen, er dog under alle omstændigheder begrænset til leverancevederlaget. Hvis en uvildig sagkyndig ved audit, har truffet afgørel-

Side 24 af 30 - er dog under alle omstændigheder begrænset til systemvederlaget. Parterne er ikke i noget tilfælde ansvarlig for driftstab, følgeskader eller andet indirekte tab. Tab af data anses for indirekte tab. se om manglende opfyldelse af kravene til modenhed kan parternes maksimum for den samlede erstatning og bod e forhøjes med 25 %. Parterne er ikke i noget tilfælde ansvarlig for driftstab, følgeskader eller andet indirekte tab. Tab af data anses for indirekte tab, bortset fra tilfælde, hvor dette skyldes Leverandørens Drift eller anden datahåndtering, hvor dette er omfattet af Kontrakten - se om manglende opfyldelse af kravene til indsigt kan parternes maksimum for den samlede erstatning og bod eller reduktion af vederlag forhøjes med [ ] %. Parterne er ikke i noget tilfælde ansvarlig for driftstab, følgeskader eller andet indirekte tab. Følgeskader og indirekte tab anses ikke at omfatte: [ ]. Tab af data anses for indirekte tab, bortset fra tilfælde hvor dette skyldes Leverandørens Drift eller anden datahåndtering, hvor dette er omfattet af Kontrakten. Driftsmodel Dette hovedtema beskriver, om og hvorledes de enkelte standardkontrakter regulerer køb af driftsydelser for den leverance, som købes i henhold til standardkontrakten. Emne K01 K02 K03 Drift og driftsmodel Drift af leverancen er ikke, som udgangspunkt, omfattet af kontrakten. Drift af leverancen er omfattet af kontrakten. Det forudsættes, at leverandøren/kunden vedlægger en selvstændig kontrakt i dedikeret bilag. Kunden skal således selv forestå beskrivelsen af de driftsydelser og servicemål, som kunden ønsker, at leverandøren skal overholde Drift af leverancen er omfattet af kontrakten. Det forudsættes, at leverandøren/kunden vedlægger en selvstændig kontrakt i dedikeret bilag. Kunden skal således selv forestå beskrivelsen af de driftsydelser og servicemål, som kunden ønsker, at leverandøren skal overholde. Bilagshåndtering og udarbejdelse af disse Dette hovedtema beskriver, hvordan de enkelte standardkontrakter er opbygget i forhold til bilagsdelen. Det beskrives, i hvilket omfang den enkelte kontrakt indeholder færdige bilagsskabeloner, som projektet kan tage udgangspunkt i, eller om projektet selv skal forestå udfærdigelsen af bilaget på baggrund af en vejledning. Det sidstnævnte kræver betydeligt flere ressourcer og kompetencer i projektet. Ved anvendelse af bilagsskabelonerne er det afgørende, at projektet nøje forstår reguleringen og risikobalancen i det enkelte bilag, således at evt. tilpasninger kan foretages for at håndtere opfyldelse af den konkrete leverance, den fremtidige vedligeholdelse eller andre forhold af afgørende karakter for kunden. Emne K01 K02 K03 Kontraktbilag Kontrakten indeholder 13 skabeloner til de væsentligste bilag. Der foreligger vejledninger til alle bilag. Kontrakten indeholder 15 bilag. Der foreligger skabeloner til udvalgte bilag, herunder vedligeholdelse. Der foreligger vejledning og tjeklister til alle bilag. Kontrakten indeholder 16 bilag. Der foreligger vejledning og tjeklister til alle bilag.

Side 25 af 30 Kontraktens generelle kompleksitets niveau Dette hovedtema beskriver en generel vurdering af standardkontraktens kompleksitet. I denne vurdering, er der lagt vægt på de krav, erfaringer og kompetencer, som den enkelte standardkontrakt forudsætter, er til stede hos projektlederen, samt i hvilket omfang kontrakten forudsætter løbende bistand fra juridiske kompetencer kombineret med contract management kompetencer. Emne K01 K02 K03 Kompleksitet for kunden/krav om erfaring Lav grad af kompleksitet Høj grad af kompleksitet - stiller krav til juridiske ressourcer hos kunden. Høj grad af kompleksitet. Både kunde og leverandør er forpligtet til at oprette og bemande en organisation, der er organisatorisk understøttet til, løbende og med kort varsel, at træffe beslutninger af betydning for projektets gennemførelse. Stiller store krav til de juridiske ressourcer hos kunden. Kompleksitet for leverandør i forbindelse med tilbudsafgivelse Lav grad af kompleksitet. Tilgængelig for alle typer af leverandører. Høj grad af kompleksitet. Stiller krav til juridiske ressourcer hos leverandøren. - Høj grad af kompleksitet. Forudsætter en moden leverandør med erfaring inden for det agile område. Stiller krav til juridiske ressourcer hos leverandøren.

Bilag 2: Oversigtsmodel Samspil mellem kontrakt og it-projektmodel [26]