Mange konflikter i prosjekter bunner i at partene har ulike bilder av hva som faktisk skal leveres. En god leveransebeskrivelse setter klare forventninger, gjør det enklere å styre tid og kost, og gir et rettferdig grunnlag for fakturering og aksept. Den er like nyttig når du kjøper utvikling av nettside, markedsføring, konsulentbistand eller når du etablerer selskap og trenger tydelige leveranser fra rådgivere.
Hva er en leveransebeskrivelse?
En leveransebeskrivelse er en avtalt, eksplisitt liste over målbare produkter, resultater eller milepæler som skal overleveres innenfor et prosjekt eller oppdrag. «Deliverables» kan være fysiske ting (maskinvare), digitale artefakter (kode, designfiler), tjenester (workshops, opplæring), dokumentasjon, eller verifiserte resultater (for eksempel en godkjent revisjonsrapport). Den er kjernen i hva kunden betaler for, og hva leverandøren forplikter seg til å produsere.
I praksis fungerer leveransebeskrivelsen som et kontraktsvedlegg. Den gir grunnlag for plan, ressursbruk, risikoanalyse og endringskontroll. Jo tydeligere den er, jo lettere er det å unngå scope creep og diskusjoner om hva som var «inkludert».
Forskjellen på leveransebeskrivelse, kravspesifikasjon og scope
Begrepene blandes ofte. En leveransebeskrivelse svarer på «hva blir overlevert?». En kravspesifikasjon beskriver egenskaper, standarder og regler leveransene må oppfylle. Scope (omfang) favner både leveranser, arbeidsoppgaver og avgrensninger. I mindre oppdrag kan alt samles i ett dokument, men skill gjerne tydelig mellom disse delene.
Offentlige anskaffelser krever ofte tydelig Kravspesifikasjon, og det samme tankesettet er nyttig for private virksomheter. For kommersielle avtaler er det viktig at leveransebeskrivelsen er tilpasset hvordan dere faktisk tenker å måle fremdrift og kvalitet.
Hva bør være deliverables i kjerneinnholdet
Målsettingen er å gjøre leveransene så konkrete at de kan krysses av. Tenk «hylleklare» resultater, ikke abstrakte løfter. Nedenfor er typiske elementer som bør beskrives, med forslag til formuleringer. Tilpass etter bransje og risiko.
- Leveranseliste: Nummererte leveranser (L1, L2, …) med navn, kort beskrivelse og ansvarlig part.
- Omfang per leveranse: Hvilke komponenter inngår/inngår ikke. For eksempel «inkluderer mobilvisning, ekskluderer flerspråk».
- Akseptkriterier: Objektive tester eller sjekkpunkter. «L1 godkjennes når 30 brukere logger inn samtidig med < 1 s responstid».
- Kvalitetsmål: Terskler for ytelse, sikkerhet, nøyaktighet, feiltoleranse, SLA, tilgjengelighet (f.eks. 99,5%).
- Dokumentasjon: Hva, format og hvor det lagres. «Administrasjonsmanual i PDF og Markdown, lagres i Git-repo/Docs».
- Overleveringsform: Filstruktur, mottakskanal, miljø (dev/test/prod), samt hvem som kvitterer mottak.
- Eierskap/IPR: Hvem eier hva ved betaling. «Kildekode for modul A overdras med ubegrenset bruksrett til kunden».
- Tidsplan og milepæler: Datoer per leveranse og avhengigheter. Milepæler knyttes til aksept og betaling.
- Endringshåndtering: Hvordan foreslås, estimeres og godkjennes endringer. Tydelig kobling til pris.
- Rapportering: Hyppighet, innhold og verktøy for status.
- Prøvedrift/pilot: Varighet, mål og hva som må være oppfylt for å gå i produksjon.
- Support og garanti: Omfang (tid, responstid, feilklassifisering), varighet, og hva som regnes som feil vs. videreutvikling.
- Opplæring: Antall økter, deltakere, format, kursmateriell som leveranse.
- Datagrunnlag: Hvilke input leveres av kunden, format og frister.
- Forutsetninger og avgrensninger: Tekniske og organisatoriske forutsetninger, samt det som uttrykkelig ikke inngår.
Mange opplever at bare det å skrive ned disse punktene avdekker uklarheter. Bruk tidlig en workshop for å sirkulere en første versjon, og lås deretter versjon 1.0 for kontrakt – med en enkel prosess for endringer.
Målbare akseptkriterier og kvalitet
Akseptkriterier er «porten» mellom leverandørens ferdigmelding og kundens godkjenning. De skal være binære: oppfylt/ikke oppfylt. Formuler dem slik at begge parter vet nøyaktig hva som testes, av hvem og med hvilke data.
- Digitalt prosjekt: «Checkout fullfører transaksjon med Visa/Mastercard i Chrome, Safari og Edge, og logger feil med korrelerende request-id».
- Markedsføring: «Minimum 30 kvalifiserte leads per måned, definert som skjema med e-post + telefon, CPL ≤ 450 kr i 2 sammenhengende måneder».
- Juridiske tjenester: «Utkast til aksjonæravtale levert som .docx + PDF, inkludert kap. om forkjøpsrett, drag/tag, deadlock, signeringsklar innen 10 virkedager etter input».
En praktisk fremgangsmåte:
- Definer målet (forretningsmessig effekt).
- Beskriv leveransen (artefakt/resultat).
- Velg målemetode (test, sjekkliste, tall).
- Sett terskelverdier (ytelse, kvalitet, volum).
- Avklar datagrunnlag (testdata, miljø, periode).
- Angi ansvar og frist (hvem tester, når).
Leveransebeskrivelse ved kjøp av hylleselskap
Kjøper du et hylleselskap, er det ekstra viktig å avklare hva som faktisk følger med – og når du har reell kontroll. Formuler leveransene slik at eierskap, navn og styringsrett er på plass uten friksjon.
- Overdragelse av aksjer: Signert aksjeoverdragelsesavtale, oppdatert aksjeeierbok og bekreftelse på registrering i Altinn/Foretaksregisteret.
- Organisasjonsdokumenter: Stiftelsesdokument, vedtekter, siste årsregnskap (om relevant), styreprotokoll for eventuelle endringer.
- Navneendring: Innsending til Foretaksregisteret (digitalt) som del av leveransen, inkludert oppfølging til vedtak. Offentlig gebyr er normalt 1 276 kr ved digital innsending.
- Rolle- og signaturrett: Registrering av nytt styre og daglig leder, samt signaturrett i Brønnøysund og bank.
- Bankkonto og KYC: Veiledning og nødvendige dokumenter for kundekontroll. Avklar om leverandør kun bistår, eller garanterer åpnet konto.
- Tilganger: Tilgang i Altinn og eventuelle regnskapssystemer. Beskriv hvordan tilganger overføres og bekreftes.
- Skatte- og avgiftsmessig status: Avklar om selskapet er MVA-registrert, og eventuelle forpliktelser ved overtakelse.
- Renhet: Erklæring om fravær av gjeld, pant og forpliktelser («rent selskap»), eventuelt bekreftet av revisor/regnskapsfører.
- Tidslinje: Når hver delleveranse er forventet godkjent (f.eks. «navneendring bekreftet innen X virkedager etter innsending»).
Alternativt til hylleselskap kan du stifte nytt AS. Da inngår gjerne utarbeidelse av stiftelsesdokumenter og registrering (offentlig stiftelsesgebyr er i dag 6 825 kr ved elektronisk innsending). Uansett valg, spesifiser leveransene slik at du vet nøyaktig når selskapet er klart til å operere.
Vurder å hylleselskaper før bestilling for å se hva som faktisk inngår hos ulike aktører, og hvordan de dokumenterer leveransene.
Roller, ansvar og kommunikasjon
Selv en god leveransebeskrivelse feiler uten klare roller. Et enkelt RACI-oppsett kan inngå som del av dokumentet, gjerne koblet til hver leveranse (hvem er ansvarlig, hvem godkjenner, hvem bidrar, hvem informeres).
- Prosjekteier: Godkjenner leveranser og endringer, prioriterer scope.
- Leveranseansvarlig: Eier fremdrift pr. leveranse, koordinerer ressursene.
- Fagansvarlige: Definerer akseptkriterier og tester.
- Kommunikasjon: Fast ukemøte, statusmal, beslutningslogg og kanal for avklaringer (f.eks. Teams, e-post med felles tråd).
Avtal også responstider for avklaringer. Forsinket kundebeslutning er en vanlig årsak til tidsavvik; ha derfor «ventetid på kundeinput» som eksplisitt registrert aktivitet som kan stoppe frister.
Pris, budsjett og insentiver
Leveransebeskrivelsen bør kobles til prismodellen. Det gjør både planlegging og styring enklere, og reduserer misforståelser om hva som utløser betaling.
- Fastpris pr. leveranse: Klar risikoavgrensning; godt egnet når akseptkriteriene er modne.
- Timepris med tak: Brukes når omfang er noe usikkert; angi ikke bare taket, men også estimerte timer per leveranse.
- Milepælsbetaling: Delbetaling ved aksepterte milepæler (f.eks. 30/40/30). Knytt til eksplisitte akseptkriterier.
- Retensjon: En liten andel (f.eks. 10%) holdes tilbake til etter prøvedrift/garantiperiode for å sikre fullføring.
- Dagmulkt/bonus: Ved kritiske frister kan tidsinsentiver fungere – beskriv nøyaktig hva som måles.
Husk å definere hva som regnes som «utenfor leveranse» og derfor utløser endringsordre. Legg inn kostnadsdrivere (for eksempel nye integrasjoner, flere språk, nye annonsekanaler) som tydelige prislinjer fra start.
Overlevering, aksept og drift
Selve overleveringen bør være en egen aktivitet med sjekkliste. Når den er bestått, starter akseptperioden, som igjen leder inn i drift/garanti.
- Overleveringsmøte: Gå gjennom leveranseliste, vis demo, pek på dokumentasjon og kjente avvik.
- Akseptperiode: Varighet (f.eks. 10 arbeidsdager), hvem tester, rapporteringsmal for avvik og frister for utbedring.
- Akseptbrev: Enkel sign-off som trigges automatisk ved utløpt frist uten kritiske avvik, eller når alle avvik er lukket.
- Driftsfase/SLA: Overgangskriterier, kontaktpunkter og prioriteringsmatrise for hendelser.
For digitale leveranser, sørg for at tilganger, lisensnøkler, repository-rettigheter, CI/CD-pipelines og infrastrukturressurser er navngitte og overført. Beskriv også hvordan rollback håndteres dersom aksept feiler.
Mal og eksempel: enkel leveransebeskrivelse
Nedenfor et kondensert eksempel du kan bruke som utgangspunkt. Utvid med detaljer for deres kontekst.
Prosjekt: Nettside for Selskap AS (fase 1)
- L1 Designsystem v1.0 – Figma-bibliotek med 12 komponenter (knapp, skjema, header, footer osv.). Aksept: Gjennomgang i workshop, 2 revisjonsrunder inkludert.
- L2 Frontend MVP – React-app med 5 sider (hjem, tjenester, om oss, kontakt, personvern). Aksept: Lighthouse ≥ 90 på mobil/desktop; WAVE uten kritiske feil; builds i GitHub Actions.
- L3 CMS-integrasjon – Sanity-skjemaer for sider, komponenter og SEO. Aksept: Redaktør publiserer endringer uten utviklerbistand; opplæring 2×1 t inkludert.
- L4 Drift og garanti – 30 dager feilretting (kritisk ≤ 8 t, høy ≤ 24 t). Aksept: Signert akseptbrev på L1–L3.
- Tidsplan: L1 dag 10, L2 dag 25, L3 dag 35, L4 dag 36–65.
- Pris: L1 45 000 kr, L2 120 000 kr, L3 55 000 kr, L4 inkludert. Delbetaling 30/40/30 per aksept.
- Forutsetninger: Kunde leverer tekst og bilder innen dag 7; domene og DNS-tilgang senest dag 20.
- Avgrensninger: Flerspråk og e-handel inngår ikke i fase 1.
Bruk samme struktur for andre oppdrag, som revisjon, HR-prosjekter, IT-drift eller kjøp av hylleselskap – bytt ut leveransene, men behold tydeligheten i aksept, roller, tidslinje og pris.