Skip to main content

Under hela min tid som utvecklare och projektledare har jag experimenterat med ett antal olika strategier för att försvara de beslut som fattats av mitt team och övertyga kunder att följa vår vision. När jag började den här resan kändes det lite som svart magi att hitta en tillförlitlig metod för detta. Jag är ambivert och den här uppgiften verkade passa bättre för en person av A-typ som är bra på att prata. Med tiden har jag insett att det helt enkelt kräver tid och noggrant övervägande.

Den metod jag använder nu ger positiva resultat. För att bespara andra besväret tänkte jag dela med mig av insikterna och upptäckterna från mina experiment kring hur man säger nej till intressenter.

Först, låt oss prata om tvivel

Kunder och intressenter vill utan undantag få alla sina förväntningar uppfyllda. De gör inte bara en betydande ekonomisk investering i koncepttestet, utan intressenternas namn står också på spel. För många intressenter är engagemanget personligt – de ser det levererade projektet som ett mått på deras prestation.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

När en kundens önskemål inte uppfylls börjar tvivlet göra sig påmint under hela ditt projekt. Och i samband med ett uppmärksammat projekt kan detta tvivel vara det första steget mot slutet på en annars välfungerande relation.

illustration av en gravsten med orden VILA I FRID till vår hälsosamma relation skrivna på den

Tvivel kan döda vilken positiv eller välfungerande relation som helst som du tidigare har byggt upp med intressenten.

Lägg märke till att jag använde ordet ”önskemål”, inte ”förväntningar”. Varför? Eftersom önskemål är subjektiva, och även om användare är subjektiva individer är siffror och användardata inte det.

Så låt oss gå vidare och utforska några olika nivåer av hur du kan säga ”nej” till din kund och få dem att ställa sig bakom teamets vision.

Experiment 1: Rakt-på-sak-argumentation

Det förmodligen mest rättframma sättet att säga nej är att … tja, helt enkelt säga nej. Jag känner många projektledare som ser sig själva som ena sidan i en konfrontativ process – försvararna av sitt projekt och sitt team samt sin organisation. Deras strategi är bokstavligen att spela hårt: säga nej och stå fast vid sin ståndpunkt.

Min erfarenhet är att resultatet oftast inte är positivt – antingen är det en vunnen strid i ett krig mellan externa intressenter och projektledaren som pågår under hela projektet, eller så är det en mobbningssituation där projektledaren pressar en kund till underkastelse och lämnar efter sig bitterhet och en känsla av besvikelse.

Jag har provat den här strategin och ärligt talat är den inte för mig. Därför provade jag en annan metod.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Experiment 2: Dogmatism

Något som fungerade bättre för mig var en mer dogmatisk metod: att använda trender och åsikterna hos tongivande opinionsbildare som ”bevis” för att teamets ståndpunkt var välgrundad. I stället för att helt enkelt avfärda kundernas idéer skulle vi lägga tid på att dela några av de texter som fanns där ute och förespråkade den metod vi rekommenderade.

Det förde oss närmare evidensbaserat beslutsfattande, men vårt ”bevis” hade ännu inte fått tillräcklig spridning för att vi skulle kunna mäta framgången. På samma sätt hade vi inte haft tid att verkligen utvärdera den nya metoden själva. Och även om det hjälpte mig att vara övertygande bidrog det inte till att öka vår kundens förståelse för sina specifika behov och utmaningar. Faktum är att det ofta höll dem utanför.

Experiment 3: Databaserat beslutsfattande

Det som till slut började fungera för oss som ett team var att flytta fokus från det subjektiva till det objektiva och mätbara. Genom att göra det kunde vi fatta välgrundade beslut som vår kund kunde se och förstå. Att fatta beslut baserat på en gemensam förståelse hjälpte oss sedan att undvika besvikelse på grund av förväntningar som inte matchade .

Men det gjorde också något annat: det byggde förtroende.

Genom att öppna diskussionen för våra kunder, gå igenom teammedlemmars framsteg med dem och ge sammanhang kring teamets resultat, öppnade vi dörren för att bygga upp vår kunds förtroende för teamet samt en gemensam förståelse av problemområdet.

På vägen mätte vi framstegen mot våra fasta begränsningar med lämpliga intervall. Vi förklarade hur justeringar av de flexibla begränsningarna och kraven kan påverka produktens funktionsuppsättning och övergripande projektkvalitet. Vi inkluderade kunden som en del av beslutsteamet och delade vår process för att avgöra vilka av deras krav som hade högst värde: krav.

Det här var visserligen lite klumpigt i början, men det ledde snabbt till en ökad känsla av kontroll över och ägarskap för projektet. Det gav dem också möjlighet att förklara för andra intressenter några av de värdefulla funktioner och egenskaper som annars kanske hade gått obemärkta förbi.

Det här är nu min föredragna metod för att avfärda alla intressentförfrågningar eller funktionsförfrågningar som inte tillför något värde. Naturligtvis fastnar kunden ibland vid något som du vet inte kommer att tillföra värde. Men om du förklarar en process för objektivt beslutsfattande blir det lättare att bygga förtroende och ofta behöver du inte säga nej; de fattar själva beslutet.

Så gör du

illustration av de 5 stegen för att fatta datadrivna beslut

Att fatta datadrivna beslut är en enkel process i fem steg.

Okej, att komma fram till datadrivet beslutsfattande i våra projekt var inte någon färdig lösning. För alla som håller på att genomföra den här övergången rekommenderar jag följande:

1. Driv en kultur av data och mätning i alla team.

Ja, det är ett påstående med mycket innehåll, men det kan börja med en enkel önskan om att varje team ska ha någon form av metodiskt tillvägagångssätt och evidensbaserade skäl för hur saker genomförs.

2. Börja i liten skala: välj ut den data du kan samla in och mät hållbarheten under ett projekt.

Dina projekt kommer inte att ha en big data-motor med maskininlärning direkt från början. Använd ett MVP-tänk för att bygga ett data­ramverk som är meningsfullt och genomförbart.

3. Utforska och dra nytta av forskningsrapporter och tillförlitliga datakällor.

Sekundära källor som forskningsrapporter, rapporter och öppna data kan komplettera områden där du inte har egna data.

4. Integrera data i varje samtal med din kund eller projektets beställare.

Du behöver också bygga en datakultur inom din kund eller projektbeställare. Ta varje tillfälle i akt att styra deras tankesätt mot datadrivna beslut i stället för subjektiva preferenser.

5. Var öppen för nya perspektiv. Testa och iterera.

Det finns ingen universallösning. Det som fungerar bra för ett projekt kanske inte fungerar alls för andra projekt. Dokumentera din process och fortsätt att testa och iterera.

Saker att se upp med

Det vore fel av mig att inte nämna att tillgång till all data inte innebär att allt kommer att gå smidigt därefter. Även om du kanske kan använda data för att förstå vad en kund verkligen behöver, jämfört med vad de säger att de vill ha, kan du möta motstånd om datan inte visar dem i ett gott ljus eller går emot deras ursprungliga vision. Du kan då oavsiktligt skapa fientlighet, eller så kan dina insatser helt enkelt ignoreras.

Det man måste ta hänsyn till när det gäller data och hur den förmedlas är den mänskliga faktorn. Ur ett psykologiskt perspektiv kräver det fortfarande takt, lyhördhet och professionalitet att dela data och driva det samtalet framåt.

illustration av ett paket som visar hur information kan paketeras med hjälp av ton, sammanhang och ordval

Det är viktigt att paketera den information du ger intressenter på rätt sätt för att bygga förtroende och upprätthålla en god relation.

En del av konsten är att paketera informationen på ett sådant sätt att den blir hörd och beaktad. Några faktorer som ingår i detta är:

  • Sammanhang: planera när och var samtalet ska äga rum. Viss data bör presenteras individuellt i förväg innan den diskuteras inför ditt team eller kundens team.
  • Ordval: öva på att använda ord som framställer datan neutralt och undvik ord som kan uppfattas som hårda eller konfrontativa. Här är några exempel på vad jag menar:
  • Saker att undvika
    • “Data säger …”
    • “Det är tydligt att …”
    • “Alla kan identifiera …”
    • “Det är uppenbart att …”
  • Saker att använda
    • “Det ser ut som att data antyder …”
    • “Baserat på användarnas preferenser under de senaste 30 dagarna … “
    • “Jag undrar hur användarna skulle kunna reagera på den här funktionen”
  • Ton: ge en stark rekommendation, men försök att erbjuda alternativ som låter dina inflytelserika intressenter och sponsorer behålla kontrollen. Se bara till att de är medvetna om konsekvenserna av sina beslut!

Vad tycker du?

För mig har det, genom att inkludera kunden som en del av teamet som fattar besluten och dela vår process för att avgöra vilka krav som har högst värde, ökat deras känsla av kontroll och ägarskap över projektet. Att dela idén om intelligensbaserad design har också bidragit till att bygga upp mina kunders förtroende för mitt team, eftersom de vet att vi arbetar metodiskt snarare än på måfå.

Men återigen är det här bara min resa, som jag kanske fortfarande befinner mig i början av. Vad tycker du? Tror du att de här tipsen skulle kunna vara användbara eller effektiva för dig? Vilka andra råd skulle du ge till digitala projektledare som försöker använda datadrivet beslutsfattande med sina team och kunder? Berätta gärna i kommentarerna!

 Här är en lista över verktyg som hjälper dig att hålla koll på allt du hanterar, så att du kan fatta bättre beslut: De 10 bästa programvarorna för projektledning på dator

Vill du förbättra dina färdigheter inom intressenthantering? Ta en titt på dessa främsta kurser i intressenthantering.