RACI 2.0: En ny og forbedret RACI til fremtiden
For nogle år siden offentliggjorde McKinsey en undersøgelse, der viste, at 80 % af de adspurgte organisationer mente, at deres beslutningstagning var ineffektiv – det tog for lang tid, og/eller de beslutninger, der blev truffet, var ikke gode.
Næsten halvdelen af de adspurgte mente, at deres organisationer ikke traf beslutninger hurtigt nok. Respondenterne sagde, at de spildte meget af deres tid på ineffektiv beslutningstagning – næsten en tredjedel af deres tid – og denne procentdel steg, jo højere oppe i organisationen man kom.
Sikke noget rod, ikke? Især når virksomheder kæmper for at følge med digitaliseringen af alting.
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 er derfor, RACI er perfekt til dette øjeblik. I hele Project Management Institutes vidensgrundlag for projektledelse er det det eneste projektstyringsværktøj, der fokuserer på beslutninger – hvem der træffer dem, og hvor.
Det hjælper dig også med at finde ud af, hvem der udfører hvilket arbejde. Af de to grunde kalder jeg ofte RACI-akronymet for en Pandoras æske – et meget enkelt værktøj, der åbner op for alle mulige interessante problemstillinger om myndighed, bemyndigelse og ansvarlighed.
Hvis du vil genopfriske det grundlæggende RACI-værktøj, kan du starte her: Sådan opretter du et RACI-diagram (plus en skabelon) og her: Bliv ekspert i RACI-diagrammer på 30 minutter (du skal være medlem for at få adgang til dette minikursus). Du kan også finde en fremragende hvidbog og andre ressourcer på min hjemmeside.
RACI er til teambuilding
Fordi jeg først lærte RACI at kende som konsulent inden for organisatoriske forandringer, tænker jeg lidt anderledes om det. I stedet for først at tænke på, hvor effektivt det er til projektstyring (hvilket det er), tænker jeg først på det som et værktøj til teambuilding.
Men hvad sker der med et team, når medlemmerne ikke har klarhed over deres roller? Her er nogle almindelige symptomer:
- Arbejdsbyrden føles skæv, og nogle personer nærer vrede mod andre i teamet, fordi de ikke løfter deres rimelige andel af arbejdsbyrden.
- Arbejdet bliver udført flere gange, hvilket folk normalt tilskriver dårlig kommunikation.
- Folk føler sig fornærmede, hvis de ikke bliver konsulteret, før planerne lægges.
- Teamet føler, at det slukker ildebrande i stedet for proaktivt at bevæge sig fremad.
- Stereotypisering af personer fra andre afdelinger eller faglige identiteter
Alt dette er forfærdeligt for teammoralen, og værre endnu kan det føles som problemer mellem personerne i teamet. Som personlighedskonflikter. I stedet er de fleste af disse problemer blot noget, som akademikere kalder “rolleforvirring”, og de kan håndteres med en vis afklaring af RACI-rollerne.
Hvor nedslående er det ikke at have et team til at arbejde på et projekt i seks måneder for så at opleve, at en person på et højere niveau i organisationen nedlægger veto mod dets anbefaling? Hvor nedslående er det ikke at forsøge at arbejde med et problem uden tilstrækkelig støtte? En god, grundig RACI-samtale kan afdække disse problemer, før en masse teammedlemmers tid er blevet spildt.
Det viser sig, at teams med god rolletydelighed har langt større sandsynlighed for at være højtydende teams. Og hvad ved man så om det – højtydende teams har som regel også høj moral.
Almindelige problemer med den oprindelige RACI
Fordi McKinsey retter sin opmærksomhed mod beslutningstagning, har de også offentliggjort en blog om problemerne med RACI her. Mange projektledere har et had-kærlighedsforhold til dette værktøj. Jeg havde engang en kunde, der fortalte mig, at hun hellere ville dø end at udarbejde endnu en RACI-matrix med sit team, fordi “det var som at se maling tørre”.
Det første problem er, at R (Udførende) og A (Ansvarlig) ofte bliver blandet sammen. Hele formålet med værktøjet er at eliminere rolleforvirring, så dette problem er virkelig ironisk.
Det andet problem er, at når man har et komplekst projekt, hvor flere personer samarbejder om at producere en leverance (flere R'er), kan rolleforvirringens dæmon dukke op igen.
Det tredje problem med RACI er, at det ikke omfatter deadlines eller en tidsplan. Rolletydelighed er fantastisk, men ikke på bekostning af rettidighed.
Det fjerde problem er, at C-rollen (Konsulteret) ofte overskrider sine beføjelser, fordi personer med C tror, at de har mere myndighed, end de reelt har.
Hvad er RACI 2.0, og hvilke fordele har den i forhold til den oprindelige?
Lad os tage fat på disse fire problemer ét ad gangen med en opgraderet RACI, som jeg kalder RACI 2.0.
Problem ét: Forvekslingen af R/A
Med vores RACI 2.0 skelner vi meget tydeligt mellem disse to roller.
- R-rollen udfører arbejdet, hvilket ofte omfatter at skabe en form for leverance. Det kan være at udføre en handling (som at bestille bord til middag) eller at komme med en anbefaling ("Baseret på min research anbefaler jeg, at vi hyrer dette bureau, og her er de 3 grunde til det.") Vi siger, at R-rollen (den ansvarlige person) er en arbejdsrolle. Hvis du ikke producerer noget, har du sandsynligvis ikke reelt en R-rolle.
- A-rollen træffer beslutninger. I RACI 2.0 definerer vi A som både bemyndigende og ansvarlig (vi synes, at bemyndigende er tydeligere). Uanset hvad du kalder det, skal det stå klart, at dette er den ansvarlige person med beføjelse til at træffe en endelig beslutning om noget. (Samme eksempel: at beslutte, hvor man skal spise middag. Eller at acceptere en andens anbefaling – eller lade være). Denne rolle har også tilsynsbeføjelser, hvilket betyder, at personen kan sige: "Gå tilbage og lav et nyt udkast af det, hvad det end er, indtil JEG BESLUTTER, at det er godt nok."
Bemærk, at Instituttet for projektledelse med den oprindelige RACI er meget tydelig om, at der kun kan være ÉN A-rolle pr. aktivitet. Det giver en meget strømlinet beslutningstagning og er bedste praksis. Men hvis man tænker på den virkelige verden, hvor mange forskellige godkendelser skal det gennemsnitlige webdesign igennem?
Især ved tværfunktionelt arbejde (arbejde, der involverer flere afdelinger) kan det være meget svært at begrænse RACI til blot én beslutningstager. I RACI 2.0 opfordrer vi folk til at se på antallet af A-beslutningstagere, de oprindeligt tildelte, og begrænse det så meget som muligt. Der er ingen garanti for, at du kan få det ned på blot én.
Problem to: For mange R'er
I den oprindelige RACI kan du indsætte et ubegrænset antal R'er i skabelsen af en leverance, og det afspejler virkeligheden i samarbejde. Men det kan i sig selv skabe mere dobbeltarbejde og forvirring – arbejder du på denne del, eller gør jeg? Og hvem holder styr på det hele?
I RACI 2.0 har vi oprettet en R-Prime-rolle (eller R1-rolle) til denne situation. Når der er mere end én person i R-rollen, skal du blot udpege én af dem som R-Prime. Denne R1 sikrer, at leverancen følger planen (som en mini-projektleder for netop den leverance).
Jo flere R'er der samarbejder, desto vigtigere bliver R-Prime-rollen. Personen koordinerer flere menneskers arbejde – men det betyder stadig ikke, at vedkommende træffer beslutninger (det er fortsat A-rollens område).
Her er et eksempel (bygget videre på LOTR-eksemplet fra denne RACI-diagramartikel)
| Aktivitet/deltager | R1 | R | A |
| Skrive tekst til webstedet | Sam Gamgee | Pippin Took | |
| Godkende tekst til webstedet | Frodo Baggins |
Det betyder, at Pippin arbejder på teksten SAMMEN med Sam, men som R1 skal Sam sikre, at alt arbejdet samles. Bemærk: R1-roller bidrager ofte OGSÅ til at udføre arbejdet.
Problem tre: Ingen tidsplan eller frister
Med RACI 2.0 anbefaler vi, at du tilføjer en kolonne til dit RACI-diagram med en frist for hver projektopgave. Der bliver ikke udrettet ret meget i tværfunktionelt projektarbejde uden en frist, som mange af os ved af bitter erfaring. Pyha, den var let at løse!
| Aktivitet/deltager | R1 | A | Frist |
|---|---|---|---|
| Skrive tekst til webstedet | Sam Gamgee | Ikke relevant | 3. april |
| Godkende tekst til webstedet | Ikke relevant | Frodo Baggins | 5. april |
Problem fire: C'er, der overskrider deres rolle
Rollen C står for rådgivning. C'er kan være fageksperter med værdifuld ekspertise at bidrage med, og vi vil virkelig gerne vide, hvad de mener om et projekt.
Men de er ikke A'er, hvilket betyder, at de ikke kan ændre projektets retning – eller sågar forsinke det. Personen i A-rollen kan indhente deres mening eller sikre sig, at de ikke holdes udenfor, takke dem og derefter se bort fra den, hvis vedkommende ønsker det. C'er kan ikke godkende, og de kan ikke nedlægge veto. Det eneste, de kan gøre, er at rådgive.
Du kan også altid sætte en frist for C'ernes input. Efter en bestemt "senest denne dato"-frist må du gå videre med dit projekt. Hvis de ikke har bidraget med deres idéer, kan du sende dem en påmindelse (endnu en fordel ved en frist) og derefter frit gå videre. Budskabet er: "Du havde din chance".
Brug RACI 2.0 som et sprog
Vi kan godt lide at tænke på RACI som et sprog, som projektteamet og organisationen kan lære at tale flydende. Vi ønsker, at vores kunder bliver organisationer, der "taler RACI flydende".
Når du taler RACI flydende, er det nemt for kolleger at justere deres roller på stedet. "Hej, jeg har virkelig travlt i denne uge – kan du overtage min R for (denne leverance)?"
Folk kan afklare beføjelser undervejs: "Hvem har egentlig A'et for dette?" eller mere sandsynligt: "Lad os få en afklaring ovenfra, alle ser ud til at tro, at de har et A for denne redesign af webstedet!" "Er der en frist for disse C-interessenter? De forsinker arbejdet!"
Er det oprindelige RACI-diagram forældet?
Nej, RACI-diagrammer er stadig værdifulde (så længe du tilføjer deadlinekolonnen, se ovenfor.). Men de kræver en tidsinvestering, så vær omhyggelig med, hvornår du har brug for at bruge dem, og hvornår du ikke har.
Begyndelsen på et projekt, der går på tværs af flere afdelinger, geografiske områder og/eller tidszoner, er et godt tidspunkt at stoppe op med det tværfunktionelle team og drøfte oprettelsen af en RACI-matrix.
At udføre arbejde, der er nyt—noget, I aldrig har gjort sammen før – er endnu en god anledning til at stoppe op i begyndelsen og tydeliggøre alles roller.
Startups og innovatører taler ofte om at begynde med et minimum levedygtigt produkt (MVP), derefter markedsteste idéen og så ændre retning – ofte flere gange.
Denne form for smidighed passer ikke godt sammen med jobbeskrivelser (som har en tendens til at være ret brede og statiske), men den fungerer rigtig godt med RACI. Den ansvarstildelingsmatrix, du opretter i begyndelsen af et projekt, kan ændre sig og tilpasses, efterhånden som projektet udvikler sig, og efterhånden som personer træder ind i og ud af dit team.
Så længe du er fortrolig med RACI, kan du og dit team håndtere ændringer i roller.
Din erfaring
Vi vil meget gerne høre om din erfaring—den gode, den dårlige og den grimme—med at anvende klassisk RACI og afprøve den opgraderede RACI 2.0.
Der er mange måder at se fordelene ved RACI på—med effekter som at skabe mere effektive møder, onboarde nye medarbejdere hurtigere og forhandle om flere ressourcer med en projektsponsor.
Hvis du vil have flere indsigter om RACI og teamledelse, kan du tilmelde dig nyhedsbrevet fra The Digital Project Manager eller se på et andet RACI-alternativ, RASCI-diagrammer.
