RACI-diagrammer brukes til å identifisere nøyaktig hvem som er ansvarlig for hva i prosjektet ditt. Uten en slik diagramoversikt vil du og teamet ditt bli usikre på oppgavefordelingen, hvem dere skal stille spørsmål til eller rådføre dere med, og hvem som gir endelig godkjenning.
I denne artikkelen går jeg gjennom bruksområder for RACI og deler tips og triks for effektiv bruk. Finn også ut hvordan du får tilgang til vår RACI-diagrammal.
Hva er et RACI-diagram?
Et RACI-diagram er et prosjektstyringsverktøy som identifiserer roller og ansvarsområder for oppgaver i et prosjekt. Det er også kjent som en matrise for ansvarsfordeling og brukes til å planlegge roller og ansvarsområder på forhånd, slik at alle vet hvem som er ansvarlig for hva.
RACI-diagrammer er nyttige for visualisering av ressursplanlegging, og du kan bruke RACI gjennom hele prosjektet for å holde oversikt over hvilke teammedlemmer som er ansvarlige, har det overordnede ansvaret, skal konsulteres og informeres om oppgaver og leveranser. Lagre det i prosjektstyringsprogramvaren din for enkel tilgang.
Hva står forkortelsen RACI for?
RACI står for R = ansvarlig, A = har det overordnede ansvaret, C = skal konsulteres, I = skal informeres. La oss se nærmere på hva hvert av disse begrepene betyr.
Ansvarlig: Utfører oppgaven
Denne personen utfører oppgaven eller leveransen. Vedkommende er ansvarlig for å få arbeidet gjort eller er beslutningstakeren.
Prøv å ha bare én person som er ansvarlig for en bestemt oppgave eller leveranse i matrisen for ansvarsfordeling. Noen ganger trenger den ansvarlige støtte fra en annen person for å fullføre oppgaven, eller vedkommende kan trenge noen å delegere til. I så fall kan du markere mer enn én person som ansvarlig.
Har det overordnede ansvaret: Eier oppgaven
Denne rollen har det overordnede ansvaret for at oppgaven eller leveransen blir fullført. Personen utfører sannsynligvis ikke arbeidet selv, men er ansvarlig for å sørge for at det ferdigstilles. Ideelt sett bør det være én person som har det overordnede ansvaret, ikke en gruppe, for å unngå forvirring rundt hvem som faktisk eier oppgaven.
Et godt eksempel på rollen med det overordnede ansvaret er lederen for teamet som er tildelt arbeidet. Hvis teamet ikke fullfører de tildelte oppgavene, har lederen det overordnede ansvaret.
Skal konsulteres: Bidrar med informasjon og kunnskap
Denne personen, rollen eller gruppen vil bidra med nyttig informasjon for å fullføre oppgaven eller leveransen. Det er toveis kommunikasjon mellom den ansvarlige rollen og dem som konsulteres, og denne personen er ofte en fagekspert.
Skal informeres: Holdes orientert
Disse personene eller gruppene holdes oppdatert om prosjektets fremdrift og milepæler, eller om hindringer teamet møter underveis. Den informerte parten blir ikke bedt om å gi tilbakemeldinger eller gjennomgå bestemte elementer, men vil bli informert etter behov. Det er vanligvis enveiskommunikasjon til disse rollene eller gruppene.
Se mer om RACI-diagrammer her!
Når bør du bruke et RACI-diagram?
Er et RACI-diagram nyttig i alle prosjekter? Det korte svaret er nei. Hvis du tilfører for mye kompleksitet og for mange prosesser i små prosjekter med høyt tempo, kan det faktisk bremse fremdriften og skape hindringer.
Her er noen situasjoner der RACI-diagrammer er nyttige:
- Større prosjekter med flere interessenter: Uten en RACI-matrise i større og mer komplekse prosjekter risikerer du situasjoner der folk spør hvorfor de ikke ble involvert, eller du oppdager at det kreves et ekstra godkjenningsnivå. I mindre prosjekter er oppgavene tydeligere for alle, og en RACI-matrise gjør prosjektet langsommere.
- Prosjekter med usikkerhet rundt ansvarsområder: Når du ikke er sikker på ansvarsområdene, kan du opprette en RACI-matrise og gjøre kvalifiserte gjetninger om oppgavefordelingen. Få godkjenning fra interessentene dine, eller bruk den som utgangspunkt for en diskusjon.
- Vannfallsprosjekter: Smidige metoder som Scrum er tydelige når det gjelder ansvar og beslutningsansvar: prosjektteamet har ansvaret, og produkteieren har beslutningsansvaret. Vannfallsprosjekter har gjerne flere interessenter og større kompleksitet, noe som gjør en RACI-matrise mer nyttig.
Eksempel på RACI-matrise: Et eksempel fra virkeligheten
Her er et eksempel på en RACI-matrise jeg opprettet for et prosjekt som omfattet oppsett av et lojalitetsprogram for et motemerke.
Som du kan se, er det ganske mange oppgaver og leveranser, i tillegg til interessenter. Da jeg opprettet denne RACI-matrisen, støtte jeg på noen konflikter:
- Det var mange interessenter både hos kunden og internt. Jeg begrenset denne matrisen hovedsakelig til interessenter på kundesiden, mens byrået hadde én rolle, ettersom vi hadde et lite team på vår side. RACI-matrisen var først og fremst ment å gjøre det enklere å håndtere de eksterne interessentene.
- For de ledende interessentene grupperte jeg dem i stedet for å navngi dem individuelt. Vi identifiserte kjerneteamet av ledende interessenter og deretter det utvidede teamet, slik at de ikke ble slått sammen til én gruppe, men jeg beholdt dem likevel i grupper for å gjøre ting enklere.
- Jeg plasserte beslutningsansvaret utover produkteieren på kundesiden for å unngå å skape ett enkelt feilpunkt og en silo. Jeg diskuterte dette med dem for å sikre at de var enige i fremgangsmåten, men det var fortsatt en tendens til at produkteieren hadde beslutningsansvar for ganske mange oppgaver.
Før vi ser på noen fordeler og ulemper, tar vi en kort avstikker:
Fordeler og ulemper ved RACI-matriser
Her er noen av fordelene og ulempene ved å bruke en RACI-matrise i prosjektet ditt.
Fordeler med RACI-matriser
RACI-matriser kan hjelpe med følgende:
1. Tydeligere forventninger
RACI-matriser tydeliggjør forventningene til hvem som leder eller har ansvaret for arbeidet. Det kan bidra til å eliminere forvirring ved å klargjøre hvem som har beslutningsansvaret, og det er nyttig for å avstemme forventningene med ledende interessenter som blir informert om hvilken type informasjon de vil motta.
2. Strømlinjeformet kommunikasjon
Du kan gå tilbake til RACI-rammeverket gjennom hele prosjektets livssyklus, noe som bidrar til å unngå å involvere hver eneste person i hver eneste beslutning. RACI-matrisen forteller deg når du skal involvere de riktige personene i riktig prosjektfase, noe som gjør godkjenninger og beslutningstaking raskere.
3. Mindre overbelastning av medarbeidere
Du vet når du innhenter meninger fra alle, og det blir et mareritt å forsøke å ta hensyn til alt? Det er her en RACI-matrise er nyttig. Ved å skille mellom konsulterte og informerte kan du skille mellom dem som deltar i tilbakemeldingene, og dem som bare får oppdateringer om fremdriften i oppgavene.
4. Mindre arbeidsbelastning og færre siloer
En RACI-matrise er et nyttig verktøy som hjelper prosjektledere med å delegere og unngå å påta seg for mye ansvar eller dekke flere roller, og dermed redusere utbrenthet. Den motvirker også at det oppstår ett enkelt feilpunkt, der all kunnskap og alt ansvar for en bestemt oppgave ligger hos én person og skaper siloer.
Vanlige fallgruver med RACI-matriser og hvordan du unngår dem
Det er mange fallgruver man bør være oppmerksom på når man oppretter en ansvarsfordelingsmatrise, og de er tidkrevende og blir ofte ignorert etter godkjenning. Her er noen ting du bør være oppmerksom på, samt måter å redusere risikoen på:
1. Prosjektlederen som den som gjør alt
Ofte kan utgangspunktet være at man tenker at prosjektlederen (eller produkteieren) er personen eller rollen som har ansvar for alt. Siden de leverer prosjektet, leverer de til syvende og sist alt som inngår i det.
Tenk over hvem som bør ha ansvar for å produsere arbeidet (f.eks. designere, utviklere og avdelingsledere), og fordel arbeidet deretter.
2. Forveksling av utførende og ansvarlig
Begrepene utførende og ansvarlig ligger ganske nær hverandre i betydning, noe som kan føre til forvirring. Her er hovedforskjellen:
- Du er utførende for en oppgave hvis det er din jobb å fullføre oppgaven. Det er ditt ansvar å få den gjort.
- Du er ansvarlig for en oppgave hvis det er din jobb å sikre at oppgaven blir fullført. Det kan hende du ikke gjør den selv, men du har ansvaret for at den blir gjort.
3. Spenningen mellom konsulterte og informerte
Det å bli konsultert har positive konnotasjoner, og personer som får denne rollen, vil føle seg mer inkludert og ha tillit til at tilbakemeldingene deres blir tatt med. Dette kan skape spenning for personer som blir informert, ettersom de kan føle at de ikke får med seg alt.
Vurder om personene du planlegger å informere, faktisk trenger å bli konsultert. Hvis dette ikke er tilfelle, må du sørge for at de vet at rollen som informert vanligvis innebærer en enveis deling av informasjon; de skal ikke gi tilbakemeldinger.
Slik oppretter du et RACI-diagram i 6 trinn
I illustrasjonen nedenfor har jeg oppsummert de seks trinnene for å lage et RACI-diagram:
Den fantastiske Meghan McInerny holdt et foredrag på Digital PM Summit 2017 og kom med det geniale forslaget at Ringenes herre faktisk er et vellykket prosjekt, og at Ringens brorskap er et team.
Så for å gjøre dette litt enklere å forstå, bruker vi dette prosjektet som eksempel. Hva er prosjektet? Å få ringen til Mordor og Dommedagsberget.
Trinn 1: Identifiser prosjektrollene
Lag en tabell med navnene på alle som er involvert i prosjektet, i den øverste raden. Tradisjonelt viser RACI-diagrammer de funksjonelle rollene øverst. Jeg mener imidlertid at det finnes tilfeller der det er bedre å bruke navn, og det er ofte det jeg foretrekker.

Grunner til å spesifisere etter rolle:
- Hvis én person fyller flere roller
- Det unngår behovet for oppdateringer ved endringer i bemanningen
- Det unngår en blanding av navn og bredere grupper, f.eks. «kunde» eller «avdeling X»
Grunner til å spesifisere etter navn:
- Det er enklere å definere hvem som er involvert i prosjektet
- Det er enklere når flere personer fyller lignende roller
Trinn 2: Identifiser prosjektoppgaver eller leveranser
Bryt prosjektet ned i tydelige oppgaver og leveranser. Plasser disse i kolonnen lengst til venstre i diagrammet. Prøv å ikke gå for detaljert til verks, ellers kan diagrammet bli for komplekst. Hvis du følger en tydelig liste over leveranser for prosjektet, bør du vurdere å føre opp disse.

Trinn 3: Tildel RACI til hver rolle og oppgave
Gå gjennom hver oppgave og avgjør hva hver rolle skal ha ansvar for. Hver oppgave bør ha noen som er ansvarlig og noen som er endelig ansvarlig (bare én person bør være endelig ansvarlig). Tenk på hvem som bør konsulteres mens oppgaven pågår, og hvem som bør informeres når den er fullført.
I vårt LOTR-RACI-eksempel er Frodo ansvarlig for å få ringen til Mordor. Gandalf, som leder for Brorskapet, er endelig ansvarlig. Sam hjelper imidlertid Frodo på veien – han konsulteres, det vil si at han er aktivt involvert.

Trinn 4: Bli enige om dette med teamet ditt
Avstem eventuelle antakelser du har gjort med teammedlemmene dine, og ikke gjør dette alene. Ta en kort prat om hvordan du har satt opp RACI, og sørg for at alle er fornøyde med rollene og ansvarsområdene sine i prosjektet.
Trinn 5: Bli enige om dette med prosjektets viktigste interessenter
Sett opp en samtale eller et møte for å bli enige om dette med de viktigste interessentene. Prøv å holde dette så enkelt som mulig for å unngå uhåndterlige tilbakemeldinger og tidkrevende diskusjoner. Tenk over hvem dette også må kommuniseres til når det er blitt enighet.
Trinn 6: Gjør det nyttig gjennom hele prosjektets levetid
Nå kan jeg legge RACI til side og konsentrere meg om å komme videre med prosjektet mitt, ikke sant? Vel, nei. Dette er et av de største problemene med dokumenter som en RACI: Når de først er opprettet, blir de ofte glemt.
Så hvordan gjør du dette til et nyttig dokument som faktisk brukes?
- Når du utfører en oppgave eller leveranse, bør du gå tilbake til RACI og avklare hvem som er ansvarlig for hva.
- Sørg for at det som ble fastsatt i begynnelsen av prosjektet, inkludert rollene og ansvarsområdene knyttet til oppgavene, fortsatt er korrekt og samsvarer med eventuelle funn eller justeringer fra et konseptbevis.
- Ha en versjon tilgjengelig på nettet, ved å bruke Confluence eller Google Docs, eller prosjektstyringsprogramvaren som brukes i organisasjonen din. Hvis du bruker et Microsoft Excel-regneark, bør du lagre det på et sted som alle har tilgang til.
- På slutten av et prosjekt kan du bruke RACI til å se hvordan de tildelte rollene og ansvarsområdene fungerte. Trengte dere så mange involverte? Utførte de ansvarlige oppgaven, eller trengte flere personer å involveres? Ble personer konsultert og informert på riktig tidspunkt?
Lytt til dette som en podkast
Suze deler sin tydelige mening om hvordan man slutter å skylde på andre og bare kommer i gang.
RACI-matrise – mal og eksempel

Jeg har utviklet en RACI-matrise-mal som du kan laste ned. Du finner også et eksempel, en sjekkliste og et jukseark. Malen fyller automatisk inn fargene basert på oppføringene dine. Du kan gjerne justere fargene etter eget ønske!
Denne malen er tilgjengelig gjennom DPM-medlemskap. Bli medlem og få tilgang til RACI-diagrammalen, samt over 100 andre maler, prøver og eksempler for prosjektdokumentasjon. Du kan også delta i samtalen om RACI-diagrammer (og mye mer) i Slack sammen med over 100 andre digitale prosjektledere.
Beste praksis for RACI-diagrammer
- Sørg for at en RACI vil være nyttig for prosjektet, og tenk gjennom hvordan og hvorfor RACI-en skal brukes. Unngå å lage et RACI-diagram bare for å ha laget det.
- Sørg for at du forstår begrepene, og ta deg tid til å lære dem bort til andre. Enten du velger RACI eller et av alternativene (mer om dette nedenfor), bør du bruke tid på å forklare teamet hvert begrep og hva det betyr. Det er en nyttig påminnelse for dem som allerede kjenner begrepene, og alle som er nye i prosjektet vil sette pris på at du har klargjort dem.
- Sørg for at bare én rolle er markert som ansvarliggjørende. En gruppe er ikke ansvarliggjørende, det er en person. Å tildele flere personer skaper forvirring og forsinker beslutningstakingen, prosjektarbeidsflyten og godkjenningsprosessene for leveranser eller dokumenter.
- Du trenger ikke å informere alle. Informerte personer er de som oppgaven eller leveransen vil påvirke, eller som har en egeninteresse i den. Prosjektet har sannsynligvis et sett med interessenter på høyt nivå som må informeres, men du trenger ikke å ta med disse detaljene i en RACI (overlat det til prosjektplanen eller planen for interessenthåndtering).
- Ikke opprett RACI-diagrammet isolert. Be sentrale prosjektinteressenter og medlemmer av prosjektteamet om innspill. Lag et førsteutkast selv, og la deretter interessentene dine gjennomgå det.
Hva er alternativene til RACI?
Her er noen andre typer RACI-diagrammer og hvorfor de kan brukes.
1. RASCI
Sannsynligvis det mest brukte alternativet til RACI, står RASCI-diagrammet for: ansvarlig, ansvarliggjørende, støttende, konsultert og informert. Teammedlemmer i den støttende rollen bistår den ansvarlige.
Forskjellen mellom støttende og konsultert er at den konsulterte gir informasjon, mens den støttende deltar aktivt i oppgaven.
2. CARS
CARS er spesifikt rettet mot handlinger, og i likhet med RASCI inkluderer modellen en støtterolle når oppgaver ikke fullføres av én rolle eller person. Tilhengere av CARS-modellen sier at den eliminerer unødvendig informasjon fra RACI. Det står for:
- Kommunisere: både rådføring og informering
- Godkjenne: godkjenneren som tar beslutningene
- Ansvarlig: personen som utfører arbeidet (samme som i RACI)
- Støtte: personene som hjelper den ansvarlige personen med arbeidet
Noen mener at RACI-modellen tildeler begreper som er ganske selvinnlysende – det vil si at den ansvarlige ofte er prosjektlederen eller produkteieren, og at informering vanligvis omfatter et bredere spekter av interessenter i prosjektet.
3. RAS
Jeg liker forenklingen i denne modellen, siden den begrenser begrepene til ansvarlig, godkjenne og støtte. Den tar imidlertid ikke høyde for eieren av oppgaven, noe som kan skape forvirring.
4. DACI
DACI ligner relativt mye på RACI-diagrammet, men erstatter den utførende med drivere, den som rådføres med bidragsytere og den ansvarlige med godkjennere, slik at beskrivelsene blir mer handlingsorienterte. Dette bidrar til å tydeliggjøre hva disse rollene skal gjøre, og fjerner forvirring som kan oppstå med RACI-matrisen.
5. CLAM
En variant av DACI som også fokuserer mer på de involverte handlingene enn på teamroller. CLAM står for bidragsyter, leder, godkjenner og overvåker.
Samlet sett definerer mange av variantene av RACI begrepene tydeligere eller spesifiserer handlinger for å fjerne tvetydighet mellom rollene. Det er ikke stor forskjell mellom modellene når det gjelder hva de forsøker å oppnå.
Hvis du er interessert i andre varianter av RACI, kan du lese om RACI 2.0 her.
Hva skjer videre?
For mer hjelp med prosjektstyring og teamledelse kan du ta vårt kurs i å mestre digital prosjektstyring. Det dekker hele prosjektets livssyklus, fra oppstart til avslutning, og omfatter også et bredt spekter av prosjektmetodikker som bidrar til å oppnå prosjektsuksess.


