Projektledelse
RACI-modellen: hvem gør arbejdet og hvem står til ansvar
En RACI-matrix er færdig, når hver beslutning har én, der står til ansvar. Ikke et team, ikke et udvalg.
Projektledelse
En RACI-matrix er færdig, når hver beslutning har én, der står til ansvar. Ikke et team, ikke et udvalg.
Kort fortalt
En RACI-model fordeler ansvaret for opgaver og beslutninger mellem rollerne i et projekt eller en organisation. For hver opgave angiver I, hvem der udfører den (R), hvem der står til ansvar (A), hvem der skal rådføres (C) og hvem der skal informeres (I). Resultatet er en RACI-matrix med opgaverne nedad og rollerne henover.
Matrixen er hurtig at lave og nem at lave forkert. De fleste RACI-matricer ender med for mange A'er, for mange C'er og roller, der er med for en sikkerheds skyld. Værdien kommer først, når I tjekker matrixen og tager de svære samtaler om, hvem der faktisk bestemmer.
Gratis skabelon · Excel
Fordel ansvaret for opgaver og beslutninger med R, A, C og I. Hver række tjekkes automatisk og et overblik viser, hvor meget hver rolle har.
Gratis og uden tilmelding.
Flere gratis skabeloner finder I under skabeloner og værktøjer.
Udfører arbejdet. Der kan være flere R'er på samme opgave, men mindst én skal der være.
Står til ansvar og godkender resultatet. Der må kun være ét A pr. opgave. Den, der er A, kan også være R.
Rådføres før beslutningen. Det er en dialog i begge retninger, så hver C koster tid. Brug dem med omtanke.
Informeres, når beslutningen er truffet. Envejskommunikation. Det er her, de fleste roller bør stå.
Forskellen på R og A er den vigtigste. R er den, der gør arbejdet. A er den, der svarer for resultatet og kan sige ja eller nej. I et IT-projekt er projektlederen ofte R på mange opgaver, mens projektejeren eller styregruppen er A på de beslutninger, der handler om penge, omfang og gevinst.
Eksemplet er fra et systemskifte med syv roller. Det er det samme eksempel, som står i skabelonen. A/R betyder, at samme person står til ansvar og udfører arbejdet.
| Opgave eller beslutning | Projektejer | Projektleder | Styregruppe | Arkitekt | IT-drift | Superbrugere | Leverandør |
|---|---|---|---|---|---|---|---|
| Business case og gevinst | A | R | C | C | I | I | I |
| Projektplan og milepæle | I | A/R | I | C | C | I | C |
| Ændringer i omfang, tid og budget | C | R | A | C | I | I | C |
| Løsningsdesign og arkitektur | I | C | I | A | C | C | R |
| Data og migrering | I | A | I | C | C | R | R |
| Test og accept af løsningen | A | C | I | I | C | R | C |
| Overdragelse til drift | I | R | I | C | A | I | C |
| Risici og eskalering | C | A/R | I | I | I | I | I |
Skriv de opgaver og beslutninger, hvor ansvaret kan være uklart. 8 til 15 rækker er nok. Hver detalje i planen hører ikke hjemme her.
Brug roller, ikke navne, så matrixen overlever udskiftninger. 5 til 8 kolonner er typisk. Navnene kan stå i en linje under rollen.
Start med at finde den ene, der står til ansvar for hver række. Det er her, uenighederne kommer frem. Tag dem nu og ikke midt i projektet.
Sæt derefter R på dem, der gør arbejdet. Brug C sparsomt og I til resten. Lad feltet stå tomt, hvis rollen ikke har noget med opgaven at gøre.
Læs matrixen vandret og lodret (se næste afsnit). Gennemgå den med styregruppen og lad projektejeren godkende den.
En udfyldt matrix er ikke nødvendigvis en god matrix. Læs den to veje. Vandret ser I, om hver beslutning har en ejer. Lodret ser I, om en rolle er overbelastet eller kun med for en sikkerheds skyld. Skabelonen tjekker rækkerne automatisk og tæller bogstaverne pr. rolle.
Hver række skal have præcis ét A og mindst ét R.
Intet A
Ingen står til ansvar. Beslutningen bliver ikke truffet eller bliver truffet af den, der råber højest.
Flere A'er
Delt ansvar er intet ansvar. Vælg én og gør de andre til C.
Intet R
Nogen godkender, men ingen har fået opgaven. Sæt en R på, også hvis det er A selv.
Mange C'er
Beslutningen bliver langsom. Spørg, hvem der reelt skal høres før. Flyt resten til I.
Hver kolonne viser, hvad rollen reelt skal bruge tid på.
Mange A'er
Rollen er en flaskehals. Uddelegér de beslutninger, der ikke kræver netop denne rolle.
Kun C og I
Rollen er med for en sikkerheds skyld. Overvej, om den skal stå i matrixen.
Mange R'er
Rollen udfører det meste. Tjek, at der er tid til det i planen.
Den klassiske model. Passer til de fleste projekter og til faste opgaver i linjen. Nem at forklare og nem at læse.
Tilføjer S for support: dem, der hjælper R med arbejdet. Kan give mening ved store leverandørsetup, men gør matrixen tungere.
Bruges til enkelte beslutninger frem for opgaver: Driver, Approver, Contributors og Informed. God til en konkret beslutning, mindre god som oversigt.
Vælg den enkleste model, der løser problemet. I de fleste IT-projekter er udfordringen ikke, at modellen mangler et bogstav. Udfordringen er, at ingen har taget stilling til, hvem der er A.
Fra vores egne projekter
Hos en større retailvirksomhed blev IT-projekter startet på mavefornemmelse og kørt af dem der råbte højest. Der var masser af R'er, altså folk der gerne ville lave noget. Men ingen var A. Ingen havde mandat til at sige nej til et projekt eller stoppe det undervejs, så projekterne sluttede, når budgettet var brugt.
Vi løste det ikke med en RACI-matrix pr. projekt. Vi placerede ansvaret i projektmodellen: hver gate fik krav til, hvad der skulle være godkendt og hvem der godkendte det. Arkitekturbeslutninger fik et fast sted i arkitekturrådet. Derefter skulle de enkelte projekter kun aftale det, der var særligt for dem.
Erfaring fra vores projekter
Start med A. De fleste matricer har styr på, hvem der laver arbejdet. Det, der mangler, er den ene person, der kan sige ja eller nej. Når A er uklart, er det den, der råber højest, der bestemmer.
Læg det faste ansvar i projektmodellen og det særlige i projektets matrix. Hvem der godkender en gate eller en arkitekturbeslutning, skal ikke forhandles forfra i hvert projekt.
Mere om projektledelse
Vi træder ind, uanset om projektet skal startes fra bunden eller allerede er i gang. Tag en uforpligtende samtale om jeres situation.