Podrozdział 3. Budowa harmonogramu projektu.

Z całą pewnością każdy widział w życiu jakiś harmonogram. Przychodzi mi na myśl najstarszy zapamiętany harmonogram: wakacje, młodzież szkolna na zorganizowanym obozie stacjonarnym, wizyta w stołówce i lektura jadłospisu. Formalnie rzecz biorąc jest to harmonogram: zawiera informację o zadaniach do wykonania (czyli wydawanie określonych posiłków) i o czasie ich realizacji (czyli kiedy należy wykonać procedurę „jedzenie posiłku”). Inny przykład. Program kilkudniowej wycieczki: data i godzina wyjazdu, przejazd, zakwaterowanie od–do, program pobytu (co i kiedy zwiedzamy, kiedy czas wolny itd.), godzina zwalniania pokojów, planowana godzina wyjazdu do domu, planowany przyjazd i zakończenie wycieczki – to także przykład harmonogramu.

Sposobów zapisu harmonogramu jest kilka. Dla ilustracji zagadnienia prezentuję dwa sposoby: tabelaryczny i graficzny. Pierwszy z nich zawiera daty w zapisie kalendarzowym bezpośrednio w wierszu dotyczącym konkretnego działania. Drugi różni się tym, że daty kalendarzowe stanowią nagłówki kolumn tabeli, a czas realizacji działania zapisany jest graficznie w postaci poziomej linii przez odpowiednie komórki tabeli.

Przykłady harmonogramu w wersji [1] :

• tabelarycznej (fragment autentycznego harmonogramu aktualizacji strategii przedsiębiorstwa):
·

Lp.	Działania	Komórka odpowiedzialna	Termin realizacji	Termin wykonania	Uwagi
1.	Spotkanie DK z Zarządem w celu przedstawienia harmonogramu działań związanych z tworzeniem i wdrażaniem strategii	DK	13.05
2.	Szkolenie dla pracowników DK Strategiczne Zarządzanie Firmą – teoria, narzędzia, praktyka	Biuro Szkoleń	20–21.05		szkolenie realizowane przez Biuro Szkoleń
3.	Zebranie informacji o konsultantach zewnętrznych ds. tworzenia i wdrażania strategii	DK	do 24.05		minimum 3 propozycje
4.	Przedstawienie Zarządowi przebiegu wyboru konsultanta zewnętrznego oraz propozycji składu Zespołu ds. Tworzenia Strategii	DK	25.05
5.	Zorganizowanie spotkań z proponowanymi konsultantami zewnętrznymi	DK	31.05–7.06		Zarząd zostanie poinformowany o terminach spotkań w celu ewentualnego wzięcia udziału
6.	Złożenie wniosków na Zarząd o dokonanie wyboru konsultanta zewnętrznego i wyrażenie zgody na podpisanie umowy z wybranym konsultantem	DK/DP	8.06
7.	Wybór konsultanta zewnętrznego Powołanie Zespołu ds. Tworzenia Strategii	Zarząd	10.06 lub 17.06
8.	Pierwsze spotkanie z cyklu „Strategiczne czwartki” – spotkanie/szkolenie interesariuszy z konsultantem zewnętrznym w celu zapoznania ich z zasadami tworzenia i wdrażania strategii	DK/Konsultant zewnętrzny	23.06		Szkolenie odbędzie się przy udziale Zarządu
9.	Cykliczne spotkania z Zarządem w celu prezentowania prac nad tworzeniem strategii	DK	24.06 8.07 22.07 05.08 19.08 2.09 16.09		Orientacyjnie co 2 tygodnie

Wprawdzie ten sposób zapisu harmonogramu zawiera wszystkie potrzebne informacje, niemniej jednak jest mało czytelny „na pierwszy rzut oka”, a wprowadzanie zmian choć proste, nie gwarantuje zachowania spójności harmonogramu, rozumianej jako zachowanie właściwej kolejności działań. Gdy projekt jest prosty, a tabela mieści się na jednej stronie A4, można posługiwać się takim zapisem. To jednak raczej rzadkość. Warto zwrócić uwagę na dwie kolumny w tym zapisie: „komórka odpowiedzialna” i „termin wykonania”. Pierwsza od razu ustala, kto odpowiada za terminowe i zgodne z zakresem wykonanie działania. Tego w przykładzie nie widać, ale wstawienie tej kolumny wynika z wcześniejszego skorzystania przez zespół projektowy z narzędzia zwanego „macierzą odpowiedzialności”. Dwie kolumny z terminami przedstawiają plan i miejsce na zapis terminu rzeczywistego wykonania. Pozwala to na śledzenie wykonania planu dla każdego działania z osobna, a jednocześnie terminy planowane składają się na harmonogram bazowy, czyli ten, względem którego będą ustalane różnice pomiędzy planem a realizacją. Warto również zwrócić uwagę na stopień szczegółowości zapisu – jest on dość ogólny, pozbawiony wielu detali. Przykład: punkt 5 i 6. Po spotkaniu z kandydatami na konsultantów zewnętrznych DK musi opracować wnioski z tych spotkań, dokonać oceny ofert, przygotować dokumentację dla zarządu w odpowiednim formacie – czyli co najmniej kilka osób będzie zaangażowanych, jednak dla tego zespołu projektowego te działania to poziom procedur i kultury organizacyjnej, a nie poziom planu projektu, więc te działania nie są wpisane jawnie do harmonogramu;

• graficznej (przykład wymyślony na potrzeby tego opracowania):



W tej formie zapisu harmonogram jest prostą tabelą, która w pierwszej kolumnie zawiera opis zadania, a pozostała część to kalendarz, gdzie na tle prostokątów symbolizujących kolejne dni projektu narysowane są poziome kreski (belki) wskazujące na realizację danego działania. Za autora tego pomysłu powszechnie uznawany jest Henry Gantt (choć nieco wcześniej Polak Karol Adamiecki działał z sukcesem w tym obszarze nauk o zarządzaniu), stąd popularne w literaturze określenia „harmonogram Gantta” lub „harmonogram belkowy”.

Wielu ludzi mylnie utożsamia stworzenie harmonogramu belkowego z pełnym planem zarządzania projektem. Trudno o większy błąd metodyczny, ponieważ widząc sam harmonogram nie da się stwierdzić, czy został on po prostu „narysowany spod dużego palca”, czy jest wynikiem złożonego działania zespołu projektowego, przy czym działanie to stanowi część metodyki. Ma to swoje konsekwencje podczas realizacji projektu: harmonogram „narysowany, bo zarząd chce go szybko mieć” stanie się nieaktualny zaraz po rozpoczęciu realizacji projektu i zacznie wręcz przeszkadzać. Harmonogram będący wynikiem działań metodycznych, choć również może stać się nieaktualny, będzie pomocą w pracy zespołu, ponieważ informacje wykorzystane do jego przygotowania pozostaną w głowach członków zespołu ukierunkowując ich działania naprawcze. Poza tym harmonogram stanowi wprawdzie istotną, ale tylko jedną z wielu części pełnego planu projektu i nie da się go zastąpić namiastką harmonogramu.

Pamiętaj: harmonogram w układzie Gantta jest niemal bezwartościowy, jeżeli nie powstał jako wynik procesu SPP, a diagram tylko został tak „narysowany”.

Wróćmy na chwilę do prostej metodyki. Masz Strukturę Podziału Prac. Ułożyłeś diagram sieciowy (oczywiście zrobiłeś to z zespołem). Oszacowałeś pracochłonność i czas realizacji zadania. Na tej podstawie – jako wynik procesu – skonstruowałeś harmonogram. I co – oddychasz z ulgą, że gotowe? No to mamy problem, sam prosisz się o kłopoty w fazie realizacji. Teraz jest szansa na dopracowanie i optymalizację harmonogramu. Jeżeli pierwszy ułożony harmonogram pasuje do twojego terminu końcowego, to mam dla ciebie dwie propozycje. Pierwsza – oddaj projekt kandydatowi na menedżera projektu (o ile jesteś w 100% pewny swojej pracy, to jest za proste zadanie dla ciebie, niech się młodzież uczy). Druga: przyjrzyj się swojej pracy, bo prawie na pewno gdzieś jest błąd – może pominąłeś jakieś zadanie, może jest błąd oszacowania czasu, a może plan działań jest skonstruowany z potężnym zapasem czasu? Obie propozycje zbadaj starannie przed podjęciem decyzji.

Jednak najczęściej przewidywany na podstawie harmonogramu czas ukończenia projektu przekracza zakładany termin końcowy. Tu znów dwie propozycje. Pierwsza – przyjrzyj się terminowi końcowemu; czy musi taki być? Jaka jest przyczyna/przyczyny wyznaczenia takiej, a nie innej daty? Jeżeli jest to widzimisię zleceniodawcy, to może da się przekonać zdaniem „ten termin jest nie do przyjęcia, ponieważ…” – i tu wspierasz się argumentami. Jeżeli data końcowa jest nie do ruszenia (na przykład przygotowujesz występ artystyczny zespołu), to nie ma wyjścia: trzeba analizować harmonogram i skrócić go. Od czego zacząć? Od ścieżki krytycznej.

Warto przyjrzeć się poniższemu rysunkowi.



Rysunek przedstawia diagram sieciowy modelowego projektu. Praca zaczyna się od zadania A trwającego 4 dni, kończy się wykonaniem zadania P trwającego 3 dni. Od A do P można przejść kilkoma drogami, na przykład ACLFP lub AEHMP, ale tylko zaznaczona czerwonym kolorem ścieżka ADFLP ma szczególną cechę: jest najdłuższa. To jest właśnie ścieżka krytyczna, a metodykę bazującą na śledzeniu tej ścieżki nazywa się Metodą Ścieżki Krytycznej (ang. CPM – Critical Path Method). Warto sprawdzić samodzielnie: przejście ścieżki krytycznej trwa 22 dni, a jest to tożsame z czasem trwania całego projektu – przy przyjętych założeniach szybciej projektu wykonać się po prostu nie da. To ma dalsze konsekwencje, teraz już oczywiste. Każde wydłużenie realizacji zadania leżącego na ścieżce krytycznej „popycha” wszystkie następujące za nim tak, że przesuwa jednocześnie datę zakończenia projektu. Każde skrócenie zadania leżącego na ścieżce krytycznej skróci czas realizacji projektu. Ale uwaga – po każdym takim cięciu trzeba ponownie sprawdzić, czy skracane zadanie nadal leży na ścieżce krytycznej – ta bowiem jest kapryśna i chętnie zmienia swój przebieg przez sieć diagramu następstwa zdarzeń. Oczywiście skracanie czasu trwania zadania leżącego poza ścieżką krytyczną nie ma żadnego wpływu na termin końcowy, szkoda więc czasu i zachodu na nieproduktywne działanie.

Wróćmy jednak do rozważań na temat skracania czasu realizacji projektu. Po to między innymi wyznaczona jest ścieżka krytyczna – najpierw refleksja, czy któregoś zadania nie da się skrócić. A może da się któreś długie zadanie zgrabnie podłączyć inaczej w diagramie sieciowym i wypadnie ono ze ścieżki krytycznej? Dwa zadania ustawione szeregowo jedno za drugim ustawić równolegle i realizować współbieżnie? Coś zrobić trzeba – nawet ograniczyć zakres projektu, skracając jednocześnie listę zadań i na nowo ułożyć diagram sieciowy. Możliwości jest wiele, któraś na pewno przyniesie pożądany efekt skrócenia czasu realizacji. Masz jeszcze jedno wyjście – przyjąć nierealny harmonogram i liczyć na cud. Jednak cuda zdarzają się rzadko i nigdy na żądanie. Wybór należy do ciebie. Konsekwencje twoich wyborów też. Dobrą reputację menedżera zdobywa się latami, a utracić ją można w kilka tygodni.

Czym jeszcze jest harmonogram? Z całą pewnością jest narzędziem kontroli realizacji projektu. Ta funkcja jest oczywista. Praca podzielona na logiczne etapy i części, przypisana odpowiedzialność za wykonanie, konkretne daty od–do, graficzna postać ułatwiająca ogarnięcie całości jednym rzutem oka. Czym jeszcze? Mniej widoczną funkcją jest kontrakt. Zespół poświęcił mnóstwo pracy tworząc harmonogram, optymalizując go, uwzględnił wszystkie rozpoznane zagrożenia. Podpisał się pod tymi ustaleniami. Czyli – zawarł kontrakt ze zleceniodawcą. Złożył jawną deklarację: jesteśmy gotowi wykonać ten projekt zgodnie z planem stworzonym przez nas. Zespół składa w ten sposób jednoznaczną deklarację wiary w sukces projektu. Czym jeszcze? Pisemnym dowodem pracy zespołowej. To ludzie robią projekty. Po pierwsze – sam plan projektu jest pracą zespołową. Po drugie: realizacja projektu też jest pracą zespołową. Gdyby ktoś miał wątpliwości, niech popatrzy na harmonogram – każdy robi swój kawałek roboty w porozumieniu z innymi i w koordynacji z innymi. Nie wcześniej, nie później. We właściwym czasie. A czym harmonogram nie jest? Z pewnością nie jest lekiem na całe zło, na błędy w komunikacji, brak zdecydowania menedżera projektu, źle rozpoznane potrzeby odbiorców produktów projektu, niewłaściwe praktyki zarządzania, nadmierną wiarę w moc sprawczą procedur… Można by jeszcze długo wyliczać, ale po co? Dobry harmonogram jest przydatny i kropka.

Pytanie kontrolne: mamy gotowy harmonogram, jednak w trakcie realizacji projektu jedno z zadań realizowane jest dwukrotnie dłużej niż on przewiduje, na przykład cztery tygodnie zamiast planowanych dwóch. Jaki wpływ ma to opóźnienie na termin końcowy? Prawidłowa odpowiedź brzmi: nie wiadomo. Na podstawie takich informacji, mając do dyspozycji harmonogram życzeń i marzeń sklecony naprędce, określenie tego wpływu jest niemożliwe. Natomiast w przypadku harmonogramu opartego o strukturę podziału prac i diagram następstwa zdarzeń można uzyskać wiarygodną odpowiedź w rodzaju: nie ma wpływu, opóźnienie wyniesie 4 dni, opóźnienie wyniesie pełne dwa tygodnie, o ile nie zostaną podjęte inne kroki zaradcze itp. w zależności od położenia tego zadania na ścieżce krytycznej lub obok niej.

W najpopularniejszym sposobie prezentacji harmonogram belkowy zawiera podstawowe informacje: co jest do zrobienia i kiedy planujemy to zrobić. Jeśli więc kultura organizacyjna w dowolny sposób premiuje działanie kosztem planowania, to mamy problem. Brak zaplanowanego czasu przeznaczonego na wykonanie planu projektu skutkuje naciskiem na rozpoczęcie realizacji. Jakiż więc problem wpisać w pierwszą kolumnę tabeli co chcemy zrobić, a potem mniej więcej „na oko” pociągnąć poziome kreski w obszarze kalendarza? Łatwość takiego podejścia jest jednak pułapką. Tak skonstruowany harmonogram ma niewielką wartość praktyczną, może również przynieść poważne szkody, zwłaszcza gdy jest załącznikiem do umowy i stanowi podstawę do ewentualnego naliczania kar umownych za opóźnienia w projekcie. Szkicować harmonogram można, a nawet należy, na etapie sporządzania Dokumentu Inicjującego Projekt. Na etapie szczegółowego planowania projektu takie podejście jest po prostu niedopuszczalne.

Jeśli masz Dokument Inicjujący Projekt, masz za sobą szacowanie czasu realizacji poszczególnych zadań, zbudowałeś z zespołem Diagram Sieciowy, to możesz zabrać się do konstruowania sensownego harmonogramu.

Dla zobrazowania podejścia do kolejnych kroków w konstruowaniu harmonogramu sięgnąłem do jednej z podstawowych metodyk zarządzania projektami. PMBoK zaleca następujące materiały wejściowe do tego procesu [2] :

1. Aktywa procesów organizacyjnych (czyli to, co masz do dyspozycji w ramach firmy).
2. Deklaracja zakresu projektu (pokrewnym pojęciem jest Dokument Inicjujący Projekt lub zamiennie Karta Projektu, dowolnie sformalizowany opis tego, co ma być zrobione).
3. Lista działań (rezultat Struktury Podziału Prac)
4. Właściwości działań (czytaj: „Da się to zrobić, jeżeli zostaną spełnione następujące warunki: ……”).
5. Diagramy sieciowe harmonogramu projektu (ustalenie kolejności działań lub inaczej następstwo zdarzeń).
6. Wymagania dotyczące zasobów działań (opisy wymagań dotyczących osób, sprzętu i materiałów, których potrzebujesz, i dostępności tychże zasobów).
7. Kalendarze zasobów (kiedy są dostawy, kiedy dostajesz do dyspozycji osoby lub sprzęt i tym podobne).
8. Oszacowania czasu działań (czyli: gdy spełnione są warunki dostępności zasobów oraz wymagania jakościowe dotyczące tych zasobów, to działanie prawdopodobnie będzie trwało przez zadeklarowany czas).
9. Plan kierowania projektem – rejestr ryzyk (wszystkie powyższe informacje mogą, choć nie muszą być modyfikowane przez znane ryzyka związane z działaniem; ryzyk nieznanych i tak nie da się wpisać do projektu, choć da się nimi zarządzać przez rezerwy czasu, pieniędzy i plany zarządzania zmianami w projekcie).

Mając materiały wyjściowe zespół projektowy buduje właściwy harmonogram, przekładając dni robocze zapisane w diagramie sieciowym na konkretne daty kalendarzowe, z uwzględnieniem sobót, niedziel i dni świątecznych. To ciekawe: czasochłonność projektu na etapie diagramu następstwa zdarzeń i szacowania zostaje na przykład wyliczona na 150 dni, a po przełożeniu na kalendarz wychodzi 6 miesięcy – niejednemu decydentowi trudno to zaakceptować. Jak to, przecież miało być pięć miesięcy a nie sześć! No tak, byłoby pięć miesięcy pod warunkiem pracy na okrągło, najlepiej na trzy zmiany.

Po raz pierwszy w planie projektu pojawiają się konkretne daty kalendarzowe. Przy czym są dwa zalecane i jeden niezalecany sposób podejścia do tej pracy. Pierwszy, zalecany: ustalamy datę początkową projektu, data końcowa wynika z harmonogramu. Drugi, zalecany: ustalamy datę końcową projektu i szukamy odpowiedzi na pytanie „Kiedy trzeba zacząć, aby zdążyć na wyznaczony termin końcowy?”. Trzeci, niezalecany: ustalamy sztywno datę początkową i końcową, projekt ma się zmieścić w tych datach ustalonych na podstawie arbitralnej decyzji zarządu.

W praktyce pojawiają się wszystkie trzy modele i trzeba być na to przygotowanym. W pierwszym modelu nieuniknione jest pytanie zarządu: „Dlaczego tak długo?”. W drugim pytaniu często pojawia się problem: „Jesteśmy na etapie planowania, a z harmonogramu wynika, że powinniśmy mieć już za sobą 20% wykonanej roboty”, bo mamy na przykład marzec i planujemy pracę, a z harmonogramu wynika rozpoczęcie projektu w połowie stycznia. W trzecim modelu pojawia się chaos. Jakie jest lekarstwo? Optymalizacja harmonogramu.

W diagramie sieciowym można prześledzić różne ścieżki zdarzeń od punktu startowego do końcowego. Jedna z tych ścieżek (może się rozwidlać) jest najdłuższa, na jej realizację przewidziane jest najwięcej dni roboczych. Taka ścieżka nazwana jest ścieżką krytyczną. Ma ona pewne szczególne cechy. Długość tej ścieżki wyznacza czas trwania projektu. Jeżeli w czasie realizacji projektu dojdzie do opóźnienia realizacji któregoś z zadań leżących na ścieżce krytycznej, to o tyle samo przesunie się termin końcowy projektu (o ile nikt nie podejmie działań naprawczych). Skrócenie czasu trwania jednego z zadań na ścieżce krytycznej skróci przewidywany czas realizacji projektu (o ile ścieżka krytyczna nie zmieni swojego przebiegu wskutek tych zmian). Optymalizacja harmonogramu polega na cyklicznym powtarzaniu czterech kroków tak długo, aż otrzymany rezultat zostanie zaakceptowany:

• Przyjrzeć się ponownie strukturze podziału prac w zakresie zadań leżących na ścieżce krytycznej. Czy te zadania są dobrze określone? Czy można któreś z nich połączyć ze sobą? Może któreś da się wykreślić bez szkody dla celów projektu? Czy jakieś długie zadanie da się podzielić na mniejsze i krótsze, tak aby dały się wykonywać równolegle?
• Przyjrzeć się ponownie oszacowaniom czasu trwania zadań leżących na ścieżce krytycznej. Jakie są realne możliwości skrócenia któregoś z nich? Może dodatkowe zasoby? Może wyspecjalizowany podwykonawca?
• Przyjrzeć się ponownie diagramowi następstwa zdarzeń. Czy każde zadanie leżące na ścieżce krytycznej musi być połączone z zadaniami poprzedzającymi i następującymi w przyjęty sposób? Może da się przenieść powiązania pomiędzy zadaniami tak, aby któreś z zadań zostało wyłączone ze ścieżki krytycznej?
• Ponownie przeliczyć zmieniony diagram sieciowy i przenieść dane do harmonogramu.

Akceptowalne są dwa rozwiązania (skrajne – istnieje wszak wiele wariantów pośrednich). Pierwsze z nich: udało się zredukować czas trwania projektu i spełnić wymagania zleceniodawcy. Drugie z nich: zoptymalizowaliśmy harmonogram do maksimum i dalej termin końcowy jest nieakceptowany – należy renegocjować terminy ze zleceniodawcą, ponieważ przy przyjętych założeniach harmonogram jest niewykonalny, a próba jego dotrzymania na siłę może się skończyć wyłącznie przegraną.

Oczywiście takie proste rozumowanie możliwe jest jedynie przy podejściu deterministycznym – każde zadanie ma przypisaną konkretną wartość trwania. Takie podejście ma swoje wady i zalety. Zaletą jest niewątpliwie prostota narzędzia połączona z łatwością użycia. Główną wadą jest – mówiąc delikatnie – niskie prawdopodobieństwo dokładnego spełnienia tej prognozy. Niemniej jednak opracowania dla małych i średnich projektów jest w sam raz. Sięganie po bardziej złożone metodyki byłoby już raczej strzelaniem z armaty do wróbla.

W praktyce pojawia się jeszcze ten trzeci model: „papier jest cierpliwy i wszystko przyjmie, stworzyliśmy niewykonalny harmonogram bo tak chciał zarząd, jak zaczniemy realizację projektu to coś się wymyśli”. Czasem się to sprawdza, ale częściej jest to gotowy przepis na klęskę projektu. Jak mawiał niejaki Murphy, Jeśli coś może pójść źle, to pójdzie.

Gdyby jednak ktoś uważał, że to koniec pracy planistów nad harmonogramem, wyprowadzę go z błędu. SPP – Diagram sieciowy – Harmonogram to początek cyklu. Jeżeli teraz nie zostanie przeprowadzona analiza obciążeń zasobów, w szczególności ludzkich, harmonogram nie będzie dobry. Jeżeli stworzony na podstawie harmonogramu i budżetu wykres przepływu gotówki (Cash Flow) wykaże okresowe niedobory finansowe, harmonogram nie będzie dobry. Jeżeli analiza ryzyk wykaże konieczność dodatkowych działań zabezpieczających, Struktura Podziału Prac okaże się niekompletna, a w harmonogramie zabraknie rezerw czasu na obsługę tych ryzyk. Dopiero tak wielostronnie przepracowany harmonogram jest dobrym punktem wyjścia do realizacji projektu.

Wniosek końcowy: zapisy w planie projektu mają charakter autorski zespołu opracowującego ten plan – to on decyduje o ostatecznym kształcie planu, który będzie realizował. Nie da się tego całkowicie sformalizować; plan ma spełniać ogólne wytyczne organizacyjne i metodyczne, ale szczegółowość struktury podziału prac wynika z decyzji zespołu, a nie z metodyki. To ma także swoje konsekwencje finansowe i czasowe. Zbyt szczegółowy harmonogram wymaga znacznych nakładów pracy (i pieniędzy) przy śledzeniu realizacji i kolejnych jego aktualizacjach po wprowadzeniu zatwierdzonych zmian. To może okazać się przeszkodą w codziennej pracy, skutkującą zaniechaniem aktualizacji harmonogramu (ze szkodą dla projektu). Z drugiej strony zbyt ogólny opis działań w harmonogramie wymusza dodatkową pracę w trakcie realizacji, polegającą na uszczegółowieniu granic między działaniami, co umożliwia między innymi prawidłową ocenę zaawansowania realizacji projektu. Utrzymywanie przez menedżera projektu zdroworozsądkowej równowagi między nadmierną szczegółowością a uogólnianiem, wsparte doświadczeniem jest możliwe.

Aby uświadomić rolę autorskiego podejścia do SPP i harmonogramu, przytoczę przykład. Jedna firma (liczba osób zatrudnionych korporacji znacznie powyżej 5000 pracowników, firma wysoko notowana na warszawskiej Giełdzie Papierów Wartościowych), szkolenie dla średniej–wyższej warstwy menedżerów zarządzających, a więc zbliżone doświadczenie zawodowe, to samo otoczenie pracy, ta sama kultura organizacyjna, te same procesy, procedury i wymagania. Podczas szkolenia utworzono kilka zespołów projektowych. Przypadkiem (to nie było wymagane) wszystkie zespoły wybrały do dalszych ćwiczeń taki sam cel projektu z praktycznie takim samym zakresem rzeczowym. W dodatku co najmniej 80% uczestników szkolenia taki właśnie projekt realizowało w ramach swoich obowiązków służbowych co najmniej raz. W efekcie powstały dość znacznie różniące się struktury podziału prac oraz zupełnie różne diagramy sieciowe – to właśnie ilustracja autorskiej (przypisanej do zespołu) swobody decydowania co najmniej o SPP i diagramie sieciowym. Uczestnicy porównali efekty pracy poszczególnych zespołów i mocno się zdziwili, widząc ile znaleźli różnic. W dalszym toku szkolenia pojawiły się poważniejsze różnice w szacowaniu kosztów i pracochłonności, tak więc na zakończenie uczestnicy dysponowali kilkoma różnymi planami takich samych projektów.

Pytanie, czy to metodyka wspomaga zarządzanie pracami w projekcie, czy też menedżer projektu premiowany jest za precyzję przechodzenia przez kolejne etapy metodyki, a projekt realizowany jest nieco na uboczu. Szczególnie sprzyjające warunki do takiej anomalii pojawiają się (twierdzę tak na podstawie własnego doświadczenia zawodowego) w urzędach publicznych i instytucjach administracyjnych. Przełożeni byli w stanie racjonalnie ocenić staranność działania menedżera projektu głównie na podstawie lektury opasłych raportów i przeglądania prostych tabelek. Szef-urzędnik doceniający sukces rzeczowy osiągnięty w projekcie przy drobnych odchyleniach od procedury prawdopodobnie nie istnieje.

Ponieważ to plan projektu ma wspierać osiąganie jego celów, a zespół projektowy ma osiągnąć cel, to zasadne jest pozostawienie maksimum decyzji co do sposobu wykonania pracy właśnie temu zespołowi, który będzie wykonywał pracę. W końcu celem projektu nie jest perfekcyjna realizacja planu, tylko osiągnięcie celów. Metodyka ma wspierać realizację projektu, a nie przeszkadzać. Nigdy nie uczestniczyłem w projekcie, w którym celem było udowodnienie perfekcji stosowania metodyki, natomiast znam niestety sponsorów projektu, którzy wyżej cenią poprawność metodyczną niż skuteczność zarządzania mierzoną osiągniętymi wynikami.