Macierz RACI (z ang. Responsibility Assignment Matrix) to jedno z najbardziej praktycznych narzędzi zarządzania projektami, służące precyzyjnemu przypisaniu ról i odpowiedzialności do każdego zadania w projekcie. Nazwa pochodzi od czterech angielskich określeń: Responsible (wykonawca), Accountable (właściciel decyzji), Consulted (ekspert) i Informed (informowany). W złożonych projektach IT, gdzie nad jednym zadaniem pracują zespoły rozproszone, zewnętrzni dostawcy i wiele warstw zarządzania, brak takiej macierzy niemal zawsze prowadzi do nieporozumień, opóźnień i konfliktów o kompetencje.
Więcej o tym, dlaczego odpowiedzialność tak często “gdzieś się gubi” w projektach, znajdziesz w artykule Kto w końcu to zrobi? Problem, który rozwiązuje macierz RACI.
Cztery role w macierzy RACI
Każda komórka macierzy to skrzyżowanie zadania z rolą projektową. Przypisanie odpowiedniej litery jednoznacznie określa, czego od danej osoby lub stanowiska oczekujemy przy konkretnym zadaniu.
- R – Responsible (wykonawca) – osoba lub osoby bezpośrednio realizujące zadanie. Przy jednym zadaniu może być wielu Responsible, co jest w pełni dopuszczalne, o ile zakresy pracy są wyraźnie rozgraniczone.
- A – Accountable (właściciel decyzji) – osoba ostatecznie odpowiedzialna za rezultat i jakość wykonania. Kluczowa zasada: dla każdego zadania może istnieć dokładnie jeden Accountable. Przypisywanie tej roli kilku osobom jednocześnie rozmywa decyzyjność i prowadzi do efektu biernego obserwatora (bystander effect), gdzie każdy zakłada, że ktoś inny podejmie decyzję.
- C – Consulted (ekspert) – osoby, z którymi należy skonsultować się przed podjęciem decyzji lub zakończeniem zadania. Komunikacja ma tu charakter dwukierunkowy: ekspert udziela informacji zwrotnej, a nie tylko otrzymuje powiadomienie.
- I – Informed (informowany) – osoby, które powinny być na bieżąco informowane o postępach i wynikach, ale nie biorą aktywnego udziału w realizacji. Komunikacja jest jednostronna.
Macierz RACI jako podstawa planu komunikacji
Warto spojrzeć na macierz RACI szerzej niż tylko jako na tabelkę z literkami. Jest ona w istocie fundamentem planu komunikacji w projekcie: precyzuje, kto, jak często i na jakim poziomie szczegółowości powinien otrzymywać informacje. Osoby z rolą C wymagają regularnego dialogu, natomiast osoby z rolą I wystarczy powiadamiać o kluczowych decyzjach i kamieniach milowych. Taka struktura ogranicza liczbę zbędnych spotkań i e‑maili, które obciążają zespół bez realnej wartości.
PMI (Project Management Institute) rekomenduje macierz RACI jako narzędzie bazowe do definiowania ról, szczególnie w projektach angażujących wielu interesariuszy i zewnętrznych dostawców. Jej zastosowanie jest równie naturalne w projektach prowadzonych metodą waterfall, jak w PRINCE2, jak i w środowiskach zwinnych podczas planowania sprintów.
Najczęstsze błędy przy wdrożeniu
Samo stworzenie macierzy nie gwarantuje, że będzie ona działać. W praktyce organizacje popełniają kilka powtarzających się błędów.
- Przypisywanie wielu Accountable do jednego zadania pod pozorem “wspólnej odpowiedzialności” – w rzeczywistości oznacza brak odpowiedzialności.
- Nadmierne uszczegółowienie macierzy i pokrywanie wszystkich mikrozadań, przez co dokument staje się nieczytelny i przestaje być używany.
- Traktowanie macierzy jako dokumentu jednorazowego, tworzonego raz na początku projektu i nigdy nieaktualizowanego. Macierz powinna być weryfikowana na każdym etapie projektu (phase gate), zwłaszcza przy zmianach zakresu.
- Brak udziału kluczowych interesariuszy w tworzeniu macierzy, co skutkuje brakiem akceptacji przypisanych ról.
Warianty macierzy RACI
Klasyczna macierz ma kilka rozszerzeń dostosowanych do specyficznych kontekstów. RASCI dodaje rolę Support (wsparcie wykonawcy), co bywa przydatne w projektach, gdzie część osób dostarcza zasobów lub pomocy technicznej bez pełnej odpowiedzialności za wynik. Z kolei DACI (Driver, Approver, Contributor, Informed) lepiej sprawdza się w procesach zdominowanych przez podejmowanie decyzji, na przykład w zarządach produktów lub przy governance dużych programów. Wybór wariantu powinien wynikać z charakteru projektu, a nie z mody na konkretne skróty.
O tym, jak macierz RACI wpisuje się w szerszy kontekst zarządzania projektem, piszemy w artykule Jakie są 4 filary zarządzania? Przewodnik dla menedżerów projektów IT.
Jak poprawnie zbudować macierz RACI
Budowanie macierzy zaczyna się od listy zadań lub etapów projektu (wiersze) oraz listy ról lub osób zaangażowanych (kolumny). Następnie każda kombinacja zadanie–rola otrzymuje przypisanie jednej z czterech liter lub pozostaje pusta, jeśli dana rola nie jest zaangażowana w dane zadanie. Po wypełnieniu warto przeprowadzić dwie weryfikacje: sprawdzić, czy każde zadanie ma dokładnie jednego Accountable, oraz czy żadna osoba nie jest obciążona zbyt wieloma rolami Responsible jednocześnie, co może sygnalizować przeciążenie zasobów.
Dodatkowe materiały na temat praktycznego zastosowania macierzy RACI znajdziesz w zasobach zewnętrznych:
