Podrozdział 9. Ocena i monitorowanie wykonania projektu.

Trzecia faza cyklu życia projektu – realizacja.

Mamy dobry, rzetelny, przedyskutowany plan realizacji projektu. Zapadła decyzja o uruchomieniu działań. Ludzie pracują, produkty powstają, ale gdzie tak naprawdę jesteśmy w naszym projekcie i dokąd zmierzamy?

Monitorowanie realizacji projektu polega na ciągłym porównywaniu planu z rzeczywistością. Planowanie monitorowania jest dość proste, wykonanie tego monitoringu – już nie. Potrzebne są zaledwie trzy kroki metodyczne: należy zebrać informacje o stanie zaawansowania zadań, przetworzyć je i wykorzystać do sterowania dalszym przebiegiem projektu.

Zbieranie informacji.

W trakcie wykonywania projektu zużywane są zasoby rzeczowe, praca ludzi oraz środki finansowe. W wyniku podejmowanych działań mają powstawać produkty pośrednie i końcowe projektu. W zbieraniu informacji pomocna jest Struktura Podziału Prac, a raczej lista zadań z przypisanymi zasobami. Jeszcze ważniejszy jest harmonogram, ponieważ pozwala na graficzne zobrazowanie postępów w projekcie. Przedstawia to poniższy rysunek .



Na harmonogramie bazowym (pierwszym) naniesiono informacje o postępach realizacji projektu na koniec czwartego tygodnia. Jaśniejsze paski to planowany czas realizacji, a ciemne poniżej – rzeczywiste dane dotyczące pracy nad zadaniami. Prosta konwencja, a ile informacji. W następnym tygodniu obraz będzie oczywiście inny.

Zadanie pierwsze zostało rozpoczęte z opóźnieniem i trwało dłużej niż planowano. Zadanie drugie wprawdzie zostało rozpoczęte zgodnie z planem, ale i tu realizacja trwała dłużej niż zaplanowano. Zadanie trzecie – inna sytuacja: poślizg na starcie, ale realizacja zgodnie z planem. Zadanie czwarte rozpoczęte z opóźnieniem i niezakończone; pozostałe zadania nierozpoczęte. To jest wynik przetworzenia surowej informacji otrzymanej od wykonawców na jeden obraz prosty do ogarnięcia.

Pora na wykorzystanie otrzymanej informacji:

• Osoba odpowiedzialna za szacowanie zadania 1 i 2 prawdopodobnie była nadmiernym optymistą, natomiast szacujący zadanie 3 trafił. Należy wykorzystać tą informację przy szacowaniu zadań w następnym projekcie, ale absolutnie nie należy karać osoby, która popełniła błąd, ani nagradzać tej, która trafiła. Członkowie zespołu mają nie tylko prawo do mylnych szacunków, ale i do popełniania błędów. Przykre konsekwencje trzeba jednak zarezerwować, ale użyć ich wyłącznie wobec osób winnych świadomego zaniechania bądź błędnego działania.
• Należy dojść do źródła przyczyny opóźnień w rozpoczynaniu zadań – czy to był jednostkowy błąd, czy też błąd systematyczny. Pierwszy nie wymaga dalszych działań. Zdarzyło się – ludzie to nie komputery i nie zawsze działają racjonalnie. Jeżeli jednak jest to błąd systematyczny, na przykład wynikający z długich łańcuchów decyzyjnych, należy w ramach zarządzania jakością w projekcie stwierdzić niezgodność i podjąć działania naprawcze w świetle normy ISO 9001.
• W ramach zarządzania integracją projektu należy zbadać, jak opóźnienie wpływa na realizację całego projektu. Wymaga to ponownego przeliczenia harmonogramu z częścią dat zaktualizowanych na realne. Program komputerowy robi to błyskawicznie. Jeżeli opóźnienia są niewielkie i poza ścieżką krytyczną, nie ma problemu. Jeżeli jednak są istotne i dotyczą zadań ze ścieżki krytycznej, należy niezwłocznie podjąć działania naprawcze. Jeżeli da się skompensować opóźnienie skróceniem czasu wykonania następnych zadań, to termin końcowy jest do uratowania. Jeżeli jednak nie, najdalej w połowie projektu wiadomo, co się dzieje i można podjąć rozmowy z zamawiającym na temat zmiany terminu końcowego lub innych działań zgodnie z zasadą złotego trójkąta projektu.

To tylko część wniosków, jakie można wyciągnąć patrząc na harmonogram bazowy z naniesionymi informacjami o realizacji. Jakiej informacji będzie trzeba szukać i jak ona będzie wykorzystana – zależy już od konkretnego projektu, jego otoczenia biznesowego, kultury organizacyjnej i zespołu projektowego.
Uwaga praktyczna: jeżeli opóźnieniu ulegnie zadanie na ścieżce krytycznej, to najprawdopodobniej opóźni się zakończenie projektu; jeżeli realizacja zadania na ścieżce krytycznej ulegnie przyspieszeniu, to taka oszczędność czasu najprawdopodobniej zostanie zmarnowana.

Jak jednak ocenić, ile pracy w danym zadaniu zostało wykonane? Jest co najmniej kilka sposobów rozwiązania tego zadania. Można mierzyć ilość zużytych materiałów i roboczogodzin w stosunku do planu. Można przyjąć jeden ze sposobów kwalifikowania zadań opisanych poniżej. Można też przyjąć oświadczenie osoby odpowiedzialnej za wykonanie zadania, ale z tym wiąże się ryzyko „mitycznych 90%”. O co chodzi? Jeżeli osoba odpowiedzialna za wykonanie zadania ma problem z określeniem rzeczywistych postępów, przyjmie dla uproszczenia planowany czas zadania za 100% i popatrzy w kalendarz: zadanie planowane na 4 tygodnie, działamy już 2 tygodnie, to zaawansowanie wynosi 50%. Pomieszanie z poplątaniem: czas zużyty w stosunku do planowanego nijak ma się do pracy wykonanej w stosunku do planowanej, to chyba oczywiste. Efekt jest taki, że po osiągnięciu 90% tak mierzonego zaawansowania wykonawca zadania będzie powtarzał te 90% tak długo, aż skończy pracę. A więc taka informacja jest bezwartościowa. Stąd sugestia przeformułowania pytania do wykonawcy zadania. Nie warto pytać „ile już zrobiliście?”, ale „ile wam jeszcze trzeba czasu na dokończenie pracy?” – to da wartościową informację o przewidywanym zakończeniu. Nie należy pytać o sprawozdawczość (choć ta też jest potrzebna), ale o prognozy rozwoju sytuacji, ponieważ menedżer projektu ma przewidywać kłopoty i zarządzać przyszłością projektu, zostawiając to, co było, historykom i archiwistom (metaforycznie rzecz jasna, nikt nie zwalnia menedżera projektu z obowiązków raportowania).

W przemyśle kreatywnym podstawową sprawą jest praca wykonana przez osoby zatrudnione w projekcie. Zasoby rzeczowe da się łatwo policzyć – są zestawienia zapotrzebowania, dowody zakupu, dokumenty magazynowe. Z wykonaną pracą jest więcej kłopotu. Jak do tego podejść? Jest kilka sposobów.

Metoda 0/100%

Przy sprawdzaniu zaawansowania prac nie ma kategorii prac w toku. Każde zadanie ma status 0% zaawansowania. W momencie zakończenia działań i przekazania wyników status zadania zostaje zmieniony na 100%. Zaletą tego podejścia do monitorowania realizacji jest prostota. Niewielką wadą jest wyprzedzanie rzeczywistego zaawansowania prac w stosunku do raportu. Błąd jest do pominięcia, jeżeli większość zadań trwa krócej niż jeden cykl raportowania, na przykład „fotografię stanu” robimy raz na miesiąc, a większość zadań nie przekracza 4 tygodni realizacji.

Metoda 50/50%

Przy sprawdzaniu zaawansowania prac zadania nierozpoczęte otrzymują status 0%. Każde zadanie rozpoczęte otrzymuje status 50% niezależnie od rzeczywistego stopnia zaawansowania prac. Status 100% zarezerwowany jest dla zadań ukończonych. To poprawia ocenę stanu zaawansowania projektu w sytuacji krótkich cykli raportowania i dłuższych czasów realizacji zadań, na przykład raporty składamy co tydzień, a większość zadań trwa dłużej.

Metody pokrewne:

Na przykład 30/50/20%. Pełna analogia. Zadanie nierozpoczęte status 0%, zadanie rozpoczęte – status 30%, zadanie przekroczyło półmetek – status 80%. Zadanie zakończone oczywiście 100%.

Dlaczego tyle sposobów podejścia? Po pierwsze – stosując którąś z powyższych metod uproszczamy proces zbierania informacji. Wykonawcy zadań nie są zmuszani do składania wiążących deklaracji o zaawansowaniu prac z dokładnością do jednego procenta. W wyniku tego mniej jest stresu, a i koszty zarządzania projektem maleją. Wniosek: to od konkretnej organizacji, a nawet od konkretnego projektu zależy, czy będzie trzeba posługiwać się droższą informacją dokładną, czy też wystarczy ta tańsza, przybliżona.

W przypadku małych projektów śledzenie wszystkich zadań jest proste. Przy średnich projektach – trudniejsze. Przy dużych ogarnięcie całości jest na granicy ludzkich możliwości. Zaradzono temu problemowi przez wprowadzenie do harmonogramu kamieni milowych – inaczej ruchomych zer. Kamień milowy jest dosłownie punktem w czasie. Jest zadaniem/czynnością w harmonogramie, która jednak nie zużywa żadnych zasobów – dlatego jest zerem w projekcie. Ale kamień milowy, jak każde inne zadanie w harmonogramie, jest połączony z innymi zadaniami w diagramie sieciowym. Oznacza to, że jeśli któreś zadanie wcześniejsze będzie trwało dłużej, to „wykonanie” kamienia milowego opóźni się w czasie. Dobra praktyka zaleca wstawienie do harmonogramu kamieni milowych w ilości kilku procent wszystkich zadań, czyli na każdą setkę średnio 4–6 (nie ma żadnego uwarunkowania, ile konkretnie). Wstawia się je nie w przypadkowych miejscach, a dla zaznaczenia ważnych dla projektu wydarzeń.

Jak wspomniano wcześniej, typów projektów w przemyśle kreatywnym jest wiele, najprościej więc odwołać się do powszechnie znanego modelu budowy domu. W takim projekcie kamienie milowe na pewno pojawią się dla zaznaczenia zakupienia działki, wykonania dokumentacji technicznej, uzyskania pozwolenia na budowę, rozpoczęcia robót, ukończenia stanu surowego i wreszcie uzyskania gotowości do zamieszkania. W sumie góra 10 kamieni milowych dla listy zadań rzędu 500–800. Mając kamienie milowe nie trzeba cały czas śledzić każdego zadania z osobna – wystarczy śledzić daty przypisane osiągnięciu kamieni milowych. W ten sposób raport z realizacji zajmie pół strony wydruku a nie kilkadziesiąt kartek plus okładki. Praktycznie każdy liczący się program komputerowy wspomagający zarządzanie projektami ma funkcjonalność wstawiania kamieni milowych i filtrowania ich położenia w harmonogramie do szablonów raportów. Co to oznacza? Jeżeli wrócimy do przykładu budowy domu, a dokładnie do bloku zadań od pierwszego wbicia łopaty do osiągnięcia stanu surowego, to dopóki budowa będzie wykonywana zgodnie z harmonogramem, nie trzeba śledzić szczegółowo całego bloku zadań – wystarczy chwila na kontrolę daty przypisanej do kamienia milowego. Dopóki ta data jest stała, to prawdopodobnie na budowie dzieje się dobrze. Jeśli na ścieżce krytycznej – nieważne w którym miejscu – wystąpi opóźnienie, data osiągnięcia kamienia milowego również ulegnie przesunięciu. Dzięki takiemu mechanizmowi menedżer projektu podczas sprawdzania stopnia zaawansowania robót może błyskawicznie sprawdzić daty przy kamieniach milowych – jeżeli są stałe, to można iść do dalszej pracy. Jeżeli zaczęły się zmieniać – to inna praca musi poczekać, a menedżer powinien szczegółowo sprawdzić, co jest przyczyną sygnalizowanego opóźnienia. Zyskiem jest zaoszczędzony czas – sprawdzenie kamieni milowych trwa około 2 minut, natomiast szczegółowy przegląd stanu projektu nawet kilka godzin. Tę technikę nazywa się „śledzeniem trendów kamieni milowych”. Jak to wygląda w praktyce? Rysujemy wykres – można dla uproszczenia w tradycyjnej tabeli.



W pierwszej kolumnie tygodnie oznaczają planowany czas w projekcie. W pierwszym wierszu tygodnie oznaczają rzeczywisty czas kalendarzowy w projekcie. Powiedzmy, że mamy w projekcie dwa kamienie milowe wypadające w 5 i 8 tygodniu planowanego trwania harmonogramu. Zaznaczamy tę informację w drugiej kolumnie tabeli, symbolizującej początek projektu. W drugim tygodniu (czyli w trzeciej kolumnie) nanosimy informacje z zaktualizowanego harmonogramu. Powiedzmy, że nic się nie zmieniło. W trzecim tygodniu trwania projektu otrzymaliśmy informację, że pierwszy kamień milowy (nr 5) będzie osiągnięty o tydzień później, ale działania naprawcze pozwolą utrzymać termin drugiego kamienia milowego (nr 8). Czwarty tydzień realizacji (piąta kolumna tabeli) potwierdza utrzymanie prognozy pierwszego kamienia i przewidywane opóźnienie dla drugiego kamienia o tydzień. I tak dalej. Z rysunku widać, że rozwijający się poziomo wykres pozwala na śledzenie kierunku zmian przewidywanych terminów. Jeśli więc menedżer dużego projektu zleci komuś nanoszenie tych informacji na wykres, wchodząc rano do biura potrzebuje jednego rzutu oka na ścianę dla oceny sytuacji w projekcie: jeśli krzywe dotyczące kamieni milowych są poziome, w projekcie prawdopodobnie jest dobrze. Jeśli skręcają ku dołowi – jest świetnie, bo oznacza to przyspieszenie w stosunku do harmonogramu wyjściowego, jeśli jednak rosną do góry, oznacza to, że w projekcie narastają opóźnienia. Taką wygodę śledzenia co się dzieje w projekcie menedżer może teraz przekazać swoim przełożonym w formie jednostronicowego raportu graficznego. Zarząd ma zawsze mało czasu, a to narzędzie do śledzenia stanu projektu proponuje rozwiązanie niewymagające ani dużej wiedzy, ani szczegółowej analizy postępów w projekcie. Prezes robi to samo co menedżer projektu – patrzy na wykres. Jeśli krzywe trendów kamieni milowych rosną w kierunku poziomym lub lekko w dół, zajmuje się inną pracą. Jeśli rosną lekko w górę, wzywa menedżera projektu „na dywanik” celem wyjaśnienia sytuacji. Jeśli ruch w górę jest bardzo szybki, szuka nowego menedżera projektu…

Takich narzędzi pozwalających na graficzne zobrazowanie stanu projektu jest więcej i warto z nich korzystać, ponieważ jedna osoba w ciągu kilku godzin może przygotować skondensowany raport o stanie projektu do wykresu, z którego może skorzystać więcej osób – i tych w zespole projektowym, i tych spoza projektu, zwłaszcza dotyczy to osób decyzyjnych. Jeśli dobrym obyczajem zarządu będzie nagradzanie osób przynoszących rzetelne raporty proste do interpretacji, a karanie osób przedstawiających raporty celowo zagmatwane dla ukrycia złych wiadomości, to pracownicy przestaną się obawiać, a co za tym idzie – ukrywać złe wiadomości - z pożytkiem dla całej organizacji. To tylko jeden drobny przykład, jak wdrożenie metodyki zarządzania projektami może zmieniać całą kulturę organizacyjną, obejmując zmianą także ludzi „nieprojektowych”.

Mamy częściowo rozwiązany problem śledzenia zużycia czasu w połączeniu z prognozą dalszych losów projektu. Są jednak jeszcze inne zasoby, których zużycie należy monitorować, a szczególnie dotyczy to finansów.

Po pierwsze – wcale nie jest tak łatwo zdobyć wszystkie dane o wydatkach związanych z projektem. Część informacji znajduje się w zaopatrzeniu, część w kadrach, część w magazynie i jeszcze w paru innych miejscach. Dlatego ważne jest, aby wszystkie wydatki rejestrować nie tylko w dziale finansowo-księgowym, ale również w archiwum projektu i mieć je zawsze aktualne pod ręką.

Po drugie – badanie zachowania płynności finansowej projektu. Menedżer musi mieć wiedzę dotyczącą nie tylko całkowitej wartości projektu, ale musi również wiedzieć, ile już wydał i czy na koncie projektu jest dość środków, aby kontynuować realizację zadań. Jeżeli dopuści do opróżnienia kasy, projekt zatrzyma się powodując lawinę kłopotów. Wcześniej sygnalizowano potrzebę rozrysowania w projekcie skumulowanych wydatków z uwzględnieniem czasu, określając to jako krzywą Cash Flow (CF). Z wykresu tego łatwo da się odczytać, ile pieniędzy planuje się wydać i kiedy spodziewane są wpływy. Szczególnie istotne jest to przy projektach dofinansowywanych z środków publicznych. Praktyka nie sprzyja ryzykantom. Budując budżet menedżer zakłada wpływy na konto w postaci zaliczki lub transz dotacji. Tymczasem nierzadko zdarzają się opóźnienia wpływów. A to są problemy z akceptacją rozliczenia otrzymanej transzy płatności, a to instytucja finansująca sama ma kłopoty z przepływem gotówki, a to ktoś poszedł na urlop, a zastępca nie dopilnował – powodów mogą być setki, skutek jeden – pieniędzy może zabraknąć, ale projekt nie może zostać zatrzymany z tego powodu. Jeżeli ktoś w zespole pilnie śledzi sprawy finansowe, jest dobrze – da się z wyprzedzeniem przewidzieć kłopoty, co pozwala podjąć działania naprawcze z czasowym wyprzedzeniem – menedżer może zarządzać ryzykiem, a nie kryzysem, a to jak najbardziej wskazane postępowanie. W szczególności podejmowane są działania w kierunku przyspieszenia spływu dotacji, opóźnienia własnych płatności, pozyskania dodatkowych środków bądź jako „pożyczki” z środków własnych organizacji, bądź kredytów czy pożyczek bankowych. Pieniądze na koncie muszą być, wtedy wszystko działa normalnie niezależnie od kłopotów finansowych. Aktywne śledzenie wydatków jest tak samo ważne w przypadku wieloletnich projektów dofinansowywanych transzami, projektów krótkich realizowanych dzięki zaliczkom czy też projektów realizowanych z środków własnych organizacji w połączeniu z późniejszą refundacją. Wprawdzie menedżer projektu odpowiada za projekt, ale skutki finansowe jego działań odczuwa cała organizacja. W przypadku projektu refundowanego – organizacja np. wykłada własne środki, a tu projekt ulega poślizgowi o (banalny!) kwartał; dla dyrektora ekonomicznego nie jest obojętny fakt kwartalnego opóźnienia wpływu refundacji – wypadałoby go na bieżąco informować o takich zakłóceniach niezależnie od podejmowanych działań naprawczych. To pewne powtórzenie, ale warto je ponownie przytoczyć: szczególnie trudno jest w przypadku kultury organizacyjnej nietolerującej posłańców przynoszących złe wieści, gdyż w takiej organizacji sukcesy są nadmiernie eksponowane, a błędy skrzętnie ukrywane – aż będzie za późno i projekt zawali się z hukiem.

Przykład szkoleniowy. Wiemy z harmonogramu, co i kiedy jest do zrobienia, więc na harmonogram nanosimy koszty realizacji każdego zadania. W przykładzie dla uproszczenia założono równomierne rozłożenie kosztów. W rzeczywistości na każde zadanie należy popatrzeć odrębnie. Jeżeli wykonują je ludzie, ich płaca będzie równomiernie obciążać konto projektu. Jeżeli kupujemy jakieś materiały zużywane w projekcie równomiernie, trzeba zdecydować, czy koszty też naliczamy równomiernie, czy – zdecydowanie lepiej – w harmonogram wstawimy przewidywaną datę zapłaty. Na przykład dla zadania trzeciego, którego realizacja przypada w drugim i trzecim tygodniu, potrzebny jest materiał, który wprawdzie kupiony będzie w pierwszym tygodniu, ale dzięki odroczonym terminom płatności faktura zostanie uregulowana jednorazowo w tygodniu piątym. Więc naliczanie równomierne wszystkiego może być źródłem sporych błędów w planowaniu finansowym. Mamy kwoty przypisane do wszystkich zadań wraz z terminami zapadalności. Teraz dla każdego jednostkowego odcinka czasu – tu tygodnia – dokonujemy sumowania w pionie, ile pieniędzy potrzeba w tym tygodniu, aby projekt był realizowany bez przeszkód. I tak przez cały projekt kolumna za kolumną [2] .



Tak otrzymany wynik przenieść należy na wykres CF [3] . Program komputerowy wskazany – ręczna robota tylko przy planowaniu prostych projektów.



Kolejne znakomite narzędzie do śledzenia postępów realizacji projektu, gdzie raz wykonana analiza przez jednego pracownika (powtarzana przy każdym okresie sprawozdawczym) daje jeden wykres i mnóstwo informacji. Prostokąty przy osi odpowiadają tygodniowym wydatkom w projekcie. Wystarczy rzut oka i wiadomo, kiedy trzeba będzie mieć gruby portfel. Krzywa powyżej osi poziomej obrazuje wydatki planowane do poniesienia narastająco. Na dole zobrazowane są wpływy do projektu. Powiedzmy, że otrzymano pierwszą transzę zaliczki i z niej planuje się finansowanie projektu. Przesuwamy więc wykres planowanych wydatków w dół, tak aby zaczynał się nie od zera (pustego portfela), a od kwoty odpowiadającej otrzymanej transzy. Tygodnie mijają, aż w końcu wykres przecina oś „zero w portfelu” i już wiadomo, kiedy zabraknie pieniędzy na kontynuację projektu. Dzięki takiemu rozumowaniu jeszcze na etapie planowania można sprawdzić, czy przewidywane transze dotacji wystarczą do finansowania projektu. To ma co najmniej dwie konsekwencje. Z jednej strony, jeżeli nie chcemy zmieniać planu projektu, wykres jest informacją ile i kiedy trzeba pożyczyć – z banku czy z konta organizacji – aby utrzymać realizację projektu na właściwej drodze. Z drugiej strony, jeśli nie chcemy pożyczać pieniędzy na realizację projektu, można spróbować zmienić plan projektu i związany z nim harmonogram wydatków, tak aby kolejna transza wypadała nieco wcześniej niż krzywa wydatków skumulowanych przetnie oś poziomą (osiągnięte będzie zero w kasie). Może trzeba przesunąć jakieś zadanie, a może naciskać na odroczony termin płatności, albo przyjrzeć się terminom dostaw i opóźnić je tak bardzo jak to jest możliwe. Da się znaleźć wiele rozwiązań pod warunkiem rozpoznania potrzeby takiego działania, a taką potrzebę można zobaczyć właśnie na tym wykresie.

Wspomniałem jednak o narzędziu do śledzenia postępów w projekcie, a tu wciąż o planowaniu. Rozwiązanie tej zagadki jest takie: tak jak na harmonogramie należy nanosić informacje o rzeczywistym wykonaniu zadań, tak na wykresie CF należy nanosić informacje o rzeczywistym wydawaniu pieniędzy. Rzut oka prezesa i dyrektora finansowego na zaktualizowany wykres wystarczy do podjęcia działań. Jeśli krzywa rzeczywistych wydatków skumulowanych pokrywa się z krzywą planowaną – nie ma powodów do niepokoju. Każde odchylenie od planu wymaga głębszej analizy. Jeżeli krzywa wydatków rzeczywistych znajduje się poniżej krzywej wydatków planowanych, to może oznaczać aż dwie możliwości, które mogą zachodzić osobno lub łącznie wymieszane w dowolnych proporcjach: wydajemy mniej pieniędzy, zatem projekt jest tańszy niż planowano (sukces) i/lub wydajemy mniej pieniędzy, ponieważ pracujemy wolniej niż planowano, mamy opóźnienia w projekcie (klęska). Analogicznie jeżeli krzywa wydatków rzeczywistych jest powyżej krzywej wydatków planowanych, może to oznaczać, że przepłacamy za wykonane roboty lub też praca idzie szybciej niż pierwotnie planowano. To nie tak łatwo śledzić trendy wykresu CF jak w przypadku śledzenia trendów kamieni milowych. Trzeba pogłębionej analizy. Może przecież zdarzyć się tak, że roboty będą opóźnione i jednocześnie droższe niż planowano, więc oba nieszczęścia na raz, a otrzymamy na wykresie efekt uspokajającego pokrywania się krzywej wydatków rzeczywistych z krzywą wydatków planowanych. Lekarstwem na te dylematy jest analiza wartości zarobionej/wypracowanej (Earned Value, EV). Metoda ta, oprócz śledzenia sytuacji bieżącej, daje dobre prognozy dotyczące trendów zmian kosztów projektu i przewidywanego końca projektu, jest więc warta wysiłku jej wdrożenia. Wysiłek jest spory, a EV stosowane w praktyce daje wymierne korzyści głównie przy dużych projektach trwających wiele miesięcy. Aby jednak móc użyć EV w projekcie, trzeba najpierw wykonać solidne fundamenty: lista zadań, diagram sieciowy, szacowanie wartości zadań, harmonogram. Szersze omówienie tej metody wykracza jednak poza zakres tego opracowania.

UWAGI KOŃCOWE.

Elastyczne podejście.

Zarządzanie projektami jest elastyczne (Project Management is flexible). Co to oznacza w praktyce? W literaturze czy na kursach i szkoleniach można znaleźć szczegółowe opisy różnych metodyk zarządzania projektem. Jak do tego podejść? Elastycznie. Dlaczego jest aż tyle metodyk? Która jest najlepsza?

Przynajmniej na to ostatnie pytanie można udzielić prostej odpowiedzi: najlepszą metodyką zarządzania projektami jest ta, którą menedżer projektu zna, potrafi jej elastycznie używać i która jest akceptowana przez zespół projektowy. Jak rozumieć takie postępowanie? Znać metodykę, to znaczy znać i zastosować narzędzia wchodzące w jej skład w odpowiedniej kolejności. Elastycznie – to znaczy menedżer projektu nie pomijając żadnego elementu metodyki decyduje, którego narzędzia będzie używał intensywnie, badając wszystkie szczegóły, a którego użyje z mniejszą uwagą. Elastycznie, czyli np. czy zespół stworzy obszerne archiwum projektu (bo takie wymagania są w regulaminie konkursu o dotację ze środków publicznych), czy też ograniczy się do notatek roboczych, ale – stosując się do metodyki – nie pominie żadnego wzorca dokumentu wypełniając go szczegółowo lub… mniej szczegółowo. Kolejny przykład – rejestr ryzyk. Metodyka nakazuje sporządzić takowy i używać podczas planowania i realizacji projektu. Ale metodyka nie precyzuje, czy rejestr ryzyk to zapisana kartka A5, mapa myśli na flipie przyklejona taśmą na ścianie, plik edytora tekstowego, arkusz kalkulacyjny, czy też może element którejś z usług sieciowych. Zadaniem menedżera projektu jest podejście elastyczne: w małym projekcie realizowanym na potrzeby pracodawcy wystarczy kartka papieru i długopis, w dużym „europejskim” projekcie bez komputera się nie obejdzie.

Elastycznie – to znaczy korzystać z najprostszych znanych narzędzi do pracy: jeżeli wystarcza schemat na ścianie i telefon, to nie używamy komputera, jeżeli wystarcza arkusz kalkulacyjny, darmowy program czy usługa internetowa w zakresie harmonogramowania, to nie kupujemy potężnego i drogiego programu komercyjnego. Jeśli jest służbowy nakaz korzystania z firmowego standardowego oprogramowania i szczegółowe rozpisanie obciążenia zasobów (tak zwane timesheet), czyli arkusze ewidencji czasu pracy z rozpisaniem, ile godzin i na co zużył pracownik, to nie ma żadnej dyskusji. Ważne jest, aby menedżer projektu metodykę znał i stosował, a zespół projektowy potrafił pracować zgodnie z nią.

W sektorze IT to właśnie z powodu sprzeczności pomiędzy klasycznymi metodykami zarządzania projektami a stylem pracy zespołów programistycznych narodziły się metodyki lekkie, zwane też zwinnymi (Agile, Scrum). Generalnie zalecane jest, aby młode stażem i doświadczeniem zespoły projektowe bazowały raczej na metodykach klasycznych (choćby i uproszczonych), a dopiero po nabraniu doświadczenia, po poznaniu ograniczeń tych metodyk poznawały te „lekkie”, zachowując jednak podstawowe zachowania: umiejętność formułowania celów krótko- i długoterminowych, wypracowaną kulturę komunikacji, strukturę zespołu, wzajemne zaufanie. Podchodząc do problemu z innej strony: metodyki klasyczne akcentują podział cyklu życia projektu na fazy, konieczność formalizacji i dokumentacji postępowania; metodyki lekkie/zwinne koncentrują się zaś na otrzymaniu produktów projektu przy minimalizacji formalności. Rozsądny i doświadczony menedżer projektu dba o elastyczne zachowanie równowagi pomiędzy formalizacją a produktywnością, biorąc pod uwagę i projekt, i jego otoczenie. Z mojego doświadczenia wynika jednoznacznie: nigdy nie będziesz pewny, który dokument sporządzony w projekcie uratuje ci życie, a który nada się tylko na makulaturę (zwłaszcza po zamknięciu projektu). Możesz tylko przewidywać i zgadywać, który jest który. Oczywiście nie dotyczy to tych dokumentów, które są bezwzględnie wymagane w formacie narzuconym przez instytucję finansującą lub organizację, w ramach której projekt jest realizowany.

Przykład zastosowania elastycznego podejścia prosto z życia. Jeden z obszarów zarządzania projektem: jeszcze raz dotyczy zarządzania ryzykiem.

Używam metodyki w projekcie, który jest bardzo podobny do projektów które już realizowałem. Jestem architektem i projektuję domki jednorodzinne. Właśnie zlecono mi kolejny projekt takiego domku. Mając świadomość stosowania metodyki bazującej na PMBoK obszar zarządzania ryzykiem nie jest dla mnie najważniejszy, ponieważ mam doświadczenie w tego typu projektach i znam ryzyka w nich występujące, więc owszem – zgodnie z metodyką będę zarządzał tymi ryzykami, ale nie przyprawią mnie one o bezsenność. Jeżeli jednak – jako ten sam architekt specjalista od domków jednorodzinnych – otrzymam zlecenie na wykonanie projektu dużego biurowca w centrum miasta – obszar zarządzania ryzykiem w takim projekcie niewątpliwie będzie dla mnie bardzo ważny, ponieważ w trakcie pracy pojawią się nowe, nieznane mi ryzyka, które jednak powinienem przewidywać i którymi muszę zarządzać.

Klasyczne, tak zwane ciężkie metodyki zarządzania projektami (PMBoK, PMI, PRINCE2) pozwalają na „mechaniczne” podejście do projektu, coś na kształt mechanizmu zegara. Mamy cykl życia projektu, podział na fazy (z założenia odrębne, w praktyce przeplatające się), procesy, z których każdy zostaje rozpoczęty, jest prowadzony, a następnie zamykany – niejako rozpatrywany oddzielnie od innych procesów. W rzeczywistości wszystkie te procesy przebiegają równolegle, splatają się ze sobą i oddziaływają wzajemnie na siebie, fazy projektu mają nieostre granice w czasie (rygorystycznie stosowany PRINCE2 wymusza wyraźniejsze zakreślenie granic faz), a w trakcie prac w jednym miejscu planu projektu przeskakiwanie i wprowadzanie zmian w już wydawałoby się wcześniej zamkniętej pracy to norma. Zwłaszcza gdy zleceniodawca nie rozumie specyfiki pracy projektowej, ma niezbyt sprecyzowane pojęcie, czego potrzebuje i w trakcie realizacji projektu metodą „to nie o to chodziło, to nie tak ma być” dochodzi do porozumienia stron. Normalną sytuacja jest, gdy w czasie prac nad Strukturą Podziału Prac dochodzi do zmian wpisów w Dokumencie Inicjującym Projekt, bo z pogłębionej analizy wynikła zmiana zakresu projektu.

Przykład: kręcimy trailer do filmu, z wstępnego założenia ma być to produkcja co najmniej półprofesjonalna. Klasyczna metodyka przewiduje: określamy, co jest do zrobienia (2 sceny: wprowadzająca z planem ogólnym i dialog kluczowy dla rozwoju akcji), czego potrzebujemy (miejsce, kamery, dźwięk, światło, scenografia, kostiumy itd.), kogo potrzebujemy (aktorzy, statyści, służby techniczne i usługi pomocnicze), kiedy i co robimy, ile to kosztuje. Dodajemy narzut kosztów ogólnych/rezerwę i mamy budżet projektu do przedstawienia zleceniodawcy. W praktyce elastyczne podejście wygląda tak: mamy orientacyjną kwotę, którą sponsor projektu powinien zaakceptować, trzeba podjąć cały szereg decyzji o charakterze zakres/zasoby/jakość, każdy wariant szacując osobno, a następnie poukładać fragmenty tej mozaiki tak, aby suma wartości oszacowań mieściła się w kwocie akceptowalnej dla sponsora. Tu dobrze widać elastyczność w podejściu do metodyki klasycznej: dokładne obliczenia zastępujemy oszacowaniami, jedną ścieżkę postępowania uzupełniamy o zestaw rozwiązań alternatywnych. Jednocześnie pracujemy zespołowo nad zakresem, strukturą podziału prac, szacowaniem wartości, a podejmowane „po drodze” decyzje nie są ostateczne, bo dodatkowe informacje mogą je jeszcze zmienić, nawet w trakcie dni zdjęciowych. Pozornie wygląda to na chaos, jednak po dokładnym przyjrzeniu się widać wpływ metodyki na pracę: struktura podziału prac jest przeglądana pod kątem kompletności, harmonogram w końcu się pojawia, choć zakłada sporą dowolność w przestawianiu terminów, budżet określony jest „mniej więcej tyle” z zastrzeżeniem górnej nieprzekraczalnej granicy, a na wybór wariantów wpływa analiza typowych ryzyk (np. załamanie pogody w trakcie dni zdjęciowych w plenerze, choroba głównych aktorów, cięcia budżetowe przed uruchomieniem działań itp.).

Jeszcze o metodykach i certyfikatach.

Historia zarządzania projektami jest zadziwiająca. Budowa centrum biznesowego dziś, a budowa kompleksu świątyń kilka tysięcy lat temu to taki sam projekt. Jednym i drugim trzeba było zarządzać (choć ten starszy nie wymagał certyfikatu). Stąd wniosek – formalne potwierdzenie wiadomości nie jest warunkiem koniecznym do zarządzania małymi czy średnimi projektami. W dużych natomiast może być warunkiem zatrudnienia na stanowisku menedżerskim.

Zarządzanie projektami jest bardziej praktyką niż nauką ścisłą. W trosce o powiększanie puli dostępnych menedżerów projektów (i chęci poznania) naukowcy obserwują pracę tych najlepszych, dzielą ją na etapy i działania, klasyfikują, opisują, dzięki temu powstają tomy opracowań, na podstawie których otrzymują tytuły naukowe i tworzone są programy szkoleniowe, ale pozostaje zawsze to trudno uchwytne „coś”, co czyni menedżera projektów wybitnym fachowcem i autorytetem w branży. Dawno temu nie było szkół czy programów MBA, a ludzie realizowali projekty bardziej w oparciu o osobisty autorytet i doświadczenie. Dziś bez problemu można przyswoić wiedzę dotyczącą którejś z metodyk i od strony „mechanicznej” zostać wybitnym ekspertem, ale pozostaje sfera „miękka” w zarządzaniu, bez której bardzo trudno o sukcesy.

Patrząc na to inaczej: W zarządzaniu projektami, jak w każdym zawodzie wymagającym zdolności do tworzenia czegoś nowego, są artyści, rzemieślnicy i reszta. Dla tych pierwszych są złożone i ambitne projekty, ale tych nie ma znowu tak wiele. Rzemieślnicy może nie zachwycają błyskotliwością, ale solidnie wykonują obowiązki realizując mnóstwo projektów bardziej typowych i to oni decydują o statystykach rejestrujących sukcesy i porażki. Dlatego wysokie kompetencje rzemieślników są takie ważne. Reszta ma inną pracę jako członkowie zespołów projektowych lub w ogóle są poza projektami.

W dzisiejszych czasach nie wiadomo, kiedy możesz nie tylko zostać włączony do zespołu projektowego, ale także mianowany samodzielnym menedżerem projektu. Dlatego warto terminować w dobrych zespołach i próbować samodzielnie zarządzać mniejszymi projektami. Dlatego warto chodzić na szkolenia (nawet te tańsze, bez certyfikatów) i czytać dobre podręczniki (nawet te grube). Dlatego warto nawet małe własne projekty poprowadzić zgodnie z wybraną prostą metodyką – dla treningu i menedżera projektu, i zespołu z którym pracuje. Wszak już starożytni Rzymianie mieli maksymę Repetitio est mater studiorum, przekładane na „powtarzanie czyni mistrzem”. Niemcy mają bardziej brutalne określenie einmal ist keinmal, czyli „raz nic nie znaczy”…

Niejednokrotnie w czasie realizacji projektu zachodzą okoliczności i zdarzenia zupełnie nieprzewidywalne. Doświadczony menedżer projektu wie, że „nieprzewidywalne” to norma i nie oznacza końca świata, więc do takich zdarzeń podchodzi elastycznie, nawet jeżeli oznacza to działania nieprzewidziane w metodyce. Jako myśl przewodnią potraktujmy słowa pierwszego burmistrza Salvora Hardina (Isaac Asimov, cykl Fundacja): Żeby odnieść sukces, nie wystarczy umieć planować. Trzeba jeszcze umieć improwizować. Umiejętność improwizacji jest jedną z cech pozwalających odróżnić artystę w zarządzaniu projektami od kiepskiego rzemieślnika. Zatem istotną częścią recepty na sukces projektu jest umiejętność zmieszania metodyki i improwizacji w stosownych proporcjach. Sztywne trzymanie się przepisów może doprowadzić do zupełnie absurdalnych rezultatów.

Na przykład metodyka PRINCE2. Prowadzenie projektu w pełni zgodne z tą metodyką oznacza rozpoczęcie tworzenia 27 dokumentów, uruchamianie i zamykanie we właściwej kolejności ponad 50 procesów i nieustanne sprawdzanie, czy na pewno to co robimy jest zgodne z 7 pryncypiami, oczywiście o tematach nie zapominając. Nic więc dziwnego w tym, że przy prostych projektach prowadzonych – według deklaracji zespołu – zgodnie z metodyką PRINCE2, „zapomina się” o części metodyki, co w konsekwencji doprowadziło do powstania „metodyki” opisanej angielskim akronimem PINEAPLE (nie mylić z ananasem – pineapple): PRINCE In Name Only And Problably Little Else – PRINCE tylko w nazwie i prawdopodobnie niewiele więcej. Dlatego menedżer projektu z którymś z certyfikatów do dużych i złożonych projektów używa znanej sobie metodyki w pełnym zakresie, ale do prostego projektu użyje mniej złożonego narzędzia. Powód? Ekonomia sił i środków. „Nie będziesz strzelał z armaty do wróbla”. Trafić trudno, chybione strzały kosztują dużo, a po celnym trafieniu prędzej można znaleźć dziurę w ziemi niż ślad po celu. Tak i w zarządzaniu projektami. Tyle w ramach zrozumienia, pora na uzasadnienie mniej metaforyczne.

Ile kosztuje zarządzanie projektem?

Warto ponownie spojrzeć na poniższy wykres [4] .



Duże 4 fale: inicjacja, planowanie, realizacja, zamykanie – oznaczają całość kosztów projektu. Piąta fala (kontrola) jest wprawdzie niska, ale ciągnie się przez cały projekt. W niej zapisane są koszty zarządzania projektem. Proporcje są nieprzypadkowe. Przyjęło się, że koszt zarządzania projektem wynosi zwykle kilka procent kosztów całego projektu. W praktyce zarządzania projektem o wartości rzędu 200 mln zł bez trudu można zaplanować kilka milionów na Biuro Projektu, z pomieszczeniem, sprzętem, archiwum, i paroma specjalistami na pełnym etacie, w tym kosztownego menedżera projektu z certyfikatem i dużym doświadczeniem. Jeżeli twój projekt ma budżet 2000 zł, to stać cię na korzystanie z udostępnionego/prywatnego komputera z drukarką i komplet kolorowych pisaków, a projekt wart 200 zł pozwoli ewentualnie na zeszyt A4 i długopis – w prostym projekcie to naprawdę wystarczy. Koszt „pełnowymiarowego” użycia PRINCE2 jest dość duży. Jeśli więc do małego projektu użyjesz rozbudowanej metodyki, to wskaźnik zysk z użycia/koszt użycia szybko pozbawi cię zajęcia w roli menedżera projektu. Żaden zleceniodawca nie zaakceptuje budżetu, w którym koszt wykonania czynności zarządczych przekracza koszt wykonania samego projektu. To też jest praktyka stosowania zasady „Zarządzanie projektami jest elastyczne”.

Każdy może popełnić błąd.

Jeżeli przyjmujemy w wyniku rozważań różnych definicji projektu podstawowy rdzeń tego pojęcia: projekt jest tymczasową organizacją powołaną dla osiągnięcia wyznaczonego celu w konkretnym czasie, to od menedżera projektu oczekuje się nie certyfikatu, pracowitego wypełniania szablonów dokumentów i recytowania formułek, ale używania metodyki do zrealizowania projektu – osiągnięcia celu w rozsądnym terminie i przy akceptowalnych kosztach. Może się przecież zdarzyć, że doświadczony menedżer projektu, z certyfikatem, przystąpił do realizacji dużego projektu, uruchomił odpowiednie procesy, i wszystko działało dobrze do ¾ budżetu. Dopiero wtedy wyszły na jaw okoliczności zewnętrzne, które omal nie położyły projektu – w rozmytej strukturze organizacyjnej nie było nikogo, kto chciałby przejąć produkty owego projektu na własność wraz z odpowiedzialnością za ich prawidłowe działanie. Menedżer projektu założył intuicyjnie racjonalność działania po stronie zleceniodawcy, co jak się okazało w tym przypadku było poważnym błędem.

Rola systemu wspierającego zarządzanie projektem.

Wyobraź sobie, że właśnie wymyśliłeś akumulator. Zupełnie nowy. Genialny. Lekki. Z łatwością mieści się w kieszeni, a energii magazynuje tyle, co klasyczny akumulator wielkości trzypiętrowej kamienicy. Co to oznacza? Nic. Dopiero gdy opatentujesz pomysł (co jest kosztowne i czasochłonne), powstanie fabryka tych akumulatorów, sensowna technologia ich ładowania i użycia, systemy dystrybucji, serwis, rozwiązany zostanie problem ich utylizacji po zużyciu, jednym słowem powstanie SYSTEM, którego akumulator jest wprawdzie centralnym elementem, ale tylko elementem i bez systemu „obudowującego” niewiele znaczy. Wówczas możesz powiedzieć „Dokonałem czegoś wielkiego”, a wdzięczni użytkownicy umieszczą twoje nazwisko w encyklopediach, nazwach ulic i placów, i pewnie postawią jeszcze pomnik „ku czci”.

Kluczem do dalszych rozważań jest zrozumienie pojęcia „system”. Podobnie jest z certyfikatem potwierdzającym formalnie znajomość którejś z metodyk zarządzania projektem. Jeden specjalista może naprawdę bardzo niewiele w konfrontacji z istniejącą strukturą i kulturą organizacyjną przedsiębiorstwa „nieprojektowego”. Dopiero gdy zostanie „obudowany systemem”, może zrobić bardzo dużo. Jak to rozumieć? Szefowie firmy w trosce o środki zainwestowane w kursy i certyfikaty (a to sporo kosztuje) angażują się w tworzenie systemu dla menedżera projektu. Aktywnie uczestniczą w przygotowaniu i wdrożeniu zmian. Powstają i są wdrażane procesy, regulaminy organizacyjne, procedury, szablony dokumentów. Wzbogacona zostaje struktura zasobów IT, budowany jest zmieniony schemat organizacyjny i mapa komunikacji. Pracownicy zostają przeszkoleni w zakresie wprowadzonych zmian, a ich nowe kompetencje testowane są w codziennej praktyce działania. Kilku pracowników zostaje przeszkolonych tak, aby mogli realnie wesprzeć menedżera z certyfikatem w jego pracy – powstaje zalążek Biura Projektów. Audytorzy otrzymują nowe zadania: sprawdzać jak PM działa. Z mojego doświadczenia zawodowego: próbowałem w kilku organizacjach, w których pracowałem, wdrożyć podstawowe elementy metodyk PM. Dopóki robiłem to „na własnym biurku i podwórku”, nikt nie protestował. Ale gdy próbowałem zrobić coś więcej – brak wsparcia „z góry” skutecznie gasił całą aktywność. Nec Hercules contra plures, jak mawiali Rzymianie. Dopiero zainteresowanie na poziomie prezesa i zarządu w jednej z firm doprowadziło do pełnego wdrożenia metodyki. Propozycja „Może masz ochotę przedstawić swoje wątpliwości na spotkaniu u prezesa?” zmuszała największych oponentów do starannego przemyślenia swoich argumentów „na nie”.

Trochę inaczej wygląda to w małych projektach. Jeden specjalista od zarządzania projektem może pociągnąć za sobą cały zespół, a nawet sam działać, angażując do jego realizacji potrzebnych mu specjalistów bez tłumaczenia im, jak ten projekt funkcjonuje od strony organizacji i zarządzania. To właśnie dzięki takim ludziom w organizacji są realizowane projekty bez formalnego ujęcia metodyki w codziennym ich funkcjonowaniu.

Na początek wystarczy kurs wprowadzający w świat zarządzania projektami, zakończony zwykłym zaświadczeniem. Do tego realizacja kilku projektów zgodnie z którąś z prostych metodyk, najlepiej jako członek zespołu pod okiem mistrza, a gdy się nie da – samodzielnie i odważnie poprowadzenie zespołu do sukcesu. Jeżeli będzie ci odpowiadała rola menedżera projektu, będziesz odczuwał głód wiedzy, ciekawość i chęć dalszego działania – dopiero wtedy podejmij decyzję, idź na kursy, zdobądź certyfikat i ruszaj na podbój świata. Jeżeli nie czujesz w sobie powołania do roli wodza, też idź na szkolenie. Ktoś musi być w drużynie wodza i stojąc w szyku pracowicie machać mieczem nie licząc specjalnie na zaszczyty i ordery.

Rola rezerw w organizacji.

Posiadane rezerwy to temat tabu, a ich ujawnienie często powoduje „trzęsienia” w organizacji. Trzeba przyznać, że problem rezerw jest chyba nierozwiązywalny. Z jednej strony organizacja mająca rezerwy cierpi na przerost struktury – jeżeli zbyt wielu ludzi robi tą samą robotę, to część się obija – cudów nie ma, jest za mało pracy dla wszystkich. Firma teoretycznie kuleje, bo ma za wysokie koszty działalności w stosunku do konkurencji. Z drugiej strony wyobraźmy sobie firmę o strukturze zatrudnienia idealnie dopasowaną do bieżących zadań – każdy pracownik z pełną wydajnością wykonuje swoją pracę bez przerw na pogaduchy, kawę czy papierosa. Jeżeli trafi się okazja, to zostanie zmarnowana – nikt nie będzie miał czasu się nią zająć. Tymczasem wdrożenie zarządzania projektami wymaga właśnie ujawnienia i wykorzystania rezerw. To trudne. Jaki kierownik zespołu zgodzi się potulnie na ujawnienie, że zatrudnia za duży zespół w stosunku do realizowanych zadań? Chomikuje swoje zasoby chroniąc je na czarną godzinę. Musi je mieć. W życiu kilkuosobowej komórki zdarzają się okresy, gdy jeden jest na urlopie, jeden na chorobowym, a jeszcze trafi się ktoś na urlopie rodzicielskim – i wtedy nie ma już połowy zespołu (i to nie rozpatrując zdolności do wzajemnego zastępowania się – nie wszyscy mają komplet wymaganych kompetencji). Zatem wdrożenie zarządzania projektami wymaga przebudowy mentalnej i pracowników, i menedżerów. Wątpliwości? Ujawnienie rezerw jest warunkiem przeżycia projektu, a dobrze realizowane projekty są warunkiem przeżycia firmy. Wyobraźmy sobie taką scenę rozmowy szefa z kierownikiem liniowym. Szef powiada: „Masz w grupie 5 osób. Masz oddelegować 2 osoby do udziału w projekcie »Karuzela« na orientacyjnie 3 miesiące. Dasz radę?”. Kierownik myśli: „Trzy osoby oraz ja do wsparcia, kwartał, nikogo nie puszczę na urlop, te dwa duże zadania związane z modernizacją archiwum przesunę na drugie półrocze”. Mówi: „Jak nie będzie epidemii grypy, to damy radę”. Mija kwartał. Kierownik nieśmiało pyta szefa o projekt „Karuzela”, bo już miał się skończyć, a on ma pilną robotę dla wracających pracowników. „Mają poślizg dwumiesięczny, czemu pytasz?” – „Brakuje mi ludzi” – „Jak dałeś sobie radę przez trzy miesiące, to znaczy że ci dwaj pracownicy nie są najpilniejszą potrzebą w moim pionie. Dasz radę”.

I tak kierownik wpadł jak śliwka w kompot. A potrzeba naprawdę niewiele – lepszej komunikacji w firmie i w projekcie. W projekcie – żeby kierownik liniowy nie był zaskakiwany tego typu informacją o poślizgach. W firmie – żeby szef lepiej wiedział, co robi kierownik, a w szczególności mógł ustalić z kierownikiem na spokojnie, co oznacza 2 miesiące poślizgu w projekcie dla pracy kierownika liniowego i jego komórki. Pewnie kierownik miał rezerwę kawałka etatu. Jednego pracownika oddałby spokojnie. Ale dwóch z perspektywą, że nie wrócą? Naruszenie rezerw musi się odbić na produktywności podstawowej struktury.

Można to zrobić w krótszym czasie, ale nie wszędzie jest to możliwe. W działach produkcyjnych da się nadgodzinami i presją podgonić zaległości. Ale pracownicy kreatywni pod presją kierownictwa nie będą myśleć szybciej. Skracanie czasu ich zadań w dłuższej perspektywie skutkuje obniżeniem jakości wyników pracy. Rozwiązania może i będą poprawne, ale rzadko błyskotliwe, a w produktach końcowych – przy braku czasu na testowanie i sprawdzanie – będzie więcej błędów. Skutki? W filmach niektórzy widzowie specjalnie tropią takie przepuszczone „smaczki”. A to gladiator ma trampki, a to rycerz zegarek, gdzieś w tle średniowiecznej bitwy widać linię wysokiego napięcia, a ja sam widziałem western, w którym kowboj na prerii nalewał kawy do blaszanego kubka korzystając ze współczesnego szklanego dzbanka do kawy. Ciekawa zależność: presja + brak czasu = niska jakość produktów projektu. Wnioski? Zaplanuj w projekcie nie tylko czas na testy i przeglądy pośrednie, ale daj też rezerwę czasu na okoliczności, których aktualnie nie przewidzisz, ale które najprawdopodobniej pojawią się i spowodują opóźnienia w realizacji. Podpowiedź – spróbuj dowiedzieć się czegoś o Teorii Ograniczeń (TOC) i jej zastosowaniu w zarządzaniu projektami pod nazwą „łańcuch krytyczny”.

Jeszcze o metodykach i projektach nieformalnych.

Metodyki wychodzą z różnych źródeł, posługują się słownictwem zbliżonym, i ewoluują w kierunku wiązki procesów. To na pierwszy rzut oka może dość dziwne, ale zrozumiałe. Projekt jest przedsięwzięciem z definicji niepowtarzalnym, ale proces zarządzania tym projektem z definicji ma być powtarzalny, i wtedy nazywamy go metodyką. Stąd ten dualizm procesowo-projektowy. Przy okazji doboru metodyki: dwa poważne zagrożenia. Podając za Wikipedią (hasło: antywzorzec projektowy):

• Złoty młotek (ang. golden hammer) – faworyzowanie jednej technologii w celu rozwiązania wszystkich problemów, również tych, dla których istnieją znacznie lepsze metody.
• Silver bullet – założenie, że sprawdzone rozwiązanie techniczne musi być zawsze skuteczne przy rozwiązaniu znacznie większego problemu

W naszych rozważaniach można to zinterpretować w sposób następujący: jeżeli zarządzanie projektami zaczynasz od certyfikacji i pełnego wdrożenia wybranej metodyki klasycznej, ryzykujesz użycie złotego młotka, czyli pełnej metodyki do projektu, który tego nie wymaga. Dyskutowałem kiedyś na ten temat z sympatycznym człowiekiem, który właśnie uzyskał certyfikat PRINCE2 Foundation i z radością neofity chciał wdrożyć świeżo poznaną metodykę w całej jej złożoności w swojej organizacji. Rzeczona firma liczyła sobie mniej niż 10 pracowników, z których tylko on przeszedł szkolenie i to za własne pieniądze, czyli bez wsparcia zarządu. Chciał użyć pełnej metodyki w projektach, które wymagały głównie starannego definiowania zakresu i dobrej komunikacji. Delikatnie odradzałem ten krok proponując prostsze narzędzia. Z drugiej strony zaczynając od prostej metodyki można ją potraktować jak srebrną kulę skuteczną na wszystkie potwory zarządzania, a to nie zawsze działa – wielki potwór nawet nie zauważy małej srebrnej kulki i stratuje cię nawet nie zwalniając biegu. W dużych i bardzo dużych projektach sam menedżer wszystkiego nie pociągnie i całego projektu naraz w głowie nie pomieści – potrzebuje wsparcia zespołu projektowego, kilku osób do prac administracyjnych i złożonej metodyki uwzględniającej wyrafinowane smaczki zarządzania. W życiu projektowym trzeba mieć pod ręką i złoty młotek, i srebrną kulę, i wiedzę kiedy czego użyć.

Tu drobna, ale ważna dygresja. W organizacjach, zwłaszcza mniejszych, należy rozróżnić dwa typy realizowanych projektów – formalne i nieformalne, lub inaczej – ujawnione i ukryte. Propozycja zrozumienia tych pojęć:

• projekt formalny (lub ujawniony) zostaje uruchomiony formalną decyzją na poziomie zarządu, ma co najmniej podstawową strukturę i przydzielone zasoby (sponsor projektu, menedżer projektu – z określonymi kompetencjami, zadaniami i odpowiedzialnością, zespół projektowy, pomieszczenie, środki komunikacji, zatwierdzony budżet), i prowadzoną dokumentację (Dokument Inicjujący Projekt, plan projektu z analizą ryzyk, raporty z realizacji, dokumentacja osiągniętych celów), a poszczególne etapy działania są określone w czasie kończąc się raportami;
• projekt nieformalny (lub nieujawniony, ukryty, nienazwany) zwykle zostaje uruchomiony ustnym poleceniem wskazującym na osobę pełniącą rolę wykonawcy zadania (będącego projektem), najczęściej nie jest dokumentowany lub dokumentacja jest niepełna, brak planu projektu – poszczególne kroki wykonywane są „na nos, intuicję i doświadczenie” wykonawcy zadania wspieranego luźną grupą specjalistów bez określonej struktury, słaba komunikacja i najczęściej brak wsparcia dla wykonawcy (nie mylić z formalnie określonym menedżerem projektu).

Metodyka zarządzania projektami dotyczy projektów formalnych. Tu znajomość wzorów dokumentów, pełna informacja „kto dowodzi” i za co odpowiada na poszczególnych obszarach, zatrudnienie osób przeszkolonych i/lub posiadających stosowne certyfikaty ma jak najbardziej sens. W projektach nieformalnych nie jest wymagana znajomość metodyki. Niemniej jednak sformułowałem kiedyś na jednym z prowadzonych szkoleń takie zdanie: Znajomość metodyki PM, czyli umiejętność używania odpowiednich metod postępowania i narzędzi w odpowiedniej kolejności w projektach nieformalnych sprzyja wzrostowi wskaźnika przeżywalności pracownika na obecnym stanowisku i zwiększa prawdopodobieństwo awansu wskutek wyższej jakości wyników jego pracy.

To proste: mając małe doświadczenie i działając bez metodyki łatwo coś przeoczyć lub zaniedbać, co równie łatwo skutkuje utratą premii, jak łatką „nieudacznika” i ewentualnie wizytą w kadrach po odbiór świadectwa pracy. Wniosek: osoba nabywająca nowe kompetencje w obszarze zarządzania projektami ma większe szanse na karierę zawodową. Podobnie zresztą dzieje się w drugim obszarze funkcjonowania przedsiębiorstwa, czyli w zarządzaniu procesami, o którym dobry menedżer projektu też musi coś wiedzieć (w końcu zarządzanie niepowtarzalnym projektem to jest, a raczej ma być powtarzalny proces). Przy czym owe dwa pojęcia – projekt formalny, projekt nieformalny – wyznaczają dwie graniczne wersje projektu, jak czerń i biel. W środku jest bardzo dużo odcieni szarości. Zwykle małe i średnie projekty są jakąś formą pośrednią – część działań jest dokumentowana, część działań jest uzgadniania ustnie i strony ufają w dotrzymanie obietnic po drugiej stronie tak, jak zamierzają dotrzymać własnych zobowiązań.

W praktyce zawsze jest jakaś dokumentacja. Minimum to ta związana z sprawami finansowymi. W realizacji projektu masz jakiś budżet, wydajesz środki na materiały, sprzęt, usługi obce i tak dalej, więc musisz mieć porządek w kasie na wypadek kontroli, a to oznacza właśnie dokumentację finansową projektu. Do tego zwykle prowadzisz jakąś korespondencję, zawierasz umowy, wykonujesz własne notatki/wydruki – i już masz początek archiwum projektu…

W jednej z definicji projektu mowa jest o ryzyku niepowodzenia. Zatem ryzyko łączy się nierozerwalnie z projektem jako takim. Metodyki mają między innymi zmniejszyć ryzyko do akceptowalnego poziomu. Z drugiej strony często decydenci dając zgodę na uruchomienie projektu bardzo niechętnie akceptują ryzyko niepowodzenia projektu. Jeśli zarząd „nie czuje ducha PM”, to na dobrą sprawę menedżer projektu ma po prostu machnąć czarodziejską różdżką, powiedzieć „hokus pokus” lub coś w tym stylu i projekt gotowy. Zero ryzyka, bez zawracania głowy zarządowi, szybko i przy minimalnym nakładzie kosztów (amortyzacja różdżki). Mało tego: najczęściej sukces projektu jest traktowany jako coś zupełnie normalnego, klęska projektu traktowana jest jako klęska osobista menedżera projektu i plama na życiorysie zawodowym sponsora projektu – zwykle jego przełożonego. Ciekawe więc dlaczego tyle projektów przekracza budżet i termin realizacji, a produkty projektu odbiegają od oczekiwań zleceniodawców? Źródeł niepowodzeń jest całkiem sporo i menedżer projektu odpowiada tylko za część spośród nich.

Trzeba w to uwierzyć na słowo lub przeżyć samemu: są takie chwile w życiu menedżera projektu, w których jedynym sensownym wyjściem jest zamknięcie projektu. Doświadczony menedżer potrafi zamknięcie nietrafionego projektu przetworzyć w sukces (ale takie działanie to też jest projekt, więc bez metodyki…).

Przykład z mojego życiorysu zawodowego. Prowadziłem swego czasu projekt modernizacji pewnej instalacji przemysłowej, w sumie przez 5 lat. Potem oddałem prowadzenie tego projektu komuś innemu, a następca (prawdę powiedziawszy przez zaniechanie) doprowadził do przerwania projektu w ciągu 6. roku. Gdzie popełniłem błąd? Byłem tak skoncentrowany na prowadzeniu projektu i osiągnięciu celu, że przeoczyłem zasadność zamknięcia tego projektu już po trzech latach. Dziś trochę wstyd, że przez 2 lata projekt ten zupełnie bez sensu pochłaniał zasoby. Ale dziś dzięki doświadczeniu wiem, że projekt nie dzieje się „w próżni”. Nauczyłem się czegoś spoza metodyki zarządzania projektem. Ówczesny mój pogląd zgodny z modelem PMI przyjmował 9 obszarów zarządzania projektem. Dziś dołożyłem na własny użytek 10 obszar: zarządzanie otoczeniem projektu. W metodyce PRINCE2 jest punkt, który tego w pewnym sensie dotyczy, tyle że nazywa się inaczej: „uzasadnienie biznesowe”. Co jest kolejnym dowodem na podobieństwo metodyk.

Znaczenie doświadczenia.

Anegdota. Kurs prawa jazdy. Teoria teorią, ale potrzebna jest też praktyka w kręceniu kierownicą. To była druga czy trzecia godzina jazdy po mieście. Powrót z trasy, auto toczyło się ze straszną dla mnie prędkością około 40 km/h, przejazd i parkowanie pod siedzibą szkoły jazdy. Instruktor pyta: – I co, zgrabna była? Odpowiedź kursanta: – Kto? Nikogo nie widziałem. – No ta dziewczyna, która zatrzymała się na chodniku, żebyś mógł przejechać bez hamowania. – Jaka dziewczyna? Pasy były puste, to jechałem. – No to teraz już wiesz, kiedy będziesz kierowcą. Kursant prowadzi samochód i koncentruje się na jeździe. Kierowca jedzie do celu i koncentruje się na otaczającej go rzeczywistości. Jak w czasie którejś lekcji powiesz mi „Ale to zgrabna dziewczyna była” to będę wiedział, że masz zadatki na kierowcę.

Podobnie z jazdą na rowerze. Jeśli nigdy w życiu nie widziałeś rowerzysty, nawet na obrazku, to jesteś w stadium „nie wiem, że nie wiem”. Kiedy zobaczysz rowerzystę jadącego, możesz powiedzieć „wiem, że nie wiem” jak się jeździ na rowerze. Jak się nauczysz utrzymywać równowagę w czasie jazdy, powiesz „wiem, że wiem” jak jechać. A po większej liczbie kilometrów wpadniesz w stan „nie wiem, że wiem” – przestaniesz koncentrować się na samym prowadzeniu roweru, te procesy sprowadzisz na poziom instynktownych zachowań i odruchów.

Dlaczego doświadczenie tak się liczy? Świadomie raczej nie prześledzisz funkcjonowania 50 procesów w projekcie. Ale gdy (oby jak największą) część z nich przeprowadzisz przez cykl „nie wiem, że nie wiem” – „wiem, że nie wiem”, „wiem, że wiem”, „nie wiem, że wiem” – to wówczas starczy ci czasu na pracę bo część pracy będziesz wykonywać instynktownie i niemal nieświadomie, bo „po prostu tak się robi”.

Doświadczony menedżer projektu sprawy techniczne opisane umiejętnościami twardymi wykonuje niemal mimochodem, tak jak kierowca prowadzi samochód czy rowerzysta utrzymuje równowagę na rowerze. Sprawy społeczne opisane umiejętnościami miękkimi zajmują mu więcej czasu i uwagi, tak jak doświadczonemu kierowcy czy rowerzyście więcej uwagi zajmuje otoczenie pojazdu, śledzenie ruchu na jezdniach i przejściach dla pieszych czy obserwacja znaków drogowych.

Umowy.

Prawnik dba, aby umowa była spójna, logiczna i niesprzeczna z obowiązującym prawem. Za stronę biznesową umowy odpowiada strona podpisana pod umową. Nie ma sensu uczenia prawnika szczegółów biznesu ani to, żeby biznes uczył się zawiłości prawa. Najprostsze podejście dla menedżera projektu: przeczytaj umowę. Czy rozumiesz treść? Jeżeli nie, popraw umowę i dopiero wtedy możesz podpisać. Oczywiście możesz nad umową pracować wspólnie z prawnikiem. W końcu zarządzanie projektem jest pracą zespołową, nieprawdaż? Ostatnio uczestniczyłem w negocjacjach dotyczących umowy. Wynikiem umowy miał być plik spełniający warunki specyfikacji. Prawnik pracując nad umową myślał jak prawnik: wartość mają dokumenty, czyli coś wydrukowanego na papierze i podpisane, z datą. Jak drukowanie pliku nie jest wymagane, to równie wartościowy jest protokół przekazania tego pliku, oczywiście podpisany przez strony i zadatowany. Zleceniodawca był – co zrozumiałe – zainteresowany otrzymaniem zleconego pliku bardziej niż papierowym protokołem. I doszło do kolizji działań, ponieważ prawnik przez termin zakończenia umowy rozumiał datę protokołu przekazania, a zleceniobiorca datę fizycznego przekazania pliku do wykorzystania, czego następstwem miał być rzeczony protokół. Ofiarą rozbieżności w definicjach stała się umowa, a raczej jej treść: wielokrotne poprawki zagmatwały sens, a całość straciła spójność logiczną. Wykonawca nie chciał podpisać bez poprawek. Krążyły pisma i maile, ale czas nieubłaganie uciekał, co groziło przekroczeniem terminów końcowych. Jeżeli zleceniodawca jest generalnym wykonawcą, a zleceniobiorca podwykonawcą, to właśnie zleceniodawca jest w ryzykownej pozycji: ma swój termin końcowy w umowie nadrzędnej, którą już podpisał, czas biegnie, negocjacje z podwykonawcą się przeciągają, a produktywność w dalszym ciągu wynosi zero, bo zleceniobiorca palcem w bucie nie kiwnie przed podpisaniem umowy; z drugiej strony umowy z nierealnym terminem wykonania też nie podpisze. Nie jest łatwo być generalnym wykonawcą, zwłaszcza gdy ma się przejściowe problemy z komunikacją.

O metodyce trochę inaczej.

Po co plan zarządzania projektem? A skąd będziesz wiedział, jak bardzo masz „w plecy”?

Opiszmy przykładową metodykę. Prostą, ale wystarczającą do podstawowych zastosowań dla kogoś, kto zaczyna. Nie jest to metodyka opisana w jakimś podręczniku, pewnie z punktu widzenia specjalistów wysokiego poziomu nie jest kompletna, ale nie chcę tu dzielić włosa na części.

Na początku jest idea. Ta zawsze rodzi się w jednej głowie. Jeżeli pomysł wydaje się autorowi właściwy, to zaczyna rozmawiać na ten temat z innymi. W ten sposób powstaje szansa na weryfikację genialności tego pomysłu. Gdy już kilka osób ma chęć zająć się dyskutowaniem tego pomysłu, mamy etap inicjacji projektu. Zaczynamy szkicować zarys tego, co będzie do zrobienia. Gdy wynik tego szkicowania będzie zadowalający, musi powstać dokument opisujący ten pomysł. W podręcznikach różnie jest to definiowane, przyzwyczaiłem się do nazwy Dokument Inicjujący Projekt (akronim angielski często spotykany: PID) Jeżeli jesteś początkujący i nie masz doświadczenia w przygotowywaniu tego dokumentu, poszukaj szablonu w Internecie.

Możesz też po prostu zajrzeć do podręcznika PRINCE2, tam jest wzorcowy dokument wraz z omówieniem.

Pamiętasz o elastyczności w zarządzaniu projektami? Szablon dokumentu wzięty z PRINCE2 nie jest „święty”. To jest przykład dokumentu, a nie kanon wiary. Więc potraktuj go elastycznie. Owszem – staranne wypełnienie tego dokumentu znacznie przyczyni się do sukcesu w działaniach, ale nie jest to ani warunek konieczny, ani wystarczający. Możesz przecież przygotować własny szablon, lub w otoczeniu w którym działasz taki wzorzec już funkcjonuje. Chodzi przecież o możliwie wszechstronne przedyskutowanie pomysłu z różnych punktów widzenia, a taki dokument znakomicie pomaga ukierunkować myślenie o projekcie.

Mamy wypełniony i podpisany przez zainteresowanych DIP. Pora wyjść z ukrycia i zacząć szukać pieniędzy. Owszem, istnieją małe projekty oparte na czystym wolontariacie i mają się całkiem nieźle, ale to wąski margines. Generalnie – nie ma pieniędzy, nie ma projektu.

I tu podstawowy problem: ile trzeba i na kiedy?

W Dokumencie Inicjującym Projekt szacujesz orientacyjnie, ile będziesz potrzebował. Jak nie masz ani doświadczenia, ani pojęcia, poszukaj pomocy. Jakąś kwotę wpisać trzeba, a reguła obowiązująca jest prosta: „albo będzie wstyd, albo strata”. Jak oszacujesz za nisko, to będzie strata w projekcie. Ktoś będzie musiał dołożyć w trakcie realizacji, a mało kto lubi być zaskakiwany koniecznością sięgnięcia do portfela. Jak oszacujesz za wysoko, może być wstyd (ale niekoniecznie). To przecież wstępne oszacowanie i każdy powinien zdawać sobie z tego sprawę. Najczęściej ktoś już realizował podobny projekt, da się poszukać na ile był wyceniony, dodać margines bezpieczeństwa, szczyptę zdrowego rozsądku i oszacowanie gotowe. Na tym etapie planowania projektu błąd oszacowania rzędu 50% kwoty się zdarza. Zwykle błąd jest rzędu 20–30%, jak ktoś oczekuje oszacowania z dokładnością do kilku procent, to należy go przymusowo skierować na szkolenie z podstaw zarządzania projektami.

Jeżeli masz już obiecane pieniądze na projekt, pora napocząć budżet (albo i nie, ale nie polecam) i porządnie zaplanować projekt. To druga faza w cyklu życia projektu. Tu jest znacznie mniej radosnej twórczości, a więcej sformalizowanych narzędzi uszykowanych w odpowiedniej kolejności. Nie ma rady: Struktura Podziału Prac (zdałaby się jednocześnie macierz odpowiedzialności), diagram sieciowy, szacowanie czasu, pierwszy harmonogram (czyli wreszcie masz lepsze oszacowanie czasu projektu), pora na przydzielenie zasobów, na tej podstawie budujesz budżet projektu i wykreślasz sobie hipotetyczny przepływ gotówki (Cash Flow). Zwykle zaniedbywana, ale ważna w tym momencie analiza ryzyk. Zaglądasz do kalendarza (tradycyjne westchnienie „ale mało czasu”) i podejmujesz dramatyczną decyzję – optymalizować dalej harmonogram czy ruszać dalej z planowaniem. Spinasz to w całość, robisz przegląd końcowy i ostatnie poprawki. Dumny (bo masz z czego!) świętujesz z zespołem przekazanie planu projektu do zatwierdzenia.

Sponsor powiedział „OK”. No to do roboty. Realizujesz i zlecasz zadania, odbierasz wykonane, skreślasz z listy to co załatwione. Tworzysz dokumentację do sprawozdania (nie łudź się – nikt nie zwolni cię z tego obowiązku). Spinasz produkty projektu, przekazujesz sponsorowi, jeszcze rozliczenie końcowe, sprawozdanie, porządki, świętowanie z zespołem sukcesu i wreszcie ty możesz się wyspać, a włosy na twojej głowie spokojnie odrastają po tym, jak targałeś je powodowany bezsilnością wobec ludzi i losu.

Do rozmów z potencjalnymi sponsorami projektu DIP jest jak znalazł – masz dokument, treść, kwotę i termin. Oraz oczywiście pozostałe warunki realizacji i listę potencjalnych korzyści.

To już naprawdę koniec.

Nie dajmy się zwariować! Świat kręcił się przed projektem, będzie się kręcił dalej, a nie każdy musi być genialnym menedżerem projektów (wystarczy, że będzie dobry!).

Trochę sztuki dla nauki.

Ballada o słoniu i ślepcach [5] .

Żyło raz sześciu w Hindustanie
Ludzi ciekawych niesłychanie
I chociaż byli ślepi,
Wybrali kiedyś się na błonie,
Aby zapoznać się ze słoniem
I umysł swój pokrzepić.
Pierwszy z nich przyspieszywszy kroku,
Nos rozbił na słoniowym boku
O twardą jego skórę;
Więc do swych towarzyszy pięciu
Krzyknął: – Już wiem o tym zwierzęciu,
Że jest najtwardszym murem.
Gdy się do słonia zbliżył Drugi,
Na kieł się natknął ostry, długi,
Więc swych przyjaciół ostrzegł:
– Ach, uważajcie moi mili,
Żebyście się nie skaleczyli,
Bo słoń to ostry oszczep!
Trzeci, podchodząc do zwierzęcia,
Nie więcej miał od tamtych szczęścia:
Słoń trąbę swą rozprężał,
A on dotknąwszy trąby dłonią,
Rzekł: – Ja już wszystko wiem o słoniu,
Słoń jest gatunkiem węża!
Wtedy powiedział ślepiec Czwarty,
Bardzo ciekawy i uparty:
– Chcę wiedzieć, czego nie wiem!
I kiedy sam przy słoniu stał,
Rzekł, obejmując mu kolano:
– Już wiem, że słoń jest drzewem!
Gdy się do słonia Piąty zbliżył,
Słoń siadł na ziemi, łeb obniżył
I ruszać jął uszami;
Więc Piąty, rzecz uogólniając,
Rzekł: – Już poznałem prawdę całą,
Słonie są wachlarzami!
Nie gorszy, choć ostatni, Szósty,
Najpowolniejszy, bo był tłusty
I dał się innym minąć,
Rzekł, gdy za ogon słonia chwycił:
Nie przypuszczałem nigdy w życiu,
Że słoń jest zwykłą liną!
I żaden z ślepców tych aż do dziś
Nie chce się z innym ślepcem zgodzić,
Część prawdy tylko znając;
Każdy przy swojej trwa opinii,
Każdy ma rację swą jak inni,
Lecz wspólnie jej nie mają.