Digitaliseringsstyrelsens høringsnotat for høring over K03 kontrakt og bilag

Transkript

1 Digitaliseringsstyrelsens høringsnotat for høring over K03 kontrakt og bilag 20. december standardkontrakt for længerevarende it-projekt baseret på en agil metode 1. Indledning K03 med tilhørende bilag er en offentlig standardkontrakt til brug for anskaffelse af it-systemer udviklet efter en agil metode. K03 kontrakten tager udgangspunkt i anerkendte og anvendte projektledelses- og udviklingsmodeller, som offentlige myndigheder arbejder med og har erfaring med at bruge. K03 tager også højde for den økonomiske ramme, der gør sig gældende i staten og er herudover egnet til at indgå i en udbudsproces. I forbindelse med offentliggørelsen af den endelige K03 kontrakt og bilag vil der blive udarbejdet en vejledning med supplerende informationer og gode råd om anvendelsen af kontrakten og dens enkelte bestemmelser. Endvidere vil der blive udarbejdet en vejledning, som særligt vejleder om K03 kontraktens sammenhæng med den fællesoffentlige it-projektmodel. Digitaliseringsstyrelsen har løbende involveret en lang række offentlige og private interessenter i arbejdet med kontrakten, og har herudover i perioden juli til oktober 2012 offentliggjort to betaversioner af kontrakten med henblik på at få bidrag og forslag til forbedringer af K03 kontrakten fra en bred kreds af interessenter. Digitaliseringsstyrelsen kvitterer for det store engagement og interesse samt for de mange konstruktive bidrag, herunder navnlig fra advokat Nicolai Dragsted, som således har bidraget til den foreliggende version af K03 kontrakt og bilag, som blev sendt i høring den 8. november Endelig version af K03 kontrakt og bilag bliver offentliggjort på Digitaliseringsstyrelsens hjemmeside ultimo december Digitaliseringsstyrelsen har den 8. november 2012 iværksat en offentlig høring over udkast til K03 kontrakt og bilag. Digitaliseringsstyrelsen har ved høringsfristens udløb den 22. november 2012 modtaget høringssvar fra: Anders Both Danske Advokater i samarbejde med Danske IT-advokater DI ITEK DIT IT-Branchen Mikkel Christensen Professor Søren Lauesen, IT-Universitetet Rigsrevisionen

2 Side 2 af 13 I det følgende refereres og kommenteres de væsentligste substansbemærkninger, som Digitaliseringsstyrelsen har modtaget i forbindelse med høringen. 2. Generelle bemærkninger til kontrakten Rigsrevisionen anfører, at der er behov for, at K03 kontrakten bliver suppleret med initiativer, der klæder den offentlige part på til at have modet og viljen til at bruge og håndhæve kontrakten som forudsat. IT-Branchen og DI-ITEK ser det som en positiv udvikling, at der i høringsversionen af K03 er tale om en bevægelse i den offentlige sektors kontraktstyring af it-projekter, hen imod en styring og et samarbejde mellem kunde og leverandør, hvor der i højere grad opereres med en skelnen mellem absolutte og øvrige krav, i stedet for en ensidig satsning på ufravigelige krav. IT-Branchen og DI-ITEK bemærker, at den definition af agilitet, som anvendes i K03 afviger fra standardopfattelsen blandt leverandører og blandt de kunder, der har erfaringer med agile samarbejder. IT-Branchen og DI-ITEK finder det misvisende og uhensigtsmæssigt at lade ordet agil indgå i kontraktens formelle navn og foreslår, at kontrakten i stedet benævnes Kontrakt for et længerevarende fleksibelt projektforløb. IT-Branchen og DI-ITEK påpeger endvidere vigtigheden af, at der i forbindelse med lanceringen af K03 i vejledning og anden kommunikation skabes opmærksomhed om, hvilke krav kontrakten stiller. Søren Lauesen bemærker, at det er godt, at forretningsmæssige mål, risiko og agil udvikling indgår i kontrakten. Søren Lauesen bemærker også, at kontraktens bestemmelser om den agile udvikling er dokumentationsmæssigt omfattende og næppe egnet til agil udvikling med ugentlige iterationer, men derimod snarere månedlige eller sjældnere iterationer. Danske Advokater og Danske IT-advokater (DITA) bemærker, at høringsversionen af K03 fremstår som et velgennemarbejdet kontraktgrundlag, som kan danne grundlag for agile udviklingsprojekter. DITA anbefaler, at K03 i videst mulig omfang gøres egnet til anvendelse på det private område, herunder oversættes til engelsk. DITA bemærker, at behovet for en standardkontrakt for agile projekter på det danske marked er stort, og at K03 er et bedre egnet grundlag for agile projekter end de kontrakter der hidtil har været anvendt på det danske marked i form af tilretninger af PS2000, K02, K02i eller leverandørsidens kontrakter. DITA bemærker, at det vil udgøre et tilbageslag, hvis K03 ikke bliver et agreed document, og foreslår en forlængelse af processen, hvis dette kan medføre et

3 Side 3 af 13 aftale dokument, som vil have den større accept i markedet som et agreed document giver. DITA beklager, at K03 ikke som oprindeligt forudset er blevet en kontrakt med en modulær opbygning, der gør det muligt at bruge standardkontraktens bestemmelser ad hoc og alternativt i relevant omfang alt afhængig af itprojektets størrelse, økonomiske og tidsmæssige rammer samt kontraktens genstand. DITA vurderer, at den manglende modularitet medfører et forholdsvis stort behov for tilretning af K03 og dertil hørende rådgivning. DITA bemærker, at der vil være behov for, at vejledningen til K03 i udbudsretlig sammenhæng sikrer ligebehandling, når det på tildelingstidspunktet er uvist, hvor stor en del af kundens behov, der vil blive opfyldt. DITA anbefaler, at K03 indeholder en mere præcis beskrivelse under de vilkår, hvor der henvises til dansk rets almindelige regler således, at K03 også er egnet til brug på det private marked i en også international kontekst. DITA finder det positivt, at forretningsmæssige mål og behov indgår i K03 kontrakten og finder vilkårene vedrørende businesscasens placering i ydelsesbeskrivelsens struktur som hensigtsmæssig. DITA anser sondringen mellem absolutte krav og øvrige krav som nødvendig og bemærker, at vejledningen til K03 bør give præcise anvisninger vedrørende udmøntningen af sondringen og i øvrigt vedrørende modenhedskrav i den forbindelse. DITA henstiller til, at vejledningen til K03 indeholder anvisninger vedrørende brugen af afhængigheder i kontrakten, herunder anvisninger vedrørende kriterierne for den rimelige risikoallokering på dette punkt. DITA er enig i afvejningen mellem systemansvar og indsats- og kvalitetsforpligtelser som K03 indeholder, herunder i at systemansvaret er begrænset og kun knyttet til absolutte krav. DITA anbefaler, at K03 indeholder modeller, der giver bedre indsigt i kvalitet, output og værditilvækst fra de enkelte udviklingsteams, hvor for eksempel en sådan evaluering er koblet til timeforbrug mm. DITA anbefaler, at man ændrer punkt 10.2 sidste afsnit således, at kundens deltagelse specificeres detaljeret enten på opgave eller ressourceindsatsniveau og ikke blot med hvad man med føje kan forvente i et projekt af denne karakter og omfang. DITA anfører, at kontraktens sondring mellem egentlige ændringer og agile tilpasninger er udbudsretligt betinget, men for praktikere kunstig og unødigt ressourcekrævende.

4 Side 4 af 13 DITA støtter indførelsen af vilkåret om kundens opsigelsesmulighed og fremhæver et behov for, at vejledningen omtaler det forhold, at store initialomkostninger ikke må medføre, at opsigelsesmuligheden bliver illusorisk. DITA anser det som en generel mangel i K-kontrakterne, at der ikke i mere udpræget grad er indarbejdet egentlige garantikataloger for anskaffelsen. Mikkel Christensen finder det opløftende at se et initiativ, som har sigte på at sikre, at det offentlige Danmark kan komme til at drage fordel af de agile modeller for sofware-leverancer. Mikkel Christensen konstaterer dog, at den ramme som K03 lægger som grundlag for at bedrive agil udvikling fundamentalt modarbejder de præmisser, som giver agile modeller deres produktivitet. Mikkel Christensen anfører i den forbindelse, at K03 overordnet betragtet indeholder en del af de mekaniske processer, som man for eksempel bruger i SCRUM, men mener, at resten af det nødvendige rammeværk ikke er inkluderet. Mikkel Christensen påpeger, at kombinationen af en låst kravspecifikation, et fast budget og en fast tidsramme samt begrebet absolutte krav og den mulige store andel af dem, er i direkte modstrid med kernen i agile modeller, hvor man hele tiden har adgang til at blive klogere, omprioritere og ombestemme sig efter forholdene. Ad vejledning til kontrakten I forbindelse med offentliggørelsen af den endelige K03 kontrakt og bilag vil der blive udarbejdet en vejledning med supplerende informationer og gode råd om anvendelsen af kontrakten og dens enkelte bestemmelser Herudover vil der blive udarbejdet en vejledning, som særligt vejleder om K- kontrakterne, herunder særligt K03 kontraktens sammenhæng med den fællesoffentlige it-projektmodel, hvor K03 kontrakten og bilag vil være et væsentligt dokument i anskaffelses- og gennemførelsesfasen for de itprojekter, som ønskes afviklet agilt. Ad oversættelse til engelsk På nuværende tidspunkt er der ikke truffet beslutning om at oversætte kontrakten til engelsk. Ad graden af agilitet i kontrakten Ved projekter i staten vil der ofte være bevillingsmæssige forhold, der sætter grænser for, hvor agil man kan være på pris. Ved projekter i staten vil der herudover ofte for eksempel som følge af hensyn og krav i en bestemt lovgivning være behov for, at projektet gennemføres til et bestemt tidspunkt, hvilket også sætter grænser for agiliteten i forhold til tid. Agiliteten i K03 ligger således i selve leverancen, hvor det - for at sikre den fornødne agilitet i projektet - anbefales, at de absolutte krav maksimalt bør udgøre 60 % således, at agiliteten ligger på de sidste 40 %.

5 Side 5 af 13 Der er bred enighed om, at man med K03 kontrakten opnår en række af de gevinster, som en agil tilgang til projektudvikling fører med, herunder særligt den opsamling af viden der løbende forudsætte at ske i projektet, og som kan føre til yderligere optimerede løsninger i forhold til det oprindeligt forudsatte. Kontrakten angiver således ikke at være en agil standardkontrakt, men er i henhold til titlen en Standardkontrakt for længerevarende it-projekt baseret på en agil metode. Endvidere fremgår det af kontraktens definition af den Agile metode, at denne udgør Den i bilag 7 valgte og beskrevne metode for udvikling af leverancen. Forslaget om at ændre navn på kontrakten vil blandt andet med baggrund i ovenstående ikke blive imødekommet. Ad agreed document Idet IT-Branchen og DI-ITEK på tidspunktet for offentliggørelsen af K03 kontrakten ikke har ønsket at stå bag K03 kontrakten i sin helhed, så er K03 på nuværende tidspunkt ikke at betragte som et agreed document. Ad moduler I forhold til det oprindelige ønske om at opbygge kontrakten modulær, så har det undervejs i arbejdet med kontrakten måttet konkluderes, at det bagvedliggende ønske som kunne begrunde et behov for modulering af kontrakten kunne opfyldes på anden vis. Med henblik på at opnå en kontrakt, der kan favne udviklingsprojekter af stor varians i størrelse og kompleksitet, er kontraktens regulering gjort rummelig. Kontrakten skal således (og i øvrigt helt i tråd med de agile principper) ses som en ramme for samarbejdet, der konkret skal udfyldes og tilpasses. Tilpasningen vil primært ske i forhold til den valgte agile metode men også i forhold til reguleringen i bilagene.. Ad garantikatalog I arbejdet med K03 kontrakten har udgangspunktet været, at K03 skulle tage sit afsæt i K02 og kun i meget begrænset omfang og primært for så vidt angår de bestemmelser, der har en betydning i en agil kontekst, skulle afvige fra afsættet i K02. I forhold til udarbejdelsen af et garantikatalog har dette ikke været en del af arbejdet med den foreliggende version af K03. Digitaliseringsstyrelsen har noteret sig bemærkningen og vil lade denne indgå i styrelsens videre arbejde med offentlige standardkontrakter. Ad kontraktens anvendelse på det private marked I arbejdet med K03 kontrakten har udgangspunktet været, at K03 skulle finde anvendelse i en offentlig kontekst og de særlige hensyn, der gør sig gældende i forhold til brug af kontrakten i en privat kontekst har således ikke været en direkte del af arbejdet med K03 kontrakten, jf. dog ovenfor vedrørende bemærkningen ad moduler, og det her anførte om kontraktens rummelighed.

6 Side 6 af 13 Digitaliseringsstyrelsen har noteret sig bemærkningen og vil lade denne indgå i styrelsens videre arbejde med offentlige standardkontrakter. Ad forklaring af danske regler i en international kontekst I arbejdet med K03 kontrakten har udgangspunktet været, at K03 skulle tage sit afsæt i K02 og kun i meget begrænset omfang og primært for så vidt angår de bestemmelser, der har en betydning i en agil kontekst, skulle afvige fra afsættet i K02. I forhold til ønsket om, at kontraktens henvisninger til dansk lovgivning suppleres med forklaringer, der tydeligt og præcist redegør for disse reglers omfang og indhold, har dette ikke været en del af arbejdet med den foreliggende version af K03. Digitaliseringsstyrelsen har noteret sig bemærkningen og vil lade denne indgå i styrelsens videre arbejde med offentlige standardkontrakter. 3. Specifikke bemærkninger til kontrakten IT-Branchen og DI-ITEK finder det problematisk med de risici og det ansvar som K03 kontrakten pålægger leverandøren blandt andet ved at leverandøren holdes ansvarlig for, om kundens forretningsbehov indfries, og om rådgivningen heri var god nok. IT-Branchen og DI-ITEK finder det herudover problematisk, at K03 kontrakten giver kunden for let adgang til at bruge afhængigheder mellem krav som anledning til at udskyde en godkendelse, ophæve kontrakten og afvise betaling for udført arbejde. IT-Branchen og DI-ITEK har herudover henvist til en række ikke nærmere specificerede kommentarer, som er afgivet i forbindelse med Digitaliseringsstyrelsens involvering af interessenter, der har ligget forud for offentliggørelsen af den version af kontrakten, som blev sendt i høring den 8. november 2012 i det omfang disse ikke er blevet imødekommet. IT-Branchen og DI-ITEK har efterfølgende præciseret, at der i den forbindelse henvises til de bemærkninger, der blev afgivet i forbindelse med afholdelsen af en workshop om K03 den 29. oktober 2012 i det omfang Digitaliseringsstyrelsen ikke har imødekommet disse. Forretningsmæssige mål og behov I forhold til bemærkningen om de risici og det ansvar, som K03 kontrakten pålægger leverandøren holdes ansvarlig for, om kundens forretningsbehov indfries, og om rådgivningen heri var god nok, har Digitaliseringsstyrelsen suppleret med følgende i vejledningen til kontrakten: Leverandørens ydelser skal være egnet til at understøtte kundens forretningsmæssige mål og behov. Har kunden således som et forretningsmæssigt mål med projektet angivet, at kunden ved en reduktion af manuelle arbejdsgange ønsker at reducere antallet af sagsbehandlere, er

7 Side 7 af 13 leverandøren således forpligtet til at levere en ydelse, der er egnet til at erstatte og dermed reducere de manuelle arbejdsgange, som sagsbehandlere foretager. Hvorvidt dette fører til en reduktion af antallet af sagsbehandlere, er kundens eget ansvar, da dette afhænger af kundens gevinstrealisering. Leverandøren eller leverancen skal altså ikke isoleret set opfylde kundens forretningsmæssige mål og behov, men leverancen skal udarbejdes med henblik på, at kunden ved brug heraf og ved egen indsats kan opnå sine forretningsmæssige mål og behov. Herudover skal kundens krav "fortolkes" i lyset af den specifikke brug af leverancen, kunden påtænker. Det udgør således en del af formålet med overtagelsesprøven at konstatere, om det leverede er egnet til at understøtte de forretningsmæssige mål og behov, jf. bilag 6, punkt 3.2. Leverandøren er imidlertid ikke ansvarlig for, hvorvidt kundens forretningsmæssige mål og behov rent faktisk opfyldes, jf. nærmere om sondringen mellem egnethed og opfyldelse i bemærkningerne til kontraktens punkt Angivelsen af kundens forretningsmæssige mål og behov og koblingen heraf til de enkelte krav har i den sammenhæng til formål at gøre kundens særlige formål med leverancen kendelige for leverandøren. Derved sikres det, at kunden kan støtte ret på, at leverancen - i overensstemmelse med almindelige obligationsretlige principper - skal være egnet til kundens særlige formål. Afhængigheder I forhold til bemærkningen om afhængigheder, som disse er reguleret i K03, har Digitaliseringsstyrelsen suppleret med følgende i vejledningen til kontrakten. Kunden bør dog ved ophævelse af allerede overtagne delleverancer nøje overveje, hvorvidt der er dele af de allerede overtagne delleverancer, der uanset den manglende opfyldelse af den angivne afhængighed er værdiskabende for kunden. Navnlig som følge af tilbageleveringspligten i Kontraktens punkt vil det således ofte være relevant for kunden at begrænse ophævelsen til alene at omfatte de dele af en allerede overtagen delleverance, der konkret og af betydning i forhold til væsentligheden af afhængige krav er væsentligt berørt af leverandørens misligholdelse. Uenighed om en ændring er agil eller egentlig IT-Branchen og DI-ITEK efterlyser en mulighed for, at parterne kan involvere en tredjepart, som kan afgøre en uenighed mellem parterne om klassificeringen af en konkret ændring. Digitaliseringsstyrelsen kan oplyse, at kontrakten bygger på en forudsætning om, at parterne så vidt muligt skal søge tvisten løst i samarbejdet. Det følger allerede af Kontraktens punkt , at hver part kan anmode en uafhængig tredjepart om at afgive en vejledende udtalelse om tvistspørgsmålet. Leverandørens ansvar for kendte fejl i standardudstyr IT-Branchen og DI-ITEK ønsker det klarlagt, at kendte og registrerede fejl i standardprogrammel ikke bliver fejl, som leverandøren hæfter for.

8 Side 8 af 13 Digitaliseringsstyrelsen har ikke imødekommet bemærkningen, idet det synes vanskeligt og uhensigtsmæssigt kontraktuelt at håndtere en sondring mellem sådanne fejl, som var kendte af leverandøren og sådanne fejl, som var alment kendte generelt. Licenser IT-Branchen og DI-ITEK ønsker, at reguleringen om licenser indrettes i overensstemmelse med reguleringen af K02, idet det er vurderingen, at leverandørerne i forhold til standardprogrammel ikke har nogen mulighed for at ændre i de licensbetingelser, der gælder for sådant programmel. Digitaliseringsstyrelsen anerkender, at leverandørerne ofte ikke har indflydelse på licenserne til standardprogrammel. Leverandørerne har imidlertid indflydelse på hvilket standardprogrammel der inddrages i leverancen og kan således vælge standardprogrammel, der matcher K03 regulering. Ond tro hos leverandøren IT-Branchen og DI-ITEK ønsker, at kontraktens afsnit om leverandørens onde tro for så vidt angår de omstændigheder, der bevirker, at en beslutning om tildeling annulleres eller kontrakten erklæres uden virkning. I forhold til denne bemærkning har Digitaliseringsstyrelsen alene ønsket at tydeliggøre, hvad der gælder i henhold til dansk rets almindelige regler. 4. Generelle bemærkninger til bilagene DITA anbefaler, at der generelt udarbejdes kommenterede modelbilag til kontrakten. DITA bemærker, at de grundet den korte høringsfrist ikke har kommenteret på alle bilag. Søren Lauesen bemærker, at K03 generelt mangler konkrete eksempler på udfyldning af skabelonerne idet det vil gøre det nemmere for parterne at udfylde bilagene. I forhold til bemærkningen om, at bilagene udarbejdes som kommenterede modelbilag kan det oplyses, at alle bilag - i tråd med modellen for bilagene i K02 - foreligger med kommentarer og vejledende tekst, som er angivet med kursiv. Digitaliseringsstyrelsen anerkender behovet for og hensigtsmæssigheden i, at bilagene bliver suppleret med eksempler på udfyldning af skabelonerne. Henset til den indtil videre begrænsede udbredelse af brugen af K03 kontrakten og dermed et begrænset kendskab til konkrete eksempler, har Digitaliseringsstyrelsen besluttet, at en sådan supplering med konkrete eksempler mest hensigtsmæssigt vil finde sted når der foreligger flere eksempler og dermed erfaringer fra såvel kunde- som leverandørside med brugen af K03.

9 Side 9 af Specifikke bemærkninger til bilagene Bilag 3 Søren Lauesen foreslår, at begrebet forretningsmæssige behov erstattes af overordnede løsninger eller løsningsvision idet begrebet forretningsmæssige behov ikke nemt og meningsfuldt kan adskilles fra begrebet forretningsmæssige mål idet behovet er at nå målet. Søren Lauesen foreslår, at vejledningen til bilaget fremhæver SL-07 i stedet for den nuværende vejledning om at anvende user stories eller use-cases idet SL-07 ifølge Søren Lauesen dækker alle områder på en måde, der er egnet til agil udvikling. Søren Lauesen finder det problematisk, at K03 kontrakten skelner mellem absolutte og øvrige krav, idet det er vurderingen, at det i praksis giver uheldige resultater. Det er i den forbindelse Søren Lauesens vurdering, at der er risiko for, at alle krav bliver absolutte og, at der skal bruges mange ressourcer på efterfølgende at få nogle af disse krav omprioriteret. Søren Lauesen foreslår, at opdelingen i absolutte og øvrige krav erstattes af en vurdering af løsningens godhed for eksempel målt som dens økonomiske værdi, idet denne værdi også er god at styre efter under den agile udvikling. Søren Lauesen bemærker, at kontrakten bør ses i sammenhæng med udbudsreglernes minimumskrav og tildelingskriterier og foreslår, at man i forbindelse med vurderingen af leverandørernes tilbud vurderer løsningernes samlede forretningsmæssige værdi og vælger den leverandør, der bidrager med størst værdi. Søren Lauesen bemærker, at SL-07 viser, hvordan man kan bruge forretningsmæssige minimumskrav og tildelingskriterier. I forhold til et forslag om at erstatte begrebet forretningsmæssige behov med begrebet overordnede behov er der i vejledningen redegjort nærmere for baggrunden for og formålet med anvendelsen af forretningsmæssige behov : Leverandørens ydelser skal være egnet til at understøtte kundens forretningsmæssige mål og behov. Har kunden således som et forretningsmæssigt mål med projektet angivet, at kunden ved en reduktion af manuelle arbejdsgange ønsker at reducere antallet af sagsbehandlere, er leverandøren således forpligtet til at levere en ydelse, der er egnet til at erstatte og dermed reducere de manuelle arbejdsgange, som sagsbehandlere foretager. Hvorvidt dette fører til en reduktion af antallet af sagsbehandlere, er kundens eget ansvar, da dette afhænger af kundens gevinstrealisering. Leverandøren eller leverancen skal altså ikke isoleret set opfylde kundens forretningsmæssige mål og behov, men leverancen skal udarbejdes med henblik på, at kunden ved brug heraf og ved egen indsats kan opnå sine forretningsmæssige mål og behov. Herudover skal kundens krav "fortolkes" i

10 Side 10 af 13 lyset af den specifikke brug af leverancen, kunden påtænker. Det udgør således en del af formålet med overtagelsesprøven at konstatere, om det leverede er egnet til at understøtte de forretningsmæssige mål og behov, jf. bilag 6, punkt 3.2. Leverandøren er imidlertid ikke ansvarlig for, hvorvidt kundens forretningsmæssige mål og behov rent faktisk opfyldes, jf. nærmere om sondringen mellem egnethed og opfyldelse i bemærkningerne til kontraktens punkt Angivelsen af kundens forretningsmæssige mål og behov og koblingen heraf til de enkelte krav har i den sammenhæng til formål at gøre kundens særlige formål med leverancen kendelige for leverandøren. Derved sikres det, at kunden kan støtte ret på, at leverancen - i overensstemmelse med almindelige obligationsretlige principper - skal være egnet til kundens særlige formål. I forhold til brugen af SL-07 i stedet for user-stories er følgende passus blevet tilføjet i vejledningen til bilag 3a.ii: Kunden skal dog være opmærksom på, om Kunden ved formuleringen af brugerhistorier eller brugsscenarier utilsigtet låser sig fast på en sekventiel løsning. En brugerhistorie eller et brugsscenarie kan således være formuleret som en dialog mellem bruger og system, der beskriver hvem af de to aktører, der gør hvad og hvornår. Det kan imidlertid være, at Leverandøren kan levere en løsning, hvor nogle af trinene i brugerhistorien eller brugsscenariet med fordel kan udgå, eller hvor rækkefølgen sammensættes mere hensigtsmæssigt. Det kan derfor være vigtigt, at Kunden ved brug af brugerhistorier eller brugsscenarier i kravspecificeringen ikke låser sig fast på en sekventiel løsning. Kunden kan således i relation til en brugshistorie eller brugsscenarie anføre, at det ikke har betydning for kravets opfyldelse, hvorvidt rækkefølgen i dialogen følger det af Kunden angivne. Følgende fremgår nu af bilag 3a.ii: Der vil dog i alle Projekter være nogle på forhånd fastlagte krav, f.eks. krav til sikkerhed, kvalitet, leveringslokaliteter, grænseflader, integrationer, deklaratoriske regler (eksempelvis Persondataloven, Arkivloven og Regnskabsbekendtgørelsen), konvertering af data, anvendelse af obligatoriske åbne standarder mv., herunder bl.a. handicaptilgængelighed, og sådanne krav bør beskrives detaljeret, uanset der er tale om et agilt projekt. Kunden bør i den sammenhæng overveje, om det er muligt - trods detaljeringsniveauet - alligevel at beskrive kravet behovsorienteret. I forhold til sondring mellem absolutte og øvrige krav, er Digitaliseringsstyrelsen er opmærksom på, at der består en udfordring for kunderne i at foretage prioriteringen i absolutte og øvrige krav. Det er derfor også forudsat at den løbende nedbrydning af kravene vil kunne hjælpe kunden til at identificere øvrige krav blandt de detaljerede krav, jf. vejledningen til bilag 3a.ii, herunder navnlig fordi kunden på dette tidspunkt er i tæt dialog med leverandøren.

11 Side 11 af 13 Uanset kontraktens sondring mellem absolutte og øvrige krav er der intet til hinder for, at kunderne evaluerer de forskellige tilbud i forhold til "løsningens" godhed, altså i hvilket omfang og hvordan kundens krav er opfyldt. Dertil kommer, at kravene jo netop er forudsat at være overordnede på udbudstidspunktet, således at også leverandørens løsning på dette tidspunkt forudsættes at være overordnet. I forhold til de udbudsretlige bemærkninger med forslag om at vurdere løsningernes forretningsmæssige værdi, vil Digitaliseringsstyrelsen blandt andet supplere med yderligere information herom i vejledningen til kontrakten: Ved udarbejdelsen af tildelingskriterier må enhver ordregivende myndighed spørge sig selv, hvilke kriterier der sikrer, at den ordregivende myndighed får den økonomisk mest fordelagtige løsning. Dette spørgsmål er vanskeligt at besvare i alle udbud af komplekse it-projekter. I et agilt udviklingsprojekt kompliceres spørgsmålet imidlertid yderligere, da man ikke ved tildelingen vil kunne basere valget på en vurdering af de tilbudte løsninger, jf. dog nedenfor punkt [..] for så vidt angår standardprogrammel. Dette skyldes, at kunden ikke på tidspunktet for udbuddet har udarbejdet en detaljeret kravspecifikation, og leverandøren er derfor heller ikke i sit tilbud fremkommet med en detaljeret beskrivelse af den løsning, som vil blive leveret. Eftersom den ordregivende myndighed ved udbud af et it-projekt baseret på K03 ikke vil kunne begrunde valget på en detaljeret løsning, må der lægges vægt på andre forhold, der kan få betydning for projektets succesfulde gennemførelse. Sådanne forhold vil typisk være: tilbudsgiverens erfaring og tidligere resultater, tilbudsgiverens forståelse af Kundens behov, den projektledelses- og udviklingsmetode, hvorunder tilbudsgiveren vil gennemføre projektet, og funktionaliteten og tilrettelæggelsen af leveringen af et muligt standardprogrammel, hvorpå leverandøren vil basere udviklingen af systemet. Bilag 4 Rigsrevisionen har foreslået en præcisering af punkt 4.3 sidste sætning, hvor der skal indsættes et ikke i følgende sætning: Kunden kan endvidere have behov for dokumentation for, at Leverandøren har fjernet alle [ikke] synlige adgange (bagdøre) til systemet inden idriftsættelse. Digitaliseringsstyrelsen præciserer bestemmelsen.

12 Side 12 af 13 Bilag 12 DIT har anført behov for præcisering af bilagets grænseflader i forhold til vedligeholdelse og support i kontraktens punkt 15 samt præcisering af kundens beskrivelse af kapacitetsparametre og forudsætninger. DIT har herudover anført, at der er et behov for, at det tydeliggøres i bilaget, hvornår der er tale om en ydelse, beskrivelse med mere, som leverandøren henholdsvis kunden har ansvaret for. Digitaliseringsstyrelsen præciserer og tydeliggør de nævnte forhold i bilaget. Bilag 14 DITA anbefaler, at prismodellen ændres således, at K03 ikke baserer sig på fast pris. DITA anfører, at prismodellen har sammenhæng med krav til og niveau for kravlisten, og hvis den valgte prismodel i henhold til vejledningen og i praksis bliver udmøntet således, at der skal foreligge detaljerede krav, som er egnet til fastprisprojekter, går gevinsterne ved agil model muligvis helt tabt. DITA foreslår, at prismodellen ændres ideelt set, så den bliver modulær. DITA anfører, at bilag 14 vilkår om måling og rapportering vedrørende tids- og ressourceforbrug er utilstrækkelige på dette punkt. I forhold til bemærkningen om uhensigtsmæssigheden i, at K03 baserer sig på fast pris, skal Digitaliseringsstyrelsen henvise til Kommissoriet for arbejdet med K03, hvor udgangspunktet er, at prisen ligger fast, i den forstand, at budgettet for Projektet ligger fast. Indenfor det faste budget kan der imidlertid opereres med forskellige vederlagsmodeller i form af target price, max pris mv. ligesom en vederlagsmodel kan differentieres for de enkelte typer af vederlag under kontrakten, og i øvrigt kan suppleres af diverse incitamentsordninger. Endelig kan Kunden beslutte at tilføre projektet mere tid og penge ved en Egentlig Ændring - dog indenfor rammerne af udbudsretten. Bilag 16 DITA anfører generelt om bilag 16, at modellen i dette bilag ikke anses som værende hensigtsmæssig dels fordi spørgsmål/svar ikke vil dække de relevante tvivlstilfælde og dels ikke bør erstatte kundens gennemgang af og stillingtagen til, om licensaftalens indhold er acceptabelt. Digitaliseringsstyrelsen fastholder indholdet af bilag 16, og har i vejledningen præciseret formålet og omfanget af bestemmelsen med følgende tekst: Mange større it-projekter er baseret på standardprogrammel, hvorpå udviklingen foretages. Dette vil også ofte være tilfældet for et agilt it-projekt.

13 Side 13 af 13 Standardprogrammellet vil stille rammer for udviklingsmulighederne af systemet og dermed også de muligheder, ordregiver har for at få opfyldt sine forretningsmæssige mål og behov, jf. endvidere nærmere om muligheden for at inddrage de af standardprogrammellet fastsatte rammer i en tilbudsvurdering nedenfor punkt [..]. Det er derfor særdeles væsentligt, at kunden har indsigt i udstrækningen af kundens rettigheder i henhold til de for standardprogrammellet gældende licensbetingelser. Med henblik på at sikre kunden denne indsigt, fastsætter bilag 16, at leverandøren som led i leverancen skal bistå kunden med licensstyring. Dette indebærer, at leverandøren i bilag 16 løbende skal indsætte licenserne til det programmel med tilhørende dokumentation, der indgår i leverancen, og at leverandøren for hver enkelt licens skal besvare en række spørgsmål/afgive en række oplysninger omkring udstrækningen af de af kunden tildelte brugsrettigheder. Bilag 16 og de oplysninger der skal afgives for hvert enkelt program sondrer mellem funktionaliteter, der falder indenfor leverancebeskrivelsen og yderligere funktionaliteter. Leverandøren er således alene forpligtet til at byde ind med funktionaliteter indenfor leverancebeskrivelsen. Kunden skal i den sammenhæng være opmærksom på, at standardprogrammellet kan sætte ret skarpe grænser for de ændringer - herunder også de konkrete udmøntninger af kundens krav - der kan foretages i projektet, jf. formuleringen "indenfor Leverancebeskrivelsen" og det i kontrakten punkt 30.1 angivne om, at det i bilag 16 anførte ikke kan medføre, at leverancebeskrivelsen ikke opfyldes. Et krav der kan opfyldes på flere forskellige måder kan således være begrænset af licenserne til standardprogrammellet, der kun omfatter én af løsningerne. En sådan licens er som udgangspunkt i overensstemmelse med kontrakten, idet den understøtter opfyldelsen af leverancebeskrivelsen - bare kun i én henseende. Det kan derfor være hensigtsmæssigt, at Kunden inddrager de yderligere funktionaliteter, der måtte være indeholdt i standardprogrammellet som en option i projektet, og derved sikrer sig mere fleksibilitet i forhold til de rammer standardprogrammellet sætter for udviklingen, jf. nærmere om optioner på yderligere funktionaliteter nedenfor i bemærkningerne til kontraktens punkt 14.