Kravspecifikation som faktiskt fungerar: en sida räcker längre än femtio

Nästan alla vet att man bör ha ett underlag innan man begär offert. Färre vet vad som ska stå i det, och resultatet blir antingen tre rader i ett mejl eller ett fyrtiosidigt dokument som beskriver lösningen i stället för problemet.

Båda gör samma skada: offerterna blir omöjliga att jämföra.

Vad underlaget ska göra

Ett kravunderlag har tre uppgifter, och bara tre:

1. Låta olika leverantörer räkna på samma sak, så att priserna går att jämföra.
2. Göra det möjligt att säga nej till något — vilket kräver att det står vad som är viktigast.
3. Ge en gemensam definition av när projektet är klart.

Allt som inte tjänar något av de tre kan strykas.

Strukturen som fungerar

1. Vad ska förändras i verksamheten?

Ett stycke. Inte vad ni vill bygga — vad som ska vara annorlunda när det är i drift. Kunder ska kunna boka utan att ringa. Personalen ska slippa föra över ordrar för hand. Vi ska kunna ta emot betalning direkt i appen.

Det här stycket är det viktigaste i hela dokumentet, och det som oftast saknas.

2. Vem använder det, och till vad?

Lista varje användartyp och vad de behöver kunna göra. Kund: söka, boka, betala, avboka. Personal: se dagens bokningar, ändra tider. Administratör: lägga upp tjänster, se rapporter.

Antalet användartyper är den enskilt största kostnadsdrivaren i nästan alla projekt, så den här listan är också det som gör priset begripligt.

3. Vilka system finns redan?

Namnge dem, och skriv om de har API. Affärssystem, bokföring, betalningar, e-post, det gamla bokningssystemet som ska ersättas eller leva kvar. Ofullständiga uppgifter är bättre än inga: leverantören vet vilka följdfrågor som ska ställas.

4. Vad måste finnas i version ett, och vad kan vänta?

Två kolumner. Detta är den mest värdefulla halvan av dokumentet, och den som kräver mest av er, eftersom den tvingar fram en prioritering ni annars gör omedvetet och sent.

En användbar regel: om något inte behövs för att den första riktiga användaren ska kunna göra det de kom för, hör det hemma i kolumn två.

5. Vad räknas som klart?

Skriv ned vad som ska vara sant vid leverans. En riktig kund kan genomföra en bokning och betala. Personalen kan se den utan att någon skickar ett mejl. Utan detta blir slutet på projektet en förhandling.

6. Vad som är beställarens leverans

Innehåll, bilder, produktdata, åtkomst till system, beslut, granskning. Det här är den vanligaste orsaken till att projekt drar över tiden, och den syns aldrig i en tidplan förrän den redan spruckit.

De fyra vanligaste misstagen

• Att beskriva lösningen i stället för problemet. Vi behöver en app med en karta säger vad ni tror att svaret är. Kunder ska hitta närmaste ombud säger vad problemet är, och öppnar för billigare lösningar.
• Att låsa tekniska val i förväg. Om ni inte har ett verkligt skäl — ett befintligt system, en kompetens ni ska förvalta med — låt leverantören föreslå. Ett tekniskt krav utan skäl är en dold kostnad.
• Att lista funktioner utan prioritering. Fyrtio jämnstora punkter tvingar leverantören att gissa vad som är viktigast, och den gissningen hamnar i priset.
• Att skriva för mycket. Ett fyrtiosidigt dokument läses sällan i sin helhet och blir inaktuellt inom en månad. En tydlig sida läses av alla.

Hur lång tid det tar

En förmiddag för de fem första punkterna. Halvdagen ni lägger på kolumnen som kan vänta är den bäst investerade tiden i hela projektet — den gör mer för slutpriset än någon prisförhandling.

Och om ni fastnar: ta med utkastet till ett första möte. En bra leverantör hjälper till att avgränsa innan de tar betalt för något, och hur de gör det säger dessutom mycket om dem. Se så väljer du utvecklingspartner.

Vad de olika punkterna sedan gör med priset finns i vad kostar det att utveckla en app och vad kostar en hemsida. Hur arbetet läggs upp därefter beskrivs under MVP och produktutveckling.