Macierz RACI – co to jest i jak ją przygotować krok po kroku?

Macierz RACI to prosta tabela, która pokazuje, kto wykonuje poszczególne zadania, kto ostatecznie odpowiada za ich rezultat, z kim trzeba się konsultować oraz kogo należy informować o postępach. Skrót pochodzi od angielskich słów: Responsible, Accountable, Consulted i Informed.

Narzędzie jest stosowane przede wszystkim w zarządzaniu projektami i procesami, zwłaszcza gdy w realizację pracy zaangażowanych jest wiele osób, działów lub firm zewnętrznych. Dobrze przygotowana macierz ogranicza sytuacje, w których kilka osób wykonuje tę samą pracę, nikt nie podejmuje ostatecznej decyzji albo ważny interesariusz dowiaduje się o zmianie zbyt późno.

RACI nie zastępuje harmonogramu, opisu stanowisk ani procedury wykonania zadania. Odpowiada na inne pytanie: jaką rolę ma każda osoba lub funkcja w odniesieniu do konkretnego działania albo rezultatu?

Co to jest macierz RACI?

Macierz RACI, nazywana również macierzą odpowiedzialności, przypisuje uczestnikom projektu jeden z czterech sposobów zaangażowania w dane zadanie:

• R – Responsible: osoba lub zespół wykonujący pracę;
• A – Accountable: właściciel rezultatu, który ma ostateczną odpowiedzialność i uprawnienie do zatwierdzenia;
• C – Consulted: osoba konsultowana przed podjęciem decyzji lub zakończeniem pracy;
• I – Informed: osoba informowana o postępie, decyzji albo ukończeniu zadania.

Wiersze tabeli zawierają zadania, etapy, rezultaty lub ważne decyzje, natomiast kolumny przedstawiają role uczestniczące w projekcie. W komórkach wpisuje się odpowiednie litery.

Project Management Institute opisuje RACI jako rodzaj Responsibility Assignment Matrix, czyli macierzy przypisania odpowiedzialności. Narzędzie może również wspierać plan komunikacji, ponieważ wskazuje, kto powinien otrzymywać informacje i jakiego rodzaju zaangażowania od niego oczekujemy.

Przykładowy fragment może wyglądać następująco:

Zadanie	Kierownik projektu	Właściciel produktu	Projektant	Programista	Dział prawny
Określenie wymagań	C	A/R	C	C	I
Projekt interfejsu	I	A	R	C	I
Budowa rozwiązania	I	A	C	R	I
Ocena zgodności prawnej	I	A	I	C	R
Akceptacja wersji końcowej	R	A	C	C	C

Zapis A/R oznacza, że ta sama osoba zarówno wykonuje pracę, jak i ponosi ostateczną odpowiedzialność za jej rezultat. Jest to dopuszczalne szczególnie w małych zespołach, choć przy bardziej złożonych zadaniach rozdzielenie obu ról może zwiększyć przejrzystość.

Co oznaczają litery RACI?

Najwięcej błędów wynika z mylenia liter R i A. W języku polskim oba angielskie określenia bywają tłumaczone jako „odpowiedzialny”, przez co różnica między wykonaniem zadania a własnością rezultatu staje się nieczytelna.

R – Responsible, czyli wykonawca

Osoba oznaczona literą R rzeczywiście realizuje zadanie. Przygotowuje dokument, programuje funkcję, wykonuje analizę, prowadzi testy, kontaktuje się z dostawcą albo organizuje wydarzenie.

R odpowiada na pytanie:

Kto wykonuje pracę?

Dla jednego zadania powinien istnieć co najmniej jeden wykonawca. Można wskazać kilka osób R, jeżeli praca rzeczywiście wymaga współdziałania, ale ich zakresy powinny być jasne. Zbyt wielu wykonawców przypisanych do jednego ogólnego zadania często oznacza, że trzeba podzielić je na mniejsze części.

Przykład:

Za przygotowanie projektu graficznego odpowiada projektant. To on otrzymuje literę R, nawet jeżeli ostateczną decyzję o zatwierdzeniu podejmuje właściciel marki.

A – Accountable, czyli właściciel rezultatu

Osoba oznaczona literą A ponosi ostateczną odpowiedzialność za to, że zadanie zostanie prawidłowo wykonane. Może zatwierdzić wynik, odrzucić go, zlecić poprawki lub podjąć decyzję w sytuacji sporu.

A odpowiada na pytania:

Kto odpowiada za końcowy rezultat? Kto ma ostatnie słowo?

Dla jednego zadania powinno istnieć dokładnie jedno A. Kilku właścicieli rezultatu może prowadzić do przeciągających się uzgodnień, wzajemnego blokowania decyzji i rozmycia odpowiedzialności. Zasada jednego Accountable dla każdego zadania jest wskazywana w materiałach ProjectManagement.com oraz NHS Education for Scotland.

Accountable nie musi samodzielnie wykonywać zadania. Powinien jednak mieć odpowiednie uprawnienia, wiedzę o celu oraz możliwość doprowadzenia pracy do końca.

C – Consulted, czyli konsultowany

Osoba C przekazuje wiedzę, opinię albo wymagania potrzebne do wykonania zadania. Komunikacja jest dwukierunkowa: zespół zwraca się do konsultowanego przed decyzją, a następnie uwzględnia lub świadomie odrzuca jego uwagi.

C odpowiada na pytanie:

Czyjej wiedzy lub opinii potrzebujemy przed zakończeniem pracy?

Konsultowanym może być:

• specjalista merytoryczny;
• prawnik;
• przedstawiciel bezpieczeństwa;
• właściciel procesu;
• użytkownik końcowy;
• ekspert techniczny;
• przedstawiciel klienta.

Nie każda osoba zainteresowana projektem powinna otrzymać literę C. Nadmierna liczba konsultantów wydłuża decyzje i zwiększa liczbę spotkań. NHS zaleca ograniczanie tej grupy do osób, których wiedza jest rzeczywiście potrzebna.

I – Informed, czyli informowany

Osoba oznaczona literą I powinna otrzymać wiadomość o postępie, decyzji, ryzyku lub ukończeniu zadania, ale nie uczestniczy aktywnie w jego realizacji ani zatwierdzaniu.

I odpowiada na pytanie:

Kto powinien wiedzieć, co się wydarzyło?

Komunikacja jest zazwyczaj jednokierunkowa. Osoba informowana może otrzymać raport, krótką wiadomość, dostęp do tablicy projektu albo zaproszenie na prezentację wyniku.

Przypisanie I nie powinno automatycznie oznaczać zapraszania na każde spotkanie. Informowanie można realizować znacznie prościej, na przykład przez cotygodniowe zestawienie decyzji.

RACI a zwykły podział obowiązków

Opis stanowiska określa ogólny zakres odpowiedzialności pracownika. Macierz RACI odnosi się natomiast do konkretnego projektu, procesu lub rezultatu.

Przykładowo opis stanowiska kierownika marketingu może obejmować prowadzenie kampanii. Nie odpowiada jednak na pytanie, kto w danym projekcie:

• przygotowuje treść reklamy;
• zatwierdza budżet;
• konsultuje zgodność prawną;
• otrzymuje raport po zakończeniu kampanii.

RACI nie zastępuje również planu projektu. Harmonogram pokazuje terminy, kolejność i zależności między zadaniami, natomiast macierz odpowiedzialności określa role ludzi wobec tych zadań.

Narzędzie	Główne pytanie
Harmonogram	Kiedy praca ma zostać wykonana?
Lista zadań	Co trzeba zrobić?
Budżet	Ile można wydać?
Struktura podziału pracy	Na jakie elementy dzieli się projekt?
Macierz RACI	Kto i w jaki sposób uczestniczy w każdym zadaniu?
Plan komunikacji	Jak, kiedy i komu przekazujemy informacje?

Macierz najlepiej działa jako uzupełnienie pozostałych dokumentów, a nie jako samodzielny plan zarządzania całym przedsięwzięciem.

Kiedy warto przygotować macierz RACI?

RACI jest szczególnie przydatna wtedy, gdy samo przypisanie jednego właściciela zadania w systemie projektowym nie wystarcza.

Warto ją zastosować, gdy:

• w projekcie uczestniczy kilka działów;
• firma współpracuje z zewnętrznym wykonawcą;
• podobne kompetencje posiada wiele osób;
• decyzje wymagają konsultacji z ekspertami;
• uczestnicy nie wiedzą, kto ma ostatnie słowo;
• zadania są regularnie przekazywane między zespołami;
• występują opóźnienia spowodowane oczekiwaniem na akceptację;
• część interesariuszy jest pomijana w komunikacji;
• organizacja wdraża nowy proces;
• projekt przechodzi przez wiele etapów zatwierdzania.

Praktyczne znaczenie macierzy rośnie wraz z liczbą zależności. W prostym zadaniu wykonywanym przez jedną osobę rozbudowana tabela nie wniesie wiele. W projekcie łączącym sprzedaż, marketing, IT, finanse, dział prawny i zewnętrzną agencję może natomiast ujawnić problemy jeszcze przed rozpoczęciem realizacji.

RACI można przygotować na etapie planowania, ale narzędzie przydaje się również w trwającym projekcie, gdy pojawiają się konflikty dotyczące zakresu ról. ProjectManagement.com wskazuje, że macierz może zarówno porządkować pracę z wyprzedzeniem, jak i pomagać diagnozować przyczyny problemów już w trakcie realizacji.

Jak stworzyć macierz RACI krok po kroku?

Samo wpisanie liter do tabeli jest łatwe. Najważniejsza część pracy polega na właściwym określeniu poziomu szczegółowości, uzgodnieniu znaczenia ról i zaakceptowaniu podziału przez uczestników.

1. Określ zakres macierzy

Na początku ustal, czego ma dotyczyć dokument. Może obejmować:

• cały projekt;
• jeden etap projektu;
• stały proces biznesowy;
• wdrożenie produktu;
• zestaw kluczowych decyzji;
• utrzymanie systemu po jego uruchomieniu.

Nie warto łączyć w jednej tabeli całego programu strategicznego, pojedynczych czynności operacyjnych i codziennych zadań administracyjnych. Gdy zakres jest zbyt szeroki, macierz staje się nieczytelna.

2. Wypisz rezultaty i ważne działania

W pierwszej kolumnie umieść zadania, produkty pracy, kamienie milowe lub decyzje. Najlepiej stosować nazwy wskazujące konkretny efekt, na przykład:

• zatwierdzona koncepcja produktu;
• przygotowany projekt graficzny;
• przeprowadzone testy bezpieczeństwa;
• zaakceptowany regulamin;
• uruchomiona kampania;
• podpisana umowa z dostawcą.

Ogólne hasła, takie jak „marketing”, „IT” czy „komunikacja”, są zbyt szerokie. Nie wiadomo, czy oznaczają wykonanie pracy, nadzór, konsultację czy pojedynczy rezultat.

Z drugiej strony nie należy wpisywać każdej drobnej czynności. Tabela zawierająca setki wierszy będzie trudna do aktualizowania i szybko przestanie być używana.

3. Wypisz role uczestniczące w pracy

W nagłówkach kolumn umieść role, zespoły albo funkcje, na przykład:

• sponsor projektu;
• kierownik projektu;
• właściciel produktu;
• dział sprzedaży;
• marketing;
• IT;
• finanse;
• dział prawny;
• dostawca zewnętrzny.

Zazwyczaj lepiej stosować role niż imiona i nazwiska. Dokument pozostanie wtedy aktualny po zmianie pracownika. Można jednak prowadzić dodatkową listę wskazującą, kto obecnie pełni każdą funkcję.

W małym, krótkim projekcie użycie nazwisk może być wygodniejsze, pod warunkiem że odpowiedzialność nie stanie się niejasna po zmianie składu zespołu.

4. Najpierw przypisz A

Dla każdego wiersza wskaż jedną osobę posiadającą ostateczną odpowiedzialność za rezultat.

To najważniejszy etap tworzenia macierzy. Jeżeli zespół nie potrafi ustalić jednego A, problem prawdopodobnie nie dotyczy tabeli, lecz rzeczywistego podziału władzy lub niejasnego procesu decyzyjnego.

Accountable powinien:

• mieć prawo do zatwierdzenia wyniku;
• dysponować wystarczającą wiedzą;
• rozumieć wpływ zadania na projekt;
• móc egzekwować wykonanie;
• akceptować przypisaną odpowiedzialność.

Nie należy wyznaczać jako A osoby, która odpowiada formalnie, ale nie ma dostępu do informacji ani możliwości podejmowania decyzji.

5. Przypisz wykonawców R

Następnie wskaż osoby lub zespoły, które rzeczywiście wykonają pracę. Każdy wiersz powinien zawierać co najmniej jedno R.

Jeżeli wykonawców jest wielu, warto sprawdzić, czy zadanie nie powinno zostać rozbite. Zapisanie pięciu osób jako R przy haśle „wdrożenie systemu” niewiele wyjaśnia. Lepszy podział może obejmować:

• konfigurację środowiska;
• migrację danych;
• integrację z płatnościami;
• testy;
• szkolenie użytkowników.

Dla każdego z tych rezultatów można wtedy przypisać inne R i jednoznaczne A.

6. Dodaj osoby konsultowane C

Wpisz C tylko tam, gdzie uzyskanie opinii jest wymagane przed wykonaniem lub zatwierdzeniem pracy.

Należy ustalić również:

• czego dotyczy konsultacja;
• na jakim etapie ma się odbyć;
• ile czasu konsultowany ma na odpowiedź;
• czy jego opinia jest doradcza, czy wynika z obowiązujących wymagań;
• kto rozstrzyga rozbieżności.

Sama litera nie wystarczy, jeżeli proces konsultacji pozostaje nieokreślony.

7. Wskaż odbiorców informacji I

Na końcu dodaj osoby, które powinny znać wynik lub postęp, ale nie muszą uczestniczyć w tworzeniu rozwiązania.

Warto od razu ustalić sposób informowania:

• raport tygodniowy;
• wiadomość po zakończeniu etapu;
• aktualizacja tablicy projektu;
• podsumowanie decyzji;
• automatyczne powiadomienie;
• prezentacja kamienia milowego.

Dzięki temu I nie zamieni się w niekontrolowaną listę odbiorców kopii każdej wiadomości.

8. Uzgodnij macierz z zespołem

Tabela nie powinna zostać przygotowana przez kierownika projektu w oderwaniu od uczestników, a następnie wysłana jako zamknięta decyzja.

Każda osoba powinna wiedzieć:

• dlaczego przypisano jej daną rolę;
• co oznacza ona w praktyce;
• jakie ma uprawnienia;
• kiedy ma się zaangażować;
• jak będzie oceniane wykonanie;
• do kogo zgłosić konflikt.

NHS Education for Scotland zaleca wspólne utworzenie macierzy przez zespół i najważniejszych interesariuszy oraz uzyskanie ich akceptacji dla przypisanych ról.

9. Sprawdź tabelę wierszami i kolumnami

Po wypełnieniu macierzy przeprowadź dwie kontrole.

Analiza pozioma, czyli każdego zadania, pozwala wykryć:

• brak A;
• więcej niż jedno A;
• brak R;
• zbyt wielu wykonawców;
• nadmierną liczbę konsultowanych;
• niepotrzebnie szeroką grupę informowanych.

Analiza pionowa, czyli każdej roli, pokazuje:

• osobę przeciążoną wieloma A i R;
• uczestnika przypisanego wyłącznie jako I;
• funkcję zaangażowaną w niemal każdy wiersz;
• osobę formalnie obecną w projekcie, ale bez realnej roli;
• wąskie gardło w akceptacji.

Macierz nie tylko opisuje odpowiedzialność. Może również ujawnić nierówny podział pracy i nadmierną centralizację decyzji.

10. Aktualizuj dokument

RACI nie powinna być jednorazowym załącznikiem, którego nikt nie otwiera po spotkaniu startowym.

Aktualizacja jest potrzebna, gdy:

• zmienia się zakres;
• dochodzi nowy dostawca;
• pracownik opuszcza projekt;
• etap przechodzi do utrzymania;
• zmienia się właściciel biznesowy;
• pojawia się nowy wymóg prawny;
• dotychczasowy podział powoduje opóźnienia.

NHS określa macierz jako narzędzie rozwijające się wraz z projektem i zaleca wracanie do niej podczas spotkań oraz aktualizacji dla interesariuszy.

Przykład macierzy RACI dla wdrożenia strony internetowej

Załóżmy, że firma przygotowuje nową stronę sprzedażową. W projekcie uczestniczą sponsor, kierownik projektu, właściciel biznesowy, projektant, programista, prawnik i marketing.

Rezultat	Sponsor	Kierownik projektu	Właściciel biznesowy	UX/UI	Programista	Prawnik	Marketing
Ustalenie celu biznesowego	A	R	C	I	I	I	C
Przygotowanie wymagań	I	C	A/R	C	C	C	C
Projekt makiet	I	I	A	R	C	I	C
Przygotowanie treści	I	C	A	C	I	C	R
Budowa strony	I	C	A	C	R	I	I
Weryfikacja prawna	I	I	A	I	C	R	C
Testy i odbiór	I	R	A	C	R	C	C
Publikacja	I	A	C	I	R	I	R
Raport po wdrożeniu	I	A	C	I	C	I	R

Taka tabela pokazuje między innymi, że:

• właściciel biznesowy odpowiada za większość rezultatów związanych z zakresem i treścią;
• projektant wykonuje makiety, ale ich nie zatwierdza;
• prawnik jest wykonawcą oceny prawnej, lecz właściciel biznesowy odpowiada za jej uwzględnienie;
• sponsor nie musi brać udziału w każdym zadaniu;
• marketing jest wykonawcą treści i raportu, ale nie zarządza budową techniczną.

W prawdziwym projekcie należałoby doprecyzować, co oznacza „publikacja”, ponieważ jednoczesne przypisanie dwóch R może być zasadne tylko wtedy, gdy programista uruchamia stronę, a marketing prowadzi działania komunikacyjne. Alternatywą jest rozdzielenie wiersza na „wdrożenie techniczne” i „uruchomienie kampanii”.

Jak czytać gotową macierz?

Dobrze przygotowana tabela powinna być zrozumiała bez długiego komentarza. Każdy uczestnik wybiera swoją kolumnę i sprawdza, gdzie:

• wykonuje pracę;
• ma prawo zatwierdzenia;
• powinien dostarczyć opinię;
• otrzymuje wyłącznie informację.

Kierownik projektu czyta tabelę przede wszystkim wierszami. Sprawdza, czy każde zadanie ma właściciela, wykonawcę i odpowiedni sposób zaangażowania pozostałych osób.

Sponsor lub menedżer może przeanalizować ją pionowo, aby zobaczyć, czy nie skupiono zbyt wielu decyzji w jednej roli.

Macierz powinna opisywać rzeczywisty sposób działania. Jeżeli w tabeli wpisano kierownika jako A, ale w praktyce każdą decyzję podejmuje dyrektor, dokument nie porządkuje projektu, lecz maskuje jego faktyczną strukturę.

Najczęstsze błędy podczas tworzenia RACI

Brak jednej osoby A

Zadanie bez A nie ma jednoznacznego właściciela rezultatu. Gdy pojawi się problem, wykonawcy nie wiedzą, kto powinien podjąć decyzję.

Równie problematyczne jest kilka A. Ostateczna odpowiedzialność staje się wtedy wspólna tylko na papierze, a w praktyce może nie należeć do nikogo.

Mylenie R z A

R wykonuje pracę, natomiast A odpowiada za rezultat i zatwierdzenie. Osoba A może delegować wykonanie, ale nie powinna delegować ostatecznej odpowiedzialności.

Przykład:

Copywriter przygotowuje tekst, więc otrzymuje R. Kierownik marketingu zatwierdza publikację i odpowiada za jej zgodność z celem kampanii, dlatego otrzymuje A.

Przypisywanie A osobie bez uprawnień

Nie wystarczy oznaczyć kogoś jako właściciela. Musi on mieć możliwość podejmowania decyzji, dysponowania zasobami albo eskalowania problemu.

Odpowiedzialność bez uprawnień prowadzi do frustracji i opóźnień.

Zbyt wiele osób C

Każdy konsultowany oznacza dodatkową komunikację, oczekiwanie na opinię i potencjalną rozbieżność stanowisk.

Jeżeli niemal cała organizacja otrzymuje C, trzeba odpowiedzieć na pytanie, które opinie są naprawdę niezbędne. ProjectManagement.com ostrzega, że nadmiar konsultowanych może spowalniać decyzje, zwiększać biurokrację i prowadzić do przeciążenia spotkaniami.

Używanie I jako zaproszenia na spotkania

Osoba informowana nie musi uczestniczyć w dyskusji. Powinna otrzymać właściwą wiadomość we właściwym momencie.

Zapraszanie wszystkich I na każde spotkanie zwiększa liczbę uczestników i zaciera różnicę między konsultacją a informowaniem.

Nadmierny poziom szczegółowości

Macierz zawierająca każdą wiadomość, telefon i drobną poprawkę staje się trudniejsza w utrzymaniu niż sam projekt.

Wiersze powinny obejmować działania, decyzje i rezultaty, dla których niejasność ról rzeczywiście może powodować problem.

Zbyt ogólne zadania

Przeciwieństwem przesadnej szczegółowości są wiersze takie jak „realizacja projektu” albo „obsługa klienta”. Przy tak szerokim zakresie większość osób otrzyma kilka liter, a tabela nie wyjaśni odpowiedzialności.

Brak akceptacji uczestników

Przypisanie roli bez rozmowy nie gwarantuje, że dana osoba rozumie zakres, ma czas i posiada wymagane uprawnienia.

Macierz powinna być uzgodnieniem, a nie tylko administracyjną tabelą.

Nieaktualizowanie dokumentu

Nieaktualna macierz może być bardziej szkodliwa niż jej brak. Ludzie działają według nowych ustaleń, a formalny dokument nadal kieruje pytania do niewłaściwych osób.

Zalety macierzy RACI

Jasny podział ról

Najważniejszą korzyścią jest ograniczenie niejasności. Każdy uczestnik wie, kiedy powinien działać, zatwierdzać, doradzać lub tylko otrzymać wiadomość.

Atlassian wskazuje, że macierz pomaga ograniczać nakładanie się obowiązków i tworzy bardziej przejrzyste ścieżki komunikacji.

Szybsze rozwiązywanie problemów

Gdy rezultat ma jedno A, zespół wie, do kogo zwrócić się w przypadku konfliktu, opóźnienia albo konieczności wyboru jednego z wariantów.

Lepsze planowanie komunikacji

Rozróżnienie C i I ogranicza liczbę osób uczestniczących w każdej rozmowie. Konsultowane są osoby wnoszące potrzebną wiedzę, a pozostali otrzymują krótszą informację.

Ujawnianie luk i przeciążeń

Analiza tabeli pokazuje zadania pozbawione wykonawcy, niejasne akceptacje oraz osoby skupiające zbyt wiele obowiązków.

Łatwiejsze wdrażanie nowych członków zespołu

Nowa osoba może szybko zobaczyć strukturę współpracy i ustalić, do kogo zwracać się w różnych sprawach.

Wsparcie współpracy między działami

RACI jest szczególnie przydatna w strukturze macierzowej, w której uczestnicy podlegają różnym menedżerom i realizują cele kilku zespołów jednocześnie.

Ograniczenia macierzy RACI

RACI nie rozwiązuje wszystkich problemów związanych z odpowiedzialnością. Tabela może poprawnie wskazywać role, a projekt nadal będzie się opóźniał z powodu braku zasobów, niejasnych celów lub złych decyzji.

Nie pokazuje sposobu wykonania

Litera R wskazuje wykonawcę, ale nie opisuje standardu jakości, terminu, budżetu ani procedury. Te informacje muszą znaleźć się w innych dokumentach.

Nie pokazuje kolejności i zależności

Macierz nie zastępuje harmonogramu ani mapy procesu. Nie wiadomo z niej, które zadanie musi zakończyć się przed rozpoczęciem kolejnego.

Może utrwalać biurokrację

Jeżeli tabela zawiera zbyt wielu C i I, zamiast przyspieszać współpracę może formalizować konieczność konsultowania wszystkiego ze wszystkimi.

Nie zawsze jasno określa decydenta

Szczególnym problemem jest używanie RACI do bardzo złożonych decyzji. R i A bywają różnie rozumiane, a konsultowani mogą w praktyce otrzymywać nieformalną możliwość zablokowania wyboru.

McKinsey wskazuje, że przy podejmowaniu decyzji RACI może nie określać wystarczająco jasno, kto rzeczywiście posiada głos decydujący. Nadmierna liczba uczestników z prawem wpływu sprzyja eskalowaniu spraw i wydłużaniu procesu.

Nie zastępuje odpowiedzialnej kultury pracy

Najlepsza tabela nie pomoże, jeżeli ludzie unikają trudnych rozmów, nie zgłaszają problemów albo traktują przypisanie A jako sposób znalezienia winnego.

RACI powinna wspierać współpracę, a nie służyć do przerzucania odpowiedzialności po wystąpieniu błędu.

Macierz RACI a podejmowanie decyzji

RACI dobrze opisuje udział ludzi w zadaniach i rezultatach. Przy decyzjach strategicznych może jednak wymagać doprecyzowania.

Należy jednoznacznie ustalić:

• kto przygotowuje rekomendację;
• kto przekazuje dane i opinie;
• kto podejmuje decyzję;
• kto może ją zawetować z przyczyn prawnych lub bezpieczeństwa;
• kto wykonuje ustalenie;
• kiedy sprawa podlega eskalacji.

Jeżeli najważniejszym problemem organizacji są powolne decyzje, bardziej odpowiedni może być model stworzony specjalnie do określania praw decyzyjnych, na przykład DACI, RAPID albo DARE.

Atlassian rozróżnia RACI, przeznaczone głównie do przypisywania odpowiedzialności projektowej, od DACI i RAPID, które skupiają się na podejmowaniu decyzji.

RACI a DACI

DACI obejmuje cztery role:

• Driver – prowadzi temat i organizuje proces decyzyjny;
• Approver – podejmuje ostateczną decyzję;
• Contributors – dostarczają wiedzę i rekomendacje;
• Informed – otrzymują informację o decyzji.

Główna różnica polega na przeznaczeniu modeli.

RACI	DACI
Skupia się na zadaniach i odpowiedzialności za wykonanie	Skupia się na konkretnej decyzji
Wskazuje wykonawcę R	Wskazuje prowadzącego decyzję D
A odpowiada za rezultat	A jest jednoznacznym zatwierdzającym
C konsultuje zadanie	C dostarcza wkład do decyzji
Dobre dla planu projektu i procesu	Dobre dla wyborów strategicznych i produktowych

W praktyce oba modele można łączyć. DACI określa, kto wybiera rozwiązanie, a RACI pokazuje, kto później je wdraża.

RACI a RASCI

RASCI jest rozszerzeniem klasycznego modelu o literę S, najczęściej rozwijaną jako Support.

Role wyglądają wtedy następująco:

• R – wykonuje główną pracę;
• A – odpowiada za wynik;
• S – wspiera wykonawcę;
• C – dostarcza opinię;
• I – otrzymuje informację.

Różnica między R a S powinna być wyraźna. Responsible odpowiada za wykonanie zadania, a Support zapewnia pomoc, zasoby lub działania uzupełniające.

Przykład:

Przy organizacji konferencji koordynator wydarzenia może otrzymać R, dział IT – S w zakresie obsługi sprzętu, dyrektor marketingu – A, prawnik – C, a zarząd – I.

Dodanie kolejnej litery jest przydatne tylko wtedy, gdy organizacja rzeczywiście potrzebuje oddzielić wykonanie od wsparcia. W przeciwnym razie model staje się bardziej skomplikowany bez zwiększenia przejrzystości.

Czy macierz RACI pasuje do Agile i Scruma?

RACI może być użyteczna w organizacji stosującej podejście zwinne, ale nie powinna naruszać odpowiedzialności określonych przez stosowany framework ani zamieniać samoorganizującego się zespołu w strukturę zatwierdzania każdej czynności.

W środowisku zwinnym macierz może pomóc na styku:

• zespołu produktowego i działu prawnego;
• kilku zespołów pracujących nad wspólnym wydaniem;
• firmy i zewnętrznego dostawcy;
• produktu i infrastruktury;
• zespołu projektowego i zarządu;
• działań operacyjnych oraz bezpieczeństwa.

Mniej sensowne jest przypisywanie RACI do każdego drobnego zadania w Sprincie, jeżeli członkowie zespołu wspólnie organizują wykonanie pracy. Tabela może wtedy ograniczać elastyczność i szybko się dezaktualizować.

Najlepszym zastosowaniem jest zwykle określenie odpowiedzialności między zespołami, przy decyzjach regulacyjnych, publikacjach, wdrożeniach i działaniach wykraczających poza codzienną pracę jednego zespołu.

Jak wdrożyć RACI, aby nie stała się martwym dokumentem?

Ustal wspólne definicje

Przed wypełnieniem tabeli wyjaśnij różnicę między R i A. Można przyjąć prostą formułę:

• R robi;
• A odpowiada i zatwierdza;
• C doradza przed decyzją;
• I dowiaduje się o wyniku.

Definicje warto umieścić bezpośrednio nad tabelą.

Powiąż macierz z narzędziami pracy

Dokument powinien być łatwo dostępny z:

• planu projektu;
• karty projektu;
• strony zespołu;
• systemu zarządzania zadaniami;
• dokumentacji procesu.

Nie musi być odrębnym arkuszem, o którego istnieniu pamięta tylko kierownik projektu.

Wskazuj role, ale przypisuj do nich osoby

W tabeli można stosować nazwy funkcji, lecz zespół musi wiedzieć, kto obecnie je pełni. Lista ról powinna mieć aktualnych właścicieli.

Aktualizuj przy zmianach zakresu

Przegląd RACI warto połączyć z ważnymi momentami projektu:

• zatwierdzeniem nowego etapu;
• zmianą zakresu;
• dołączeniem dostawcy;
• reorganizacją;
• przygotowaniem wdrożenia;
• przekazaniem do utrzymania.

Egzekwuj wynikające z niej uprawnienia

Jeżeli osoba A ma ostatecznie odpowiadać za rezultat, musi faktycznie móc podjąć decyzję. W przeciwnym razie macierz będzie tylko pozorem delegowania.

Oceniaj skuteczność, nie kompletność tabeli

Celem nie jest wypełnienie każdej komórki. Puste pola są prawidłowe, jeżeli dana rola nie uczestniczy w zadaniu.

Lepsza jest prosta tabela używana przez zespół niż rozbudowany arkusz obejmujący wszystkich interesariuszy w każdym wierszu.

Macierz RACI – najważniejsze wnioski

Macierz RACI to narzędzie służące do jasnego podziału ról w projekcie lub procesie. Litera R wskazuje wykonawcę, A – osobę ostatecznie odpowiedzialną za rezultat, C – osoby konsultowane, a I – odbiorców informacji.

Każde zadanie powinno mieć co najmniej jednego wykonawcę i dokładnie jednego właściciela rezultatu. Liczbę konsultowanych i informowanych należy ograniczać do osób rzeczywiście potrzebnych. Gotową macierz trzeba uzgodnić z zespołem, powiązać z codziennymi narzędziami oraz aktualizować wraz ze zmianami projektu.

RACI sprawdza się najlepiej przy porządkowaniu odpowiedzialności za działania i rezultaty. Jeżeli głównym problemem są powolne lub niejasne decyzje, warto uzupełnić ją modelem wyraźnie wskazującym decydenta.

FAQ

Co to jest macierz RACI?

Macierz RACI to tabela przypisująca uczestnikom projektu cztery rodzaje ról: wykonanie zadania, ostateczną odpowiedzialność, konsultowanie oraz otrzymywanie informacji. Wiersze zawierają działania lub rezultaty, a kolumny role zespołowe. Narzędzie pomaga ograniczyć luki, nakładanie się obowiązków i niejasne akceptacje.

Co oznaczają litery RACI?

R oznacza Responsible, czyli wykonawcę pracy. A to Accountable – osoba ostatecznie odpowiedzialna za rezultat i uprawniona do jego zatwierdzenia. C oznacza Consulted, czyli osobę udzielającą opinii przed decyzją. I to Informed – osoba otrzymująca informację o postępie lub wyniku.

Czym różni się Responsible od Accountable?

Responsible wykonuje zadanie, natomiast Accountable odpowiada za jego końcowy rezultat i ma prawo do zatwierdzenia pracy. Przykładowo grafik może przygotować materiały jako R, a kierownik marketingu zatwierdzić je jako A. W małym projekcie ta sama osoba może mieć role A i R, ale nie są one znaczeniowo identyczne.

Ile osób może mieć A w macierzy RACI?

Dla jednego zadania powinno istnieć dokładnie jedno A. Kilku właścicieli końcowej odpowiedzialności utrudnia rozstrzygnięcie, kto podejmuje decyzję i odpowiada za zatwierdzenie. Jeżeli nie da się wskazać jednej osoby, warto podzielić zadanie na mniejsze rezultaty albo doprecyzować strukturę decyzyjną.

Czy jedno zadanie może mieć kilku wykonawców R?

Tak, jedno zadanie może wymagać kilku wykonawców, ale ich zakres powinien być jednoznaczny. Duża liczba R często sygnalizuje, że wiersz jest zbyt ogólny. Zamiast przypisywać wiele osób do „wdrożenia systemu”, lepiej oddzielić konfigurację, migrację danych, testy i szkolenia oraz nadać każdej części własnego wykonawcę.

Kiedy warto stosować macierz RACI?

RACI jest szczególnie przydatna w projektach międzydziałowych, przy współpracy z dostawcami oraz wszędzie tam, gdzie nie wiadomo, kto wykonuje pracę, zatwierdza wynik lub powinien zostać skonsultowany. W bardzo małych i prostych zadaniach tabela może być zbędna, ponieważ jej utrzymywanie przyniesie więcej pracy niż korzyści.

Czym RACI różni się od RASCI?

RASCI rozszerza klasyczną macierz o literę S oznaczającą Support, czyli rolę wspierającą wykonawcę. R nadal odpowiada za wykonanie zasadniczej pracy, a S dostarcza pomoc, zasoby lub czynności uzupełniające. Wariant warto stosować wtedy, gdy odróżnienie wykonawcy od wsparcia rzeczywiście poprawia przejrzystość projektu.