Przestań zrzucać winę na innych — użyj macierzy RACI (z Suze Haworth)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze działa w 100% poprawnie.

Ben Aston:

Jedną z najtrudniejszych rzeczy w zarządzaniu projektami jest konieczność współpracy z ludźmi — a ludzie bywają niezwykle różnorodni. Jesteśmy niespójni, egocentryczni, zawodni i bardzo zmienni — a mówię tu tylko o sobie. Zastanawiam się więc, czy wasze projekty przypominają moje. Kiedy coś idzie nie tak — a oczywiście na pewnym etapie tak się dzieje — sytuacja może szybko przerodzić się w okropne wzajemne obwinianie, w którym każdy oskarża innych o niewłaściwe wykonywanie obowiązków. Jak więc zarządzać projektem, gdy musimy mierzyć się z tym wszystkim? Tego dowiecie się dzisiaj.

Dziękuję za dołączenie. Nazywam się Ben Aston, a to podcast The Digital Project Manager. Ten podcast powstaje dzięki firmie Clarizen, liderowi w dziedzinie oprogramowania do zarządzania projektami i portfelami projektów dla przedsiębiorstw. Odwiedźcie stronę Clarizen.com, aby dowiedzieć się więcej. Dzisiaj rozmawiam z Suze Haworth, jedną z naszych ekspertek DPM w The Digital Project Manager. Suze, dziękuję, że dołączyłaś do programu.

Suze Haworth:

Dziękuję, Ben, dziękuję za zaproszenie.

Ben Aston:

Pozwólcie, że właściwie przedstawię Suze, ponieważ jest z nami od niedawna. To chyba nasz pierwszy wspólny podcast.

Suze Haworth:

Tak.

Ben Aston:

Suze jest niezależną dyrektorką ds. projektów cyfrowych w Londynie i ma ogromne doświadczenie — pracuje w branży od ponad 13 lat. Zaczynała w zarządzaniu klientami, podobnie jak ja, a następnie przeszła do zarządzania projektami. Zamiast jednak tylko czytać twoją biografię, Suze, opowiedz nam, nad jakimi projektami obecnie pracujesz.

Suze Haworth:

Obecnie? W zeszłym roku przeszłam na samozatrudnienie. Przez wiele lat pracowałam w różnych agencjach, ale rok temu zostałam freelancerką. W tej chwili pracuję w agencji w Londynie i prowadzę dwa duże projekty: jeden dotyczy systemu projektowego dla dość dużej marki detalicznej, a drugi — programu prac dla innej marki detalicznej. To bardzo interesujące projekty.

Ben Aston:

Czy handel detaliczny to twoja specjalność?

Suze Haworth:

Tak naprawdę pracuję w różnych obszarach. Mam wielu klientów z sektora handlu detalicznego, nadawcę, organizację charytatywną i wiele innych podmiotów. Obecnie w projektach, o których wspomniałam, rzeczywiście dominuje handel detaliczny, więc można tak powiedzieć.

Ben Aston:

W swojej roli freelancerki co uważasz za najtrudniejsze? Z jakimi większymi wyzwaniami mierzysz się teraz?

Suze Haworth:

Myślę, że największym wyzwaniem — i dotyczy to chyba wszystkich kierowników projektów — jest ogromna liczba różnych rzeczy, którymi trzeba zarządzać i które trzeba wykonać. Odpowiadasz nie tylko za pomyślną realizację projektu, lecz także za harmonogram, budżet, wyniki pracy zespołu, jego członków, problemy wewnątrz zespołu oraz kontakt z klientem. Trudno pogodzić tak wiele obowiązków w ograniczonym czasie. Często mam wrażenie, że każdego dnia nieustannie próbuję zmieścić wszystko w dostępnych godzinach.

Ben Aston:

Czy jest to trudniejsze, skoro wcześniej pracowałaś na stałe, a teraz działasz jako kontraktorka? Czy widzisz różnicę?

Suze Haworth:

Tak, jest trochę inaczej, ponieważ jako freelancerka ponosisz większą odpowiedzialność za własny czas i za sposób rozliczania go z agencją. Nie możesz dopuścić do sytuacji, w której czujesz, że nie możesz odmawiać. Nauczyłam się lepiej rozpoznawać, kiedy mam zbyt wiele obowiązków. Można zrobić tylko określoną ilość rzeczy i trzeba wykonać je właściwie, dlatego lepiej ustalać własne granice, zamiast zgadzać się na wszystko.

Ben Aston:

Tak. Kiedy sam pracowałem jako kontraktor, też to zauważyłem. Jest coś naprawdę przyjemnego w pracy kontraktowej, ponieważ nie zabiegasz o awans. Oczywiście chcesz przedłużyć umowę i nadal z nimi pracować, ale nie starasz się zaimponować ludziom w taki sam sposób jak stały pracownik, który myśli: „Lepiej się zgodzę, bo inaczej źle to będzie wyglądać”.

Suze Haworth:

Dokładnie. Nadal chcesz zrobić dobre wrażenie, oczywiście. Branża jest mała i wszyscy się znają, ale pod koniec dnia możesz trochę bardziej się wycofać i powiedzieć: „Dobrze, moje godziny pracy się skończyły”. Czasami jest to łatwiejsze niż przy pracy na stałe.

Ben Aston:

Od kiedy pracujesz na kontraktach, w ilu różnych miejscach pracowałaś?

Suze Haworth:

Jak dotąd tylko w kilku, ponieważ nie robię tego jeszcze zbyt długo. To ma swoje zalety, bo zdążyłam spędzić trochę czasu w obecnej agencji i dobrze znam ludzi. Lepiej znam też klientów, ponieważ projekty i obsługa klientów trwają dłużej.

Ben Aston:

Pracujesz na miejscu czy głównie zdalnie?

Suze Haworth:

Na miejscu. Właściwie bardzo zachwalam pracę zdalną wszystkim, z którymi o niej rozmawiam, bo uważam, że jest ważna i dla wielu osób może być bardziej produktywna. Jednak wiele agencji, szczególnie w Londynie, gdzie często pracowałam, działa głównie na miejscu.

Ben Aston:

Interesujące. Wiem, że oprócz freelancingu i pracy kontraktowej również piszesz. Przygotowywałaś materiały dla DPM, a w tym roku wystąpisz także podczas szczytu DPM. Możesz opowiedzieć nam o tym trochę więcej?

Suze Haworth:

Tak. Bardzo się z tego cieszę. W zeszłym roku występowałam podczas szczytu DPM w Las Vegas, a w tym roku poprowadzę warsztat. Temat jest interesujący, ponieważ jako kierownicy projektów jesteśmy chyba bardzo przywiązani do metodyk, szczególnie do metodyk zwinnych. Podczas warsztatu będę mówić o łączeniu podejść, a konkretnie o podejściu dwutorowym, które wdrażam w obecnie prowadzonym programie prac. Wykorzystuje ono pewne elementy podejścia zwinnego, ale je łączy. Omówię też Kanban, Lean oraz sposoby łączenia różnych podejść w projektach — niekoniecznie czyste Agile czy jedną metodykę, lecz dostosowywanie istniejących metodyk.

Ben Aston:

To świetne. Suze jest jedną z naszych ekspertek DPM i wystąpi również w naszym kursie doskonalenia zarządzania projektami cyfrowymi. Jednym z tematów kursu jest to, aby nie przywiązywać zbyt dużej wagi do nazwy metodyki.

Suze Haworth:

Tak, dokładnie.

Ben Aston:

Ostatecznie chodzi o dostarczanie pracy i znajdowanie lepszych sposobów jej realizacji — takich, które sprawdzają się w przypadku zespołu, projektu i klienta. Trzeba podchodzić do tego pragmatycznie, a nie dogmatycznie. Nie chodzi o to, czy coś jest Scrumem, tylko o to, żeby dostarczyć projekt.

Suze Haworth:

Dokładnie. Często jesteśmy zbyt skupieni na procesie i dopasowaniu do konkretnej metodyki. Tymczasem trzeba spojrzeć na projekt lub tworzony produkt i zapytać: „Co sprawdzi się w tym przypadku?”. Różne projekty wymagają różnych rozwiązań, dlatego należy je dostosowywać i łączyć.

Ben Aston:

Zdecydowanie. Niektórzy krytykują rozmywanie czystości metodyk, ale nigdy nie widziałem, żeby ich całkowicie czysta forma działała.

Suze Haworth:

Dokładnie. Wokół ulubionych podejść jest sporo snobizmu, ale jestem otwarta na ich stosowanie. W większości przypadków, szczególnie w świecie agencji, trzeba łączyć procesy zamiast stosować jedną czystą metodykę — ze względu na sytuację, w której się znajdujemy.

Ben Aston:

Porozmawiajmy więc o twoim artykule. Wracając do początku: jak zarządzać osobami, które chcą przejąć projekt albo nie chcą brać na siebie żadnej odpowiedzialności? Twój artykuł dotyczy używania macierzy RACI. Dla osób, które jeszcze go nie czytały: czym jest macierz RACI?

Suze Haworth:

RACI to skrót od angielskich określeń: responsible — wykonujący, accountable — odpowiedzialny za ostateczny rezultat, consulted — konsultowany oraz informed — informowany. To po prostu macierz, w której zestawia się zadania lub rezultaty projektu z interesariuszami albo członkami zespołu i przypisuje każdej roli oraz każdemu zadaniu jedną z czterech liter. Jedna osoba wykonuje zadanie, inna odpowiada za jego zatwierdzenie, ktoś jest konsultowany, a ktoś inny informowany. To świetny sposób na przypisanie odpowiedzialności za każde zadanie lub rezultat, ograniczenie liczby osób uczestniczących w każdej decyzji oraz jasne określenie, kto nad czym pracuje w trakcie projektu.

Ben Aston:

Wydaje mi się, że największe nieporozumienie dotyczy różnicy między odpowiedzialnością za wykonanie zadania a odpowiedzialnością za jego zatwierdzenie. Jak sobie z tym radzisz?

Suze Haworth:

To rzeczywiście najtrudniejszy obszar macierzy RACI. Osoba wykonująca zadanie faktycznie je realizuje — tworzy rezultat albo prowadzi pracę do końca. Osoba odpowiedzialna za rezultat zatwierdza zadanie i nadzoruje je, ale nie wykonuje go osobiście. Trzeba też uważać, aby nie przypisywać kierownikowi projektu odpowiedzialności za wszystko tylko dlatego, że prowadzi projekt. Należy zastanowić się, kto jest starszy lub bardziej kompetentny w danym obszarze. Jeśli chodzi o projektowanie, może to być dyrektor kreatywny po stronie agencji albo klienta. Nie należy automatycznie przypisywać tej roli kierownikowi projektu lub właścicielowi produktu.

Ben Aston:

To kluczowe, prawda? Łatwo popełnić błąd i uznać, że wszyscy są odpowiedzialni za wszystko. Czasami mówimy o zbiorowej odpowiedzialności, ale wtedy nikt nie ma jasnego obowiązku.

Suze Haworth:

Tak. Trzeba ograniczyć liczbę osób i jasno określić punkty kontaktu oraz poziom zatwierdzania. Jeśli role zostaną rozdzielone między wszystkich, macierz RACI nie spełni swojej funkcji. Jej zadaniem jest wyraźne wskazanie jednej osoby albo kilku osób kontaktowych i zatwierdzających.

Ben Aston:

Konsultowane osoby mogą faktycznie wykoleić projekt, ponieważ mają głos i wpływ, choć nie odpowiadają za terminowe dostarczenie właściwego rezultatu.

Suze Haworth:

Tak. Skoro ktoś jest konsultowany, powinien mieć możliwość wyrażenia opinii. Dlatego tak ważne jest właściwe przypisanie osoby odpowiedzialnej za rezultat. Musi ona przejąć odpowiedzialność za zadanie i dopilnować, aby osoby konsultowane wnosiły swój wkład, ale nie wykoleiły projektu nadmiarem uwag.

Ben Aston:

Jak utrzymać macierz RACI w lekkiej formie? Przy dużej szczegółowości jej przygotowanie może trwać bardzo długo.

Suze Haworth:

Nie warto tworzyć dokumentacji tylko dla samego jej tworzenia. Jeśli jednak przygotowujesz macierz RACI, musi być użyteczna i rzeczywiście wykorzystywana. Nie należy stworzyć jej na początku projektu, a potem pozwolić jej zniknąć na serwerze. Trzeba do niej wracać przy realizacji rezultatów, a na końcu projektu ocenić, czy była przydatna i czy właściwie określono role.

Ben Aston:

Czy używasz jej podczas cotygodniowych spotkań statusowych?

Suze Haworth:

Nie zawsze używam jej bezpośrednio podczas spotkań statusowych. Jest raczej wewnętrznym punktem odniesienia, który pomaga przypomnieć sobie, kto uczestniczy w danym rezultacie, komu trzeba wysłać go do konsultacji i kto powinien zostać poinformowany po jego dostarczeniu. Jeśli role zaczynają być naruszane, można wskazać macierz i wyjaśnić, że została stworzona po to, aby zwiększyć efektywność, usprawnić komunikację i nie dodawać projektowi zbędnych warstw oraz czasu.

Ben Aston:

Czy tworzysz jedną macierz obejmującą agencję i klienta, czy dwie osobne?

Suze Haworth:

To zależy od projektu. Jeśli po obu stronach są duże zespoły, mogą być potrzebne dwie macierze. Ostatnio częściej tworzyłam macierz po stronie klienta, gdy zaangażowanych było wielu interesariuszy. Po naszej stronie zespół był mniejszy, więc traktowałam agencję jako jedną jednostkę. Najważniejsze jest dopasowanie rozwiązania do projektu. Jeśli projekt jest mały, z niewielką liczbą osób i jednym klientem, macierz może być zbędna. Należy najpierw ocenić potrzebę jej zastosowania i jasno określić, co ma pomóc osiągnąć.

Ben Aston:

Macierz RACI pomaga zapobiegać pomijaniu zadań. Dzięki niej pod koniec projektu nikt nie może powiedzieć: „Dlaczego nie dano mi możliwości zgłoszenia uwag?” albo „Myślałem, że dział projektowy nanosił uwagi na makiety”.

Suze Haworth:

Właśnie dlatego tak ważne jest zaangażowanie klientów lub zespołu wewnętrznego w jej tworzenie. Nie powinna być dokumentem przygotowanym w izolacji i wysłanym komuś wyłącznie do zatwierdzenia. Jeśli ludzie uczestniczą w podejmowaniu decyzji od początku, role są jasne i łatwiej realizować projekt.

Ben Aston:

Kiedy macierz RACI przestaje działać? Jakie są sygnały ostrzegawcze?

Suze Haworth:

Przede wszystkim wtedy, gdy nie uzyskano zgody wszystkich zainteresowanych na początku. Nie można przypisać komuś odpowiedzialności bez poinformowania tej osoby i uzgodnienia tego z nią. Macierz trzeba też wykorzystywać w trakcie projektu — sprawdzać, czy prace przebiegają zgodnie z planem i czy uczestniczą w nich właściwe osoby. Po projekcie warto ją przeanalizować i ocenić, czy była pomocna oraz czy role zostały prawidłowo odwzorowane.

Ben Aston:

Co zrobić, gdy mimo dokumentacji zaczyna się wzajemne obwinianie, zadania przepadają, a ludzie są zdenerwowani?

Suze Haworth:

Nie należy używać macierzy jako narzędzia do wypominania: „Zgodziłeś się na to, więc nie masz prawa robić inaczej”. Lepiej przypomnieć, gdzie wszyscy uzgodnili wspólne zasady, dlaczego je ustaliliśmy i jakie konsekwencje dla projektu ma ich nieprzestrzeganie. Trzeba wyjaśnić osobom, które zakłócają pracę, dlaczego dana rola została przypisana właśnie w ten sposób i co może się wydarzyć, jeśli sytuacja będzie się rozwijać w tym kierunku.

Ben Aston:

Jeśli chcesz pobrać szablon macierzy RACI, Suze przygotowała go dla nas wraz z pomocnym przykładem wykorzystującym „Władcę Pierścieni”.

Suze Haworth:

Kiedy tworzyłam tę macierz dla „Władcy Pierścieni”, obawiałam się, że część rzeczy będzie niepoprawna. W pewnym sensie zrobiłam więc dokładnie to, czego sama odradzam, ale chciałam przedstawić temat w przystępny i obrazowy sposób.

Ben Aston:

Suze, dziękuję za udział w rozmowie. Wspaniale było cię gościć.

Suze Haworth:

Dziękuję.

Ben Aston:

Jeśli chcesz dołączyć do rozmowy, skomentuj wpis albo przejdź do sekcji Zasoby na stronie TheDigitalProjectManager.com i dołącz do naszego zespołu na Slacku. Jeśli chcesz usłyszeć więcej od Suze, przejdź do sekcji Szkolenia na stronie TheDigitalProjectManager.com i zapisz się na kolejny kurs doskonalenia zarządzania projektami cyfrowymi, w którym wystąpi Suze. Do usłyszenia następnym razem.