Typowy problem w – każdym właściwie – rodzaju projektu, to opóźnienia harmonogramu. Jak się więc przed nimi zabezpieczyć? To jednak źle sformułowane pytanie; powinniśmy raczej zapytać: czy istnieją metody zwiększające szanse dotrzymania obiecanego terminu realizacji projektu?

Najpierw warto odpowiedzieć na pytanie: a skąd się biorą te opóźnienia i szybko odpowiedzieć: z opóźnień tych zadań, które leżą na ścieżce krytycznej, czyli na ścieżce tych zadań, które warunkują czas trwania projektu. W tradycyjnym podejściu przed opóźnieniami zadań zabezpieczamy się dodając do oszacowania czasu trwania zadania pewien margines bezpieczeństwa. Niestety to podejście w praktyce nie działa: po pierwsze presja rynku, klienta, biznesu wymusza jak najkrótsze czasy oszacowań; po drugie pojawiają się zjawiska takie, jak Syndrom Studenta (nie muszę chyba tłumaczyć) i Prawo Parkinsona (każda praca zajmuje tyle czasu, ile na nią przeznaczymy), powodujące te opóźnienia.

Szukając rozwiązania naszego problemu warto wyjść od analizy rozkładu czasu trwania nie-trywialnych zadań projektowych. Zwykle rozkład ten będzie wyglądał, tak jak na rys. 1. Punkt A to najbardziej prawdopodobny czas realizacji zadania, natomiast punkt B oznacza czas, w którym wykonawca ma 50% szans na wykonanie tego zadania (powierzchnie pod krzywa rozkładu na lewo i prawo od punktu B są takie same). Punkt C to oszacowanie, jakie zwykle podaje wykonawca, czyli – jak widać oszacowanie bezpieczne z około 90% szans na realizację zadania. I właśnie różnica pomiędzy C i B stanowi ten wspomniany powyżej margines  bezpieczeństwa.

Rys. 1 Agresywne i bezpieczne oszacowanie czasu trwania zadania

Więc może do budowy harmonogramu można by przyjąć te 50% oszacowania?  Tylko co zrobić z tą 50%-ową szansą przekroczenia tego oszacowania? Przecież jako PM nie jestem kamikadze, a ryzyka związane z zadaniami z pewnością trzeba wziąć pod uwagę. Odpowiedź – bardzo logiczna – narzuca się sama: dodać na końcu harmonogramu bufor, czyli skumulowany dla poszczególnych zadań margines bezpieczeństwa. Warto też zauważyć, że ten bufor nie będzie prostą sumą dawnych marginesów bezpieczeństwa zadań, lecz będzie krótszy. Dlaczego? Odpowiem pytaniem: a jaka jest zasada działania towarzystw ubezpieczeniowych? Już wiecie? Dużo bardziej skomplikowana jest odpowiedź na pytanie: a jak określić wielkość takiego bufora? Potrzymam Was trochę w niepewności, gdyż właśnie kwestia wielkości bufora będzie tematem kolejnego tekstu w tym blogu.

Mamy więc harmonogram przedstawiony na rysunku 2: czasy trwania zadań są oszacowaniami 50%-owymi, a na końcu projektu mamy bufor. Moim zadaniem jako PM-a jest zrealizowanie projektu najpóźniej na koniec bufora. Ale przecież mam szanse skończyć ten projekt wcześniej!

Rys. 2 Harmonogram z czasami agresywnymi i z buforem projektu

Co więc daje nam taka metoda budowy harmonogramu? Po pierwsze: harmonogram nawet z uwzględnieniem bufora będzie krótszy w stosunku do zbudowanego metodami tradycyjnymi (bez bufora i czasów 50%-owych).  Mamy też duże szanse, że projekt zakończy się wcześniej, ponadto ryzyka projektowe są zabezpieczone buforem, a PM dostaje do ręki narzędzie do monitorowania projektu w trakcie jego realizacji. Zgadzacie się, że takie mogą być korzyści z takiego właśnie harmonogramu?

Pewnie w tym momencie powiecie: może i są w/w korzyści, ale przecież projekty są bardziej złożone niż zwykła sekwencja zadań. W jakich sytuacjach to podejście może więc znaleźć zastosowanie w praktyce?
Już odpowiadam: a na początek projekt softwarowy, realizowany metodami zwinnymi (ang. agile). Zakres prac w takim projekcie wynika z historyjek użytkownika (tzw.user stories), które mają powstać w projekcie. Każdą z tych historyjek można oszacować zarówno w punktach lub idealnych dniach na poziomie 50%, jak i 90%. Możliwe więc będzie oszacowanie wielkości bufora projektu. I jeśli znana jest prędkość zespołu (velocity) podczas iteracji, to można określić ile iteracji potrzebnych będzie do realizacji projektu, którego zakres opisany jest w user stories.

A co w sytuacji bardziej złożonej, np. gdy metodami lekkimi pracuje kilka zespołów, zajmujących się odrębnymi funkcjonalnościami. Albo, gdy realizujemy „tradycyjny” projekt, dla którego opracowaliśmy i diagram projektu i wykres Gantta. W obu tych sytuacjach można zidentyfikować taką ścieżkę zadań, która decyduje o czasie trwania projektu, a także ścieżki dochodzące do tej najdłuższej. Ścieżkę zadań, oszacowanych metodą 50% (tzw. czasy agresywnej), decydującą o czasie trwania projektu możemy chronić wtedy buforem projektu, natomiast połączenia innych ścieżek z tą najdłuższą specjalnym buforem „łącznikowym”, zwanym buforem zasilającym.

Prosta i co ważniejsze skuteczna metoda budowania i monitorowania harmonogramu.  Sam ją stosuję niemal w każdym moim projekcie. Zarówno w projekcie doradczym, np. dotyczącym budowania systemu zarządzania projektami u moich Klientów, jak i podczas 3-dniowego szkolenia z zarządzania projektami.  A także przy realizacji prostej sekwencji zadań,  której celem jest dotarcie na lotnisko, tak by nie spóźnić się na samolot i – z drugiej strony – nie tkwić na lotnisku zbyt długo przed odlotem.

Spróbujcie!  A może już próbowaliście tego podejścia  i chcielibyście podzielić się swoimi doświadczeniami  na tym blogu? Serdecznie zapraszam.

I jeszcze jeden istotny punkt. Po przeczytaniu powyższego tekstu z pewnością zadajecie sobie pytanie: a jak określić wielkość bufora? To naprawdę „dobre pytanie”! Odpowiem na nie w kolejnym tekście na blogu.