En kravspesifikasjon er et verktøy for å beskrive noe du vet at du trenger, slik at noen andre kan levere det til avtalt pris. Den forutsetter altså at behovet er kjent og stabilt nok til å skrives ned. Er det ikke det, blir dokumentet en presis beskrivelse av en gjetning — og du betaler for presisjonen uten å få nytten av den.
1. Når dere ikke vet hva dere trenger ennå
Skal dere utforske et nytt område, teste om noe i det hele tatt lar seg gjøre, eller finne ut hva brukerne faktisk har behov for — da er kravspesifikasjonen feil verktøy. Den låser en forståelse du ennå ikke har.
I stedet: kjøp en avgrenset utredning eller en forstudie først. Beskriv spørsmålet som skal besvares og hva leveransen er — en rapport, en prototype, et beslutningsgrunnlag — ikke løsningen. Da har du en kravspesifikasjon for kunnskapen, som er noe helt annet og mye kortere.
2. Når anskaffelsen er liten
Til en avtale på noen titusen kroner kan et 40-siders dokument koste mer å skrive enn det som skal kjøpes. Det er ikke god forvaltning, og det skremmer bort små leverandører som kanskje var de best egnede.
I stedet: en til to sider med behov, avgrensning, budsjettramme og noen få absolutte krav. De grunnleggende prinsippene om konkurranse og likebehandling gjelder fortsatt, men omfanget skal stå i forhold til kjøpet.
3. Når dere kjøper en tjeneste, ikke et system
Kjøper dere rådgivning, utviklingskapasitet eller bistand, er det ikke en løsning som skal spesifiseres — det er kompetanse og arbeidsform. Krav om funksjonalitet gir da lite mening.
I stedet: beskriv oppgaven, konteksten, hva som er levert når, hvilken kompetanse som trengs og hvordan samarbeidet skal foregå. Se kontraktsoversikten for hvilke avtaler som passer til bistand framfor leveranse.
4. Når løsningen allerede er gitt
Skal dere utvide en løsning dere allerede har, fra en leverandør dere allerede har avtale med, er det en endringsbestilling — ikke en anskaffelse. Da trenger du en presis beskrivelse av endringen, ikke et fullt dokument med bakgrunn og målbilde.
Men: sjekk at endringen faktisk ligger innenfor den eksisterende avtalen. Vesentlige utvidelser kan kreve ny konkurranse, uansett hvor upraktisk det er.
5. Når problemet ikke er teknisk
Uklart ansvar, uenighet om hva som er riktig praksis, for lite folk, dårlige data. Alle fire ser ut som systemproblemer på avstand, og ingen av dem løses av et system. Se trenger dere nytt system i det hele tatt?
I stedet: løs det som må løses av mennesker først. Systemet kan gjerne komme etterpå — det blir da både billigere og bedre, fordi kravene endelig kan bygge på en avklart praksis.
Ofte er svaret verken «full kravspesifikasjon» eller «ingenting», men en behovsbeskrivelse: hva problemet er, hvem det gjelder, hva det koster i dag, hva som må være på plass, og hva som uttrykkelig ikke er med. Fem til ti sider. Det er nok til å få gode tilbud på det meste som ikke er stort og komplekst.
Når du absolutt bør skrive én
For balansens skyld — kravspesifikasjonen er riktig verktøy når flere av disse er sanne:
- Behovet er kjent og stabilt nok til å beskrives
- Flere leverandører kan levere, og du vil kunne sammenligne dem
- Beløpet er stort nok til at grundighet lønner seg
- Løsningen skal leve lenge, og drift og exit må avklares nå
- Det skal inngås en kontrakt der noen må kunne holdes til noe
Det er de fleste systemanskaffelser. Men det er ikke alle innkjøp, og forskjellen er verdt å kjenne — særlig fordi et unødvendig grundig dokument også har en kostnad, både i tid og i antall tilbud du får.