Sluta peka finger – använd en RACI-matris (med Suze Haworth)

Läs utskriften:

Vi testar att skriva ut våra poddavsnitt med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte har rätt 100 procent av gångerna.

Ben Aston:

En av de knepigaste sakerna med att leda projekt är kanske att vi måste arbeta med … ja, människor, och människor är otroligt varierande. Vi är inkonsekventa, egocentriska, opålitliga och oerhört ombytliga – och jag pratar bara om mig själv. Därför undrar jag om dina projekt liknar mina. När de går fel, vilket naturligtvis också händer förr eller senare, kan det snabbt förvandlas till ett hemskt pekande med fingrarna, där alla verkar anklaga alla andra för att inte göra sitt jobb ordentligt. Så hur ska vi egentligen kunna hantera ett projekt när vi måste hantera allt detta? Det får du veta i dag.

Tack för att du lyssnar. Jag heter Ben Aston och det här är Digital Project Manager-podden. Den här podden presenteras av Clarizen, ledande inom programvara för företagsövergripande projekt- och portföljhantering. Besök Clarizen.com för att läsa mer. I dag har jag sällskap av Suze Haworth, en av våra egna DPM-experter på Digital Project Manager. Suze, tack så mycket för att du är med i programmet.

Suze Haworth:

Tack Ben, tack för att jag fick komma.

Ben Aston:

Låt mig presentera Suze ordentligt, eftersom hon är ny här. Det här är, tror jag, vår första podd tillsammans.

Suze Haworth:

Ja.

Ben Aston:

Suze är frilansande digital projektledare i London och har en mängd erfarenhet. Hon har arbetat i branschen i över 13 år, började inom kundansvar precis som jag och gick sedan över till projektledning. Men i stället för att bara läsa upp din biografi, Suze, kan du berätta lite om vilka typer av projekt du arbetar med just nu?

Suze Haworth:

Just nu? Förra året gick jag faktiskt över till frilans, så jag har, som du sa, arbetat i flera år på olika byråer, men förra året började jag frilansa. För tillfället har jag en roll på en byrå i London och arbetar med två stora projekt. Det ena är ett designsystem för ett ganska stort detaljhandelsvarumärke och det andra är att jag leder ett arbetsprogram för ett annat detaljhandelsvarumärke. Det är mycket intressanta projekt.

Ben Aston:

Är detaljhandel ditt område?

Suze Haworth:

Det är faktiskt ganska blandat. Jag har mycket detaljhandel, en medieorganisation, välgörenhetsorganisationer och lite av varje, men just nu ligger tyngdpunkten på detaljhandel i de kunduppdrag jag nämnde, så det kan man väl säga.

Ben Aston:

Okej. I din roll som frilansare, vad tycker du är svårast? Vilka är några av de större utmaningarna du hanterar just nu?

Suze Haworth:

Jag tror att den största utmaningen, och det gäller nog alltid projektledare, är att man har så många olika saker att hantera och göra som man ansvarar för. Man ska inte bara leverera ett projekt framgångsrikt, utan också hantera tidsplan, budget, teamets resultat, själva teammedlemmarna – alltså en hel del teamproblem – och dessutom kontakten med kunden. Det är verkligen svårt att få ihop så många saker på den tid man har. Ofta känns det som en ständig kamp att få in allt under en enda dag.

Ben Aston:

Ja. Tycker du att det är svårare eftersom du tidigare varit fast anställd och nu arbetar som konsult? Märker du någon skillnad?

Suze Haworth:

Ja, det är lite annorlunda eftersom du som frilansare har större ansvar för din egen tid, bland annat när det gäller hur du tar betalt av byrån. Man kan inte hamna i en situation där man känner att man inte kan säga nej. Jag har lärt mig att bli bättre på att förstå att om man har för mycket på sitt bord kan man bara göra en viss mängd, och man måste göra det ordentligt. Därför är det bättre att sätta gränser än att säga ja till allting.

Ben Aston:

När jag var konsult upplevde jag samma sak. Det finns faktiskt något väldigt trevligt med att vara konsult, eftersom man inte försöker få befordran. Man vill naturligtvis behålla kontraktet och fortsätta arbeta med dem, men man försöker inte imponera på människor på samma sätt som när man är fast anställd och tänker: ”Jag borde nog säga ja, annars ser det illa ut.”

Suze Haworth:

Ja, precis. Man vill fortfarande göra ett gott intryck. Branschen är liten, så alla känner alla, men det är skönt att kunna ta ett steg tillbaka i slutet av dagen och säga: ”Okej, mina arbetstimmar är slut.” Det går ibland lite lättare än när man är fast anställd.

Ben Aston:

Hur många olika ställen har du arbetat på sedan du började ta konsultuppdrag?

Suze Haworth:

Bara ett par än så länge, eftersom jag inte har gjort det särskilt länge. Det har varit bra på sätt och vis, eftersom jag har hunnit vara ett tag på den byrå där jag arbetar nu och känner människorna ganska väl. Jag känner också kunderna bättre, eftersom man får mer tid i projekten och kunduppdragen.

Ben Aston:

Arbetar du på plats eller huvudsakligen på distans?

Suze Haworth:

På plats. Jag brukar verkligen framhålla fördelarna med distansarbete när jag pratar med människor om det, eftersom jag tycker att det är viktigt och kan göra många mer produktiva. Men många byråer, särskilt i London där jag har arbetat mycket, arbetar huvudsakligen på plats.

Ben Aston:

Intressant. Jag vet att du, utöver frilans- och konsultarbetet, också skriver. Du har skrivit för DPM, och du ska även delta i DPM Summit senare i år. Kan du berätta lite om det?

Suze Haworth:

Ja. Jag ser verkligen fram emot det. Förra året talade jag på DPM Summit i Las Vegas och i år leder jag en workshop. Det är ett intressant ämne eftersom vi projektledare ofta är ganska besatta av metoder, särskilt agila metoder. I workshopen pratar jag om att kombinera arbetssätt, särskilt det som kallas Dual-Track och som jag har infört i ett arbetsprogram jag arbetar med nu. Det använder vissa delar av agilt arbete men kombinerar dem på ett annat sätt. Jag pratar om det, Kanban, Lean och hur man kan kombinera olika arbetssätt i sina projekt – inte nödvändigtvis arbeta med ren agil metod eller en enda metod, utan anpassa de metoder man redan har.

Ben Aston:

Ja, det är bra. Och det är så viktigt. Suze är en av våra DPM-experter och medverkar i vår kurs i digital projektledning. Om du inte vet vad jag menar—

Suze Haworth:

Ja, det gör jag.

Ben Aston:

Det är faktiskt nu på fredag och det blir Suz­es första medverkan. En sak vi pratar om på kursen är att inte fastna för mycket i namnet på metoden eller vad—

Suze Haworth:

Ja, precis.

Ben Aston:

I slutändan handlar allt om att leverera arbete och hitta bättre sätt att göra det på – på ett sätt som fungerar för teamet, projektet och kunden. Man måste vara pragmatisk snarare än dogmatisk och säga: ”Det här är inte Scrum, så vi måste göra Scrum.” Det spelar egentligen ingen större roll. Vi måste leverera projektet.

Suze Haworth:

Exakt. Jag har alltid tyckt att man kan bli så fokuserad på processen och på att passa in i en viss process. I stället måste man titta på projektet eller produkten man skapar och fråga: ”Vad fungerar för det här?” Det skiljer sig mellan olika projekt, så man måste anpassa eller kombinera.

Ben Aston:

Jag håller helt med. Vissa kan vara ganska nedlåtande mot att späda ut metodernas renhet, men jag har aldrig upplevt att de fungerar på det sättet.

Suze Haworth:

Nej, precis. Det finns mycket prestige kring favoritmetoder, men jag är ganska öppen för att använda dem. I de flesta fall, särskilt på byråer, måste man kombinera processer i stället för att använda något helt rent, helt enkelt på grund av de situationer man befinner sig i.

Ben Aston:

Bortsett från konferenser, artiklar och arbete – har du satt upp några mål för året som du arbetar mot eller försöker bli bättre på?

Suze Haworth:

Det var en svår fråga. Just nu är jag så fokuserad på nuet, på det jag gör i och utanför arbetet, att det ibland är svårt att tänka på den långsiktiga framtiden. Men en viktig sak jag nämnde tidigare är att lära mig säga nej. Jag försöker bli mycket bättre på att delegera och faktiskt släppa lite av ansvaret, vilket alltid har varit svårt för mig. Som projektledare blir man lätt lite av en kontrollfreak, så det är definitivt ett långsiktigt mål.

Ben Aston:

Ja, delegering är svårt. Särskilt som konsult kan man vara osäker på om personen man delegerar till kommer att ta en på allvar eftersom man bara är konsult, och man har kanske ingen tidigare erfarenhet av att arbeta med personen. Man vet inte om personen faktiskt kan göra det man försöker delegera.

Suze Haworth:

Precis.

Ben Aston:

Låt oss prata lite om verktyg. När man arbetar på olika platser får man ju inblick i olika lösningar. Har du hittat något på sistone som gör livet enklare, något som du tycker att alla borde känna till?

Suze Haworth:

Ärligt talat blir man som frilansare, och även i fasta roller, exponerad för så många olika verktyg och måste vanligtvis använda det företaget använder. Jag skulle därför aldrig säga att jag har hittat det perfekta verktyget som gör allt jag vill eller saknar svårigheter som måste hanteras. Jag har använt många resursplaneringsverktyg och tidrapporteringssystem. Varje verktyg har haft bra och dåliga sidor. Det enda verktyg jag verkligen älskar, om man kan kalla det ett verktyg, är Google Kalkylark. Det kan användas till nästan allt.

Ben Aston:

Har du provat Monday.com?

Suze Haworth:

Nej, det har jag faktiskt inte.

Ben Aston:

För någon som gillar att hantera saker i kalkylark tror jag att Monday kanske skulle—

Suze Haworth:

Vilken nörd.

Ben Aston:

Det fina med kalkylark är att de är gratis, eller åtminstone Google Kalkylark är det, och att de är mycket flexibla. Men Monday lägger till automatisering samt bättre filtrering och kontroll. Du borde prova det. Det är som kalkylark på steroider.

Suze Haworth:

Då ska jag definitivt titta på det. Det låter helt rätt för mig.

Ben Aston:

Bra. Låt oss prata om din artikel. Det var ett tag sedan du skrev den, men om vi går tillbaka till utgångspunkten: hur hanterar vi människor som antingen verkar vilja ta över ett projekt eller inte ta något ansvar alls? Suz­es artikel handlar om hur vi använder en RACI-matris för att göra det. För dem som inte har läst artikeln, berätta om RACI-matriser. Vad betyder ”RACI”?

Suze Haworth:

RACI står för ansvarig, ytterst ansvarig, rådfrågad och informerad. Det är helt enkelt en matris där man kopplar projektets uppgifter eller leveranser till projektets intressenter eller interna teammedlemmar och tilldelar en av de fyra bokstäverna till varje roll och uppgift. R står för den som utför uppgiften, A för den som ytterst ansvarar och godkänner den, C för dem som ska rådfrågas och I för dem som ska informeras. Det är ett bra sätt att fördela ansvar för varje uppgift eller leverans, se till att inte för många personer deltar i varje beslut och skapa tydlighet kring vem som arbetar med vad under projektets gång.

Ben Aston:

Det som ofta skapar mest förvirring verkar inte vara vem som ska informeras eller rådfrågas. De delarna brukar vara ganska raka. Förvirringen gäller snarare skillnaden mellan att vara ansvarig för att göra något och att vara ytterst ansvarig. Hur hanterar du det och personer som vill vara ansvariga men inte ytterst ansvariga?

Suze Haworth:

Det här är faktiskt den svåraste delen av RACI, och något jag själv har haft problem med. Därför kan en RACI-matris bli omfattande att skapa. Man lägger mycket tid på att fundera över vad rollerna faktiskt betyder och vad de innebär för personen som får dem. Enkelt uttryckt är den ansvariga personen den som faktiskt utför uppgiften, skapar leveransen eller driver arbetet framåt. Den ytterst ansvariga är personen som godkänner och övervakar uppgiften, men inte nödvändigtvis utför den.
En annan utmaning är att man lätt tilldelar projektledaren eller produktägaren det yttersta ansvaret för allt, eftersom de leder projektet och är central kontaktpunkt. Men man behöver skilja projektledaren från ansvaret för varje enskild sak och fundera på vem som är mest senior inom just den uppgiften eller leveransen. Om det gäller design, är det då en kreativ chef? På den egna sidan eller kundens sida? Försök att inte lägga det yttersta ansvaret på projektledaren eller produktägaren hela tiden.

Ben Aston:

Det är viktigt. Ett vanligt misstag är att göra alla ansvariga och ytterst ansvariga – inte bara projektledaren. Alla ska vara ansvariga för detta, tänker man. Vi behöver ett kollektivt ansvar.

Suze Haworth:

Ja, exakt. Det är svårt eftersom man tänker att flera teammedlemmar kommer att göra uppgiften och därför är alla ansvariga. Men man måste förenkla och begränsa antalet roller. Om man sprider rollerna över alla kommer man inte att uppnå det som RACI är bäst på: att tydligt definiera en eller några få kontakt- eller godkännandepunkter. Det är det RACI-matrisen ska göra.

Ben Aston:

Att avgöra vem som faktiskt gör arbetet är vanligtvis inte det svåra. En knepigare del är skillnaden mellan rådfrågad och informerad, och framför allt mellan ytterst ansvarig och rådfrågad. Vi vill normalt ha en person som har sista ordet om huruvida resultatet håller måttet. Det är en form av kvalitetskontroll. Sedan kan fler personer rådfrågas och ännu fler informeras. De informerade får helt enkelt veta vad vi har kommit fram till.
De rådfrågade kan däremot få projektet att spåra ur, eftersom de har en röst och får lämna synpunkter. De är inte nödvändigtvis ansvariga för att leverera i tid eller på rätt sätt, men de har inflytande. Därför uppstår den verkliga känsligheten mellan den ytterst ansvariga och de rådfrågade – i maktspelet mellan personer som vill hävda sin position, auktoritet eller åsikt utan att ha det yttersta ansvaret för leveransen.

Suze Haworth:

Ja, och en annan spänning är att den som får rollen som rådfrågad nästan förväntar sig att få komma till tals. Därför är det yttersta ansvaret så viktigt. Den personen måste äga leveransen eller uppgiften och se till att de rådfrågade bidrar utan att, som du säger, spåra ur projektet med långa återkopplingsrundor.

Ben Aston:

Var ärlig: använder du en RACI-matris i varje projekt? Hur håller du den lättviktig? Om man går ner på för många detaljer kan det ta evigheter att skapa den. Hur undviker man att den bara blir ännu en arbetsfördelningsstruktur med namn bredvid?

Suze Haworth:

Jag vill verkligen undvika att skapa dokumentation bara för sakens skull. Jag vill inte föreslå dokumentation som inte kommer att användas. Men om du skapar en RACI måste den vara användbar och faktiskt användas. Skapa den inte i början av projektet och låt den sedan dö på någon server. Hänvisa till den när ni arbetar med leveranserna. I slutet av projektet bör ni också gå igenom hur den användes: fungerade den och var den korrekt? Dokumentet blir användbart först när man använder det.

Ben Aston:

Beskriv en situation där du tar fram RACI-matrisen. Använder du den på statusmöten när ni planerar den kommande veckan och säger att vissa personer är ytterst ansvariga, andra ansvariga och ytterligare andra ska rådfrågas eller informeras? Hur använder du den vecka för vecka?

Suze Haworth:

Jag använder den inte nödvändigtvis under statusmöten. Den visar förstås vem du ska vända dig till, involvera, dela leveranser med eller tilldela uppgifter. Men främst är den ett internt uppslagsverk. Jag kan kontrollera vem som är involverad i en leverans, vem som ska få den för återkoppling och vem som ska informeras när den är klar.
Den kan också användas när saker inte går enligt planen. Om alla på kundsidan plötsligt vill vara involverade, trots att någon bara har fått rollen som rådfrågad, kan man prata med kundens huvudkontakt och säga: ”Det här skapade vi tillsammans i början. Vi behöver följa det för att effektivisera arbetet, hålla kommunikationen tydlig och undvika onödig tid och administration.”

Ben Aston:

Har du en gemensam RACI-matris som omfattar både byrån och kunden, eller två separata?

Suze Haworth:

Jag har använt olika arbetssätt. Det beror verkligen på projektet. Om det finns två stora team, ett på din sida och ett på kundens, kan det vara bättre att skapa två matriser. På senare tid har jag ofta skapat en särskild matris för kunden när många intressenter varit involverade, eftersom det viktiga då är att veta vilka personer på kundens sida som ska involveras och när. Vårt team har varit mer sammanhållet, så vi har ibland stått som en gemensam enhet på vår sida. Det beror alltså på projektet.
Det viktigaste är att göra RACI-matrisen användbar. Alla projekt behöver inte en. Om projektet är litet och resurssnålt, med några få teammedlemmar och en kund, är det förmodligen meningslöst. Bedöm behovet och vad du vill uppnå. Om det finns många interna eller externa intressenter och du behöver hantera dem och tydliggöra förväntningarna, då skapar du en.

Ben Aston:

RACI är bra på att förhindra att saker faller mellan stolarna. Ingen kan i slutet av projektet säga: ”Varför fick jag inte möjlighet att lämna återkoppling?” eller ”Jag trodde att designteamet skulle kommentera trådskisserna.”
Men vi behöver inte alltid ge kunden full insyn i allt som händer internt – vem som gör vad, vem som är ansvarig, vem som har det yttersta ansvaret och vem som rådfrågas. Det kan skapa förvirring. Däremot är det mycket användbart på kundsidan, särskilt när teamet är stort eller organisationen är politisk och har svårt att fatta beslut. Då kan man identifiera den person som har det yttersta ansvaret och fråga: ”Är det fortfarande du? Om inte måste vi ändra processen, förlänga tidsplanen och kanske även öka budgeten.”

Suze Haworth:

Därför är det så viktigt att involvera kunden eller det interna teamet när man tilldelar roller. Låt dem vara med och skapa matrisen. Det är lätt att skapa den isolerat och bara skicka den till någon för godkännande. Då kanske personen inte tänker igenom den utan bara säger: ”Det ser bra ut, vi fortsätter.” Om de däremot deltar i besluten från början blir rollerna tydliga och arbetet kan gå framåt på ett bättre sätt.

Ben Aston:

När slutar RACI att fungera? När faller den samman? Ni har skapat dokumentationen, försökt komma överens om allt – vilka varningssignaler visar att den inte fungerar?

Suze Haworth:

För det första om du inte får allas godkännande från början. Om du skapar den isolerat och tilldelar en teammedlem ansvar utan att personen känner till eller accepterar det, eller om du antar vad kunden vill, kommer den inte att fungera. Alla måste ställa sig bakom den, särskilt de personer som får ansvar eller yttersta ansvar.
Det är också avgörande att använda den. Hänvisa till den under projektets gång, kontrollera att arbetet går enligt plan och att rätt personer är involverade. Om den bara ligger där blir den en tom kryssruta i början av projektet. Efteråt bör ni gå igenom om den var användbar och korrekt, så att ni kan förbättra framtida RACI-matriser.

Ben Aston:

Men när den faktiskt faller samman – när pekandet med fingrarna börjar, saker faller mellan stolarna och människor blir upprörda – hur stramar du upp situationen igen?

Suze Haworth:

Det kan vara frestande att hålla upp matrisen och säga: ”Du gick med på det här från början.” Men den ska inte användas som ett ”titta vad du lovade”-verktyg. Säg i stället: ”Det här var det vi enades om. Vi försökte skapa effektivitet och tydliga förväntningar, men vissa följer det inte och det tillför tid och arbete till projektet.”
Prata med personerna som orsakar problemen eller med dem som arbetar med dem. Gå igenom konsekvenserna för projektet och förklara varför ni skapade matrisen och varför vissa personer fick vissa roller. De behöver förstå vad som kan hända om utvecklingen fortsätter.

Ben Aston:

Att påminna människor om varför rollerna definierades på ett visst sätt är ett bra sätt att få dem tillbaka inom sina ansvarsområden. Då kan någon inse: ”Det finns en anledning till att jag inte har det yttersta ansvaret – jag har inte kompetensen att bedöma detta.”

Suze Haworth:

Det går tillbaka till att göra dokumentet användbart. Det måste finnas en anledning, till exempel att skapa effektivitet inom begränsad tid eller budget. Om du skapar RACI-matrisen utan ett tydligt syfte är den i praktiken värdelös. Se till att du kan se konkreta fördelar med att använda den och att den faktiskt skapar effektivitet.

Ben Aston:

Om du vill ladda ner en RACI-mall har Suze skapat en åt oss, tillsammans med ett användbart exempel med ”Sagan om ringen” som visar hur detta kan tillämpas i ett projekt. När vi skickade ut ett mejl om artikeln och exemplet med ”Sagan om ringen” svarade någon: ”Jag kan inte förstå att ni slösar allas tid på det här.” De skrev ett väldigt spydigt mejl. Jag tror inte att jag svarade, men blev förvånad. Dagen efter skrev de: ”Jag läste faktiskt artikeln. Den var bra. Jag gillar bara inte ’Sagan om ringen’.”

Suze Haworth:

Jag vet. Det är ganska specifikt. När jag skapade matrisen för ”Sagan om ringen” tänkte jag: ”Jag kommer säkert att ha fel om en del av detta.” Så i det fallet gjorde jag precis det jag säger att man inte ska göra. Men tanken var att göra ämnet konkret på ett sätt som människor kan relatera till.

Ben Aston:

Det fina var att åtminstone vissa personer skulle förstå uppdraget att få ringen. Men ja, det är naturligtvis lite polariserande. Jag tycker ändå att det blev bra. Suze, tack så mycket för att du var med. Det har varit trevligt att ha dig här.

Suze Haworth:

Tack.

Ben Aston:

Om du vill delta i samtalet kan du kommentera inlägget eller gå till resurssektionen på TheDigitalProjectManager.com och gå med i vårt Slack-team, där du hittar många intressanta diskussioner. Om du vill höra mer av Suze kan du gå till utbildningssektionen på TheDigitalProjectManager.com och anmäla dig till nästa kurs i digital projektledning, där Suze medverkar. Men tills nästa gång – tack för att du lyssnade.