Metoda ścieżki krytycznej: a co z ryzykiem?

Metoda ścieżki krytycznej umożliwiająca harmonogramowanie przedsięwzięć jest kluczowym narzędziem zarządzania projektami. Kierownicy projektu powinni jednak zrozumieć, że standardowa metoda ścieżki krytycznej wymaga uzupełnienia analizą ryzyk harmonogramowych. Inaczej prawdopodobieństwo zmieszczenia się w wyznaczonych terminach realizacji projektu będzie bardzo niskie.

Metoda ścieżki krytycznej umożliwiająca harmonogramowanie przedsięwzięć jest kluczowym narzędziem zarządzania projektami. Kierownicy projektu powinni jednak zrozumieć, że standardowa metoda ścieżki krytycznej wymaga uzupełnienia analizą ryzyk harmonogramowych. Inaczej prawdopodobieństwo zmieszczenia się w wyznaczonych terminach realizacji projektu będzie bardzo niskie.

Metoda ścieżki krytycznej opiera się na diagramie sieciowym pokazującym kolejność działań i zależności między nimi, reprezentującym de facto strategię projektu. Standardowa metoda ścieżki krytycznej ma swoje słabości, które można częściowo zneutralizować, wprowadzając analizę ryzyka harmonogramu. Inaczej prawdopodobieństwo realizacji projektu w terminie będzie bardzo niskie. Analiza ryzyka nie jest szczególnie istotna w małych, mało ryzykownych, stawiających nam niewielkie wyzwania projektach. Ale przy dużych projektach CPM (Critical Path Method) ma kilka słabych punktów, których musimy być świadomi. Po pierwsze, oszacowany metodą ścieżki krytycznej całkowity czas trwania projektu bazuje na kilku założeniach, które w rzeczywistości rzadko są prawdziwe (choćby tym, że prace zajmą tyle czasu, ile mają zająć zgodnie z planem, bez uwzględnienia scenariusza optymistycznego i pesymistycznego). Po drugie, w metodzie CPM posługujemy się ściśle określonymi czasami trwania poszczególnych działań, podczas gdy w rzeczywistości mamy raczej do czynienia z pewnymi zakresami określającymi najkrótszy i najdłuższy możliwy czas trwania projektu. Po trzecie, ścieżka zidentyfikowana jako krytyczna zgodnie z metodą CPM wcale nie musi być krytyczna w rzeczywistości. Innymi słowy, bardzo często wcale nie na niej należy szukać działań, których opóźnienie spowoduje opóźnienie całego projektu.

Kilka symulacji

Wyobraźmy sobie projekt, który składa się z dwóch prac mających przebiegać równolegle. Każda z tych prac ma zgodnie z planem zająć 15 miesięcy. Jaka jest szansa, że projekt zakończy się zgodnie z planem w ciągu 15 miesięcy? 100%? Czy tak bywa w rzeczywistości? Spójrzmy na inny typowy przykład: dwa działania zaplanowane jedno po drugim. Pierwsze ma zająć 50 dni, drugie - 80 dni. Jaki jest najbardziej prawdopodobny czas trwania projektu, na który składają się te właśnie dwa działania? To proste, 130 dni. Wpisując te dane w oprogramowanie MS Project otrzymujemy potwierdzenie: o ile wszystko zabierze dokładnie tyle, ile ma zabrać, to łączny czas trwania projektu wyniesie właśnie tyle. Ale czy ktoś z was wziął kiedyś udział w projekcie, w którym zaplanowane prace zajmują w rzeczywistości dokładnie tyle czasu, ile miały zająć? W rzeczywistości mamy do czynienia z pewnym zakresem możliwości, pewnymi ramami określanymi przez pesymistyczny i optymistyczny scenariusz.

Dobrym przybliżeniem pozwalającym oszacować minimalny i maksymalny czas trwania naszego projektu jest rozkład trójkątny (triangular distribution). Przypomnę, że cały czas mówię o tym samym zakresie pracy - żadnych nieoczekiwanych zdarzeń, żadnych nieoczekiwanych dodatkowych prac. Jaki mamy wynik? PERTMaster podaje oszacowanie: od 110 do 200 dni. Do tego prawdopodobieństwo zakończenia projektu w najbardziej prawdopodobnym czasie - owe wspomniane wcześniej 130 dni - wynosi tylko 15%. Załóżmy teraz, że te nasze dwa działania, 50- i 80-dniowe, są równoległe. Prawdopodobieństwo, że zmieścimy się w planowanym czasie trwania projektu wynosi tylko 25%, a to, że przekroczymy ów czas - 75%. Analogiczną analizę można przeprowadzić dla dowolnie dużego projektu. Wróćmy na chwilę do naszego pierwszego projektu, w którym dwie równoległe prace miały zająć po 15 miesięcy. Jaka jest tak naprawdę szansa, że cały projekt zakończy się w ciągu 15 miesięcy? 25%. Tak naprawdę nie jest to zaskakujące. Okazuje się po prostu, że nawet "najbardziej prawdopodobny czas zakończenia projektu" nie jest najbardziej prawdopodobny - w większości sytuacji.

Zastanówmy się jeszcze nad "krytycznością" ścieżki krytycznej. Wyobraźmy sobie projekt składający się z dwóch równoległych działań. Ich charakterystyki wyglądają tak: działanie A - optymistyczny czas trwania 10 tygodni, najbardziej prawdopodobny 12, pesymistyczny 16, działanie B - optymistycznie 8 tygodni, najbardziej prawdopodobnie 10, pesymistycznie 18. Która ścieżka jest krytyczna? Na oko A. Jaki jest najbardziej prawdopodobny czas zakończenia projektu? W przybliżeniu 12 tygodni. Tak naprawdę jednak najbardziej prawdopodobny czas zakończenia projektu wynosi 13,1 tygodnia, a 90-proc. szansę zakończenia projektu na czas osiągamy dopiero na poziomie 15 tygodni. Ścieżka A jest krytyczna tylko w 63%. Innymi słowy, istnieje ryzyko na poziomie 37%, że projekt zostanie opóźniony przez działania, które znajdują się na ścieżce B.

Jaki z tego wniosek? Tak naprawdę to, co uznajemy zgodnie z metodą ścieżki krytycznej za najbardziej prawdopodobny scenariusz, jest scenariuszem optymistycznym! Oszacowany w ten sposób termin zakończenia projektu bardzo łatwo jest przekroczyć!

Proces analizy ryzyka harmonogramu

Ten proces składa się z sześciu etapów: przeglądu, identyfikacji ryzyka, modelowania, określania zakresów czasów trwania działań, symulacji Monte Carlo oraz podsumowania w postaci raportów, wykresów i planu ograniczania ryzyka.

Na etapie przeglądu ustalamy planowaną sekwencję i harmonogram działań, wykorzystując standardową metodę ścieżki krytycznej. Ważne, by wziąć pod uwagę dni wolne od pracy i inne sztywne ograniczenia wpływające na harmonogram; być pewnym, że pamiętano o wszystkich koniecznych działaniach i jeszcze sprawdzić, że uwzględniono założenia i zastrzeżenia poczynione przez osoby, które określały najbardziej prawdopodobne czasy trwania poszczególnych działań. Drugi etap, identyfikacji ryzyka, jest najważniejszym etapem całego procesu. Wykorzystując wszystkich dostępnych ekspertów i doświadczonych uczestników projektu staramy się określić, jakie ryzyko związane jest z działaniami, które znajdują się na ścieżkach o największym stopniu krytyczności. W trzecim etapie, modelowania, określamy harmonogram sumaryczny według metody CPM, koncentrując się na ścieżkach najbardziej krytycznych. Na tym etapie musimy uwzględnić korelacje, jakie zachodzą między poszczególnymi działaniami, a które są nieuchronne we wszystkich większych projektach. Niewątpliwie jest nam potrzebny specjalista od tworzenia takich modeli. Zastrzegam, że taki model nie powinien obejmować więcej niż 200 działań, ale też nie mniej niż 50. Jeśli nasz projekt jest bardziej złożony, należy pogrupować działania w kategorie o podobnej charakterystyce ryzyka, określanej podobnym rozkładem. Staramy się przy tym podzielić projekt na działania, które zajmują mniej więcej tyle samo czasu. Im więcej czasu zajmuje analizowane działanie, tym większe ryzyko, że ewentualne opóźnienia mogą okazać się naprawdę poważne w skutkach dla całego projektu. Czasy przestoju, przerw technicznych itp. oznaczamy również jako działania, co zwiększa przejrzystość całego modelu. Nie ma sensu przyjmowanie sztywnych zastrzeżeń, że MUSIMY coś skończyć w określonym terminie. W tej analizie zastanawiamy się nad tym, co jest możliwe (i z jakim prawdopodobieństwem), nie nakładamy sobie sztywnych ograniczeń. W kolejnym etapie, kluczowym dla rezultatów całego naszego ćwiczenia, określamy optymistyczne, najbardziej prawdopodobne i pesymistyczne czasy trwania poszczególnych działań, opierając się na opinii ekspertów i doświadczonych członków zespołu projektu. Dochodzimy wreszcie do etapu wymagającego wykorzystania narzędzi takich jak Crystall Ball czy PERTMaster, a więc na podstawie naszego modelu i znajdujących się w nim danych przeprowadzamy symulację Monte Carlo składającą się z minimum tysiąca iteracji. Na koniec podsumowujemy całość i zastanawiamy się, co oznaczają dla nas uzyskane wyniki. Sporo informacji uzyskamy tworząc wykresy skumulowane, umożliwiające określenie, którego dnia zakończymy projekt z prawdopodobieństwem 70%, 80% czy 90%. Czy mamy w harmonogramie rezerwy, które zwiększają prawdopodobieństwo osiągnięcia wyznaczonej daty zakończenia projektu do 80%? Nie można podpisywać kontraktu, w którym prawdopodobieństwo naszego sukcesu wynosi 2%! Ale jaki powinien być bufor? Do jakiego prawdopodobieństwa osiągnięcia sukcesu mamy dążyć? Na te pytania musimy odpowiedzieć sobie sami.

Końcowe zastrzeżenia

Jak zmniejszyć prawdopodobieństwo, że dane, które zgromadziliśmy na początku, mają niewielką wartość? Jeśli to tylko możliwe, należy zapytać o zdanie więcej niż jednego eksperta. Można posłużyć się komercyjnie dostępnymi bazami danych zawierającymi informacje o kilku tysiącach zrealizowanych projektów. Każdemu z takich projektów przypisanych jest kilka tysięcy atrybutów, które mogą być nam przydatne. Korzystanie z takiej bazy jest kosztowne, ale oczywiście, jeśli projekt jest duży i mamy zasoby na takie badania, to może warto zapłacić. Można skorzystać z innych wzorców. Można skorzystać z własnej bazy danych o historii zrealizowanych projektów. Można też odwołać się do norm określających np. wydajność pracy. Możliwości bardziej precyzyjnego określenia czasów trwania planowanych prac jest sporo.

Czy każdy projekt wymaga przeprowadzenia opisanej tu analizy ryzyka związanego z harmonogramem projektu? Oczywiście nie, zasadność przeprowadzenia takiej analizy zależy od wielkości i szacowanych kosztów projektu. Ale jeśli wysiłek włożony w analizę jest mniejszy niż potencjalne straty wynikające z kiepskiego oszacowania harmonogramu, to znaczy, że warto podjąć wysiłek analizy. Zawsze trzeba rozważać koszty i potencjalne korzyści równolegle.

<hr>Artykuł napisano na podstawie wykładu "Schedule Risk Analysis" wygłoszonego przez George'a Sifri na kongresie zorganizowanym przez warszawski oddział Project Management Institute oraz Management

Training & Development Center.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200