Et krav uten kontekst er en instruksjon. Et krav med kontekst er et problem noen kan hjelpe deg å løse. Forskjellen ligger i dette kapittelet: her forteller du hvorfor anskaffelsen finnes, hva som utløste den, og hva som er annerledes hvis den lykkes.
Det høres selvsagt ut, men det er lett å hoppe over. Alle som har jobbet med saken i månedsvis vet jo hvorfor. Problemet er at ingen av dem skal skrive tilbudet.
Hva kapittelet skal inneholde
- Hvem dere er. Virksomhet, sektor, størrelse, oppdrag. To til fire setninger. En leverandør som ikke kjenner dere fra før trenger et ankerpunkt.
- Hva som utløste behovet. Et system som går ut av support, en ny lov, en vekst dere ikke lenger håndterer manuelt, en sammenslåing. Det finnes alltid en utløsende årsak — skriv den.
- Hva anskaffelsen omfatter, i én setning. «Vi skal anskaffe et nytt saksbehandlingssystem for byggesak, inkludert migrering fra dagens løsning og drift i fem år.» Detaljene kommer senere; her handler det om å gi leseren riktig bilde fra første avsnitt.
- Hvem som eier anskaffelsen. Navn og rolle på den som svarer på spørsmål. Se hvert krav trenger en eier.
En halv til én side. Blir det tre, har du sannsynligvis begynt å skrive dagens situasjon eller mål og gevinster i feil kapittel.
Slik ser det ut
Virksomheten ønsker å anskaffe et moderne og fremtidsrettet system som skal understøtte virksomhetens behov og bidra til effektivisering og digitalisering av arbeidsprosessene.
Dette kunne stått i hvilken som helst kravspesifikasjon i landet. Det forteller leverandøren nøyaktig ingenting, og det signaliserer at resten av dokumentet kanskje er like generisk.
Kommunen behandler omtrent 1 400 byggesaker i året. Dagens fagsystem ble innført i 2009, og leverandøren har varslet at det tas ut av support fra utgangen av 2027. Saksbehandlerne bruker i dag tre parallelle løsninger, og arkivering skjer manuelt.
Vi skal anskaffe ett samlet saksbehandlingssystem for byggesak, med migrering av historiske saker og drift i fem år med opsjon på to.
Legg merke til hva det andre eksempelet gir bort: volumtall, tidsfrist, antall systemer, at arkivering er manuell i dag. En leverandør som leser dette vet allerede hvor skoen trykker, og kan bruke tilbudet på å svare på det.
Bakgrunn er ikke det samme som begrunnelse
Et vanlig sidespor er å bruke kapittelet til å rettferdiggjøre budsjettet internt. Det er en annen tekst, til et annet publikum. Beslutningsnotatet skal overbevise ledelsen om at pengene bør brukes; kravspesifikasjonen skal sette leverandøren i stand til å forstå oppgaven. Hold dem fra hverandre.
Det samme gjelder politiske vedtak og strategidokumenter. Vis gjerne til dem, men ikke lim dem inn. Et vedlegg er billigere enn tre sider ingen leser.
Vanlige feil
- Interne forkortelser uten forklaring. Prosjektnavn, systemnavn og avdelingskoder som er selvsagte for dere er støy for alle andre. Ta dem inn i begreper og definisjoner.
- Løsningen smuglet inn i bakgrunnen. «Bakgrunnen er at vi trenger en skybasert plattform» er ikke en bakgrunn, det er en beslutning. Se beskriv behovet, ikke løsningen.
- Ingen tall. Volum, antall brukere, antall saker, datamengde. Ett tall i bakgrunnen er verdt en side med adjektiver.
- Kopiert fra forrige anskaffelse. Gjenbruk struktur, ikke innhold. Se den kopierte kravlisten.