Czas – zmora każdego project managera. Sztywny, uwierający gorset. I jednocześnie rzeczywistość projektowa. Po jednej stronie zespół realizujący projekt, po drugiej klient i jego coraz głośniej tykający zegar. Jeśli PM patrzy na harmonogram i widzi ciemność, to znak, że czas go przegonił.
fot. Fotolia
Dane Standish Group pokazują, że walka z terminami to jedno z najważniejszych źródeł problemów w projekcie. Zgodnie z nimi, tylko nieco ponad 16% projektów jest realizowanych w przyjętych początkowo ramach czasowych. To pociąga za sobą kolejne konsekwencje, co dobrze przedstawia poniższa infografika.
Źródło: Standish Group. Chaos Report (https://cs.nmt.edu/~cs328/reading/Standish.pdf)
Nasuwa się jeden wniosek. Kiedy pojawia się opóźnienie w projekcie zaczynamy je kompensować. Kompensacja jednego z czynników wpływa na kolejne – gdy chcemy nadrobić czas, musimy zmienić zakres i/lub budżet (zmniejszenie zakresu/wzrost budżetu). Nie zawsze jest to możliwe. Niestety najczęściej już nie jest. A renegocjacja umowy? Miły klient, który zgodzi się na mniej za więcej? PM nie może liczyć na przychylność losu.
Problem w tym, że o opóźnieniu często wiemy już w momencie startu projektu. Dlaczego tak się dzieje? Skąd bierze się poślizg czasowy w projekcie? Złe szacowanie? To by było zbyt oczywiste. Najczęściej przystępując do realizacji projektu, mierzymy się z jednym ze scenariuszy:
- … nie do końca wiemy co jest do zrobienia – „dziurawa” specyfikacja,
- klient ma problem z określeniem swoim potrzeb,
- klient nie jest zaangażowany – a skoro on nie, to my też nie,
- pojawia się zbyt wiele zmian,
- brak potrzebnych zasobów,
- konkurencja o priorytety między projektami i ludźmi – kto ma strategiczny projekt, ten ma władzę.
Często analiza przedwdrożeniowa nie dostarcza odpowiedzi na wszystkie pytania, które pojawiają się w trakcie realizacji projektu. Specyfikacja posiada pewne luki w obszarze tak zwanym „do omówienia w toku dalszych prac”, dostarcza wątpliwości project managerowi, jak również programistom. Zadaniem PM’a w takiej sytuacji jest uczynić warunki projektu realnymi. Doprecyzować to, co nie zostało ujęte w specyfikacji. Zrozumieć klienta i – co równie ważne – programistę. Walczyć (zwycięsko), myśleć strategicznie. Musi umieć liczyć i znać się na zegarku.
Projekt ruszył, zegar bije
Pytanie, jak zatem podejść do szacowania. Znane są różne strategie, w tym 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, project managerowie nie są wolni od problemów, ryzyk czy zagrożeń projektowych. Żadna z metod nie gwarantuje realizacji projektu na czas, ale ich umiejętnie stosowanie pozwala redukować opóźnienia i przede wszystkim skutecznie na nie reagować. Wśród podstawowych problemów w harmonogramowaniu możemy wskazać:
- 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 – umiejętności programistów znacznie się różnią,
- 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ń.
Czas – zmora każdego project managera. Sztywny, uwierający gorset. I jednocześnie rzeczywistość projektowa. Po jednej stronie zespół realizujący projekt, po drugiej klient i jego coraz głośniej tykający zegar. Jeśli PM patrzy na harmonogram i widzi ciemność, to znak, że czas go przegonił.
Lek na całe zło
Receptą na bolączki związane z opóźnieniem jest bufor, czyli rezerwa na zabezpieczenie zadań, których realizacja nie zakończy się w czasie. Powodów takiego poślizgu może być wiele.
Po pierwsze, przyda się w przypadku niedoszacowania realizacji zadań. Bufor pomoże nam zabezpieczyć czas przewidziany na realizację zadania, kiedy np. estymował go doświadczony programista, a realizował mniej początkujący lub w sytuacji, kiedy szacując zadanie nie znaliśmy wszystkich jego szczegółów, mających wpływ na realizację. Wówczas mamy do czynienia z niedoszacowaniem w kontekście zasobów realizujących projekt lub zakresu.
Po drugie, taki margines pozwala przygotować się na zagrożenia i ryzyka, które są przecież wpisane w naturę projektu. Wystąpienie ryzyka nie oznacza wprawdzie jego zmaterializowania się, ale powinno wyostrzyć zmysły project managera. Często ryzykiem samym w sobie jest właśnie niedotrzymanie jakiegoś terminu. Wówczas bufor może okazać się zbawienny.
Na koniec warto pamiętać o urlopach i chorobach członków zespołu projektowego. O ile urlopy można zaplanować z pewnym wyprzedzeniem, o tyle choroby zawsze nas zaskakują. Harmonogram powinien również uwzględniać planowaną i nieplanowaną nieobecność programistów, którą na ogół „ukrywa się” właśnie w buforach.
Zarządzanie buforem
Zabezpieczenie czasu poprzez dodanie marginesu bezpieczeństwa nie zapewni sukcesu. Może się wręcz okazać, że będzie go jeszcze więcej do marnowania. Brzmi strasznie? Należy zwrócić uwagę na to, 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.
Szacowanie prac w projekcie to jedno, szacowanie buforów – drugie. Zarządzanie czasem oczywiście uwzględnia margines bezpieczeństwa, jednak z uwagi na to, że bufor potrafi być doskonale marnowany, polecam czasem oddzielić te dwa zakresy i zarządzać buforem niezależnie, bo w nim potrafią kumulować się problemy, bo kiedy nie pozostaje już nic, powinien pozostać jeszcze bufor.
Karolina Jarocka
Project Manager w Grupie Unity
Zarządza projektami w sposób zrównoważony i zarazem skuteczny. Doskonale potrafi organizować pracę swoją oraz zespołu projektowego, co wykorzystuje w pracy z klientami Grupy Unity. Od wielu lat pasjonuje się światem mediów, marketingu i reklamy. Wcześniej związana m.in. z Zubi.pl.
