RACI 2.0: En ny och förbättrad RACI för framtiden
För några år sedan publicerade McKinsey en studie som visade att 80 % av de tillfrågade organisationerna ansåg att deras beslutsfattande var ineffektivt – det tog för lång tid och/eller de beslut som fattades var inte bra.
Nästan hälften av de tillfrågade ansåg att deras organisationer inte fattade beslut tillräckligt snabbt. Respondenterna sade att de slösade mycket av sin tid på ineffektivt beslutsfattande – nästan en tredjedel av sin tid – och att andelen ökade ju högre upp i organisationen man kom.
Vilken röra, eller hur? Särskilt när företag kapplöper för att hinna med digitaliseringen av allt.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Det är därför RACI passar perfekt just nu. I hela Project Management Institutes kunskapsbok för projektledning är det det enda projektledningsverktyget som fokuserar på beslut – vem som fattar dem och var.
Det hjälper dig också att klargöra vem som gör vilket arbete. Av dessa två skäl brukar jag kalla akronymen RACI för en Pandoras ask – ett mycket enkelt verktyg som packar upp alla möjliga intressanta frågor om auktoritet, befogenheter och ansvar.
Om du vill påminna dig om det grundläggande RACI-verktyget kan du börja här: Så skapar du ett RACI-diagram (inklusive en mall) och här: Bemästra RACI-diagram på 30 minuter (du måste vara medlem för att få tillgång till den här minikursen). Du hittar också ett utmärkt faktablad och andra resurser på min webbplats.
RACI är till för teambyggande
Eftersom jag först lärde mig RACI som konsult inom organisationsförändring tänker jag på det på ett lite annorlunda sätt. I stället för att först tänka på hur kraftfullt det är för projektledning (vilket det är), ser jag det först som ett verktyg för teambyggande.
Men vad händer med ett team när medlemmarna inte har tydliga roller? Här är några vanliga symtom:
- Arbetsbelastningen känns obalanserad, och vissa personer i teamet blir irriterade på andra eftersom de inte tar sin rättvisa del av arbetsbördan.
- Arbete dupliceras, vilket människor vanligtvis skyller på dålig kommunikation.
- Personer känner sig förolämpade om de inte rådfrågas innan planerna fastställs.
- Teamet känner att det släcker bränder i stället för att proaktivt gå framåt.
- Att stereotypisera personer från andra avdelningar eller yrkesidentiteter
Allt detta är förödande för teammoralen, och ännu värre är att problemen kan upplevas som konflikter mellan individerna i teamet. Som personlighetskonflikter. I stället handlar de flesta av dessa problem bara om något som akademiker kallar ”rollförvirring” och som kan hanteras genom att klargöra rollerna med RACI.
Hur nedslående är det inte att låta ett team arbeta med ett projekt i sex månader, bara för att någon på en högre nivå i organisationen ska lägga in sitt veto mot rekommendationen? Hur nedslående är det inte att försöka arbeta med ett problem utan tillräckligt stöd? Ett bra och grundligt RACI-samtal kan upptäcka dessa problem innan mycket av teammedlemmarnas tid har gått till spillo.
Det visar sig att team med tydliga roller har betydligt större sannolikhet att vara högpresterande team. Och vad säger man om det – högpresterande team brukar vanligtvis också ha hög moral.
Vanliga problem med den ursprungliga RACI-modellen
Eftersom McKinsey riktar sin uppmärksamhet mot beslutsfattande har de också publicerat en blogg om problemen med RACI här. Många projektledare har en hatkärlek till det här verktyget. En gång hade jag en kund som sade att hon hellre skulle dö än skapa ännu en RACI-matris med sitt team, eftersom ”det var som att se färg torka”.
Det första problemet är att R (ansvarig) och A (ytterst ansvarig) ofta blandas ihop. Hela poängen med verktyget är att eliminera rollförvirring, så det här problemet är verkligen ironiskt.
Det andra problemet är att när du har ett komplext projekt där flera personer samarbetar för att ta fram en leverans (flera R) kan rollförvirringens demon återkomma.
Det tredje problemet med RACI är att det inte innehåller några tidsfrister eller någon tidslinje. Tydliga roller är fantastiskt, men inte på bekostnad av att saker blir klara i tid.
Det fjärde problemet är att rollen C (konsulterad) ofta går till överdrift, eftersom personer i C-rollen tror att de har mer befogenhet än de faktiskt har.
Vad är RACI 2.0 och vilka fördelar har den jämfört med originalet?
Låt oss ta itu med dessa fyra problem ett i taget med en uppgraderad RACI-modell, som jag kallar RACI 2.0.
Problem ett: sammanblandningen av R och A
Med vår RACI 2.0 gör vi en mycket tydlig åtskillnad mellan dessa två roller.
- R-rollen utför arbete, vilket ofta innefattar att skapa någon form av leverans. Det kan innebära att vidta en åtgärd (som att boka en middagsreservation) eller att ge en rekommendation (”Baserat på min research rekommenderar jag att vi anlitar den här byrån, och här är de tre anledningarna.”) Vi säger att R-rollen (den ansvariga personen) är en arbetsroll. Om du inte producerar något är chansen stor att du egentligen inte har en R-roll.
- A-rollen fattar beslut. I RACI 2.0 definierar vi A som att ge tillstånd såväl som att vara ansvarig (vi tycker att ”ge tillstånd” är tydligare). Oavsett vad du kallar den ska det vara tydligt att detta är den ansvariga personen med befogenhet att fatta ett slutgiltigt beslut om något. (Samma exempel: att besluta vart man ska gå och äta middag. Eller att acceptera någon annans rekommendation – eller inte.) Den här rollen har också tillsynsbefogenhet, vilket innebär att personen kan säga: ”Gå tillbaka och gör ett andra utkast av vad det än gäller tills JAG BESLUTAR att det är tillräckligt bra.”
Observera att Project Management Institute, med den ursprungliga RACI-modellen, är mycket tydligt med att det bara kan finnas EN A-roll per aktivitet. Det innebär verkligen strömlinjeformat beslutsfattande och är bästa praxis. Men om vi tänker på verkligheten, hur många olika godkännanden går en genomsnittlig webbdesign igenom?
Det kan vara särskilt svårt att begränsa RACI till bara en beslutsfattare när arbetet är tvärfunktionellt (arbete som involverar flera avdelningar). I RACI 2.0 uppmanar vi människor att se över antalet A-beslutsfattare som de ursprungligen tilldelade och minska det så mycket som möjligt. Det finns ingen garanti för att du kan minska det till bara en.
Problem två: För många R
I den ursprungliga RACI-modellen kan du lägga in ett obegränsat antal R i skapandet av en leverans, och det speglar verkligheten i samarbete. Men det kan i sig skapa mer dubbelarbete och förvirring – gör du den här delen eller jag? Och vem håller reda på allt detta?
I RACI 2.0 har vi skapat en R-Prime-roll (eller R1-roll) för den här situationen. När det finns mer än en person i R-rollen utser du helt enkelt en av dem till R-Prime. Denna R1 ser till att leveransen följer planen (ungefär som en mini-projektledare för just den leveransen).
Ju fler R som samarbetar, desto viktigare blir R-Prime-rollen. Personen samordnar arbetet mellan flera personer – men det betyder fortfarande inte att personen fattar beslut (det är fortfarande A:s ansvarsområde).
Här är ett exempel (med utgångspunkt i LOTR-exemplet från den här RACI-artikeln)
| Aktivitet/deltagare | R1 | R | A |
| Skriva webbtext | Sam Gamgee | Pippin Took | |
| Godkänna webbtext | Frodo Baggins |
Det betyder att Pippin arbetar med texten TILLSAMMANS MED Sam, men som R1 måste Sam se till att allt arbete kommer samman. Obs! R1-roller bidrar ofta OCKSÅ till att utföra arbetet.
Problem tre: Ingen tidsplan eller inga tidsfrister
Med RACI 2.0 rekommenderar vi att du lägger till en kolumn i din RACI-tabell med tidsfrist för varje projektuppgift. Det blir inte mycket gjort i tvärfunktionellt projektarbete utan en tidsfrist, vilket många av oss vet av hård erfarenhet. Puh, den var lätt att åtgärda!
| Aktivitet/deltagare | R1 | A | Tidsfrist |
|---|---|---|---|
| Skriva webbtext | Sam Gamgee | N/A | 3 april |
| Godkänna webbtext | N/A | Frodo Baggins | 5 april |
Problem fyra: C som överskrider sina befogenheter
C-rollen står för rådgivning. C kan vara ämnesexperter med värdefull sakkunskap att bidra med, och vi vill verkligen veta vad de tycker om ett projekt.
Men de är inte A, vilket innebär att de inte kan ändra projektets riktning – eller ens bromsa det. Personen i A-rollen kan be om deras åsikt eller se till att de inte lämnas utanför, tacka dem och sedan bortse från den om personen så önskar. C kan inte godkänna och kan inte lägga in veto. Allt de kan göra är att ge råd.
Du kan alltid sätta en tidsfrist även för C:s synpunkter. Efter ett visst ”senast detta datum” får du gå vidare med projektet. Om de inte har bidragit med sina idéer kan du skicka en påminnelse (ännu en fördel med en tidsfrist) och sedan är du fri att gå vidare. Budskapet är: ”Du hade din chans.”
Använd RACI 2.0 som ett språk
Vi tycker om att se RACI som ett språk som projektteamet och organisationen kan lära sig att tala flytande. Vi vill att våra kunder ska bli organisationer som är ”RACI-flytande”.
När du talar RACI flytande är det lätt för kollegor att ändra sina roller i stunden. ”Hej, jag har fullt upp den här veckan, kan du ta min R för (den här leveransen)?”
Man kan klargöra befogenheter direkt: ”Vem har A för det här egentligen?” eller mer sannolikt: ”Låt oss få klarhet från ledningen, alla verkar tro att de har A för den här omdesignen av webbplatsen!” ”Finns det en tidsfrist för de här C-intressenterna? De hindrar arbetet från att gå framåt!”
Är det ursprungliga RACI-diagrammet föråldrat?
Nej, RACI-diagram är fortfarande värdefulla (så länge du lägger till deadlinekolumnen, se ovan.). Men de kräver en tidsinvestering, så tänk igenom när du behöver använda dem och när du inte behöver det.
Början av ett projekt som sträcker sig över flera avdelningar, geografiska områden och/eller tidszoner är ett bra tillfälle att stanna upp med det tvärfunktionella teamet och föra en dialog om att skapa en RACI-matris.
Att utföra arbete som är nytt – något ni aldrig har gjort tillsammans tidigare – är ett annat bra tillfälle att stanna upp i början för att tydliggöra allas roller.
Startups och innovatörer talar ofta om att börja med en minsta livskraftiga produkt (MVP), sedan marknadstesta idén, därefter ändra inriktning och ofta ändra inriktning igen.
Den typen av agilitet passar inte särskilt bra ihop med arbetsbeskrivningar (som tenderar att vara ganska breda och statiska), men fungerar mycket bra med RACI. Den ansvarsfördelningsmatris du skapar i början av ett projekt kan förändras och anpassas i takt med att projektet utvecklas och personer börjar i eller lämnar teamet.
Så länge du behärskar RACI kan du och ditt team hantera förändringar i rollerna.
Din erfarenhet
Vi vill gärna ta del av dina erfarenheter – de bra, de dåliga och de riktigt besvärliga – av att använda klassisk RACI och av att testa den uppgraderade RACI 2.0.
Det finns många sätt att se fördelarna med RACI – till exempel genom att skapa effektivare möten, introducera nyanställda snabbare och förhandla om mer resurser med en projektsponsor.
För fler insikter om RACI och teamledning, prenumerera på nyhetsbrevet från The Digital Project Manager eller ta en titt på ett annat RACI-alternativ, RASCI-diagram.
