Kravspecifikation vs. SOW vs. kontraktbilag — hvad er forskellen?

Kravspecifikationen er jeres beslutningsgrundlag. SOW er leveranceaftalen. Kontraktbilaget er den juridiske forankring.

En kravspecifikation er dokumentet, der beskriver behov, scope, funktionelle og tekniske krav, prioriteter og succeskriterier — før I beder om tilbud.

I dansk B2B-praksis er det typisk det, I sender ud som tilbudsgrundlag eller bruger som fælles reference, når flere bureauer skal byde. Uden den får I tre tilbud på tre forskellige projekter — og kan ikke sammenligne dem.

En god kravspecifikation er:

- Præcis — antal sider, funktioner, integrationer, ikke "moderne hjemmeside"
- Prioriteret — must-have vs. nice-to-have
- Testbar — I kan afgøre, om et krav er opfyldt
- Afgrænset — hvad der ikke er med i fase 1

Den er ikke en kontrakt. Den er jeres kravgrundlag. Se også kravspecifikation til webprojekt for indhold og struktur, og hvad koster en kravspecifikation for realistiske priser.

Hos Specify er udarbejdelse af præcise, prioriterede og testbare krav en kerneydelse under behov og krav — netop fordi uklare krav er den dyreste fejl, før byggeriet starter.

En SOW — Statement of Work — er leveranceaftalen mellem jer og webbureauet. Den beskriver, hvad der konkret skal leveres, i hvilken kvalitet, hvornår, af hvem, og til hvilken pris.

Hvor kravspecifikationen siger "vi har brug for X", siger SOW'en "bureauet leverer X, Y og Z inden for denne ramme".

En SOW til et webprojekt bør typisk dække:

- Leverancer (sider, features, integrationer, migration, træning)
- Milepæle og tidsplan
- Ansvarsfordeling (kunde vs. bureau — især indhold)
- Acceptkriterier og godkendelsesproces
- Ændringshåndtering (change request)
- Pris, betalingsmilepæle og hvad der er uden for scope

SOW er det dokument, der gør et vagt tilbud til noget, I kan styre efter. Uden den er "fast pris" ofte bare et starttal. Læs også timepris eller fast pris — prismodellen giver kun mening, hvis scopet er defineret.

Bemærk: mange danske bureauer kalder deres tilbud for "SOW", "projektbeskrivelse" eller "leverancebeskrivelse". Navnet er ligegyldigt. Indholdet er det ikke. Hvis dokumentet ikke definerer leverancer, grænser og ændringsproces, er det ikke en SOW — det er en salgsbrochure.

Et kontraktbilag er et dokument, der knyttes til hovedkontrakten og dermed bliver juridisk bindende. Det kan være kravspecifikationen, SOW'en, en SLA, en liste over rettigheder, en exit-klausul eller en teknisk bilagsfortegnelse.

I praksis er kontraktbilaget svaret på spørgsmålet: "Hvis der opstår uenighed — hvad står der så i aftalen?"

Det er her, mange webprojekter fejler juridisk — ikke fordi kontrakten mangler, men fordi bilaget er vagt, forældet eller aldrig er vedhæftet. Et tilbud i en e-mail er ikke det samme som et bilag, der er refereret i kontrakten.

Typiske kontraktbilag i et webbureau-samarbejde:

- Scope / SOW (leverancer og afgrænsning)
- Kravspecifikation (eller en frysning af den aftalte version)
- Tidsplan og milepæle
- Pris og betalingsplan
- SLA / support efter lancering
- Rettigheder til kode, design og data
- Exit- og overdragelsesvilkår

Specify hjælper blandt andet med kontraktbilag og governance-setup som del af leverandørvalg — uden selv at sælge websitet. Det er bevidst: vi repræsenterer dig, ikke bureauet. Se også uvildig digital rådgivning.

De tre dokumenter overlapper i indhold, men har forskellig rolle, ejerskab og timing:

Du behøver ikke altid alle tre dokumenter i fuld længde. Men du skal vide, hvilket hul du har.

Tommelfingerregel: Kravspecifikation før I shopper. SOW når I køber. Kontraktbilag når I binder jer.

Seks fejl vi ser igen og igen i danske webprojekter:

Sådan ser et sundt forløb ud i et dansk webprojekt:

1. Afklaring — mål, interessenter, budgetramme, risici
2. Kravspecifikation — prioriterede, testbare krav og afgrænsning
3. Udbud / tilbudsindhentning — samme kravgrundlag til alle bureauer
4. Tilbudsvurdering — sammenlign på substans, ikke kun pris
5. SOW — konkretiser leverancer, milepæle, ansvar og pris med den valgte leverandør
6. Kontrakt + kontraktbilag — SOW/krav (frysset version), rettigheder, exit, betaling
7. Governance — ændringer kun via aftalt proces; bilag opdateres ved væsentlige ændringer

Spring et trin over, og risikoen flytter sig. Spring kravspecifikationen over, og I køber blindt. Spring SOW over, og I styrer blindt. Spring kontraktbilaget over, og I står svagt, når det gælder.

Det er præcis den struktur, Specify arbejder efter under ydelser: afklaring → specifikation → eksekvering og governance — uden at sælge hjemmesiden selv.

I danske webprojekter møder I ofte en blanding af dansk og engelsk terminologi. "Kravspec" fra IT-projekter. "SOW" fra bureauernes internationale skabeloner. "Kontraktbilag" fra jeres advokat eller indkøb. Alle tre kan indeholde scope — men de spiller forskellige roller i processen.

Det bliver særligt problematisk, når:

- Marketing ejer briefet, men ikke kravene
- Bureauet "hjælper" med kravene, mens de samtidig byder
- Juridisk først kommer ind efter underskrift
- Ledelsen tror, at et underskrevet tilbud er det samme som en styret leveranceaftale

Resultatet er kendt: tilbud, der ikke kan sammenlignes; ekstraarbejde uden ændringsproces; og en kontrakt, der ikke beskytter jer, når projektet skrider. Det er ikke et teknologiproblem. Det er et dokumentations- og governance-problem.

Er I midt i et forløb uden klar dokumentstruktur, er det stadig værd at rette op — også efter bureauvalg. En opdateret SOW og korrekte kontraktbilag er billigere end en konflikt midt i udviklingen.

De spørgsmål vi oftest får om kravspecifikation, SOW og kontraktbilag: