Czas – zmora każdego PM’a. Sztywny, uwierający gorset. I jednocześnie rzeczywistość projektowa. Po jednej stronie Ty, po drugiej klient i jego coraz głośniej tykający zegar. Patrzysz na harmonogram, widzisz ciemność. To znak, że czas Cię przegonił. Jak być z nim „do przodu”?
Problemy wpisane są w projekty. Jest ich więcej, niż zdołałabym wymienić, ale ich skutki na ogół są 3:
- Opóźnienia
- Przekroczenie budżetu
- Aplikacja niezgodna z wymaganiami
Jaki nasuwa Ci się wniosek?
Kiedy pojawia się opóźnienie w projekcie zaczynamy je kompensować. Kompensacja jednego z czynników wpływa na kolejne; gdy chcemy kompensować czas, musimy zmienić zakres i/lub budżet (zmniejszenie zakresu / wzrost budżetu). Nie zawsze jest to możliwe. Najczęściej już nie jest.
Renegocjacja umowy? Miły klient, który zgodzi się na mniej za więcej? Nie licz na przychylność losu. Jeśli nie wiesz co robić, zacznij się modlić.
Wydłużanie czasu = przekraczanie budżetu
O opóźnieniu często wiemy już w momencie startu projektu. Dlaczego tak się dzieje? Skąd się biorą opóźnienia w projekcie? Złe szacowanie? To by było zbyt oczywiste.
Przystępujemy do realizacji projektu, a tymczasem…
- Nie do końca wiemy co jest do zrobienia – „dziurawa” specyfikacja
- Klient nie wie czego chce – to my mamy wiedzieć?
- Klient nie jest zaangażowany – skoro on nie, to my też nie
- Pojawia się zbyt wiele zmian – projektowe „widzimisie”
- Brak potrzebnych zasobów – gdzie oni są? Ci wszyscy programiści…
- Konkurencja o priorytety między projektami i ludźmi – kto ma strategiczny projekt, ten ma władzę
To PM musi uczynić warunki projektu realnymi. Dospecyfikować to, co niedospecyfikowane. Zrozumieć klienta, a co gorsze – programistę. Walczyć (zwycięsko), myśleć strategicznie. Musi umieć liczyć i znać się na zegarku. Projekt ruszył, zegar bije.
Jak zatem podejść do szacowania?
Znane są różne podejścia, m.in.:
- Popularna ścieżka krytyczna oparta o analizę PERT (CPM)
- Konkurencyjne i stosunkowo nowe podejście – łańcuch krytyczny (CCPM)
- Harmonogramowanie agresywne
- Harmonogramowanie bezpieczne
- Złoty środek pomiędzy dwoma powyższymi
- Wyznaczanie buforu w wymiarze 1/3 czasu przeznaczonego na realizację projektu
Wybór metody zależny jest od doświadczeń PM’a oraz od specyfiki projektu. Niezależnie jednak od metody nie jesteśmy wolni od problemów, ryzyk czy zagrożeń projektowych. Żadna z metod nie gwarantuje realizacji projektu na czas.
Podstawowe problemy w harmonogramowaniu
- Estymacja czasu przez ludzi ją prowadzących różni się od estymacji czasu osób realizujących
- X programistów nie zawsze oznacza x programistów – programista programiście nie równy
- Brak marginesów bezpieczeństwa (buforów) – niepoprawnie optymistyczne planowanie
- Marnowanie marginesów bezpieczeństwa i brak reakcji
- Kumulowanie opóźnień
Zapewne każdy PM dopisałby tu jeszcze kilka ze swoich doświadczeń.
Po co bufor?
Lekiem na bolączki związane z opóźnieniem ma być bufor, który jest rezerwą na zabezpieczenie:
- Zadań, których realizacja nie zakończy się w czasie
- Niedoszacowania realizacji zadań
- Zagrożeń / ryzyk
- Urlopów / chorób członków zespołu projektowego
Co się stało z buforem?
Zabezpieczenie czasu poprzez dodanie marginesu bezpieczeństwa nie zapewni Ci sukcesu. Wręcz może być tak, że będzie go jeszcze więcej do marnowania. Brzmi strasznie? Zobacz, co się dzieje z buforem, kiedy nikt nie patrzy:
- Syndrom studenta – odkładamy wszystko na ostatnią chwilę, pracę rozpoczynamy w momencie przerażenia
- Prawo Parkinsona – praca rozszerza się tak, aby wypełnić czas dostępny na jej wykonanie
- Akumulowanie opóźnienia – opóźnienie jest przekazywane dalej, przyspieszenie jest marnowane
- Czekanie na swój termin – ja nie zacznę dopóki ty nie skończysz
- Niezgłaszanie wcześniejszego wykonania zadania (wiem, brzmi niewiarygodnie)
Jak widzisz, bufor potrafi być doskonale marnowany. Pamiętaj, że szacowanie prac w projekcie to jedno, szacowanie buforów – drugie. Bywa, że planowanie zadań uwzględnia margines bezpieczeństwa, ale polecam oddzielić te dwa aspekty i zarządzać buforem niezależnie, bo w buforze potrafią kumulować się problemy, bo kiedy nie pozostaje już nic, może uratować Cię jeszcze bufor.
Dziękuję Tomku za komentarz. Jak najbardziej zgadzam się z Tobą – opóźnienia nie należy planować. Jednak nawet najlepsze planowanie nie uchroni nas przed tym, co nieplanowane, a co często jest przyczyną opóźnień. Rzeczywiście właściwe zarządzanie buforem nie polega na rozleniwianiu siebie i zespołu wizją pozornego bezpieczeństwa i jak zauważyłeś bufor sam w sobie niewiele da, jeśli nie będzie właściwie monitorowany i zarządzany. Dla mnie to wręcz narzędzie pewnej mobilizacji (np. agresywne planowanie, o którym wspomniałeś) :-)
Oczywiście dobrze jest mieć bufor na projekt, lecz sam w sobie nie jest rozwiązaniem, co więcej w praktyce, ze względu na istniejące wymagania związane z terminem wykonania projektu, bardzo trudno jest uzyskac akceptacje klienta na wydłużenie przedsięwzięcia, w jego rozumieniu bezpodstawne i często niekorzystne dla jego biznesu (cel projektu, zasadność biznesowa, konsekwencje finansowe, itp), nie dając nic w zamian (przy czym zwiększenie prawdopodobieństwa realizacji projektu na czas nie jest argumentem dla klienta jedynie dla PMa). Zastosowanie samych buforów ma tez kolejna wadę – świadomość ich obecności, a tu działają juz znane mechanizmy psychologiczne opisane w artykule. Stosowanie bufora w realnych warunkach projektu przyniesie nam realne korzyści jedynie wówczas, gdy podejdziemy do tematu kompleksowo. Jedno z kompleksowych podejść zakłada stosowanie m.in. agresywnego planowania, uświadomienia celu projektu, sztafetę pracy podczas realizacji, ograniczenie wielozadaniowości…, a z kontrolowania poziomu wykorzystania bufora projektu czyni narzędzie zarządzania projektem. W praktyce, możliwe jest uzyskanie skrócenia czasu trwania projektu (także kosztu) i jednoczesne posiadanie buforu, dającego możliwość ciagłego przejrzystego monitorowania stanu przedsięwzięcia i skuteczne zarzadzanie ryzykami (tez tymi pozytywnymi). Tu zadania i bufory sa skorelowane (nie osobno, jak w artykule). Zatem bufor, redukcja niepewności ne etapie realizacji i korzyść dla klienta. To oczywiście nic innego jak Teoria Ograniczeń i jej aplikacja dla zarządzania projektami, czyli model CCPM (wspomniana ogólnikowo), która pomimo pewnych niedoskonałości, swietnie sprawdza sie w warunkach dużych, złożonych projektów o możliwie stabilnej, dającej sie przewidzieć sieci projektu. Zatem, bufor tak, ale sam w sobie to tworzenie pozornego stanu bezpieczeństwa, który najcześciej zostanie planowo zmarnotrawiony, w najlepszym wypadku akumulujac jedynie opoźnienia, w realnym przypadku i tak doprowadzając do opoźnienia projektu. Opóźnień… nie należy planować.