Förhandling och konsten att formulera ett nej

2006-01-26 — Mikael Lundgren

En effektiv organisation har samma spelregler inom hela företaget, säger Mikael Lundgren. Det innebär bland annat att alla kan och bör använda sig av förhandling som ett verktyg i det dagliga arbetet.

I alla företag borde projekt handla om att ta välinformerade beslut, underhålla tydliga roadmaps och använda folk på rätt sätt för maximal utväxling, vare sig man väljer att arbeta lättrörligt eller ej. Men när det går undan hemfaller vi som utvecklare och projektledare ibland ändå till att blint hålla fast vid den första uppskattningen och den första planen vi gjorde när vi egentligen inte visste vilka utmaningar som låg framför oss. Varför har vi som teknisk organisation ofta så svårt att erkänna att en plan är föränderlig, och hantera den som sådan? Och varför upplever vi ibland att vi saknar argument gentemot produktägare, ledning, och alla andra som vill att vårt projekt ska gå som på räls?

För att vi är usla förhandlare.

Inte de. Inte produktägare, säljchefer, account managers och supportansvariga. De lever och andas förhandlingar, förhandlingar är deras levebröd och profession. De förhandlar dagligen i olika situationer, och är ofta välutbildade i denna yrkeskunskap som en del till och med vill se som en konstform.

Men med oss vill man ogärna förhandla, vi som tillverkar det de säljer och marknadsför.

“Vi har ju precis fått det här kontraktet påskrivet, vad menar ni med att ni inte kan leverera inom utsatt tid?"

En effektiv organisation har samma spelregler inom hela företaget. Detta innebär även att allt är potentiellt föremål för förhandling.

Låt oss för en sekund belysa hur detta fungerar i en lättrörlig organisation.

När omfånget av ett projekt definieras, är detta en förhandling mellan produktägaren och produktutvecklingen. Alla är införstådda med att den ursprungligt beräknade kostnaden är en så bra skattning som kan göras vid tillfället, och att den kommer att justeras under projektets gång (vilket bör få effekter på projektet), och att den första roadmap som tagits fram av förstudien speglar en uppfattning om projektets innehåll och längd givet så mycket information vi har vid den tidpunkten. Detta är ju inte så märkvärdigt, eftersom vi så ofta vi vill kan stämma av hur vi ligger till mot plan, eller hur?

Vid starten av varje iteration förhandlas innehållet i iterationen mellan beställare och utförare. Det kan leda till att projektets roadmap direkt eller indirekt omförhandlas!

Varje dag kan dessutom innehållet i iterationen potentiellt omförhandlas, med avseende på oförutsedda problem, tidsåtgång, och annat.

Vi som produktutvecklare behöver alltså möta beställaren med dennes språk, och på dennes villkor. Det innebär att vi betraktar varje tillfälle där vi etablerar ett projekt eller en iteration som en förhandling där vi är den drivande parten. I de flesta fall visar det sig att “dekret" från beställarsidan egentligen är ett uttryck för att man antingen inte förväntar sig en förhandling, eller inte kan få “ett vettigt besked" och att det därför är lika bra att skärpa tonen och få alla närvarande att förstå hur viktigt det är att göra just det här. (Och alla andra åtaganden som också har högsta prioritet)
 
Det är lättare att säga ja än nej, eftersom ja uppfattas som positivt, och ambitiöst, medan ett nej alltid kräver motivering - och utan konkreta siffror faller ofta ett “nej på magkänsla" platt, eller blir beroende av den individuella pondusen hos nej-sägaren. I själva verket är det ofta ja-sägandet som dödar eller skadar svenska företag, eftersom viktig information till strategiska beslut göms undan, och återkommer som obehagliga överraskningar strax innan leverans.

Varför hamnar vi som produktutvecklare då i denna situation om och om igen? Låt mig upprepa på nytt.

Därför att vi är usla förhandlare.

Vi tränas sällan i förhandlingsteknik under vare sig teknisk utbildning eller vårt yrkesliv, och har därför redan från början ett underläge. För att tillföra företaget ett mervärde måste vi alltså bli bättre på detta.

Vilka är då våra förhandlingstekniker?

Var tydlig - påminn gärna beställaren om att ni arbetar i ett lättrörligt företag, och att det finns en stor risk (möjlighet, som jag gärna vill se det) att förhandla om innehållet under resans gång. Detta är kontinuerlig strategisk information, precis lika viktig som den kontinuerliga integrationen.

Arbeta scenariobaserat - kom till förhandlingen med lättfattliga alternativ, presentera de tekniska möjligheterna för beställaren ur kundperspektiv och ge beställaren möjlighet att välja från ett bra underlag. Dokumentera beslutet (på ett lättrörligt sätt - på en Wiki)

Svälj stoltheten - haka inte upp dig på det tekniskt bästa eller det roligaste alternativet. Många beställare förväntar sig just detta beteende, och ibland hör man teorier om att “hålla teknikerna kort" och liknande. Överraska genom att våga fråga om en tekniskt simplare lösning - om VD har lovat ut en finess till några kunder på ett visst datum har sällan innehållet kvantifierats i detalj - använd utrymmet för att förhandla fram ett rimligt omfång. Var kreativ och snål - och våga fråga!

Var inte omöjlig - argumentera inte känslomässigt, utan med siffror och scenarios. Låt dig inte dras in i en teknisk diskussion, du behöver inte motivera ditt projekts beräkningar, men du ska kunna förklara dem. Tänk på att i en förhandling kommer båda parter att få göra eftergifter.

Varför inte skicka dina utvecklare på en förhandlingskurs? Eller du kanske själv ska passa på att gå en sådan? I moderna projekt är även framställningsteknik viktigt, eftersom det i sådana förhandlingar jag beskriver här finns ett behov för tekniker att framställa lösningsalternativ på begripligt sätt.

Det finns mycket mer kunskap att hämta ur böcker och artiklar om förhandlingsteknik än vad jag kan gå igenom här. Men det viktiga första steget är att börja förhandla.
Som en naturlig del av arbetet.

Varje dag.

Det tjänar du på.


Dela |

Kommentera artikeln

Din kommentar

Hantering: Publiceras inte. Vi delar aldrig din e-post med tredje part och vi skickar aldrig oönskad reklam.

Karin Edsröm, VD på Citerus

Vi söker konsulter!

Kontakta VD Karin Edström om du brinner för mjukvaruutveckling och är duktig på det du gör!  Bli en av oss →

 

 

Inspiration via e-post

  Artiklar om framgångsrik mjukvaruutveckling
  Information om nya kurser och seminarier

Hantering: Vi delar aldrig din e-post med tredje part och vi skickar aldrig oönskad reklam.

 

 

 

Om Citerus

Citerus hjälper företag att lyckas med sin mjukvaruutveckling. Vi erbjuder verksamhetsutveckling, kurser och träning samt systemutveckling och kan dessutom avlasta våra kunder genom ta oss an både delprojekt och hela projektåtaganden. Allt för att de ska kunna hålla en hög innovationstakt och skapa smarta lösningar som ökar deras konkurrenskraft. Citerus kunder har den gemensamma nämnaren att de ser mjukvaruutveckling som affärskritiskt. Läs mer →

monthly
0.5