Sådan afdækker du behov før du skriver kravspecifikationen

Behovsafdækning er ikke en ønskeliste

Mange kravspecifikationer bliver lange dokumenter med hundredevis af funktioner. Ifølge median.dk svarer leverandørerne ofte ja til det meste, mens virksomheden fortsat er usikker på, om løsningen løser de rigtige problemer.

Det er fælden, behovsafdækningen skal forhindre. En funktionsliste siger intet om den værdi, løsningen skal skabe. Bagefter kan man derfor ikke vurdere, om kravene var nødvendige.

Behovsafdækning hører under forretningsanalyse. Sopra Steria Danmark citerer BABOK Guiden: Forretningsanalyse er praksis for at muliggøre forandring i en virksomhed ved at definere behov og anbefale løsninger, der leverer værdi til interessenterne.

Rækkefølgen er: behovene defineres, før løsningen anbefales, og længe før kravene formuleres. Praktisk betyder det, at du før kravspecifikationen skal kunne svare på to spørgsmål: Hvad er behovet, og hvordan dækker vi det?

Det er den opsplitning, Kjellerup Kommunikation bruger som definition af behovsafdækning. Kan du ikke svare på det første, er det for tidligt at skrive krav – uanset hvor mange funktioner du har fået ønsker om.

Sådan afdækker du behov før kravspecifikationen

Start med problemet, ikke løsningen

Før kravene beskrives, bør virksomheden kunne forklare, hvilket problem der skal løses. median.dk peger på fire typiske mål: spare tid, reducere fejl, skabe bedre overblik eller understøtte en ny forretningsmodel.

Når problemet er tydeligt, bliver det ifølge samme kilde langt lettere at vurdere, hvilke krav der er nødvendige. Sopra Steria Danmark bruger en case som eksempel på en problemformulering: Virksomheden skal digitalisere og ensarte onboarding af nye kunder.

I dag foregår processen forskelligt i de tre lande, virksomheden opererer i. Den er manuel, tager for lang tid for kundeservice at håndtere, og der går for lang tid for kunderne, fra de søger om at blive kunder, til de rent faktisk bliver det.

Valget af system – i casen et BPMS – står som en konsekvens sidst, ikke som udgangspunktet. Skriv derfor problemet ned i to sætninger: hvordan situationen er i dag, og hvilken effekt I vil opnå.

Formuleringen bliver senere det filter, du sigter krav igennem: Understøtter dette krav effekten, eller gør det bare løsningen større?

Spørgeteknik der åbner og indsnævrer

IDA Learning beskriver åbne spørgsmål som spørgsmål, der opmuntrer kunden til at dele mere information og skabe en åben samtale. De starter ofte med ord som »hvordan«, »hvad« eller »hvorfor« og inviterer til dybdegående svar.

De giver kunden mulighed for at forklare sine tanker – og dig et klart billede af situationen. Et eksempel fra samme kilde: »Hvordan oplever du de udfordringer, du står overfor i din nuværende situation?«

Kjellerup Kommunikation beskriver behovsafdækning som en tragt: Dialogen starter bredt, og spørgsmålene skal hele tiden indsnævre behovet. Et åbent spørgsmål er kendetegnet ved, at man ikke kan svare ja eller nej.

I toppen af tragten kan spørgsmålene være »Hvad kan jeg gøre for dig?«, »Hvad kunne du godt tænke dig?« eller »Hvad er du på udkig efter?«. I kaffebutik-eksemplet går næste trin fra det brede til det smallere: »Ok, så det er kaffe, du er ude efter. Hvilken kaffe er du til?«

Lukkede spørgsmål tager over, når du skal præcisere og bekræfte. De besvares typisk med ja eller nej og bruges ifølge IDA Learning til hurtigt at få præcise svar, bekræfte antagelser og konkretisere behovet.

IDAs eksempel: »Er du interesseret i en løsning, der kan reducere din arbejdsbyrde?«. Rækkefølgen er afgørende: Begynd med åbne spørgsmål for at skabe dialog, og brug lukkede til at samle information og komme tættere på løsningen.

Åbne vs. lukkede spørgsmål i behovsafdækning

Aktiv lytning og bekræftelse af behov

IDA Learning anbefaler som et selvstændigt tip at lytte aktivt, før du stiller næste spørgsmål. Den næste relevante afklaring ligger i det, kunden netop har sagt – ikke i den spørgeliste, du havde forberedt.

Skriver du videre ned, mens svaret kommer, mister du de formuleringer, der senere skal bruges i kravspecifikationen. Opsummer derfor løbende, hvad du har hørt, og få det bekræftet, før du går videre.

Når lukkede spørgsmål bruges til at bekræfte antagelser, som IDA Learning beskriver, bliver opsummeringen den kontrol, der skiller et udtalt ønske fra et reelt behov. Kunden kan ønske sig et bestemt system, mens bekræftelsen viser, at problemet er sagsbehandlingstiden.

Hold fast i opsplitningen mellem behov og dækning af behovet. Når referatet indeholder både konstaterede behov og de ønsker, der blev afvist undervejs, har du dokumentation for, hvorfor kravene senere ser ud, som de gør – og hvorfor et ønske ikke blev et krav.

Kortlæg nuværende arbejdsgange og udfordringer

median.dk anbefaler, at dokumentet tager udgangspunkt i, hvordan virksomheden arbejder. Beskriv de vigtigste processer, hvor udfordringerne opstår, og hvordan en ny løsning skal understøtte dem.

Gevinsten er dobbelt – det giver leverandøren mulighed for at foreslå den bedste løsning, ikke bare den løsning virksomheden selv havde forestillet sig. Sopra Sterias case viser, at kortlægningen skal fange, hvor processen er manuel, hvor den varierer, og hvor den tager for lang tid – både for kundeservice og for kunderne.

Det er den slags detaljer, der senere bliver til krav om ensartet proces på tværs af lande og om kortere gennemløbstid. Gå processen igennem trin for trin med dem, der udfører den til daglig: Hvem udfører hvad, hvilke trin er manuelle, hvor skiftes der mellem systemer, og hvor opstår der ventetid?

Skriv varianterne ned – de steder, hvor de enkelte lande eller teams gør det forskelligt, er et af de tydeligste input til de kommende krav.

Inddrag forretning og interessenter

Sopra Steria Danmark anbefaler at starte med at definere forretningens behov og krav i samarbejde med forretningen. Forretningskravene svarer på, hvorfor løsningen skal udvikles, og hvad der skal til for, at projektet bliver en succes.

De er altid high-level og er mål for hele forretningen. Forretningskravene har en styrende funktion: De bestemmer, hvilken løsning du skal vælge, hvilke interessenter du skal inddrage i kravspecifikationen, og de bruges til den løbende prioritering i projektet.

De indgår i og udgør business casen, som ifølge samme kilde bør justeres løbende, hvis og når kravene ændrer sig gennem projektforløbet. I praksis betyder det, at du skal tale med to grupper: dem, der ejer målet og effekten (forretningen), og dem, der udfører arbejdet i dag (brugere og kundeservice).

Har du kun den ene part, får du enten overordnede mål uden detaljer om, hvor det gør ondt, eller detaljer om arbejdsgange uden et filter til at prioritere mellem dem.

Omsæt behov til målbare succeskriterier

Sopra Steria Danmark understreger, at kravene er nødt til at være målbare. I casen har forretningen på basis af en analyse besluttet sig for målsætninger, der stilles som krav i projektet – blandt andet en forbedring af kundetilfredsheden med minimum 5 %.

median.dk giver flere eksempler på, hvordan succeskriterier kan formuleres: 30 % mindre manuelt arbejde, færre fejlregistreringer, hurtigere sagsbehandling, bedre datakvalitet og øget kundetilfredshed. Flere af dem kan måles direkte og giver derfor et efterprøveligt svar på, om projektet lykkedes.

For at kriteriet kan bruges til at styre krav, skal det have en baseline: Mål størrelsen i dag – manuelle trin, fejlregistreringer, tid pr. sag – før du skriver målet ned.

Uden dagens tal kan du ikke senere afgøre, om en løsning leverede de 30 % eller 5 %, og kriteriet bliver reelt ikke målbart.

Målbare succeskriterier i kravspecifikation

Fra behov til beslutningsgrundlag

Median.dk anbefaler at skelne mellem ufravigelige, vigtige og ønskelige krav – det giver både virksomhed og leverandør større fleksibilitet, gør prioriteringen undervejs lettere og sætter ledelsen i stand til at træffe bevidste valg, når der skal indgås kompromiser.

Behovsafdækningen dokumenteres som de første dele af kravspecifikationen. median.dk angiver indholdet i denne rækkefølge: baggrund og formål, forretningsmæssige mål, beskrivelse af nuværende arbejdsgange, problemer og udfordringer, succeskriterier – derefter funktionelle krav, ikke-funktionelle krav (sikkerhed, performance, drift), integrationer, projektets rammer og forudsætninger samt prioritering af krav.

De fem første er behovsafdækningens output; resten er kravene. Median.dk gør op med idéen om, at kravspecifikationen skal være færdig fra starten.

I praksis udvikler forståelsen sig ofte undervejs. Dokumentet bør derfor ses som et beslutningsgrundlag, der kan kvalificeres løbende – ikke som et statisk dokument, der aldrig må ændres.

Det stemmer med Sopra Sterias pointe om, at business casen bør justeres, når kravene ændrer sig.

Fordele og ulemper ved at skrive kravspecifikation fra start