Tidsestimat

Tjänsteförsäljning handlar oundvikligen om att göra tidsuppskattningar, både för små och stora projekt. Det är viktigt att det blir rätt eftersom det ger leveransprojektet arbetsro, men samtidigt kan det stjälpa affären om det görs på fel sätt.

En sak som är viktig att komma ihåg är att kostnaden är i de flesta fall är oväsentlig, förutsatt att kostnaden ger avkastning. Det viktigaste är att ge ett korrekt underlag för investeringskalkylen, så länge det finns en rejäl och trovärdig lönsamhet är det inte priset som avskräcker.

Den felaktiga kravspecifikationen

Förutom att hålla koll på kravspecifikation måste jag också titta framåt och bakåt. För det första; utgå alltid från att kravspecen är felaktig. Den är oprecis, innehåller icke uttalade krav och fokuserar oftast på fel detaljer. Därför måste den kompletteras med intuition, min känsla för vad det är kunden förväntar sig. Det här är ett stort problem eftersom jag oftast vet att kunden ber om mer än han frågar efter. I ärlighetens namn borde jag påpeka det men samtidigt vet jag att det inte går hand i hand med själva försäljning... Alltså får kravspecen till viss del ändå ligga till grund för mina bedömningar. Knepet är att dela upp försäljningen i faser, där fas ett utgår från kundens krav - allt som är outtalat skjuts till fas två.

Fakta

Uppskattningarna måste alltid baseras på fakta och den bästa faktan är i det här fallet historien. Med hjälp av intuition kan jag jämföra det kommande projektet med tidigare och därigenom få en realistisk bild av tidsåtgången. Det här ställer krav på att tidigare projekt är enkla att följa upp och att informationen baseras på det verkliga utfallet, det vill säga att alla timmar fakturerats på rätt konton.

Ett alternativ skulle vara att bryta ner problemet i sina beståndsdelar och höfta tider för varje enskilt moment. Det är så våra utvecklare bedriver sitt agila utvecklingsarbete vilket är bra i det sammanhanget men allt för oprecist för tidsestimat – eftersom specen det baseras på (som jag sa tidigare) är felaktig. Dessutom är det väldigt tidsödande att bryta ner projektet på det här sättet.

Målprissättning

En viktig del är att förstå värdet för kunden. Varje story eller use-case måste på något sätt betala sig. Här kan du tänka på två sätt – antingen strunta i vissa delar om de verkar olönsamma eller tänka om det finns något sätt att lösa problemet på ett enklare sätt.

När Canon ville göra skrivaren till en massprodukt utgick de från vad folk kunde tänkas betala för en skrivare istället för att titta på kostnaden att bygga en. Det gav nya innovativa lösningar och det här är en lärdom du kan ta med dig när projekt ska implementeras.

Den här posten blev visst väldigt lång, så jag fortsätter någon annan dag...