Med en god kravspecifikation kan du øge sandsynligheden for, at dit projekt bliver en succes. Ja, det er faktisk en betingelse.
Men mange projektansvarlige holder sig stadig tilbage med at skrive dette dokument.
I dette indlæg vil vise dig, at arbejdet med kravspecifikationen for det første er forholdsvis ukompliceret, for det andet en overskuelig opgave, og for det tredje helt centralt i forbindelse med alle projekter.
Hvorfor skal du lave en kravspecifikation?
En kravspecifikation er en vigtig del af projektledelse, det er her, hvor du som projektleder og virksomheden du arbejder for, skal definere jeres behov og krav til projektet. Der er desværre mange, som springer denne del over, men det kan have katastrofale konsekvenser for projektet.
Mange springer over enten fordi de tror, det er vanskeligt og teknisk kompliceret. Eller fordi de forestiller sig, at det er tidskrævende og dermed kostbart. Derfor er der forbavsende mange projekter, der starter med intet andet end en deadline, et budget og en løs forestilling om, hvad slutproduktet konkret skal være.
Jeg har alt for tit hørt om projekter, hvor kunden og leverandøren havde vidt forskellige forestillinger omkring kravene til projektet, og der var ingen kravspecifikation, som kunne bruges som argumentation for nogen af parterne.
En kravspecifikation skal være udførlig, og ligesom projektets målsætninger skal bruges som projektets kompas, så skal kravspecifikationen være projektets rutevejledning.
Den skal være meget konkret; drej til højre om 200m, og dernæst tag anden afkørsel i rundkørslen.
Prøv at forestille dig hvis den blot sagde “Kør til Odense, ankomst om 121 km” det ville du jo ikke kunne bruge til så meget, medmindre du allerede vidste, hvordan du kom derhen. Men det er vigtigt at tænke på at den ligesom en GPS ikke skal fortælle dig hvordan opgaven (drej om 200 meter) skal løses. Den skal bare sætte retningen, og lade ham som kører bilen klarer opgaven under de forudsætninger han arbejder under. Men mere om det længere nede i indlægget.
Hvad går der typisk galt?
Jeg har efterhånden set en lang række kravspecifikationer og fulgt deres skabelse. I min erfaring er det næsten altid det samme, der går galt: Personen, som skal lave kravspecifikationen, glemmer at fokusere på det mest væsentlige i projektet – De tager ikke højde for projektets målsætninger.
Kernen af problemet er, at:
- Leverandøren sjældent har et lige så godt kendskab til, hvordan en virksomhed skal, og bør fungere, som dig som kunde har.
- Og du har sjældent en særlig god idé om, hvad IT kan gøre for virksomheden.
- Det resulterer i, at projektet lammes, og frem for at arbejde mod et godt slutprodukt, fokuserer man på meningsløse deadlines og foruddefinerede budgetter.
Men hvordan ser en god kravspecifikation ud? Hvordan kommer man i gang? Og hvad skal den indeholde? Lad os se nærmere på udfordringerne.
Hvor lang skal en kravspecifikation være?
For de fleste projektledere, kan arbejdet med kravspecifikationen forekommer som en enormt stor opgave. De har en forestilling om, at den skal indeholde hundredvis af sider med detaljerede tekniske specifikationer, og hvor hver detalje skal gennemarbejdes før projektet kan komme fra start. Sådan behøver det ikke at være, jeg har set flere gode kravspecifikationer helt nede på 3-5 sider.
Så lad os lige kigge på, hvad den gode kravspecifikation ikke er:
- Det er ikke en telefonbog med detaljerede tekniske krav til løsningen. Det skal helst gerne være et overskueligt dokument, der beskriver, hvordan slutproduktet skal fungere. Du behøver ikke at lave use cases eller andre detaljerede beskrivelser.
- Det er ikke et udbudsmateriale. Det er oplagt, at kravspecifikationen kan indgå i et udbudsmateriale, men selve kravspecifikationen handler om dine krav til en løsning, ikke om købet af systemet.
- Det er ikke et dokument, der beskriver, hvad en udvikler skal levere. Din kravspecifikation skal ikke beskrive, hvordan udvikleren skal løse opgaven. Du har den samme rolle som en arkitekt. Arkitekten beskriver, hvilke krav der stilles til huset, og skitserer hvordan det skal se ud. Men de definere ikke valget af beton til fundamentet eller hvilken isolering der skal bruges.
Så kravspecifikationen skal ses som en beskrivelse af, hvad du ønsker af et system, og hvad du mener, vil give værdi for din virksomhed.
Hvad består en kravspecifikation af?
For at opnå det bedst mulige overblik skal du lave fire hovedpunkter, som er opdelt i underpunkter. Herunder kan du læse lidt om hovedpunkterne og de generelle principper bag disse hovedpunkter.
I virkeligheden behøver du ikke en masse teknisk viden for at specificere projektets krav, tværtimod kan det faktisk være en ulempe. Men efterhånden som du begynder at specificere, hvad det er, du vil have, eller ønsker at opnå med projektet, så begynder det tekniske sprog automatisk at komme frem.
Introduktion til projektet
Du skal gerne starte kravspecifikationen med en lille introduktion til projektet. Det er ikke denne introduktion, som der er altafgørende for projektets succes, men det giver dig mulighed for at fortælle lidt omkring, hvorfor I starter projektet. Du kan her bruge meget af det, du skrev i din idébeskrivelse.
Det skal bare være en overordnet beskrivelse af projektet, og bruges mest af alt som en ramme for, hvordan kravene skal læses. Så den skal bare startes “Vi vil i [virksomhed] gerne have opdateret vores nuværende webshop, fordi…” og afsluttes med “… Nedenfor kan du læse vores krav til projektet, samt hvilke målsætninger vi har sat for projektet.”
Det er en god ide at komme ind på følgende:
- Hvor mange bruger den nuværende løsning? (både internt og eksternt i virksomheden)
- Eller hvor mange brugere forventer I en ny løsning ville have?
- Hvem er målgruppen? Jobtitel, alder, køn, privat/erhverv og så videre.
- Hvad synes I er godt ved den nuværende løsning?
- Hvad er det I gerne vil lave om i dette projekt?
Huske også at tilføje kontaktinformationer, enten her i slutningen af introduktionen, eller i slutningen af dokumentet. Det er ikke så afgørende hvor de er, så længe de er let tilgængelige.
Funktionelle krav – Hvad skal systemet kunne
Du skal lave en liste med de funktionelle krav, som du ønsker, at systemet skal kunne udføre.
Et eksempel for en ny webshop kunne være:
- Webshoppen skal indeholde alle produktinformationerne, vi har på produkterne (Se vedhæftet produktdatablad).
- Webshoppen skal hente lagerstatus, pris og SKU nummer fra ERP-systemet
- Kunden skal kunne genbestille ordre (meget almindeligt i B2B webshops)
- Kunden skal kunne se Track&Trace på webshoppen
- Kunden skal kunne betale med Dankort, Mastercard og Visa-kort
- Kunden skal kunne betale på kredit, hvis han er sat op til det i ERP‐systemet
Det vigtige er, at du beskriver, hvad du ønsker af systemet, og ikke hvordan leverandøren skal løse opgaven. Så du skal ikke helt ned at definere, at “Genbestillings knappen skal være grøn og placeres i øverste højre hjørne”, det er leverandørens ansvar at komme med et udlæg til designet, så kan du gå ned i dybden omkring det.
Ikke-funktionelle krav – Forskellige begrænsninger
De ikke-funktionelle krav er egentlig ganske simple, det er en beskrivelse af nogle forskellige begrænsninger, vi sætter for løsningen og den måde, den kan bygges på.
Formålet med de ikke-funktionelle krav er ganske simpelt at begrænse løsningsmulighederne. For i princippet er der jo mange måder, at leverandøren kan løse dine funktionelle krav på.
Start med at dele de ikke-funktionelle krav op i to grupper, krav til løsningen og krav til projektet.
Krav til løsningen
Dine krav til løsningen handler om, hvordan systemet skal performe, når det først er leveret.
Dine krav til en webshop uden nogen som helst begrænsninger, kunne sagtens resultere i en løsning, der ikke lever op til dine forventninger. Derfor skal du tilføre en række krav til løsningen, der skal opfyldes for at projektet er vurderet til at have været en succes.
De handler tit omkring performance, kapacitet, skalerbarhed, tilgængelighed osv.
Eksempler på krav til løsningen kunne være følgende:
- Webshoppen skal kunne have mere end 4.500 produkter uden problemer
- Webshoppen skal være hurtig – helst under 1 sek. for at hente siden
- Webshoppen skal være teknisk sat korrekt op i forhold til SEO optimering
- Webshoppen skal hente nye priser fra ERP-system hver dag
- Webshoppen skal kunne bruges af alle moderne browsere
Det vigtige er, at du beskriver, hvad du ønsker af systemet, og ikke hvordan systemet skal løse opgaven. Så du skal helt ned at definere, at “Produktets navn skal være en H1 overskrift”, det er leverandørens ansvar, at SEO optimerer webshoppen, det er ikke dit.
Denne liste kan blive meget lang, så udvælg bare de vigtigste. Men de er vigtige at få med, for jeg har tidligere oplevet, at en leverandør lavede en webshop, som tog over 4,5 sekunder at hente pr. Sidevisning.
Jeg havde bare regnet med, at hastighedsoptimering automatisk var en del af projektet, fordi det er så vigtigt i et webshop projekt. Men de holdte på, at det ikke var defineret i kravspecifikationen. Så pas på med at regne med, at noget automatisk er en del af projektet. Det skal altså dokumenteres i kravspecifikationens funktionelle eller ikke-funktionelle krav.
Et vigtigt punkt også at notere under ikke-funktionelle krav ville være, hvis I har krav til eksempelvis hvilke værktøjer som leverandøren skal bruge. Det kunne eksempelvis være, det skulle ligge på en Microsoft Server, som I allerede har, eller den skal baseres på en bestemt teknologi, eksempelvis webshoppen skal baseres på Umbraco eller lignende.
Det vigtige her er, at disse betingelser begrænser udviklerens løsningsmuligheder. Men stadig med udgangspunkt i virksomhedens behov og ønsker. Og uden at anvise, hvordan udvikleren skal løse sin opgave. Det vil bringe dig tættere på en løsning, der leverer det, du havde forestillet dig.
Krav til projektet
Ud over krav til løsningen er det også en god idé at inkludere nogle krav for selve projektet.
Eksempler på krav til projektet kunne være følgende:
- Ressourcer – Hvor mange personer stiller I til rådighed i projektet? Kan leverandøren bruge de nuværende tekster og billeder til en ny webshop? Har I en designguide, som I kan give til leverandøren?
- Budget – Skriv gerne budgettet for projektet. Nogle vælger at undlade dette, og det er også fint, så skal du nok bare forvente at du skal bruge tid på nogle leverandører som nok ender med at være for dyre.
- Tid – Skriv hvornår skal løsningen være færdig. Du kan også lige notere, om det er en ønsket deadline eller en fast deadline. Altså om den kan skubbes, hvis der sker noget undervejs, eller om det absolut skal være den dag senest. Har du forskellige faser af projektet, hver med deres deadlines, så kan det give mening at lave et Gantt diagram, der viser dette.
- Kvalitet – Skriv lidt om, hvad I har af forventninger til kvaliteten af leverancen. Hvis du kan tolerere en smule fejl efter lanceringen af projektet, så kan I spare en del penge på test af løsningen inden lanceringen. Du kan i stedet overveje at stille til krav, at du ønsker en 14 dage periode efter projektlanceringen hvor alle fejl rettes uden betaling som en del af projektet.
- IP rettigheder – Det er også en god idé lige at nævne dit syn på IP rettighederne efter projektets afslutning. Personligt mener jeg altid kunden skal have 100% IP rettigheder over projektets slutprodukt, men har set projekter hvor leverandøren beholder IP rettighederne for projektets slutprodukt.
Projektets målsætninger
Hvis du har læst flere af mine indlæg, så vil du opdage, at jeg tit nævner vigtigheden af projektets målsætninger. Og det er der en god grund til.
Leverandøren kan ikke automatisk regne ud, hvad det er i projektet, som du mener, er det vigtigste, så det skal du fortælle dem. Derfor skal du inkludere projektets formål og projektet mål. Har du ikke allerede lavet dette dokument, så skynd dig at lave det med det samme, du kan se hvordan her.
Dette vil fortælle leverandøren, hvad det er som du mener, er det vigtigste, er det brugervenlighed? Er det meromsætning? Er det lavere omkostninger? Eller hvad er hele formålet med, at I vil starte dette projekt?
Og hvordan vil I efterfølgende måle, om projektet var en succes? Hvad er de konkrete mål, som I ønsker at nå?
Hvis leverandøren ikke kender til disse mål, så kan det være, de ender med at lave noget, som ikke understøtter målene, hvilket ville gøre at hele projektet, ses som en fiasko, selvom leverandøren leverede alt i kravspecifikationen.
Eksempler på dårlige krav
Jeg har allerede nævnt, at dine krav helst ikke må være for specifikke, men du skal også passe på at de ikke bliver for uklare.
Eksempler på uklare krav kunne være:
– Webshoppen skal være brugervenlig.
– Webshoppen skal give vores kunder en god User Experience (UX)
Disse krav kan se fornuftige ud ved første øjekast, men hvad betyder ”brugervenlig”, og hvordan måler man niveauet af UX? Begge disse ”krav” optræder i ca. 60% af de udkast til kravspecifikationer, som jeg har set til webshops. Du skal derfor finde en balancegang imellem for uklare og for specifikke krav. Det kan nogle gange være en svær balance, og det er også derfor, jeg ville råde dig til at få en erfaren projektleder til at læse den igennem, inden du begynder at bruge kravspecifikationen.
Prioritering af krav
Når du så har samlet listen af krav og defineret dem nærmere, skal de dernæst prioriteres. Deadlines, ressourcer og andre omstændigheder gør, at du måske ikke kan få alt, hvad du ønsker i den første fase af projektet.
Hvis du ikke foretager en prioritering af kravene, så bliver denne prioritering afgjort af tilfældige omstændigheder, eller af udviklerne undervejs i projektet. Så du kan ikke være sikker på, at de krav du mener er de vigtigst, bliver prioriteret højest.
Hvordan kan man prioritere krav?
Du prioriterer de enkelte krav efter fire kriterier. Princippet kaldes for MoSCoW metoden.
Her er der en kort forklaring af MoSCoW metoden:
– Must have: Krav der skal opfyldes
– Should have: Krav der bør opfyldes, hvis det kan lade sig gøre
– Could have: Krav der kan opfyldes, hvis der er mulighed for det
– Won’t have: Krav der stilles til projektet, men som kan vente til en senere fase af projektet
Ved at lave denne prioritering gør du det klart, hvad der er vigtigt for dig og din virksomhed. Og du viser samtidig leverandøren, hvad dine prioriteter er.
Sådan kommer du i gang (download skabelon)
Alle arbejder selvfølgelig forskelligt, men det er min erfaring, at man gerne skal gå i gang med at lave en kravspecifikation så hurtigt som muligt. Grunden til det er, at jeg relativt sjældent har set nogen skrive en god kravspecifikation i første forsøg.
Der er altid nogle ting, man kommer på en dag eller to efter, og det er en god ide, at dele den med andre, inden man sætter sig, for at den er færdig.
Jeg kigger gerne på en kravspecifikation 4-5 gange med nogle dage imellem, for at sikre mig, at jeg har fået det hele med. Så for mig tager det typisk 2-3 uger for at lave en god kravspecifikation.
Jeg kunne sagtens lave en på første forsøg, men så ved jeg også, at jeg tit glemmer en ting eller to, som man så opdager undervejs i projektet istedet, og hvor det så potentielt kan lede til en meromkostning.
Herunder kan du downloade min skabelon til en kravspecifikation, så kan du bruge den til dit næste projekt. Eller beskrivelserne står i kravspecifikationen, så du kan følge mine råd direkte i dokumentet.
Opsummering
En gennemtænkt kravspecifikation er altså helt afgørende for, at dit projekt kommer sikkert i mål. Den gode nyhed er, at det ikke kræver specielle tekniske kompetencer at lave en kvalificeret kravspecifikation.
Den behøver heller ikke at være en tyk og detaljeret telefonbog, der beskriver alle omstændigheder omkring projektet. Faktisk er arbejdet lige til at gå til. Hvis man går systematisk til værks.
Den gode kravspecifikation består overordnet af fire dele:
- Introduktion til projektet
- Funktionelle krav
- Ikke-funktionelle krav
- Projektets målsætninger
Det er vigtigt, at de enkelte krav prioriteres. Og husk; kravspecifikationen skal ikke fortælle, hvordan leverandøren skal nå frem til slutproduktet, men derimod, hvilke behov som den skal understøtte.
