Najczęstsze wyzwania w zarządzaniu projektami

Najczęstsze wyzwania w zarządzaniu projektami nie wynikają wyłącznie z niewłaściwego harmonogramu. Problemy pojawiają się wtedy, gdy niejasny jest cel, zmienia się zakres, brakuje zasobów, decyzje trwają zbyt długo, a ryzyka i zależności zostają zauważone dopiero wtedy, gdy powodują opóźnienie.

Skuteczne zarządzanie projektem nie polega na unikaniu wszystkich problemów. W praktyce jest to niemożliwe. Chodzi o stworzenie sposobu pracy, który pozwala wcześnie wykrywać odchylenia, oceniać ich wpływ i podejmować decyzje zanim niewielki problem zacznie wpływać na cały projekt.

PMI w najnowszym PMBOK Guide podkreśla właśnie wartość, adaptacyjność i odpowiedzialność jako istotne elementy współczesnego zarządzania projektami.

1. Niejasny cel projektu

Jednym z najpoważniejszych problemów jest rozpoczęcie realizacji bez wystarczającej jasności, jaki rezultat projekt właściwie ma osiągnąć.

Cel:

wdrożyć nowy CRM

opisuje rozwiązanie.

Lepszy cel:

ograniczyć ręczne przepisywanie danych pomiędzy sprzedażą a obsługą klienta i stworzyć jedno źródło informacji o kliencie

wyjaśnia, jaki problem biznesowy ma zostać rozwiązany.

Ta różnica ma znaczenie przy podejmowaniu późniejszych decyzji.

Jeżeli pojawia się propozycja nowej funkcjonalności, można zapytać:

czy pomaga osiągnąć rezultat projektu?

Bez jasno określonego celu każda propozycja może wydawać się równie ważna, a projekt stopniowo zamienia się w zbiór niezależnych oczekiwań.

PMI wskazuje brak zgodności projektu z celami organizacji oraz niewystarczające planowanie jako jedne z powtarzających się przyczyn problemów projektowych.

Co zrobić?

Na początku ustal:

• problem, który projekt rozwiązuje,
• oczekiwany rezultat,
• kryteria sukcesu,
• najważniejsze ograniczenia,
• osoby odpowiedzialne za decyzje.

Cel powinien być na tyle konkretny, aby można było używać go do oceny kolejnych decyzji.

2. Nieprecyzyjny zakres projektu

Niejasny zakres prowadzi do konfliktów dotyczących tego, co właściwie miało zostać dostarczone.

Zespół może zakładać, że określona funkcjonalność nie należy do projektu, podczas gdy klient traktuje ją jako oczywisty element rozwiązania.

Problemy pojawiają się szczególnie wtedy, gdy wymagania:

• są ogólne,
• występują wyłącznie w wiadomościach i rozmowach,
• nie mają kryteriów akceptacji,
• są różnie interpretowane przez zainteresowane strony.

PMI zwraca uwagę, że nieprecyzyjne wymagania i brak uzgodnienia zakresu utrudniają stworzenie rozwiązania spełniającego oczekiwania oraz zwiększają ryzyko niekontrolowanego rozszerzania projektu.

Jak ograniczyć problem?

Nie chodzi o stworzenie setek stron dokumentacji.

Trzeba przede wszystkim uzgodnić:

co dostarczamy → czego nie dostarczamy → kiedy uznajemy rezultat za zaakceptowany

W projektach, w których zakres może ewoluować, powinien istnieć również jasny mechanizm jego aktualizacji.

3. Scope creep – projekt rośnie bez kontroli

Scope creep to niekontrolowane rozszerzanie zakresu projektu bez odpowiedniej zmiany czasu, budżetu lub dostępnych zasobów.

Zaczyna się często niewinnie:

• dodajmy jeszcze jedno pole,
• skoro robimy raport, przygotujmy drugi,
• klient potrzebuje małej modyfikacji,
• ta funkcja zajmie przecież tylko chwilę.

Każda zmiana osobno może być niewielka. Problemem jest ich skumulowany wpływ.

PMI definiuje scope creep właśnie jako niekontrolowane rozszerzanie zakresu bez odpowiedniego dostosowania czasu, kosztu i zasobów.

Zmiana zakresu nie jest sama w sobie problemem

Projekt może i powinien reagować na nowe informacje.

Klient może odkryć nową potrzebę. Mogą zmienić się regulacje. Pilotaż może pokazać, że wcześniejsze założenie było błędne.

Problemem jest zmiana bez analizy wpływu.

Każda istotna propozycja powinna prowadzić do pytania:

Jeżeli to dodamy, co zmieni się w terminie, koszcie, zakresie, ryzyku albo innych priorytetach?

PMI podkreśla, że dobrze zarządzana zmiana może poprawić rezultat projektu, podczas gdy niekontrolowany scope creep powinien być ograniczany.

4. Opóźnienia i nierealistyczny harmonogram

Nie każde opóźnienie oznacza, że zespół pracuje zbyt wolno.

Harmonogram może być błędny już w momencie zatwierdzenia.

Typowe przyczyny to:

• nieuwzględnione zależności,
• zbyt optymistyczne estymaty,
• brak czasu na testy i poprawki,
• pominięcie oczekiwania na decyzje,
• nieuwzględnione zamówienia i dostawy,
• jednoczesne wykorzystanie tych samych osób w kilku projektach.

Szczególnie często pomijany jest czas oczekiwania.

Praca może wymagać dwóch dni wykonania, ale cały etap trwać dwa tygodnie, ponieważ zadanie czeka kolejno na decyzję, dane, review i akceptację.

Co pomaga?

Zamiast obserwować tylko końcową datę projektu, sprawdzaj wcześniej:

• kamienie milowe,
• zadania znajdujące się na ścieżce krytycznej,
• zależności zewnętrzne,
• elementy długo pozostające bez zmiany,
• decyzje oczekujące na zatwierdzenie.

Nie czekaj na moment, w którym cały projekt jest już opóźniony.

5. Brak odpowiednich zasobów

Projekt może być dobrze zaplanowany, ale niewykonalny przy dostępnej obsadzie.

Problem nie zawsze oznacza po prostu zbyt małą liczbę pracowników.

Może brakować konkretnej kompetencji.

Przykład:

projekt ma dziesięć osób, ale tylko jedna może zatwierdzić architekturę rozwiązania.

Wtedy ograniczeniem nie jest wielkość zespołu, lecz jedna zależność kompetencyjna.

Podobny problem pojawia się, gdy te same osoby są współdzielone pomiędzy wieloma inicjatywami.

Na papierze każdy projekt ma dostęp do specjalisty. W praktyce specjalista stale przełącza się między zadaniami i staje się wąskim gardłem.

Jak reagować?

Trzeba sprawdzać nie tylko liczbę osób, ale także:

• dostępność kompetencji,
• obciążenie kluczowych specjalistów,
• zależność od pojedynczych osób,
• pracę wykonywaną równolegle,
• zapotrzebowanie na kompetencje w kolejnych etapach.

Czasami lepszym rozwiązaniem niż dodanie kolejnych osób jest ograniczenie liczby rzeczy wykonywanych jednocześnie.

6. Konflikt priorytetów między projektami

To szczególnie częsty problem w organizacjach prowadzących wiele inicjatyw równocześnie.

Projekt A jest priorytetem.

Projekt B również jest priorytetem.

Projekt C musi zostać wykonany pilnie.

Wszystkie wykorzystują tych samych ludzi.

W efekcie pracownicy nieustannie zmieniają kontekst, a project managerowie konkurują o zasoby.

PMI wymienia brak priorytetyzacji pomiędzy projektami jako jeden z powtarzających się problemów organizacji projektowych.

Co zrobić?

Priorytety muszą działać również wtedy, gdy dwa projekty potrzebują tego samego zasobu.

Jeżeli wszystko jest najwyższym priorytetem, organizacja w rzeczywistości nie posiada priorytetów.

Przydatne jest ustalenie na poziomie portfolio:

• które inicjatywy mają pierwszeństwo,
• które mogą poczekać,
• gdzie nie wolno rozpoczynać kolejnego projektu bez zwolnienia zasobów.

7. Problemy z komunikacją

Problemem nie jest zwykle brak wiadomości.

W projektach często jest ich wręcz za dużo.

Problemem jest brak właściwej informacji u właściwej osoby we właściwym momencie.

Przykład:

Developer wie, że termin integracji jest zagrożony.

Project manager dowiaduje się o tym tydzień później.

Klient otrzymuje informację dopiero w dniu planowanego wdrożenia.

Każda osoba w projekcie posiadała fragment wiedzy, ale komunikacja nie doprowadziła do odpowiednio wczesnej decyzji.

PMI wskazuje, że problemy komunikacyjne wpływają m.in. na rozumienie odpowiedzialności, zakresu, aktualnego stanu oraz możliwość wczesnego reagowania na negatywne trendy.

Dobra komunikacja projektowa odpowiada na pytania:

• kto potrzebuje informacji,
• jakiej informacji,
• kiedy,
• kto odpowiada za jej przekazanie,
• gdzie znajduje się aktualna wersja ustaleń.

Nie każdy interesariusz potrzebuje tego samego raportu.

Zespół wykonawczy potrzebuje konkretów operacyjnych. Sponsor częściej potrzebuje informacji o rezultacie, ryzyku, budżecie i decyzjach wymagających jego udziału.

8. Brak zaangażowania interesariuszy

Projekt może mieć sprawny zespół i nadal utknąć, jeśli osoby potrzebne do decyzji nie angażują się w odpowiednim momencie.

Typowa sytuacja:

zespół pracuje przez trzy miesiące → przedstawia rezultat → kluczowy interesariusz pierwszy raz dokładnie ogląda rozwiązanie → okazuje się, że oczekiwania były inne.

Problemem nie jest tylko komunikacja.

Problemem jest zbyt późna walidacja.

PMI wskazuje zarządzanie interesariuszami jako silnie powiązane z zarządzaniem zakresem i oczekiwaniami projektu.

Jak ograniczyć ryzyko?

Nie ograniczaj interesariuszy do listy adresatów raportu.

Określ:

• kto zatwierdza,
• kto posiada istotną wiedzę,
• kto będzie korzystał z rezultatu,
• kto może zablokować wdrożenie,
• kto ponosi konsekwencje zmiany.

Następnie ustal, w którym momencie projektu potrzebujesz zaangażowania każdej z tych osób.

9. Zbyt wolne podejmowanie decyzji

Projekt może być zablokowany nie dlatego, że brakuje rozwiązania, ale dlatego, że nikt nie wie, kto może je zatwierdzić.

Decyzja przechodzi przez:

managera → dyrektora → dział prawny → bezpieczeństwo → sponsora.

Każdy etap dodaje czas oczekiwania.

Problem nasila się, gdy brak jasnych progów decyzyjnych.

Nawet niewielka zmiana trafia wtedy na najwyższy poziom organizacji.

Rozwiązanie

Warto wcześniej określić:

zespół może zdecydować o X

project manager o Y

sponsor musi zatwierdzić Z

Dzięki temu odpowiedzialność za decyzje znajduje się możliwie blisko miejsca, w którym istnieje potrzebna wiedza.

Eskalacja powinna służyć wyjątkowym sytuacjom, a nie być podstawowym sposobem prowadzenia projektu.

10. Niewłaściwe zarządzanie ryzykiem

Ryzyko nie jest problemem, który już wystąpił.

Jest zdarzeniem lub warunkiem, który może wpłynąć na projekt w przyszłości.

Przykład:

Ryzyko: kluczowy dostawca może opóźnić dostawę.

Problem: dostawca właśnie potwierdził miesięczne opóźnienie.

Rejestr ryzyk nie daje wartości, jeżeli powstaje na początku projektu i nikt później do niego nie wraca.

Dobre zarządzanie ryzykiem wymaga:

1. identyfikacji,
2. oceny prawdopodobieństwa i wpływu,
3. właściciela,
4. reakcji,
5. regularnej aktualizacji.

PMI podkreśla, że projekty zawsze zawierają ryzyko, a brak aktywnego zarządzania nim zwiększa podatność projektu na problemy.

Szczególną uwagę zwracaj na zależności

Nie wszystkie największe ryzyka znajdują się wewnątrz zespołu.

Projekt może zależeć od:

• dostawcy,
• innego systemu,
• zespołu infrastruktury,
• decyzji regulatora,
• migracji wykonywanej w innym projekcie.

Zależności powinny być widoczne tak samo jak własne zadania zespołu.

11. Niekontrolowane zmiany

Zmiana zakresu to tylko jeden rodzaj zmiany projektowej.

Zmienić może się:

• harmonogram,
• budżet,
• technologia,
• dostawca,
• zespół,
• sposób wdrożenia,
• wymaganie prawne,
• model operacyjny.

Dlatego projekt potrzebuje prostego procesu zarządzania zmianą:

zgłoszenie → analiza wpływu → decyzja → aktualizacja planu → wdrożenie → weryfikacja

Zmiana powinna być oceniana nie tylko pod kątem kosztu.

Trzeba uwzględnić jej wpływ na harmonogram, ryzyko, jakość i pozostałe elementy projektu. PMI zaleca właśnie takie szersze spojrzenie na zmianę zamiast utożsamiania change management wyłącznie z zakresem.

Nie należy przy tym budować procedury tak ciężkiej, że zespół zacznie ją omijać.

12. Problemy z jakością zauważane zbyt późno

Projekt może wyglądać dobrze na dashboardzie:

• zadania zamykane,
• kamienie milowe realizowane,
• budżet pod kontrolą.

A następnie na końcu pojawia się duża liczba poprawek.

Powodem może być traktowanie jakości jako ostatniego etapu, zamiast części całego procesu.

Przykład w projekcie software’owym:

development → development → development → kilka tygodni testów → ogromna kolejka błędów.

Podobny mechanizm występuje poza IT. Jeżeli rezultat jest sprawdzany dopiero przed finalnym odbiorem, koszt poprawy jest zwykle większy.

Lepsze podejście

Weryfikuj rezultat stopniowo.

Może to oznaczać:

• częstsze review,
• wcześniejsze testowanie,
• kryteria akceptacji,
• pilotaż,
• kontrolę jakości na kolejnych etapach,
• szybki feedback użytkowników.

Celem jest wykrycie problemu jak najbliżej momentu jego powstania.

13. Brak kontroli nad zależnościami

Wiele projektów nie opóźnia się z powodu własnej pracy.

Zespół czeka na:

• API innego systemu,
• decyzję prawną,
• zakup licencji,
• infrastrukturę,
• dane od klienta,
• zakończenie innego projektu.

Jeżeli zależności są traktowane jak zwykłe zadania, łatwo stracić je z pola widzenia.

Każda krytyczna zależność powinna mieć:

• właściciela,
• oczekiwany termin,
• wpływ na projekt,
• sposób monitorowania,
• plan reakcji w przypadku opóźnienia.

To szczególnie istotne w dużych projektach obejmujących kilka zespołów i dostawców.

14. Zbyt dużo raportowania, za mało zarządzania

Project manager może spędzić znaczną część tygodnia na:

• kopiowaniu danych,
• aktualizowaniu prezentacji,
• zbieraniu statusów,
• przepisywaniu informacji między systemami.

Problemem nie jest sam raport.

Problem pojawia się wtedy, gdy przygotowywanie informacji zaczyna zabierać czas potrzebny do ich analizy i podejmowania decyzji.

Raport powinien przede wszystkim wskazywać:

• odchylenia,
• ryzyka,
• decyzje,
• zależności,
• problemy wymagające reakcji.

Jeżeli dashboard ma 40 wskaźników, ale nie wiadomo, co należy zrobić po jego przeczytaniu, nie wspiera zarządzania projektem.

Jak automatyzacja może ograniczyć problemy projektowe?

Nie wszystkie wyzwania rozwiązuje się narzędziem.

Można jednak ograniczyć pracę administracyjną wokół projektu.

Automatyzacja może wspierać:

• aktualizację statusów,
• przypomnienia o terminach,
• routing zgłoszeń,
• rejestrowanie change requestów,
• alerty o blokadach,
• synchronizację Jira, Asany, CRM i innych systemów,
• przygotowanie dashboardów,
• zbieranie danych do raportów,
• eskalację po przekroczeniu ustalonego czasu.

Przykład:

change request → formularz → nadanie ID → przypisanie analizy → decyzja → aktualizacja statusu → powiadomienie interesariuszy

Nie trzeba ręcznie pilnować każdego przekazania.

Automatyzacja nie powinna jednak podejmować za ludzi decyzji o zakresie, ryzyku czy priorytecie tylko dlatego, że technicznie można zbudować taką regułę.

Agile, podejście klasyczne czy hybrydowe nie usuną problemów projektu

Nie istnieje metoda zarządzania, która automatycznie rozwiąże brak celu, niewystarczające zasoby czy konflikt interesariuszy.

Podejście powinno zostać dobrane do rodzaju projektu.

W środowisku o dużej niepewności pomocne może być częstsze dostarczanie i zdobywanie feedbacku.

W projekcie o stabilnym zakresie i silnych zależnościach fizycznych więcej wartości może dawać szczegółowe planowanie z wyprzedzeniem.

Wiele organizacji łączy oba sposoby.

Aktualny PMBOK Guide 8 również odchodzi od przedstawiania jednej obowiązkowej metody prowadzenia wszystkich projektów i podkreśla adaptacyjność oraz możliwość działania w różnych podejściach i środowiskach.

Najważniejsze nie jest więc pytanie:

Agile czy Waterfall?

Najpierw trzeba ustalić:

jakiego rodzaju niepewność, zależności i ryzyko występują w tym konkretnym projekcie?

Jak wcześnie rozpoznać, że projekt zaczyna mieć problemy?

Najlepiej reagować na sygnały poprzedzające kryzys.

Niepokojące są sytuacje, gdy:

• terminy regularnie przesuwają się bez aktualizacji planu,
• zakres rośnie, ale budżet i czas pozostają bez zmian,
• coraz więcej pracy jest rozpoczęte, a mało kończone,
• te same problemy pojawiają się na kolejnych spotkaniach,
• decyzje długo oczekują na zatwierdzenie,
• rośnie liczba poprawek,
• kluczowe osoby są przeciążone,
• interesariusze mają różne rozumienie celu,
• nikt nie potrafi wskazać właściciela ważnego ryzyka,
• raporty pokazują zielony status mimo widocznych problemów.

PMI wskazuje podobne sygnały ostrzegawcze w obszarach harmonogramu, kosztu, jakości, ryzyka, zasobów i komunikacji.

Co zrobić, gdy projekt już ma problemy?

Nie zaczynaj od tworzenia nowego harmonogramu.

Najpierw ustal stan faktyczny.

1. Przywróć jedno źródło informacji

Ustal aktualny:

• zakres,
• harmonogram,
• koszty,
• otwarte problemy,
• ryzyka,
• zależności.

Bez tego różne osoby mogą ratować różne wersje tego samego projektu.

2. Oddziel objaw od przyczyny

Opóźnienie jest często objawem.

Przyczyną może być brak decyzji, scope creep, niedostępny specjalista albo rosnąca liczba poprawek.

3. Znajdź największe ograniczenie

Nie próbuj poprawiać wszystkiego jednocześnie.

Jeżeli cały projekt czeka na jedną integrację, optymalizacja innych zadań nie odzyska terminu.

4. Podejmij decyzję o kompromisie

Czasami nie da się zachować jednocześnie:

• pełnego zakresu,
• pierwotnego terminu,
• tego samego budżetu.

Wtedy trzeba jawnie zdecydować, co zmieniamy.

Udawanie, że wszystkie trzy parametry nadal są możliwe, tylko przesuwa problem.

5. Zaktualizuj plan i zakomunikuj zmianę

Nowy plan musi stać się oficjalnym punktem odniesienia.

Ukrywanie problemu przed sponsorem lub klientem zwykle ogranicza dostępne możliwości reakcji.

Zamiast walczyć z każdym problemem, popraw system zarządzania projektem

Najlepszym sposobem na ograniczenie wyzwań projektowych nie jest tworzenie procedury na każdą możliwą sytuację.

Warto mieć kilka prostych mechanizmów:

jasny cel → widoczny zakres → właściciele decyzji → monitorowane ryzyka → kontrolowane zmiany → regularna weryfikacja rezultatu

Do tego potrzebna jest możliwość zauważenia problemu bez tworzenia kultury, w której ludzie boją się przekazać złą wiadomość.

Projekt, w którym problem jest widoczny wcześnie, ma znacznie więcej możliwości reakcji niż projekt, w którym wszystko pozostaje zielone aż do tygodnia przed terminem.

Dlatego przy kolejnym projekcie warto zacząć nie od wyboru narzędzia czy frameworka, lecz od pięciu pytań:

1. Jaki rezultat chcemy osiągnąć?
2. Co dokładnie znajduje się w zakresie?
3. Kto może podejmować najważniejsze decyzje?
4. Od jakich osób, systemów i projektów jesteśmy zależni?
5. Po jakich sygnałach poznamy, że projekt zaczyna odchodzić od planu?

Jeżeli odpowiedzi są jasne, znaczna część późniejszych wyzwań staje się łatwiejsza do wykrycia i opanowania.