Jak ustalić, kto podejmuje ostateczną decyzję w projekcie?

Projekt może mieć świetny zespół, rozsądny harmonogram i dobrze opisany zakres, a mimo to utknąć na pozornie prostym pytaniu: kto właściwie ma prawo powiedzieć „robimy właśnie tak”?

Problem pojawia się szczególnie w projektach międzydziałowych. Marketing chce jednego rozwiązania, sprzedaż drugiego, dział techniczny ostrzega przed ryzykiem, a właściciel biznesowy oczekuje szybkiego wdrożenia. Jeśli wcześniej nie ustalono, kto podejmuje ostateczną decyzję, każde kolejne spotkanie może jedynie powtarzać tę samą dyskusję.

Najpierw oddziel osobę wykonującą pracę od osoby podejmującej decyzję

To podstawowe rozróżnienie.

Kierownik projektu może organizować pracę, pilnować terminów i zbierać informacje, ale nie musi mieć prawa do podejmowania wszystkich decyzji biznesowych.

Podobnie specjalista może przygotować najlepszą rekomendację techniczną, ale niekoniecznie decyduje o budżecie.

W projekcie mogą więc jednocześnie istnieć:

• osoba prowadząca temat,
• osoby przygotowujące rozwiązania,
• eksperci opiniujący,
• osoba ponosząca odpowiedzialność za rezultat,
• osoba podejmująca ostateczną decyzję.

Jeżeli wszystkie te role wrzuci się do jednego worka pod nazwą „właściciel projektu”, nieporozumienia są niemal gwarantowane.

Najprostsze pytanie brzmi: kto może powiedzieć „tak”, gdy inni się nie zgadzają?

To dobry test praktyczny.

Wyobraźmy sobie, że zespół ma dwie realne opcje.

Pierwsza jest tańsza, ale wolniejsza.

Druga kosztuje więcej, ale pozwala szybciej wejść na rynek.

Marketing popiera drugą.

Finanse pierwszą.

Zespół techniczny twierdzi, że obie są możliwe.

Kto podejmuje decyzję?

Jeżeli odpowiedź brzmi:

„Musimy jeszcze wszyscy porozmawiać”,

to nadal nie wskazano osoby decyzyjnej.

Konsultacja może być grupowa, ale ostateczna odpowiedzialność za decyzję powinna być przypisana konkretnie.

Jedna decyzja nie musi mieć tego samego decydenta co cały projekt

To częsty błąd.

Projekt może mieć sponsora albo właściciela biznesowego, ale nie oznacza to, że ta osoba musi zatwierdzać każdą drobną rzecz.

Przykładowo:

budżet dodatkowy — sponsor projektu,

wybór technologii — lider techniczny,

kolejność wdrażania funkcji — właściciel produktu,

termin codziennego spotkania zespołu — kierownik projektu,

treść kampanii — osoba odpowiedzialna za marketing.

Dlatego zamiast pytać:

„Kto decyduje w projekcie?”

lepiej zapytać:

„Kto podejmuje ostateczną decyzję w tej konkretnej kategorii spraw?”

W małym projekcie wystarczy prosta tabela

Nie każdy zespół potrzebuje rozbudowanej metodologii.

Przy kilku osobach można stworzyć bardzo prostą tabelę:

Obszar	Przygotowuje rekomendację	Podejmuje decyzję	Konsultowani
Budżet	PM	Sponsor	Finanse
Technologia	Tech Lead	CTO	Zespół developerski
Zakres MVP	Product Manager	Product Owner	Sprzedaż, marketing
Termin wdrożenia	PM	Sponsor	Tech Lead, Product Owner

Taka tabela często usuwa więcej problemów niż kilkunastostronicowy dokument opisujący strukturę projektu.

Najważniejsze, aby była znana wszystkim zainteresowanym.

RACI pomaga ustalić odpowiedzialność, ale trzeba właściwie rozumieć role

Jednym z popularnych modeli jest RACI.

Skrót oznacza:

R — Responsible
osoba wykonująca pracę;

A — Accountable
osoba odpowiedzialna za rezultat i mająca ostateczną odpowiedzialność;

C — Consulted
osoby, z którymi decyzję należy skonsultować;

I — Informed
osoby, które trzeba poinformować o rezultacie.

Najważniejszą zasadą w kontekście decyzji jest zwykle to, żeby dla konkretnego elementu nie tworzyć kilku równoległych osób z rolą Accountable.

Jeżeli za decyzję formalnie odpowiadają trzy osoby, łatwo doprowadzić do sytuacji, w której w praktyce nie odpowiada nikt.

DACI jeszcze wyraźniej pokazuje, kto ma ostatnie słowo

W projektach, w których największym problemem są właśnie przeciągające się decyzje, przydatny może być model DACI.

Role wyglądają następująco:

Driver — osoba prowadząca proces decyzyjny;

Approver — jedna osoba podejmująca ostateczną decyzję;

Contributors — osoby dostarczające wiedzę i rekomendacje;

Informed — osoby, które trzeba poinformować o wyniku.

Dużą zaletą tego podejścia jest wyraźne rozdzielenie osoby koordynującej temat od osoby decyzyjnej.

Kierownik projektu może być Driverem, ale Approverem może zostać sponsor, dyrektor działu albo właściciel produktu.

Nie wybieraj decydenta wyłącznie według stanowiska

„Najwyżej stanowiskiem” nie zawsze oznacza „najlepszy decydent”.

Prezes firmy nie powinien zatwierdzać koloru przycisku w aplikacji.

Dyrektor marketingu nie powinien samodzielnie decydować o zmianie architektury systemu.

Lider techniczny nie powinien bez zgody biznesu zwiększać budżetu projektu o kilkaset tysięcy złotych.

Decydent powinien mieć trzy rzeczy:

• odpowiedni zakres odpowiedzialności,
• wystarczającą wiedzę lub dostęp do ekspertów,
• realne uprawnienia do podjęcia decyzji.

Jeżeli którejś z nich brakuje, decyzja będzie później kwestionowana.

Sprawdź, kto ponosi konsekwencje decyzji

To dobry sposób na znalezienie właściwej osoby.

Jeżeli decyzja dotyczy zwiększenia budżetu, kto odpowiada za budżet?

Jeżeli dotyczy zmiany zakresu produktu, kto odpowiada za produkt?

Jeżeli dotyczy ryzyka technicznego, kto formalnie akceptuje takie ryzyko?

Jeżeli dotyczy terminu, kto odpowiada przed klientem lub zarządem za jego dotrzymanie?

Często właśnie odpowiedź na pytanie o odpowiedzialność prowadzi do właściwego decydenta.

Nie myl osoby najbardziej kompetentnej z osobą odpowiedzialną za decyzję

Ekspert może wiedzieć najwięcej o danym problemie.

Nie musi jednak mieć uprawnień do zaakceptowania wszystkich konsekwencji rozwiązania.

Przykład:

architekt systemu rekomenduje rozwiązanie droższe o 80 tys. zł, ale bezpieczniejsze technologicznie.

Może bardzo dobrze ocenić aspekt techniczny.

Nie oznacza to automatycznie, że powinien samodzielnie zatwierdzić dodatkowy koszt.

Jego rolą może być przygotowanie rekomendacji, a ostateczna decyzja należy do sponsora projektu albo osoby odpowiedzialnej za budżet.

Ustal granicę samodzielności kierownika projektu

Kierownik projektu bez żadnych uprawnień decyzyjnych staje się jedynie osobą przekazującą wiadomości między interesariuszami.

Z drugiej strony kierownik nie powinien samodzielnie zatwierdzać wszystkiego.

Warto więc ustalić konkretne granice.

Na przykład:

PM może samodzielnie przesuwać zadania w obrębie sprintu.

PM może zatwierdzić koszt dodatkowy do 3000 zł.

Zmiana harmonogramu o więcej niż tydzień wymaga zgody sponsora.

Zmiana zakresu projektu wymaga zatwierdzenia właściciela biznesowego.

To znacznie lepsze niż ogólne stwierdzenie:

„Kierownik projektu zarządza projektem”.

Kwoty decyzyjne potrafią rozwiązać wiele sporów

W projektach z budżetem warto ustalić progi.

Przykładowo:

do 1000 zł — decyduje lider zespołu;

1000–10 000 zł — kierownik projektu;

powyżej 10 000 zł — sponsor.

Liczby oczywiście zależą od skali organizacji.

W projekcie wartym 50 tys. zł próg 10 tys. zł byłby ogromny.

Przy inwestycji za kilkadziesiąt milionów może być drobną decyzją operacyjną.

Najważniejsze jest ustalenie mechanizmu.

To samo zrób z terminem i zakresem

Nie tylko pieniądze potrzebują progów eskalacji.

Można ustalić:

opóźnienie do 2 dni — decyzja operacyjna zespołu;

3–7 dni — PM;

powyżej tygodnia — sponsor projektu.

Podobnie z zakresem.

Zmiana sposobu wykonania zadania może należeć do zespołu.

Usunięcie całej funkcji produktu powinno już wymagać decyzji osoby odpowiedzialnej biznesowo.

Konsultacja nie oznacza prawa weta

To jeden z największych problemów projektów międzydziałowych.

Do konsultacji zaproszono pięć osób.

Każda zaczyna zachowywać się tak, jakby miała prawo zablokować decyzję.

Efekt: nic się nie dzieje, dopóki wszyscy nie są całkowicie zadowoleni.

Przed rozpoczęciem konsultacji trzeba powiedzieć jasno:

„Chcemy poznać Waszą opinię. Ostateczną decyzję podejmuje Anna”.

Nie umniejsza to roli ekspertów.

Po prostu wyznacza granicę między opinią a decyzją.

Nie każdy interesariusz musi zatwierdzać wszystko

Osoba zainteresowana projektem nie staje się automatycznie decydentem.

Dyrektor sprzedaży może chcieć wiedzieć, co powstaje.

Dział prawny może opiniować zgodność.

Marketing może przekazywać potrzeby klientów.

Finanse mogą oceniać koszt.

To nie oznacza, że każdy z tych działów powinien mieć ostateczne słowo w każdej decyzji.

Im więcej wymaganych akceptacji, tym wolniej działa projekt.

Dlatego trzeba odróżnić:

kto musi zostać wysłuchany

od

kto musi formalnie zatwierdzić.

Ustal decydenta przed rozpoczęciem dyskusji

Najgorszy moment na wybieranie osoby decyzyjnej to chwila, w której zespół już się podzielił.

Jeżeli spór trwa od dwóch tygodni i dopiero wtedy pada pytanie:

„To kto właściwie może zdecydować?”,

każda odpowiedź będzie wyglądała jak próba przechylenia wyniku na jedną stronę.

Znacznie lepiej określić rolę przed pojawieniem się konfliktu.

Dlatego przy większych decyzjach już na początku zapisz:

• temat decyzji,
• termin,
• osobę przygotowującą materiały,
• konsultowanych ekspertów,
• osobę zatwierdzającą.

Wyznacz termin decyzji

Decydent bez terminu nadal może blokować projekt.

Przykład:

„Marek podejmie decyzję”.

Tydzień później:

„Marek jeszcze analizuje”.

Po kolejnym tygodniu:

„Marek chce dodatkowych danych”.

Dlatego dobra definicja powinna brzmieć:

„Marek podejmuje decyzję do czwartku do 15:00 na podstawie wariantów przygotowanych przez zespół”.

Dzięki temu proces ma zakończenie.

Ustal, jakie informacje są potrzebne do podjęcia decyzji

Często problemem nie jest brak decydenta, tylko brak jasności, czego potrzebuje.

Zamiast przygotowywać 40-slajdową prezentację, można ustalić prosty zestaw:

• wariant A,
• wariant B,
• koszt obu,
• wpływ na termin,
• najważniejsze ryzyka,
• rekomendacja zespołu.

Decydent nie musi znać każdego szczegółu operacyjnego.

Potrzebuje danych pozwalających świadomie wybrać.

Zawsze wskazuj rekomendację

Zespół często popełnia taki błąd:

„Przygotowaliśmy cztery opcje. Prosimy zdecydować”.

To przerzuca całą analizę na osobę zatwierdzającą.

Znacznie lepiej przedstawić:

„Rekomendujemy wariant B, ponieważ skraca termin o trzy tygodnie przy akceptowalnym zwiększeniu kosztu. Wariant A pozostaje rozwiązaniem oszczędniejszym”.

Decydent nadal może wybrać inaczej.

Otrzymuje jednak opinię osób, które pracowały nad problemem.

Ostateczna decyzja nie musi oznaczać jednomyślności

Zespół może nie zgadzać się z wyborem i nadal prawidłowo go realizować.

W przeciwnym razie każda decyzja wymagałaby pełnego konsensusu, co w większej organizacji może być praktycznie niemożliwe.

Dobra kultura projektowa powinna pozwalać powiedzieć:

„Rekomendowałem inne rozwiązanie, ale decyzja została podjęta. Realizujemy ustalony wariant”.

To znacznie bardziej efektywne niż otwieranie tej samej dyskusji na każdym kolejnym spotkaniu.

Zapisuj decyzje, nie tylko zadania

W wielu projektach istnieje świetna lista zadań, ale po kilku miesiącach nikt nie pamięta, dlaczego wybrano dane rozwiązanie.

Dlatego warto prowadzić prosty rejestr decyzji.

Może zawierać:

• datę,
• temat,
• osobę decyzyjną,
• rozważane opcje,
• podjętą decyzję,
• krótkie uzasadnienie,
• ewentualny termin ponownej weryfikacji.

To chroni przed dyskusją:

„Kto właściwie zdecydował, że to robimy?”

Tablica decyzyjna może sprawdzić się przy pracy stacjonarnej

Jeżeli zespół pracuje wspólnie w jednym biurze, część kluczowych decyzji można wizualizować na tablicy.

Przykładowe kolumny:

DO DECYZJI

CZEKAMY NA DANE

DECYZJA DO

ZDECYDOWANE

Na każdej karcie wystarczy wpisać temat i osobę zatwierdzającą.

Materiał zawiera linki afiliacyjne. Możemy otrzymać prowizję za zakup dokonany po przejściu przez taki link. Nie wpływa to na cenę produktu dla kupującego.

Do takiego zastosowania może przydać się magnetyczna tablica suchościeralna 60 × 90 cm. Można podzielić ją na prosty rejestr otwartych decyzji, przypisać nazwiska i terminy, a po spotkaniu szybko zaktualizować status.

Nie jest oczywiście potrzebna zespołowi pracującemu całkowicie zdalnie. W takim przypadku podobny rejestr lepiej prowadzić we wspólnym narzędziu cyfrowym. Ważna jest nie forma, lecz to, żeby informacje były dostępne dla wszystkich.

Co zrobić, gdy dwóch dyrektorów uważa, że to oni decydują?

To klasyczny problem organizacyjny.

Nie powinien być rozwiązywany przez kierownika projektu poprzez zgadywanie, kto ma „większą władzę”.

Trzeba wrócić do struktury odpowiedzialności.

Sprawdź:

• kto jest sponsorem projektu,
• kto odpowiada za budżet,
• kto odpowiada za dany obszar biznesowy,
• jaki zakres kompetencji został formalnie przypisany obu osobom.

Jeżeli to nadal nie daje odpowiedzi, potrzebna jest eskalacja o poziom wyżej.

Najgorszym rozwiązaniem jest prowadzenie równoległych rozmów z obiema osobami i realizowanie tej decyzji, która została wypowiedziana jako ostatnia.

Co jeśli sponsor nie chce podejmować decyzji?

Zdarza się również sytuacja odwrotna.

Sponsor mówi:

„Dogadajcie się między sobą”.

Przy drobnych sprawach może to być rozsądne.

Jeżeli jednak zespół ma realny konflikt dotyczący zakresu, pieniędzy albo ryzyka, sponsor powinien wykonać swoją rolę.

Warto wtedy nie eskalować samego problemu, lecz przedstawić wybór.

Zamiast:

„Nie możemy się dogadać”.

Lepiej:

„Mamy dwa warianty. Zespół techniczny rekomenduje A, sprzedaż B. A kosztuje mniej, B skraca wdrożenie o miesiąc. Potrzebujemy decyzji do środy”.

Taką sprawę znacznie łatwiej rozstrzygnąć.

Zasada „decyduje większość” nie pasuje do każdego projektu

Głosowanie może sprawdzać się przy wyborze:

• terminu spotkania,
• nazwy wewnętrznej inicjatywy,
• miejsca integracji.

Nie powinno automatycznie decydować o:

• ryzyku prawnym,
• bezpieczeństwie,
• budżecie,
• architekturze technicznej,
• zobowiązaniach wobec klienta.

Pięć osób bez odpowiedzialności budżetowej nie powinno przegłosować jednej osoby, która formalnie odpowiada za milionowy wydatek.

Mechanizm decyzji musi pasować do jej rodzaju.

Prawne i bezpieczeństwa „nie” może działać inaczej niż zwykła opinia

Nie wszystkie role konsultacyjne są równe.

Jeżeli dział prawny wskazuje, że rozwiązanie narusza przepisy, nie jest to zwykła preferencja porównywalna z opinią o kolorze interfejsu.

Podobnie może wyglądać kwestia cyberbezpieczeństwa, ochrony danych czy bezpieczeństwa fizycznego.

Dlatego przed projektem trzeba ustalić, w jakich obszarach konkretne funkcje mają rzeczywiste prawo zatrzymania wdrożenia.

Takie wyjątki powinny być opisane wcześniej.

Decyzję można delegować

Dyrektor nie musi osobiście podejmować każdej decyzji należącej do jego obszaru.

Może delegować uprawnienie.

Warto jednak określić granice.

Przykład:

„Lider produktu może samodzielnie podejmować decyzje dotyczące zakresu, o ile nie zwiększają budżetu i nie przesuwają premiery o więcej niż tydzień”.

To daje zespołowi szybkość bez utraty kontroli.

Co zrobić, gdy decydent jest niedostępny?

Urlop jednej osoby nie powinien zatrzymać całego projektu.

Przy kluczowych rolach dobrze ustalić zastępstwo.

Na przykład:

Approver: Anna

podczas nieobecności: Piotr

Nie oznacza to, że każda decyzja musi zostać natychmiast podjęta przez zastępcę.

Przy pilnych sprawach zespół wie jednak, do kogo się zwrócić.

Ustal również ścieżkę eskalacji

Nie każda decyzja zostanie podjęta na podstawowym poziomie.

Może pojawić się spór, którego wyznaczony decydent nie ma prawa rozstrzygnąć.

Dlatego warto ustalić:

poziom 1 — lider projektu

poziom 2 — sponsor

poziom 3 — komitet sterujący lub zarząd

Dzięki temu eskalacja nie wygląda jak osobisty konflikt.

Jest normalną częścią procesu.

Nie eskaluj wszystkiego

Przeciwieństwem braku eskalacji jest wysyłanie każdej różnicy zdań do dyrektora.

To również blokuje projekt.

Zanim sprawa trafi wyżej, zespół powinien odpowiedzieć:

Czy decyzja przekracza nasze uprawnienia?

Czy wykorzystaliśmy dostępne informacje?

Czy rzeczywiście istnieją dwie nierozstrzygalne opcje?

Czy znamy konsekwencje obu?

Dopiero wtedy eskalacja ma sens.

Dobra karta decyzji może mieć tylko siedem pól

Nie trzeba tworzyć skomplikowanego formularza.

Wystarczy:

Temat: co trzeba zdecydować?

Decydent: kto ma ostatnie słowo?

Termin: do kiedy?

Opcje: jakie są realne możliwości?

Rekomendacja: co proponuje zespół?

Konsekwencje: koszt, czas, ryzyko.

Decyzja: co ostatecznie wybrano?

Taki zapis można przygotować w kilka minut.

Praktyczny test przed rozpoczęciem projektu

Weź pięć przykładowych sytuacji.

Na przykład:

Projekt przekracza budżet o 10%.

Kto decyduje?

Zespół chce przesunąć premierę o miesiąc.

Kto decyduje?

Marketing chce usunąć jedną funkcję.

Kto decyduje?

Pojawia się ryzyko prawne.

Kto może zatrzymać projekt?

Trzeba wybrać jedną z dwóch technologii.

Kto ma ostatnie słowo?

Jeżeli przy każdym pytaniu zespół od razu wskazuje konkretną osobę, struktura jest prawdopodobnie czytelna.

Jeżeli odpowiedź za każdym razem brzmi:

„to zależy”,

potrzeba dokładniejszego podziału odpowiedzialności.

Najgorsze rozwiązanie to komitet, w którym wszyscy mają ostatnie słowo

Komitet może dobrze zbierać perspektywy.

Może również formalnie podejmować określone decyzje, jeżeli taki model został świadomie przyjęty.

Problem zaczyna się wtedy, gdy do zatwierdzenia potrzebna jest nieformalna zgoda wszystkich uczestników.

Jedna nieobecna osoba zatrzymuje projekt.

Jedna wątpliwość otwiera całą dyskusję od początku.

Nikt nie chce powiedzieć „decyduję”, bo odpowiedzialność została rozmyta.

Jeżeli decyzja rzeczywiście ma należeć do grupy, zasady głosowania lub zatwierdzania również powinny zostać jasno opisane.

Ustal reguły przed pierwszym poważnym konfliktem

Najlepszy moment na opisanie decyzyjności to początek projektu.

Wystarczy krótkie spotkanie.

Zespół ustala:

1. jakie typy decyzji będą występowały,
2. kto przygotowuje rekomendacje,
3. kto jest konsultowany,
4. kto podejmuje ostateczne decyzje,
5. jakie istnieją limity finansowe i czasowe,
6. kiedy sprawę trzeba eskalować,
7. gdzie zapisujemy rezultat.

Nie trzeba przewidzieć każdej sytuacji.

Chodzi o stworzenie mechanizmu, który pozwoli rozstrzygnąć również te nieprzewidziane.

Najważniejsza jest jedna osoba z jasno określoną odpowiedzialnością

Projekt nie przyspiesza dlatego, że mniej osób zabiera głos.

Przyspiesza wtedy, gdy wszyscy wiedzą, jaka jest rola ich głosu.

Eksperci dostarczają wiedzę.

Kierownik projektu prowadzi proces.

Interesariusze przedstawiają potrzeby.

Osoba odpowiedzialna podejmuje decyzję.

Pozostali wiedzą, kiedy decyzja została zakończona i przechodzą do realizacji.

Jeżeli po spotkaniu zespół nadal pyta: „czy to już jest ostateczne?”, problemem najczęściej nie jest brak kolejnego spotkania. Problemem jest brak jasno wskazanej osoby, która może powiedzieć: „tak, decyzja została podjęta”.