Statystyki co roku są podobne. Co roku równie smutne i nie napawające nadzieją. Źródłowe przyczyny niezmienne i wciąż te same. Apele i nawoływania zdają się na nic i pozostają bez echa. Czy chodzi o statystyki utonięć w czasie kolejnych wakacji? A może o liczbę wypadków drogowych w czasie trwania policyjnej „Akcji Znicz”? Nic podobnego.


Każdego roku firma doradcza PM Solutions Inc. ankietuje 160 firm i ponad 20 tysięcy przeprowadzonych przez te firmy projektów. Tzw. „powodzeniem” zakończyła się mniej niż połowa przedsięwzięć a blisko 40% skończyło jako „ewidentne porażki”. Codzienne rozmowy z wyższą kadrą kierowniczą, nie tylko firm branży IT, potwierdzają tę smutną prawdę o projektach, które osiadły na mieliźnie.

I co roku wszyscy zastanawiamy się głośno „dlaczego tak się dzieje”?

Jest pięć zasadniczych przyczyn, niezmiennych od wielu lat, z powodu których projekty zbaczają z kursu i osiadają na mieliźnie:

  1. niejasno sprecyzowane wymagania;
  2. brak wykwalifikowanych i odpowiedniej jakości zasobów;
  3. nierealistyczne i zbyt optymistyczne harmonogramowanie;
  4. błędne dane i niedokładne szacowanie i planowanie;
  5. niezidentyfikowane ryzyka.


Pomimo tego, że kadra kierownicza i społeczność kierowników projektów doskonale zdają sobie sprawę z przyczyn porażek projektów, niewiele podejmuje się działań na rzecz poprawy sytuacji.

– Świadomość przyczyn porażek jest ważna i należy o tych przyczynach pamiętać. Jednak naprawdę kluczowa dla sukcesu projektu jest umiejętność właściwego zdiagnozowania, oceny i szybkiej reakcji w sytuacji, gdy pojawiają się przesłanki, że projekt może osiąść na mieliźnie. Wydaje się, że większość, a przynajmniej niektóre projekty w firmach, udałoby się uratować, gdyby organizacje wiedziały jak to zrobić – mówi George Sifri, znany w międzynarodowym środowisku ekspert w dziedzinie zarządzania projektami, trener i główny konsultant Management Training & Development Center (MT&DC) oraz instruktor TwentyEighty Project Execution z Waszyngtonu.

Jest kilka sygnałów, które kwalifikują projekt do bycia zagrożonym i te sygnały nie muszą występować łącznie:

  1. odchylenie powyżej 15% realizacji harmonogramu i budżetu;
  2. trudności z określeniem faktycznego terminu zakończenia projektu;
  3. powstający produkt posiada wiele usterek;
  4. zespół projektowy stale pracuje powyżej 60 h tygodniowo;
  5. relacje pomiędzy interesariuszami są napięte;
  6. zespół projektowy pracuje pod presją i ma obniżone morale;
  7. klient wyraża swoje niezadowolenie i straszy podjęciem działań prawnych.


Niestety, o tym że projekt jest zagrożony dowiadujemy się często zbyt późno, czasami nawet dopiero gdy zbliża się termin jego zakończenia… Dlaczego tak się dzieje? Jeśli kierownik takiego tonącego projektu nie może liczyć na wsparcie w organizacji, lecz najwyżej na ciągłą krytykę i „stawianie na dywanik”, będzie dążył do tego, aby jak najdłużej ukrywać problemy w nadziei, że sam jakoś je rozwiąże.

Pamiętajmy też, że przyszłość projektu jest zawsze w rękach sponsora. To sponsor zadecyduje o jego dalszych losach. Ratowanie zagrożonego projektu jest trudne, drogie i bolesne – sponsorzy bardzo nie lubią takich sytuacji, więc musimy znać odpowiedź na pytanie czy tonący projekt jest w ogóle wart ratowania?

– Jeżeli projekt jest zagrożony z powodów „politycznych” to podejmowanie kroków naprawczych nie ma najmniejszego sensu, gdyż nie będziemy w stanie zapewnić najważniejszego – pełnego poparcia najwyższego kierownictwa – ostrzega George Sifri.

Z moich rozmów z szefami firm IT wynika, że bardzo często i w wielu projektach pojawiają się sygnały wskazujące na zagrożenia, lecz niezmiernie rzadko podejmowane są skoordynowane i ubrane w proces działania naprawcze.

Co ciekawe, firmy posiadają metodyki prowadzenia projektów, wytwarzania oprogramowania czy dostarczania produktów, lecz rzadko zdarza się, aby posiadały metodykę ratowania zagrożonych projektów. A takie usystematyzowane podejście może znacznie poprawić statystki, o których wspominałem na początku artykułu.

O podejściu do ratowania projektu mówi John Buxton, były kierownik programu w Siłach Powietrznych USA, trener MT&DC oraz TwentyEighty Project Execution: – Liczy się czas i szybkie podejmowanie decyzji. Precyzyjna ocena faktycznego stanu zaawansowania projektu – zgodnie z zasadą „100% done” zrobione-niezrobione, jest-nie ma, działa-nie działa. Pomiędzy kamienie milowe do harmonogramu wprowadzamy kamienie calowe. Należy działać bardzo szybko i sprawnie, ale zarazem delikatnie, pamiętając, że oceniamy stan projektu, a nie pracę ludzi. Dlatego bardzo często rekomenduję powołanie „projektu ratunkowego” działającego na rzecz „projektu ratowanego” a wszystkie prace odbywają się w tzw. War Roomie, sztabie kryzysowym pod nadzorem kierownika projektu ratunkowego. W takiej sytuacji kluczowe jest ustalenie relacji pomiędzy kierownikami projektu ratowanego i ratunkowego oraz podbudowanie morale zespołu projektowego. Nie trzeba nikogo przekonywać, że zestresowani, zrezygnowani i nie angażujący się z własnej woli pracownicy stanowią niepotrzebny balast, który ciągnie taki tonący okręt na dno.

George Sifri konstatuje: – Moje 30-letnie doświadczenia w pracy na projektach wskazują jednoznacznie, że aby skutecznie uratować projekt należy:

  • ograniczyć zakres projektu – wszędzie tam gdzie jest to możliwe;
  • zwiększyć wydajność – wszędzie tam gdzie jest to możliwe;
  • komunikować zmiany i opóźnienia – wszystkim, których one dotyczą;
  • zdobyć i utrzymać poparcie Sponsora – w każdych okolicznościach.