Fælles projektmodel i staten – skal skaleres i forhold til projektets ...

KONTRAKTUNDERSTØTTELSE AF 

ITERATIVE PROJEKTMODELLER 

Advokat, LL.M. Søren Wolder

AGENDA 

13:30 – 14:00 Registrering 

14:00 – 14:10 Velkomst og introduktion til emnet 

14:10 – 14:30 Generel introduktion til den juridiske vinkling af iterative 

projekter og agil programudvikling 

14:30 – 15:00 Kontraktretlige temaer i den iterative it-kontrakt med 

15:00 – 15:15 Pause 

særlig focus på emnerne leverancebeskrivelse, 

prismodeller, kontrakt/projektstyring 

15:15 – 16:00 Fortsat gennemgang af kontraktretlige emner 

16:00 – 16:15 Pause 

16:15 – 16:30 Iterative projekter og udbudsreglerne 

16:30 – 17:00 Tak for i dag / spørgsmål (buffer)

VELKOMST OG INTRODUKTION TIL EMNET

VELKOMST OG INTRODUKTION TIL EMNET 

Advokater og de interne juridiske afdelinger må 

nødvendigvis se på kontraktgrundlaget for iterative 

projekter med nye og innovative øje og holdninger.

VELKOMST OG INTRODUKTION TIL 

EMNET 

“Recently, I attended a talk by an excellent lawyer on software contracts. Her 

message was quite clear: write a sound and detailed specification and 

contract the vendor based on this document. Seems simple enough, but I 

raised my hand and asked her how to deal with the fact that projects are 

much more efficient and have fewer risks when done iteratively and in an 

agile way as compared to the waterfall style she had laid out. "Well, these 

are business problems, and I'm not a business expert" was her reply.” 

“She was right: the life of a lawyer would be much easier, if perfect 

specifications were written right from the beginning - and the life of a 

project manager would be easier, too. But project managers have tried this 

path for 20 years without any significant success. And some "experts" claim 

that the method we use is not right, and we only need to use/buy their great 

tool or process to solve any problems. But they have been telling us this for 

20 years, and their claims resemble Jerry Weinberg's first law of bad 

management: "If what you're doing isn't working, do more of it“. 

Kilde: Cutter Consortium

GENEREL INTRODUKTION TIL DEN 

JURIDISKE VINKLING AF ITERATIVE 

PROJEKTER OG AGIL PROGRAMUDVIKLING

DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL 

PROGRAMUDVIKLING 

Den traditionelle kontraktopfattelse 

Traditionelle vs. Iterative kontrakter 

• forventning om, at kontrakten kan placere og definerer parternes ansvar, 

medvirken og roller i projektet 

• Kontrakten bør fordele ansvar på en “fair” måde, så enhver kun er ansvarlig 

for det kontraktparten faktisk har indflydelse på. 

• disse antagelser hviler på en forudsætning om, at målet for projektet er 

kendt. 

Den agile kontrakts udfordring 

• Agile projekter kræver i højere grad, at projekterne er baseret på sharedprofit 

kontrakter. (mål-pris, fleksible tidsplaner fleksibelt scope) 

• Dvs. et ”skæbnefællesskab”, som ikke er særligt populært i de afdelinger 

der tager sig af indkøb, jura og styring.



Traditionelle vs. Iterative kontrakter




Vandfaldsmodellen er baseret på tillid til kundens forberedende arbejde inden 

kontraktens indgåelse og mistillid til leverandørens kontraktopfyldelse. 

Iterative kontrakter er baseret på tillid til parternes samarbejde ved 

kontraktens opfyldelse.




• Samarbejde er omdrejningspunkt i iterative kontrakter. Kernen i en iterativ 

proces er et tæt og dynamisk samarbejde mellem parterne – ofte via fælles 

projektteam. 

• Samarbejdet omfatter både ”projektet” og udviklere. Forretning og IT skal 

arbejde sammen om at skabe forretningsværdi under styret risiko. 

• Kontrakten skal derfor styre risiko og facilitere samarbejdet.




• Implementering af iterative projekter kræver i høj grad, at fokus flyttes fra 

kontraktstyring til projektstyring. 

… hvilket stiller krav til kontraktens fokus.



Den procesorienterede aftale 

• I stedet for alene at basere kontrakten på et resultat, baserer man den på en 

proces, der skaber dette resultat. 

• Og derfor bliver kontrakten som styringsredskab for processen helt 

afgørende. 

• Kontrakten skal have særlig fokus på reguleringen af processen og styringen 

af processen. 

• Den skal i (endnu) højere grad styre projekts gennemførelse end en 

traditionel vandfaldsbaseret kontrakt




• Kontrakten skal navnlig have fokus på 

• Samarbejdsrelation mellem parterne 

• Bemanding af projektet 

• Den iterative metode 

• Projektledelse og projektstyrelse 

• Prioritering af krav og ønsker 

• Fremdriftsrapportering og risklogs 

• Styring af økonomi og tid



• ITST 10 arkitekturprincipper 


• Nr. 1. ” Forretningsbehov bør drive og definere løsningerne” 

• Nr. 3. ”Processer bør optimeres i forbindelse med digitalisering” 

• Nr. 8. ” Udnyt mulighederne ved anskaffelser” 

• ITST ”15 skarpe” 

• Nr. 4. ”Brug agile udviklingsmetoder – og spis elefanten i små bidder” 

• Nr. 15. ”Del viden og samarbejde på tværs



IT udredning 2010 

• Indsatsområde 1: Kompetenceløft og fælles metoder: 

Fælles projektmodel i staten – skal skaleres i forhold til projektets størrelse 

og risikoprofil, og der udarbejdes en ”light-model” for mindre it-projekter 

• Indsatsområde 2: Fokus på de risikofyldte projekter: 

Etablering af fem principper for gennemførelse af it-projekter. 

• 4. Projekterne skal opdeles i mindre og selvstændige værdiskabende dele, 

som besluttes og gennemføres uafhængigt af hinanden. 

• Indsatsområde 3: Bedre samarbejde med leverandører og rådgivere 

Mindre omfattende kravspecifikationer



Grundlæggende vilkår for den iterative proces 

Kontrakten skal fortsat respektere, at iterative projekter er 

hverken rendyrket anarki eller et tag-selv bord for leverandøren



Grundlæggende vilkår for den iterative proces 

Agile kontrakter bør derfor hvile på følgende hovedregler: 

• Ændringer er gratis på ikke påbegyndt funktionalitet 

• Ændringer i prioritet er gratis, forudsat totalen ikke ændre sig 

• Nye funktioner/krav kan lægges ind undervejs – så længe funktionaliteter/ 

krav af tilsvarende størrelse tages ud 

• Kunden kan opsige/afbryde samarbejdet når som helst mod betaling af 

forud defineret udtrædelsesvederlag 

• Kunden skal være i stand til at prioritere alle sine krav indbyrdes 

• Kunden er ansvarlig for, at relevante og kompetente brugere følger og 

deltager i projektet og at disse er udstyret med tilstrækkeligt ansvar og 

beslutningskompetence for at kunne give leverandøren nyttigt feedback og 

i øvrigt bidrage uden at forsinke projektet



• Juli 2008: SKI 02:18 

På vej til den iterative kontrakt 

• April 2009: SKI vejledning til udformning af kontrakter under 02.18 med brug 

af iterative forløb 

• Efterår 2009: 01i, 02i, 03i (BvHD – DAHL) 

• Marts 2010: ITST redegørelse 

• Ultimo 2012:K03



• 01i, 02i og 03i 


• Mindre projekter kan anvende 01i eller 03i 

• Større projekter kan anvende 02i 

• 01i er baseret på K01, 02i er baseret på K02 

• 03i er formuleret mere frit i forhold til K-kontrakterne



Fællestræk ved 01i, 02i og 03i 

• Krav til modenhed 

• Business case 

• T&M/Maksimalpris 

• Metodeneutral 


• Fokus på samarbejde, ressourcestyring og prioritering 

• Fleksibel udtrædelsesadgang for kunden

KONTRAKTRETLIGE TEMAER I DEN 

ITERATIVE IT-KONTRAKT MED SÆRLIG 

FOCUS PÅ EMNERNE 

LEVERANCEBESKRIVELSE, PRISMODELLER, 

KONTRAKT/PROJEKTSTYRING

LEVERANCEBESKRIVELSE OG 

PROJEKTGENNEMFØRELSE

KONTRAKTRETLIGE TEMAER - 

LEVERANCEBESKRIVELSE 

Leverancebeskrivelsen er ikke slutproduktet 

• Ydelser - Leverandørens ydelser er andet end blot etablering af forud 

fastlagt funktionalitet 

• Metodeanvendelse 

• Projektledelse 

• Ressourcestyring 

• Rådgivning 

• (SKI vejledning pkt. 2.4 – s. 10) 

• Procedure og samarbejde - Større krav til forankring i kontrakten af 

projektledelse, beslutningskompetence og procedurer. 

• Krav - Kravspecifikationen får en anden rolle. Virker som ramme for 

samarbejdet og prioriteringsoversigt, mens de konkrete funktionalitetskrav 

fastlægges undervejs



Håndtering i K01 og K02 

• Kunden udarbejder kravspecifikation, og denne danner grundlag for 

leverandørens besvarelse. 

• HR: Kravspecifikation forventes at være udtømmende oplistning. 

• U. ”Hvad kunden med føje kan forvente” 

• Kunden er hovedansvarlig for, at kravene er formuleret entydigt. 

• Leverandøren er primært ansvarlig for opfyldelsen



Håndtering i iterative kontrakter 

• Kunden udarbejder en Behovsopgørelse, som skal indeholde: 

(i) beskrivelse af Kundens Business Case, 

(ii) de forretningsgange, Leverancen skal understøtte, samt 

(iii) overordnet beskrivelse af ønsket funktionalitet 

• Dette dokument danner grundlag for leverandørens tilbud




• Indhold af business case 

• Forretningsmæssige mål 

• Baggrund for valg af projekt model 

• Interessenter 

• Beskrivelse af løsning 

• Delprojekter 

• Specifikke ”constraints” 

• Kunderessourcer til rådighed 

• Afhængigheder 

• Risici 

• Opfølgning 

• Etc. 

• Den Digitale Taskforce, Videnskabsministeriet, KL og Danske Regioner: 

”Business case for digitaliseringsprojekter” 

http://modernisering.dk/da/projekter/business_case/ 

•



• Brug af business case 

• Planlægning 


• Dialogværktøj i forholdet kunde – leverandør 

• Grundlag for leverandørens udarbejdelse af tilbud 

• Leverandørens tilbud kan eventuelt kræves relateret direkte til 

kundens business case 

• Afklaringsfasens forløb kan styres af business case 

• enyttes af kunden til efterfølgende intern evaluering af projektets 

forløb



Løsningsbeskrivelse 

• På baggrund af kundens behovsopgørelse udarbejder leverandøren en 

Løsningsbeskrivelse forud for aftalens indgåelse. 

”Leverandørens overordnede besvarelse af Kundens Behovsopgørelse ved 

Kontraktens indgåelse. Løsningsbeskrivelsen udgør en del af 

Leverancebeskrivelsen og vil – som den øvrige del af Leverancebeskrivelsen – 

løbende undergå ændringer undervejs i Projektet.”



Løsningsbeskrivelse - detailspecifikation 

• Under de efterfølgende iterationer frembringes løbende en række 

detailspecifikationer. 

• Når detailspecifikationerne er godkendt af Kunden, udgør disse en del af 

Leverancebeskrivelsen sammen med Behovsopgørelsen og 

Løsningsbeskrivelsen.



Leverancebeskrivelse 

• Leverancebeskrivelsen = Behovsopgørelse+Løsningsbeskrivelse 

+detailspecifikationer 

• Leverandøren skal holde Leverancebeskrivelsen løbende ajour med 

godkendte detailspecifikationer samt foretage de fornødne 

konsekvensrettelser af Behovsopgørelsen og Løsningsbeskrivelsen, som den 

enkelte Iteration giver anledning til, og indhente Kundens godkendelse heraf 

ved Iterationens afslutning. 

• Den gældende udgave af Leverancebeskrivelsen skal til enhver tid være 

elektronisk tilgængelig for Kunden på et Projektsite eller lignende.



Leverancebeskrivelse – alternativ model uden behovsopgørelse 

Kunne baseres på ”sure step” metoden. I den forbindelse gennemføres en 

diagnose og analysefase. 

• Diagnosefasen 

• tilvejebringelse af overordnet løsningsbeskrivelse 

• Analysefasen 

• definere og fastlægge de aktiviteter, der er nødvendige med henblik på at 

få defineret og planlagt hele projektet 

Denne model er velegnet til mindre projekter, men kræver stor parathed hos 

Leverandøren og er baseret på en grundlæggende forudsætning om, at Kunden 

ønsker en standardløsning i så vid udstrækning som muligt.


LEVERANCEGENNEMFØRELSE 

Leverancemodel - iterativt



• De overordnede faser i i01 og i02 

• Afklaring 

• Design, udvikling og test 

• Godkendelse og overtagelse 

Leverancemodel – i01 og i02




• Afklaring 

Leverancemodel – i01 og i02 

• Fortsat behov for grundlæggende drøftelser af kundens 

behovsopgørelse og belysning af risikofaktorer i projektet




• Design, udvikling og test 


• Etablering af udviklingsmiljø og testmiljø 

• Design og udvikling baseres på den valgte iterative model 

• definition og beskrivelse af trin 

• Kontrolpunkter 

• Testprocesser 

• Delovertagelse og ibrugtagning




• Godkendelse og overtagelse 


• Projektet godkendes og overtages samlet 

…. men reduceret betydning




Aktiviteterne i en fase (vil afhænge af den 

valgte iterative model)



Leverancemodel – sure step 

Bruges sure step metoden gennemløbes følgende faser: 

• Diagnose 

• Analysefase 

• Designfasen 

• Udviklingsfasen 

• Udrulningsfasen 

• Drift 

I dette forløb arbejdes der iterativt. Men projekterne er baseret på en 

tidsplan og en projektøkonomi. Udfordringen består i håndteringen af dette.



Leverancemodel – sure step



• Projektledelse og projektstyring 

Centrale elementer 

• Metode, kvalitetssikring og risikostyring 

• Styring på tid frem for funktionalitet (”time boxing”) 

• Fokus på styring af parternes personale 

• Samarbejds- og beslutningsprocedurer 

• Styring af økonomi – v/ fast pris/maksimal pris og/eller stramme krav til 

rapportering af tidsforbrug 

• Krav til fremdriftsrapportering og risikolog

PAUSE

PRISMODELLER

PRISMODELLER 

Prisregulering 

• I den ideelle agile verden fraviges udgangspunktet om fast pris, identificeret 

leveringstidspunkt og klart definerede krav. 

• De tre parametre må behandles ”alternativt” i den agile kontrakt. 

• Graden af fleksibilitet på de tre områder er givetvis ikke identisk 

• Offentlige kunder operere med bevillinger og private kunder arbejder 

under budgetter, og det er derfor ofte ikke muligt at arbejde uden en fast 

defineret økonomisk ramme. 

• Risikoen for budgetoverskridelser er alt andet lige ofte mindre i et 

iterativt end i et vandfaldsprojekt(!)

PRISMODELLER 

Specifikationer 

Graden af fleksibilitet (udtrykt gennem cirklernes størrelse) 

Leveringstid 

Pris 

Systemet 

Billedet kan ikke vises. Computeren har muligvis ikke 

hukommelse nok til at åbne billedet, eller billedet er 

muligvis blevet beskadiget. Genstart computeren, og åbn 

derefter filen igen. Hvis det røde x stadig vises, skal du 

muligvis slette billedet og indsætte det igen. 

Leveringstid 

Prisen 

Specifikationer

PRISMODELLER 

• Prismodeller 

• Forbrugsafregning 

Principper 

• Forbrugsafregning med shared risk (målpris) 

• Forbrugsafregning med maksimal pris (maksimalpris) 

• Fast pris 

• Bemærk at omfanget af funktionalitet ikke er fast i et iterativt forløb. 

Det endelige omfang fastlægges undervejs i projektet, og er delvis 

bestemt af de ressourcer, der er til rådighed for projektet 

• Forbrugsafregning forudsætter fastlæggelse af krav til registrering af 

forbrug, rapportering samt bestemmelser om opfølgning i forhold til 

økonomi

PRISMODELLER 

Målpris 

Anvendelsen af målpris forudsætter at kunden er villig til at give afkald på den 

sikkerhed der ligger i det loft maksimalprisen er udtryk for. 

Fra IT- og Telestyrelsens vejledning

PRISMODELLER 

Målpris i norske kontrakter

PRISMODELLER 

Målpris i norske kontrakter

PRISMODELLER 

Maksimalpris 

• Leverandøren angiver en maksimalpris bestående af; 

a) En fast pris for de leverancer, hvor prissætningen af disse 

er uafhængig af omfanget af Leverandørens ydelser. 

b) En forventet pris på de dele af Leverancen, som skal 

udføres efter medgået tid. 

c) Et usikkerhedstillæg. 

• Maksimalprisen må ikke overskrides. 

• Maksimalprisen omfatter ikke vederlag for vedligeholdelse og 

support, og løbende betalinger for anvendelse af Programmel.

PRISMODELLER 

Maksimalpris

KONTRAKTSTYRING/PROJEKTSTYRING

KONTRAKTSTYRING/PROJEKTSTYRING 

Krav til kontraktstyring uanset prismodel 

• Jo større fleksibilitet i prismodellen – des større krav til styringen 

• Opgaverne i kontraktstyringen 

• Styringen af udviklingen i risiko-loggen og indflydelsen på prisrammen 

• Udvidelser af projekt-scope kontra påregnelig fleksibilitet og betydningen 

for prisrammen – en udvidelse eller indskrænkning af projektet skal 

således også håndteres i forhold til en eventuel ændring i prisrammerne 

• Oplysningspligten i forhold til timebaseret afregning


Styring af timebaserede vederlag 

• Specifikationskrav med hensyn til ydelser, der vederlægges på grundlag af 

medgået tidsforbrug. 

• Det er Leverandørens ansvar til stadighed at give Kunden et retvisende og 

fyldestgørende billede af projektets økonomi baseret på Projektets status. 

• Leverandøren skal senest hver den 5. i en måned sende Kunden en detaljeret 

opgørelse af tidsforbruget i den forgangne måned og om nødvendigt 

maksimalpris (i) Leverandørens eventuelle forslag til ændret prioritering, (ii) 

aftalte ændringer eller udvidelser af Projektet og (iii) en opdatering af 

Risikologgen. 

• Maksimalprisen må ikke overskrides uden Kundens forudgående godkendelse.



• Der skal være balance mellem sikkerhed og fleksibilitet 

Eksempel på uheldig kontraktformulering (kundevenlig): 

Leverandørens vederlagsestimat er baseret på en grundig gennemgang af 

kundens krav og forventninger til projektet og er således udtryk for et 

ansvarligt estimat. Det er i enhver henseende leverandørens ansvar, at 

prisestimatet er forsvarligt. Leverandøren kan ikke kræve større vederlag 

end estimeret, medmindre fravigelsen skyldes omstændigheder, som 

leverandøren ikke kunne have forudset ved meddelelsen af 

prisestimatet.”



• Der skal være balance mellem sikkerhed og fleksibilitet 

Eksempel på uheldig kontraktformulering (leverandørvenlig): 

”Såfremt en opgave ikke udføres på fast tid, kan der fastsættes et estimat. 

Et sådant estimat er baseret på Kundens ønsker og Leverandørens viden om 

projektet på aftaletidspunktet og er ikke bindende for Leverandøren. 

Såfremt et estimat overskrides væsentligt, skal Kunden informeres herom, 

således at Parterne i fællesskab kan aftale de nødvendige 

konsekvensrettelser. 

Medmindre overskridelserne kan tilregnes Leverandørens væsentlige 

misligholdelse, fritages Leverandøren for resultatansvaret, såfremt Kunden 

ved overskridelse af estimatet ikke ønsker arbejdet fortsat. Kunden betaler 

Leverandøren for de timer, der er erlagt, forinden Kundens anmodning om 

afslutning af arbejdet er modtaget.”


Hvor går projektstyringen typisk galt? 

Det kan også gå galt i iterative projekter. Årsagerne kan være: 

• Ofte ”glemmer” Leverandøren at gøre opmærksom på, hvad det vil sige at 

arbejde agilt. 

• Kunden er ikke klar til at arbejde agilt, og omkostninger/tid løber løbsk. 

• Manglende fokus på de omkringliggende behov (samspillet med andre dele af 

kundens IT-miljø) 

• Leverandøren får ikke dokumenteret ændringer og udviklinger i projekter og 

der opstår et ”gab” mellem det beskrevne og det realiserede projekt?


Projektorganisation 

• Kvalifikationer hos kundens projektdeltagere 

• Kundens deltagere! 

• Leverandøren skal være opmærksom på, at der ikke kan forventes 

bedre kvalifikationer end angivet af kunden, og leverandøren skal 

indrette sine ydelser efter disse oplysninger 

• Kundens beslutningstagere i projektet 

• Skal sikre at forretningsmæssig viden er tilrådighed 

• Skal træffe beslutninger 

• Formidle behov og forretningsmæssig viden 

• Hurtig og umiddelbar eskalationsvej

TIDSPLAN OG AFPRØVNING

TIDSPLAN OG AFPRØVNING 

Tidsplan 

• Ved Kontraktens indgåelse angives alene en overordnet hovedtidsplan, der 

• Fastlægger projektets overordnede rammer, 

• Fastlægger de enkelte trin (funktionelle testbare område og 

kontrolpunkter) 

• Fastlægger opdelingen i Delleverancer og tidspunktet for levering heraf. 

• Aktiviteterne i afklaringsfasen bør dog være detaljeret beskrevet 

• Udarbejdelse af detaljeret tidsplan 

• Løbende opdatering af hovedtidsplan

TIDSPLAN OG AFPRØVNING 

Afprøvning 

• Den iterative metode indebærer ofte løbende tests af de det leverede i hver 

enkelt iteration. 

• De tests, der er en del af den iterative metode, er beskrevet i bilaget, der 

indeholder den iterative metode. 

• De kontraktuelle tests er beskrevet i prøvebilaget. 

• Inden idriftsættelsen af den enkelte delleverance skal der være gennemført 

en delleveranceprøve. 

• Behov for ændringer i bilaget om afprøvning?

MISLIGHOLDELSESBEFØJELSER

MISLIGHOLDELSESBEFØJELSER 

Forsinkelse 

• Frister angives som ved vandfaldsmodel-kontrakter 

• Bod for forsinkelse 

• Reduktion af vederlag indtil milepæl er opfyldt 

• ”Klassisk” beregning


Mangler 

• Begrebet mangel vil afhænge af prismodel og kravspecifikationen 

• mangelsbegrebet er i højere grad relevant i forhold til ”processen og 

leverandørens evne til at skabe ”value for money” 

• En række mangelsvurderinger vil ikke være ”sort/hvide” men derimod 

afhænge af et fagligt skøn.


• Reducerede timesatser 

Mangler – forslag til sanktion 

• ”For arbejde med afhjælpning af Mangler i garantiperioden og andre 

garantiarbejder, som ikke er omfattet af en eventuel 

vedligeholdelsesaftale, hvor der er aftalt en fast pris, er 

Leverandøren berettiget til at fakturere Kunden dette arbejde i 

henhold til de aftalte timesatser med fradrag af 25%.”


Ophævelse 

• Fortsat nødvendigt med mulighed for hel eller delvis ophævelse. 

• Bør kun være en mulighed for ophævelse ”ex nunc” (fremadrettet). 

• Skal ses i lyset af den løbende opsigelsesadgang og ”working software”. 

• Opfyldelse af vedligeholdelses- og driftsaftaler ingen afsmittende virkning. 

• Erstatningskravet ved ophævelse.

UDTRÆDELSESADGANG

UDTRÆDELSESADGANG 

Kunden kan altid udtræde 

• Den iterative tankegang bygger på forudsætning om fuldstændig fleksibilitet 

• Derfor skal kunden også have mulighed for at stoppe undervejs; 

• Når som helst – men varsel skal indbygges 

• Forpligtelser bortfalder 

• Frembragt materiale – ret til efterfølgende brug 

• Betaling af vederlag 

• Allerede gennemførte leverancer 

• Allerede bestilte leverancer 

• Kompensation?


Særlige problemstillinger 

• Garantier for allerede foretagne leverancer 

• Support- og vedligeholdelse 

• Udlevering af oplysninger


• Vederlaget kan opgøres som: 

Udtrædelsesvederlag 

a. Det beløb som Leverandøren har til gode for den del af Projektet, som 

allerede er gennemført, 

b. Dokumenterede direkte udlæg og direkte omkostninger i tilknytning til 

Projektet, som Leverandøren har pådraget sig, inden Leverandørens 

modtagelse af Kundens Meddelelse om at ville udtræde, og som ikke er 

dækket af Leverandørens krav på vederlag i henhold til punkt a). 

Leverandøren er i forbindelse med opgørelsen af punkt (b) ovenfor 

forpligtet til at søge at begrænse udgifterne mest muligt.

PAUSE

ITERATIVE PROJEKTER OG 

UDBUDSREGLERNE


UDBUDSREGLERNE 

IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor



IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor



IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor 

• Udgangspunktet for udbud af kontrakten er den samme som ”almindelige 

projekter” 

• Den udbudte genstand er ikke et detaljeret beskrevet slutprodukt 

• Leverandørens ydelser er andet end etablering af forud fastsat funktionalitet 

• Metodeanvendelse / Projektledelse 

• Ressourcestyring 

• Rådgivning 

• Kontrakten er opbygget om andet end slutresultatet 

• Projektledelse, metoder og procedurer 

• Kravspecifikationen får en anden betydning end i vandfaldsprojekter 

• Konkret funktionalitet fastlægges undervejs i projektet



Gennemsigtighedsprincippet og ligebehandlingsprincippet 

Gennemsigtighedsprincippet 

• Kontrakten skal give en klar og præcis beskrivelse af den opgave 

leverandøren skal løse og ydelseskategorier beskrevet. Beskrivelsen af 

funktionelle krav eller funktionsdygtighed skal være så præcis, at 

tilbudsgiver kan identificere kontraktens genstand. 

Ligebehandlingsprincippet 

• Fortsat forbud mod at ”skræddersy” kravspecifikation og mod at anvende 

diskriminerende standarder eller krav.



Gennemsigtighed kan bl.a. opnås ved at 

• Kontrakten er med i udbudsmaterialet og den er udformet specifikt for et 

agilt projektforløb 

• Kravspecifikation og kontrakten giver et klart billede af den opgave, der skal 

løses (men ikke af slutproduktet) 

• Kundens business case indgår i kontrakten (kravspecifikationen) 

• Leverandørens ydelser omkring projektledelse, ressourcestyring og 

rådgivning beskrives i kontrakten (kravspecifikationen) 

• Udbudsmaterialet angiver tydeligt kundens fastlagte rammer for økonomi, 

tidsrammer, overholdelse af standarder, integrationer m.v.



Ligebehandling kan bl.a. opnås ved at 

• Undgå bilateral dialog med tilbudsgiver omkring udbudsmaterialet 

• Sikre gennemsigtighed og klarhed i forhold til evaluering



Evaluering



Evaluering



Evaluering



Ændring af projekt under udbudsreglerne

TAK FOR I DAG / SPØRGSMÅL (BUFFER)

KONTAKTOPLYSNINGER 

Søren Wolder 

E-mail: swk@dahhlaw.dk 

Telefon: 88 91 92 45

Fælles projektmodel i staten – skal skaleres i forhold til projektets ...

Create successful ePaper yourself

Delete template?

Save as template?