Kravspesifikasjon.comIngen skal måtte være ekspert

ForsidenFormulering › Skal, bør og kan

Skal, bør og kan

Kravnivået er det billigste styringsverktøyet du har. Det koster ingenting å sette, og det avgjør hva leverandøren prioriterer når tiden blir knapp — noe den alltid blir.

Et kravnivå sier hvor bindende kravet er. Konvensjonen i norske anskaffelser er tre nivåer, og de betyr noe helt konkret for både tilbud, pris og evaluering.

NivåBetydningKonsekvens hvis ikke oppfylt
Skal Absolutt krav. Løsningen er ubrukelig uten. Tilbudet avvises. Leveransen kan nektes godkjent.
Bør Sterkt ønsket. Gir uttelling i evalueringen. Tilbudet står, men scorer lavere.
Kan Ønskelig hvis det er rimelig. Ingen forventning. Ingen. Registreres som et pluss.
Hva de tre kravnivåene gjør med tilbudet Konsekvens for tilbudet Skal Absolutt krav. Ikke oppfylt betyr at tilbudet avvises. Prøven: ville du takket nei på grunn av dette? Bør Gir uttelling i evalueringen. Tilbudet står. Uten poeng i modellen blir det ignorert. Kan Ønskelig hvis det er rimelig. Ingen forventning. Registreres som et pluss.
Jo lenger til venstre, jo dyrere. Leverandøren priser inn risikoen for å bomme på et skal-krav — derfor koster en liste der alt står til venstre mer enn den er verdt.

Regelen som gjør nivåene nyttige

Et skal-krav er et krav du er villig til å avvise et ellers godt tilbud på. Er du ikke det, er det ikke et skal-krav. Denne prøven er ubehagelig, og den er hele poenget.

Når nesten alt er merket «skal», skjer to ting. Leverandørene priser inn risikoen for at de ikke treffer på alt, og prisen går opp. Og du mister evnen til å skille tilbudene fra hverandre, fordi alle krysser av på det samme. Da sitter du igjen med pris som eneste reelle kriterium — som sjelden var det du ville.

Tommelfingerregel

Kommer du over 60 prosent skal-krav, har du sannsynligvis ikke prioritert — du har bare skrevet ned alt du kom på. Gå gjennom listen på nytt og spør ved hvert krav: ville jeg takket nei til en ellers utmerket løsning på grunn av akkurat dette?

Slik ser det ut i praksis

Svakt

Systemet skal ha god søkefunksjonalitet, og bør være raskt. Det skal også helst kunne integreres med økonomisystemet.

Her er «skal» brukt om noe umålbart, «bør» om noe kritisk, og «skal også helst» er ikke et nivå i det hele tatt.

Bedre

K-114 (skal) Systemet skal kunne søke i fritekst på tvers av saksnummer, tittel og innhold, og returnere treff innen 2 sekunder ved 500 000 saker.

K-115 (skal) Systemet skal utveksle fakturagrunnlag med økonomisystemet via dokumentert grensesnitt.

K-116 (bør) Søket bør støtte synonymer og bøyningsformer på norsk.

Vanlige feil

  • Skal-krav som egentlig er en løsningsbeskrivelse. «Systemet skal bruke PostgreSQL» er sjelden et reelt behov. Se beskriv behovet, ikke løsningen.
  • Bør-krav uten uttelling. Sier du «bør», men gir ingen poeng for det i evalueringsmodellen, blir kravet ignorert. Da er det et kan-krav, og du bør si det.
  • Nivå blandet inn i kravteksten. Skriv nivået som eget felt, ikke gjemt inne i setningen. Da kan du sortere, telle og evaluere maskinelt.
  • Endret nivå etter tilbudsfristen. Å oppgradere et bør-krav til skal-krav underveis er å endre konkurransegrunnlaget. I offentlige anskaffelser er det ikke lov.

Om MoSCoW

Mange bruker MoSCoW — Must, Should, Could, Won't — i stedet. Det er i praksis de samme tre nivåene, pluss et fjerde som er undervurdert: Won't, altså det du bevisst har bestemt at ikke skal med. Det fjerde nivået er verdt å ta med uansett hvilket system du velger, fordi det er der avgrensningen blir synlig. Les mer under MoSCoW.