Skip to main content

For noen år siden publiserte McKinsey en studie som viste at 80 % av organisasjonene som ble undersøkt, mente at beslutningstakingen deres var ineffektiv – det tok for lang tid, og/eller beslutningene som ble tatt, var ikke gode. 

Nesten halvparten av de spurte mente at organisasjonene deres ikke tok beslutninger raskt nok. Respondentene sa at de kastet bort mye av tiden sin på ineffektiv beslutningstaking – nesten en tredjedel av tiden – og denne andelen økte jo høyere opp i organisasjonen man kom. 

For et rot, ikke sant? Særlig når selskaper kappes om å holde tritt med digitaliseringen av alt. 

Continue Reading for Free

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

Det er derfor RACI passer perfekt akkurat nå. I hele Project Management Institutes kunnskapsbok for prosjektledelse er det det eneste prosjektstyringsverktøyet som fokuserer på beslutninger – hvem som tar dem, og hvor. 

Det hjelper deg også med å finne ut hvem som gjør hvilket arbeid. Av disse to grunnene kaller jeg ofte RACI-akronymet en Pandoras eske – et svært enkelt verktøy som avdekker alle slags interessante problemstillinger knyttet til myndighet, myndiggjøring og ansvarlighet. 

Hvis du vil friske opp minnet om det grunnleggende RACI-verktøyet, kan du begynne her: Slik lager du et RACI-diagram (inkludert en mal) og her: Bli ekspert på RACI-diagrammer på 30 minutter (du må være medlem for å få tilgang til dette minikurset). Du finner også et utmerket fagnotat og andre ressurser på nettstedet mitt.

RACI er for teambygging

Fordi jeg først lærte om RACI som konsulent innen organisasjonsendring, tenker jeg litt annerledes om det. I stedet for å tenke på hvor kraftfullt det er innen prosjektledelse (noe det er), tenker jeg først og fremst på det som et verktøy for teambygging. 

Men hva skjer med et team når medlemmene ikke har klart for seg hvilke roller de har? Her er noen vanlige symptomer:

  • Arbeidsbelastningen føles ubalansert, og noen blir irritert på andre i teamet fordi de ikke tar sin rettmessige del av arbeidsmengden.
  • Arbeid blir gjort dobbelt, noe folk vanligvis tilskriver dårlig kommunikasjon.
  • Folk føler seg fornærmet hvis de ikke blir konsultert før planene legges.
  • Teamet føler at det slukker branner i stedet for å bevege seg proaktivt fremover.
  • Stereotypisering av personer fra andre avdelinger eller med andre profesjonelle identiteter

Alt dette er svært dårlig for moralen i teamet, og enda verre er det at det kan føles som problemer mellom enkeltpersonene i teamet. Som personlighetskonflikter. I stedet er det meste av dette bare noe akademikere kaller «rolleforvirring», og det kan håndteres med en viss rolleavklaring ved hjelp av RACI.

Hvor nedslående er det ikke å la et team arbeide med et prosjekt i seks måneder, bare for at noen på et høyere nivå i organisasjonen skal nedlegge veto mot anbefalingen? Hvor nedslående er det å forsøke å arbeide med et problem uten tilstrekkelig støtte? En god og grundig RACI-samtale kan avdekke disse problemene før mye av teammedlemmenes tid er sløst bort.

Det viser seg at team med god rolleavklaring har langt større sannsynlighet for å være høytytende team. Og hva vet du – høytytende team har som regel også høy moral. 

Vanlige problemer med den opprinnelige RACI-modellen

Fordi McKinsey retter oppmerksomheten mot beslutningstaking, har de også publisert et blogginnlegg om problemene med RACI her. Mange prosjektledere har et elsk–hat-forhold til dette verktøyet. En gang fortalte en kunde meg at hun heller ville dø enn å lage enda en RACI-matrise med teamet sitt, fordi «det var som å se maling tørke». 

Det første problemet er at R-en (ansvarlig) og A-en (beslutningsansvarlig) ofte blandes sammen. Hele poenget med verktøyet er å eliminere rolleforvirring, så dette problemet er virkelig ironisk. 

Det andre problemet er at når du har et komplekst prosjekt der flere personer samarbeider om å produsere en leveranse (flere R-er), kan rolleforvirringens demon dukke opp igjen. 

Det tredje problemet med RACI er at det ikke inkluderer tidsfrister eller en tidslinje. Rolleavklaring er fantastisk, men ikke på bekostning av punktlighet. 

Det fjerde problemet er at C-rollen (konsultert) ofte går for langt, fordi personer i C-rollen tror de har mer myndighet enn de faktisk har.

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.

Hva er RACI 2.0, og hvilke fordeler har den fremfor den opprinnelige modellen?

La oss ta for oss disse fire problemene ett om gangen med en oppgradert RACI-modell, som jeg kaller RACI 2.0. 

Problem én: R/A-forvirringen

Med RACI 2.0 skiller vi tydelig mellom disse to rollene. 

  • R-rollen utfører arbeid, som ofte innebærer å lage en form for leveranse. Det kan være å utføre en handling (som å bestille bord til middag) eller å komme med en anbefaling («Basert på undersøkelsene mine anbefaler jeg at vi engasjerer dette byrået, og her er de tre grunnene til det.») Vi sier at R-rollen (den ansvarlige personen) er en arbeidsrolle. Hvis du ikke produserer noe, er sjansen stor for at du egentlig ikke har en R-rolle.
  • A-rollen tar beslutninger. I RACI 2.0 definerer vi A som «godkjenne» i tillegg til «ansvarlig» (vi synes «godkjenne» er tydeligere). Uansett hva du kaller det, må du være tydelig på at dette er den ansvarlige personen med myndighet til å ta en endelig beslutning om noe. (Samme eksempel: å bestemme hvor man skal spise middag. Eller å godta andres anbefaling – eller ikke.) Denne rollen har også tilsynsmyndighet, noe som betyr at denne personen kan si: «Gå tilbake og lag et nytt utkast av det som skal gjøres, helt til JEG BESTEMMER at det er godt nok.» 

Merk at Project Management Institute, med den opprinnelige RACI-modellen, er svært tydelig på at det bare kan være ÉN A-rolle per aktivitet. Dette gir virkelig strømlinjeformede beslutninger og er beste praksis. Men hvis vi tenker på den virkelige verden: Hvor mange ulike godkjenninger må et gjennomsnittlig nettsteddesign gjennom? 

Det kan være spesielt vanskelig å redusere RACI til bare én beslutningstaker når arbeidet går på tvers av funksjoner (arbeid som involverer flere avdelinger). I RACI 2.0 oppfordrer vi folk til å se på antallet A-beslutningstakere de opprinnelig tildelte og redusere det så langt som mulig. Det er ingen garanti for at du får det ned til bare én. 

Problem to: For mange R-er

I den opprinnelige RACI-modellen kan du sette inn et ubegrenset antall R-er i arbeidet med å lage en leveranse, og det gjenspeiler virkeligheten ved samarbeid. Men dette kan i seg selv føre til mer dobbeltarbeid og forvirring – er det du eller jeg som gjør denne delen? Og hvem holder oversikt over alt dette? 

I RACI 2.0 har vi opprettet en R-Prime-rolle (eller R1) for denne situasjonen. Når det er mer enn én person i R-rollen, utpeker dere én av dem som R-Prime. Denne R1-rollen sørger for at leveransen følger planen (som en mini-prosjektleder for den aktuelle leveransen). 

Jo flere R-er som samarbeider, desto viktigere blir R-Prime-rollen. Denne personen koordinerer arbeidet til flere personer – men det betyr fortsatt ikke at vedkommende tar beslutninger (det er fortsatt A-rollens ansvarsområde). 

Her er et eksempel (basert på LOTR-eksempelet fra denne artikkelen om RACI-diagrammer)

Aktivitet/deltakerR1RA
Skrive innhold til nettstedetSam GamgeePippin Took
Godkjenne innhold til nettstedetFrodo Baggins

Dette betyr at Pippin arbeider med innholdet SAMMEN MED Sam, men som R1 må Sam sørge for at alt arbeidet blir samordnet. Merk: R1-roller bidrar ofte OGSÅ til selve arbeidet. 

Problem tre: Ingen tidsplan eller tidsfrister

Med RACI 2.0 anbefaler vi å legge til en kolonne i RACI-diagrammet som inneholder tidsfristen for hver prosjektoppgave. Det blir ikke gjort særlig mye i tverrfunksjonelt prosjektarbeid uten en tidsfrist, slik mange av oss vet av bitter erfaring. Puh, den var enkel å løse! 

Aktivitet/deltakerR1ATidsfrist
Skrive innhold til nettstedetSam GamgeeIkke relevant3. april
Godkjenne innhold til nettstedetIkke relevantFrodo Baggins5. april

Problem fire: C-er som går for langt

C-rollen står for rådgivning. C-er kan være fageksperter med verdifull kunnskap å bidra med, og vi ønsker virkelig å vite hva de mener om et prosjekt.

Men de er ikke A-er, noe som betyr at de ikke kan endre prosjektets retning – eller engang forsinke det. Personen i A-rollen kan be om deres mening eller sørge for at de ikke holdes utenfor, takke dem og deretter se bort fra innspillet hvis vedkommende ønsker det. C-er kan ikke godkjenne, og de kan ikke nedlegge veto. Alt de kan gjøre, er å gi råd. 

Du kan også alltid sette en tidsfrist for C-enes innspill. Etter en bestemt «innen denne datoen»-frist har du lov til å gå videre med prosjektet. Hvis de ikke har bidratt med ideene sine, kan du sende dem en påminnelse (enda en fordel med en tidsfrist) og deretter står du fritt til å gå videre. Budskapet er: «Du fikk sjansen din». 

Bruk RACI 2.0 som et språk

Vi liker å tenke på RACI som et språk som prosjektteamet og organisasjonen kan lære å snakke flytende. Vi ønsker at kundene våre skal bli organisasjoner som «snakker RACI flytende». 

Når du snakker RACI flytende, er det enkelt for kolleger å endre rollene sine der og da. «Hei, jeg har det veldig travelt denne uken, kan du ta R-en min for (denne leveransen)?»

Folk kan avklare myndighet underveis: «Hvem har egentlig A-en for dette?» eller, mer sannsynlig: «La oss få en avklaring fra ledelsen, alle ser ut til å tro at de har en A for denne redesignen av nettstedet!» «Finnes det en tidsfrist for disse C-interessentene? De forsinker arbeidet!» 

Er det opprinnelige RACI-diagrammet utdatert?

Nei, RACI-diagrammer er fortsatt nyttige (så lenge du legger til kolonnen for tidsfrist, se ovenfor). Men de krever en tidsinvestering, så vurder nøye når du trenger å bruke dem, og når du ikke gjør det. 

Begynnelsen av et prosjekt som går på tvers av flere avdelinger, geografiske områder og/eller tidssoner, er et godt tidspunkt for å stanse opp sammen med det tverrfunksjonelle teamet og diskutere utarbeidelsen av en RACI-matrise.

Å utføre arbeid som er nytt – noe dere aldri har gjort sammen før – er en annen god anledning til å stanse opp i begynnelsen for å avklare alles roller. 

Oppstartsbedrifter og innovatører snakker ofte om å begynne med et minimum levedyktig produkt (MVP), deretter teste ideen i markedet, så endre retning – og ofte endre retning igjen.

Denne typen smidighet passer ikke godt med stillingsbeskrivelser (som har en tendens til å være ganske brede og statiske), men fungerer svært godt med RACI. Matrisen for ansvarsfordeling som du oppretter i begynnelsen av et prosjekt, kan endres og tilpasses etter hvert som prosjektet utvikler seg, og etter hvert som personer kommer inn i og forlater teamet ditt. 

Så lenge du behersker RACI, kan du og teamet ditt håndtere endringer i rollene. 

Din erfaring

Vi vil gjerne høre om erfaringene dine – de gode, de dårlige og de stygge – med å bruke klassisk RACI og teste ut den oppgraderte RACI 2.0. 

Det finnes mange måter å se fordelene ved RACI på – for eksempel gjennom å skape mer effektive møter, lære opp nyansatte raskere og forhandle om flere ressurser med en prosjektsponsor. 

For mer innsikt i RACI og teamledelse kan du abonnere på nyhetsbrevet til The Digital Project Manager eller se nærmere på et annet RACI-alternativ, RASCI-diagrammer.