En god kontrakt er ikke kun et juridisk dokument. I projekter er den også et styringsværktøj, der gør det lettere at planlægge, prioritere, håndtere ændringer og undgå, at samarbejdet går i hårdknude, når virkeligheden rammer tidsplan og budget.
Mange tvister starter ikke med ond vilje, men med uklare formuleringer, manglende bilag eller antagelser om “det plejer vi”. Kontraktudarbejdelse handler derfor lige så meget om præcision og forventningsafstemning, som det handler om paragraffer.
Hvad kontraktudarbejdelse betyder i projekter
Som projektleder sidder du ofte mellem forretning, teknik og jura. Du skal kunne omsætte behov til noget, der kan leveres, måles og godkendes. Kontrakten er det fælles referencepunkt, når der opstår spørgsmål om omfang, ansvar, betalingsmodel eller ændringer.
— Du kan få dem tilsendt herunder! —
En “skudsikker” kontrakt er sjældent den længste. Den er den, hvor parterne kan finde svar på de svære spørgsmål, før de bliver til konflikter: Hvad er leveret, hvornår er det leveret, hvordan accepteres det, og hvad sker der, hvis planen ændrer sig?
De aftaleretlige grundregler du bør kende
I dansk ret står parterne generelt frit til at aftale vilkår (aftalefrihed), så længe aftalen ikke strider mod lovgivning eller grundlæggende principper. Aftaleloven er central, fordi den beskriver spillets regler for tilbud, accept og fortolkning.
To bestemmelser er praktiske at have i baghovedet, når du forhandler og versionerer kontrakter:
- Aftalelovens §6: Et “ja, men…” er typisk ikke en accept. Hvis modparten svarer med ændringer, kan det juridisk blive set som et afslag og et nyt tilbud. Det lyder teoretisk, men i praksis betyder det, at du skal have styr på, hvornår I faktisk er enige, og hvad “endelig version” er.
- Aftalelovens §36: Urimelige vilkår kan helt eller delvist tilsidesættes. En kontrakt, der er ekstremt ensidig, kan give falsk tryghed, fordi den ikke nødvendigvis kan håndhæves som skrevet.
Kontraktudarbejdelse skal også tage højde for konteksten: Købeloven ved varekøb, Forbrugeraftaleloven ved forbrugere, AB 18/ABT ved bygge og anlæg, og i internationale handler kan FN’s købskonvention (CISG) blive relevant. Det ændrer både “standardforventninger” og hvilke klausuler der bør være på plads.
Fra scope til signatur: en praktisk proces
En effektiv proces reducerer risikoen for, at kontrakten bliver en hastesag til sidst, hvor ingen reelt når at læse den. Brug kontraktarbejdet som en del af projektets planlægning, ikke som en afsluttende formalitet.
Nedenstående workflow kan bruges som en enkel ramme, uanset om du arbejder med en leverandøraftale, en konsulentaftale eller en projektaftale mellem afdelinger.
Hent vores bøger og skabeloner herunder
| Skridt | Hvad du gør i praksis | Output du kan styre efter |
|---|---|---|
| Initiér behov og rammer | Afdæk formål, succeskriterier, scope, parter, afhængigheder | Kort “kontraktbrief” til internt brug |
| Forbered udkast | Skriv et første udkast med kernevilkår og bilagsstruktur | Version 0.1 med tydelige åbne punkter |
| Intern revision | Få fagligt og juridisk review, tjek formkrav og standarder | Kommentarer, rettelser og risikonoter |
| Forhandling | Udveksl redline, afklar uenigheder, lås bilag og definitioner | “Agreed in principle” og ændringslog |
| Endelig gennemgang | Tjek konsistens, henvisninger, bilag, datoer og definitioner | Signeringsklar PDF/kontraktpakke |
| Godkendelse og underskrift | Sikr bemyndigelse, underskriv, arkivér korrekt | Gyldig aftale og styrbar version |
| Opbevaring og opfølgning | Opret kontraktmilepæle i projektplanen, følg op på frister | Kontrakt som aktivt styringsgrundlag |
Skriv så det kan styres: klarhed, definitioner og bilag
Hvis du vil forebygge diskussioner om “hvad mente vi”, så skriv som om en ny projektleder overtager projektet om tre måneder. Det tvinger dig til at være konkret: Hvem gør hvad, hvornår, med hvilke input, og hvad er kriteriet for godkendelse?
Mange kontrakter fejler på de små ord: “snarest”, “rimelig tid”, “løbende”, “efter behov”. De kan være nødvendige, men brug dem bevidst og bind dem op på en proces, så de bliver styrbare.
Her er en enkel måde at arbejde med definitioner, så både projektplan og kontrakt taler samme sprog:
- Leverance: Hvad der konkret afleveres, og i hvilket format (dokument, kode, workshop, installation)
- Acceptkriterier: Hvad der skal være opfyldt, før kunden kan godkende, og hvordan testen gennemføres
- Milepæl: En dato eller et resultat, der udløser betaling, status eller næste fase
- Ændring: Hvad der tæller som ekstraarbejde, og hvad der er “inkluderet”
- Arbejdsdage: Om weekender og helligdage tæller med i frister, og hvilken kalender der gælder
Bilag er din ven, når detaljeniveauet bliver højt. Læg teknik, kravspecifikation, tidsplan, RACI eller kommunikationsplan i bilag, men sørg for, at kontrakten fortæller, hvilke bilag der er gældende, og hvad der gælder ved uoverensstemmelse mellem dokumenter.
De klausuler der oftest afgør om aftalen holder
Når kontrakter skaber problemer, skyldes det ofte, at nogle grundelementer enten mangler eller er skrevet for bredt. Det er sjældent “den fancy” klausul, der redder dig, men de klassiske områder: scope, betaling, ansvar og ændringer.
De fleste projektaftaler bør som minimum forholde sig til:
- Parter og kontaktpunkter
- Aftalens formål og omfang
- Levering, tidsplan og afhængigheder
- Pris, betalingsplan og fakturering
- Misligholdelse (forsinkelse, fejl, manglende betaling)
- Ansvarsbegrænsning og forsikring (hvis relevant)
- Fortrolighed og databeskyttelse
- Immaterielle rettigheder (hvem ejer hvad, og hvilke licenser gives)
- Opsigelse, ophævelse og exit (overdragelse, dokumentation, adgang til materialer)
- Lovvalg og tvistløsning (domstol, voldgift, mediation)
Skriv også gerne direkte, hvem der har beslutningskompetence. En stor del af “kontraktbrud” i projekter er i virkeligheden beslutninger, der træffes af personer uden mandat, eller godkendelser der aldrig bliver givet.
Ændringer, ekstraarbejde og det uforudsete
Der er to slags projekter: dem der ændrer sig, og dem der har opdaget det for sent. Derfor bør ændringshåndtering være en procedure, ikke en sætning.
En praktisk ændringsklausul beskriver typisk: hvordan ændringer foreslås, hvilket informationsniveau der kræves (konsekvens på tid, pris, kvalitet), hvem der godkender, og hvordan ændringen dokumenteres (ændringsordre, change request, appendiks). Når det er på plads, kan du styre forventningerne og undgå, at projektet langsomt udvider sig uden økonomi.
Force majeure er et andet område, der ofte kopieres ind uden omtanke. Det vigtigste er ikke at have ordet med, men at beskrive, hvad der sker: varsling, dokumentation, suspension, mulighed for opsigelse ved langvarige hændelser.
Hvis du arbejder med underleverandører, så tjek også “flow down”: Har du lovet kunden noget, som din underleverandør ikke er bundet af? Hvis ja, har du skabt et hul, der kan blive dyrt.
Godkendelser, underskrift og opbevaring
Skriftlighed er ikke altid et lovkrav i erhvervsforhold, men det er næsten altid et praktisk krav. Ikke fordi papir i sig selv skaber samarbejde, men fordi det skaber bevis og fælles hukommelse.
En stor kontrakt kan godt være korrekt, men stadig risikabel, hvis den underskrives af nogen uden bemyndigelse, eller hvis den endelige version ikke kan genfindes.
Brug en enkel signeringsrutine, så projektet kan komme sikkert i gang:
- Fastlæg “single source of truth”: Én filplacering og én versionsstandard (fx v1.0 signeret)
- Tjek mandat: Hvem må underskrive, og kræver det intern godkendelse først?
- Sikr bilag: Er alle bilag vedhæftet, navngivet korrekt og nævnt i kontrakten?
- Vælg signeringsform: Digital signatur eller fysisk, og samme metode for begge parter
- Arkivér og operationalisér: Læg nøglefrister ind i projektplanen (betaling, optioner, opsigelsesvarsler)
Notar og vidner er sjældent nødvendige i almindelige erhvervsaftaler, men notarbekræftelse kan give ekstra tryghed i særlige situationer, især når der er internationale parter eller høje beløb.
Typiske faldgruber og hvordan du undgår dem
Den mest almindelige fejl er at genbruge en standardkontrakt uden at tilpasse den til projektets reelle leverancemodel. Du ender med klausuler, der ikke passer til arbejdet, og mangler netop de bestemmelser, du har brug for.
Den næstmest almindelige fejl er intern inkonsistens: tidsplanen siger én ting, betalingsplanen noget andet, og bilagene bruger andre begreber end kontraktens hovedtekst. Det bliver hurtigt en tolkningskamp, hvor begge parter kan finde en sætning, der støtter deres læsning.
Og så er der de “usynlige” huller: adgang til kundens systemer, kundens leverancer (data, miljøer, beslutninger), blackouts i ansvar ved tredjepartssoftware, eller manglende exit-plan, hvis samarbejdet stopper midt i en leverance.
En enkel vane hjælper: Når du læser kontrakten igennem, så markér alt det, der kræver en proces i projektet. Hvis kontrakten kræver månedlig status, godkendelser, varslinger eller dokumentation, så skal det oversættes til konkrete aktiviteter i din projektplan.
BlivProjektleder.dk arbejder generelt med projektledelse som praksisfag, og det samme mindset passer godt her: Kontrakten skal ikke bare kunne underskrives, den skal kunne bruges i hverdagen. Når du kan koble kontraktens krav direkte til milepæle, roller og beslutningspunkter, bliver den et styringsværktøj frem for en skuffeaftale.
Når du vil gøre kontrakten “skudsikker” uden at gøre den tung
Start med de ting, der næsten altid skaber friktion: scope, accept, ændringer, ansvar og samarbejdsform. Skriv derefter kort, konkret og med gentagelig struktur, så parterne kan finde svar hurtigt.
Inden du sender kontrakten til modparten, kan du lave en sidste realitetstest i ren prosa: Er der en klar beskrivelse af leverancen, en entydig acceptmetode, en styrbar ændringsprocedure, en rimelig balance i ansvar, og en plan for hvad der sker ved forsinkelse eller stop? Hvis du kan pege på det sted i kontrakten, hvor hvert spørgsmål besvares, er du tæt på en aftale, der holder, også når projektet ændrer sig undervejs.
— Du kan få dem tilsendt herunder! —
