2. SYMULACJA REALIZACJI PROJEKTU CPM


Załóżmy, że projekt CPM rozpoczyna się w chwili zerowej. Harmonogram projektu przewiduje terminy ES (Early Start), czyli najwcześniejsze terminy rozpoczęcia kolejnych zadań, zgodnie z rysunkiem 5 i wykazem podanym w tabeli 2.

Tabela 2. Terminy najwcześniejszego rozpoczęcia zadań i przykładowe wyniki symulacji

	zadanie	t0,9 [dni]	poprzednik	zasoby	terminy ES	wynik symulacji t
1	3,5	19	-	Jan	0	10
2	B	32	A	Ewa	19	13
3	C	15	B	Karol	51	8
4	D	18	-	Ewa	0	19
5	E	20	D	Beata	18	24
6	F	22	E	Filip	38	4
7	G	38	A	Beata	38	24
8	H	17	G	Alek	76	5
9	I	14	C;F;H	Alek	93	10

Wykorzystując „symulator” czasów t realizacji zadań, można łatwo symulować rzeczywisty czas TCPM realizacji projektu, wpisując wyniki w zaznaczone pola tabeli 3.


Tabela 3. Schemat 25 etapów symulacji projektu CPM i przykład jednej realizacji

1	Ile trwało zadanie A?	wynik symulacji	10
2	Termin zakończenia zadania A:	przenieść wynik z pola 1	10
3	Ile trwało zadanie D?	wynik symulacji	19
4	Termin zakończenia zadania D:	przenieść wynik z pola 3	19
5	Kiedy Ewa może zacząć zadanie B?	maksimum z pól 1; 3; ES zadania B	19
6	Ile trwało zadanie B?	wynik symulacji	13
7	Termin zakończenia zadania B:	suma pól 5 + 6	32
8	Kiedy Karol może zacząć zadanie C?	maksimum z pól 7; ES zadania C	51
9	Ile trwało zadanie C?	wynik symulacji	8
10	Termin zakończenia zadania C:	suma pól 8 + 9	59
11	Kiedy Beata może zacząć zadanie E?	maksimum z pól 2; 4; ES zadania E	19
12	Ile trwało zadanie E?	wynik symulacji	24
13	Termin zakończenia zadania E:	suma pól 11 + 12	43
14	Kiedy Filip może zacząć zadanie F?	maksimum z pól 13; ES zadania F	43
15	Ile trwało zadanie F?	wynik symulacji	4
16	Termin zakończenia zadania F:	suma pól 14 + 15	47
17	Kiedy Beata może zacząć zadanie G?	maksimum z pól 2; 13; ES zadania G	38
18	Ile trwało zadanie G?	wynik symulacji	24
19	Termin zakończenia zadania G:	suma pól 17 + 18	62
20	Kiedy Alek może zacząć zadanie H?	maksimum z pól 19; ES zadania H	76
21	Ile trwało zadanie H?	wynik symulacji	5
22	Termin zakończenia zadania H:	suma pól 20 + 21	81
23	Kiedy Alek może zacząć zadanie I?	maksimum z pól 10; 13; 22; ES zadania I	93
24	Ile trwało zadanie I?	wynik symulacji	10
25	Termin zakończenia zadania I oraz całego projektu;	maksimum z pól 10; 13; 22; ES zadania I	103

Procedurę symulacji projektu CPM powtórzono 500 razy, obliczając również pracochłonność projektu, równą sumie czasów realizacji wszystkich zadań, pomnożonej przez 8 godzin/dzień.

Rys. 7. Wyniki 500 symulacji projektu CPM


Wyniki symulacji (rys. 7) są dość zaskakujące. Tylko 1 projekt (0,2%) przekroczył planowaną pracochłonność (1560 roboczogodzin), ale aż 67 projektów (13,4%) przekroczyło planowany termin TCPM = 107 dni realizacji! Zastanawiające jest również to, że minimalny czas realizacji projektu CPM wyniósł 96 dni, czyli niewiele mniej, niż planowane 107 dni. Dolna granica czasu realizacji projektu wydaje się być nieprzekraczalna, nawet przy bardzo sprzyjających warunkach realizacji zadań. Taki wynik zastanawia w porównaniu z pracochłonnością, która osiągała dość często wartości równe połowie planowanych 1560. W jednym przypadku pracochłonność była mniejsza od planowanej (1256 roboczo-godzin), a czas realizacji projektu był równy aż 154 dni!

Oznacza to, że przekroczenia deklarowanego terminu nie są spowodowane przekroczeniem estymat bezpiecznych t0,9 czasów realizacji zadań. Podstawowym powodem jest „efekt zastawki”, spowodowany brakiem odpowiedniej synchronizacji zadań projektu.

Podczas realizacji projektu może zdarzyć się wiele różnych sytuacji, które będą miały różny wpływ na czas realizacji projektu. Niektóre sytuacje będą sprzyjały wcześniejszemu ukończeniu projektu, a inne będą projekt opóźniać. Takie efekty powinny być wyraźniej widoczne na wykresie (rys. 7), a związek między pracochłonnością i czasem realizacji projektu powinien być silniej skorelowany. Tymczasem współczynnik korelacji danych na rysunku 6 wynosi zaledwie 0,382.



3. MODYFIKACJA HARMONOGRAMU PROJEKTU



Czas realizacji ścieżki zadań można wyraźnie skrócić (nawet o 20%), zachowując odpowiednie prawdopodobieństwo jej terminowej realizacji. Wystarczy, jak wiadomo, przyjąć estymaty agresywne i na końcu ścieżki dodać odpowiedni bufor. W projekcie takich ścieżek jest więcej niż jedna, ale nie zmienia to istoty rzeczy.

Modyfikację klasycznego harmonogramu CPM wykonamy w kilku etapach, polegających na wprowadzeniu kilku logicznych zmian. Zastosowana metoda znana jest jako CCPM (Critical Chain Project Management) i oprócz samego harmonogramowania, opisuje także sposób zarządzania projektem w fazie jego realizacji.

Zaczniemy od zastosowania dwóch podstawowych zaleceń:

1. przyjąć agresywne estymaty czasów realizacji zadań, równe medianom t_0,5,
2. usunąć wielozadaniowość.

W pierwszym etapie (rys. 8a) opracowano wykres Gantt’a z estymatami agresywnymi oraz z uwzględnieniem zależności między zadaniami, wynikającymi z wykazu poprzedników (tab. 1). W takim harmonogramie występują dokładnie te same trzy ścieżki: A-B-C-I, A-G-H-I, D-E-F-I, a ścieżkę krytyczną tworzą zadania A-G-H-I.

Rys. 8. Harmonogramu projektu z estymatami agresywnymi (a) i usunięcie wielozadaniowości pracy Beaty (b)

Oba zadania (E i G), realizowane przez Beatę w trybie wielozadaniowym, różnią się tym, że zadanie G leży na ścieżce krytycznej A-G-H-I, a zadanie E nie jest zadaniem krytycznym. Wielozadaniowość pracy Beaty usunięto nieco inaczej, niż w projekcie CPM (rys. 5b). Przyjęto, że zadanie G będzie realizowane najpierw, a zadanie E później (rys. 8b), co nie zmienia istoty zależności między zadaniami projektu.

Niemal zawsze istnieje kilka alternatywnych sposobów usunięcia wielozadaniowości. W większych projektach, w których występuje więcej konfliktów przydziałów zasobów, zaleca się je usuwać zaczynając od końca projektu, czyli prawej do lewej strony wykresu Gantt’a. Kolejność wykonywanych zadań określa ich priorytet, który powinien wynikać z wielu przesłanek. Krytyczność zadania jest tylko jednym z kryteriów określania priorytetu zadania. Pozostałe to: niepewność (wyrażona różnicą lub stosunkiem estymat t_0,9 i t_0,5), trudność realizacji, długość t_0,5 czasu realizacji i inne. W niektórych przypadkach wybór sposobu usunięcia wielozadaniowości ma bezpośredni wpływ na czas realizacji projektu. Należy wtedy oczywiście wybrać sposób, dający w wyniku projekt krótszy.


3.1. Powiązania nieformalne

Przyglądając się harmonogramowi z rysunku 7b, warto zauważyć, że krytyczne zadanie H nie jest w rzeczywistości tak „ważne”, jak zadania E i F. Po pierwsze, zadanie H ma dość duży luz (12 dni), a po drugie, opóźnienia realizacji zadań E i F będą silniej wpływać na opóźnienie terminu rozpoczęcia ostatniego zadania I. Zadanie E będzie mogło być zrealizowane dopiero wtedy, kiedy zakończą się G i D. Dochodzimy tu do kluczowej kwestii nieformalnych, ale logicznych powiązań zadań.

Zadanie G jest bezpośrednim poprzednikiem zadania E w szczególny sposób - nie jest wykazane jako poprzednik E w formalnym wykazie (tab. 4), ale E będzie realizowane bezpośrednio po zadaniu G, ponieważ oba zadania mają tego samego wykonawcę (Beata). To nieformalne, logiczne powiązanie zadań G-E zaznaczono na rysunku 9a, strzałką w innym kolorze.

3.2. Łańcuch krytyczny projektu

Uwzględniając nieformalne powiązanie zadań G i E, można teraz wskazać w projekcie cztery ścieżki: A-B-C-I, A-G-H-I, D-E-F-I oraz A-G-E-F-I.

W analizowanym przykładzie projektu, łańcuchem krytycznym jest ścieżka A-G-E-F-I. Za-danie H nie jest teraz krytyczne, co ostatecznie rozstrzyga wątpliwości dotyczących znaczenia zadania H w klasycznym harmonogramie CPM. Dla wygody notacji, łańcuch kry-tyczny A-G-E-F-I pokazano (rys. 9b) w postaci „wyprostowanej” ścieżki. W łańcuchu kry-tycznym powinny znaleźć się te zadania, które mają wyższy priorytet w stosunku do zadań niekrytycznych.

3.3. Zadania niekrytyczne ALAP

Zadania niekrytyczne projektu (B, C, D, H) nie muszą być planowane jako ASAP. Lepiej jest wykonać je tak późno, jak to możliwe (ALAP = As Late As Possible).
Opóźnienie realizacji zadań niekrytycznych przynosi następujące korzyści:

1. zmniejszenie intensywności prac na początku realizacji projektu,
2. zwiększenie dostępności informacji dotyczących zadań rozpoczynanych później²,
3. poprawa przepływu gotówkowego i zwiększenie NPV (Net Present Value) projektu.

Zadania niekrytyczne przesunięto „w prawo” tak bardzo, jak to możliwe. Wyniki tej zmiany pokazano na rysunku 10a. Na tym etapie budowy harmonogramu, można zauważyć, że zadania, tworzące łańcuch krytyczny, mają szczególną cechę: nie można ich przesunąć „w lewo”, bez wydłużenia czasu realizacji projektu. Cechy tej nie mają zadania niekrytyczne B, C, D, H, które można rozpocząć wcześniej, bez wpływu na czas realizacji projektu. Jest to jeden z alternatywnych sposobów identyfikacji łańcucha krytycznego.


3.4. Bufory ścieżek projektu

Czasy realizacji wszystkich zadań harmonogramu są zgodne z estymatami agresywnymi, co wymaga dodatkowej, skoncentrowanej „ochrony” ścieżek w postaci buforów. Ostatni etap modyfikacji harmonogramu polega właśnie na dodaniu buforów w odpowiednich miejscach i o odpowiedniej wielkości.


3.4.1. Bufor projektu

Najważniejszym buforem jest tzw. BUFOR PROJEKTU (Project Buffer), który chroni naj-ważniejszą ścieżkę – łańcuch krytyczny projektu. Zadaniem bufora projektu (BP) jest zapewnienie, że deklarowany termin realizacji projektu zostanie dotrzymany z dużym (90%) prawdopodobieństwem.

Wielkość bufora projektu wyznaczana jest tak samo, jak dla każdej ścieżki zadań. W naszym przykładzie, łańcuch krytyczny składa się z pięciu zadań (A-G-E-F-I), więc na-leży zastosować drugi (BII) system wyznaczania wielkości buforów. W tym celu trzeba wykonać następujące obliczenia:

Bufor projektu, dodany na końcu łańcucha krytycznego (rys. 9b), wyznacza ostatecznie czas realizacji całego projektu, równy w tym przykładzie T_CCPM = 86 dni³.



3.4.2. Bufory dopływów

Projektu nie wystarczy chronić tylko w jednym miejscu. Bufor projektu chroni tylko zadania łańcucha krytycznego. Należy pamiętać, że ścieżki niekrytyczne też wymagają ochrony, ponieważ ich zadania mogą się opóźnić, średnio w połowie przypadków. Opóźnienia za-kończenia zadań niekrytycznych będą wpływać na opóźnienie całego projektu. Wynika to z tego, że zadania niekrytyczne ALAP są „wprowadzane” do łańcucha krytycznego w miejscach, które są ściśle zlokalizowane na osi czasu. Przez podobieństwo do systemu rzeki (łańcuch krytyczny) i jej dopływów (ścieżki niekrytyczne) bufory dodawane na końcu ścieżek niekrytycznych, określane są jako BUFORY DOPŁYWÓW (Feeder Buffers⁴).

Wielkość buforów dopływów BD wyznaczana jest tak samo, jak dla każdej ścieżki zadań. W analizowanym przykładzie potrzebne będą trzy bufory dopływów, wyznaczane według systemu B_II.

1. Dla ścieżki dwuzadaniowej B-C:
BD = sqrt((t_0,9B-t_0,5B)²+(t_0,9C-t_0,5C)²) = sqrt((32-17)²+(15-7)²) = sqrt(15²+8²) = sqrt(289) = 17


2. Dla ścieżki jednozadaniowej D:

BD = sqrt((t_0,9D-t_0,5D)²) = t_0,9D - t_0,5D = 18 - 10 = 8

3. Dla ścieżki jednozadaniowej H:

BD = sqrt((t_0,9H - t_0,5H)²) = t_0,9D - t_0,5D = 17 - 10 = 7.

Ścieżki jednozadaniowe są przypadkiem szczególnym. Zadaniom D i H „oddajemy” w całości usunięty zapas bezpieczeństwa. W ten sposób jednozadaniowe „dopływy” zrealizowane będą w planowanych terminach z prawdopodobieństwem 90%. Dla celów planowania można więc od razu zastosować bezpieczne estymaty t0,9 dla ścieżek jednozadaniowych. Dla wykonawców zadań taka różnica ma jednak znaczenie, gdyż naruszenie bufora zadania-ścieżki wywołuje pewne skutki, związane z zarządzaniem buforem.
 
Dodanie buforów dopływów następuje w miejscach, w których ścieżki niekrytyczne wpływają w łańcuch krytyczny, rys. 10b.

Rys. 10. Harmonogramu projektu z zadaniami niekrytycznymi typu ALAP (a) oraz ostateczna wersja (b) harmonogramu CCPM z buforami BP, BD i BZ


Może się zdarzyć, że dodanie bufora dopływu spowoduje tak duże przesunięcie ścieżki niekrytycznej w lewo, że wyczerpie to cały luz ścieżki. Gdyby, na przykład, bufor dopływu ścieżki zadań niekrytycznych B-C (rys. 10b) wynosił więcej niż 19 dni, wówczas zadanie A musiałoby się przesunąć w lewo. W łańcuchu krytycznym A-G-E-F-I pojawiłaby się przerwa i cały projekt wydłużyłby się. Taka sytuacja dotyczy tylko ścieżek niekrytycznych, które „wypływają” z łańcucha krytycznego i ponownie do niego „wpływają” w „późniejszym” miejscu. Jeśli BD „wypchnie” inną ścieżkę niekrytyczną poza termin zerowy, to łańcuch krytyczny nie zmienia się - jest identyfikowany jeszcze przed dodaniem buforów.

Według CCPM, projekt należałoby rozpocząć 10 czerwca i realizować przez 86 dni.

3.4.3. Bufory zasobów

Wprowadzone bufory BP i BD powinny gwarantować terminowe zakończenie całego projektu z prawdopodobieństwem 90%. Taka „gwarancja” wymaga jednak doskonałej synchronizacji projektu, zwłaszcza zadań łańcucha krytycznego. Chodzi o to, żeby w łańcuchu krytycznym, decydującym o terminie zakończenia projektu w czasie TCCPM, nie nastąpiły żadne przerwy.

Terminy te są znane tylko kierownikowi projektu na etapie planowania. Wykonawcy wiedzą jedynie, że:

1. zostaną odpowiednio wcześnie zawiadomieni o zbliżających się terminach rozpoczęcia swoich zadań,
2. powinni pracować możliwie intensywnie od samego początku realizacji zadań i zakończyć je tak szybko, jak to możliwe,
3. pojawienie się jakichkolwiek kłopotów, które są od nich niezależne i opóźniają realizację zadania, powinni zgłaszać kierownikowi, wiedząc, że nie będą za to karani,
4. po zakończeniu projektu, mogą natomiast liczyć na nagrodę za sprawne i bezbłędne wykonanie swoich zadań.

Wcześniejsze powiadomienie wykonawców, o zbliżających się terminach rozpoczęcia ich zadań, zostało opisane przy okazji „sztafetowej” synchronizacji zadań ścieżki. Taką synchronizację można zapewnić na dwa sposoby:

1. kierownik projektu śledzi stan realizacji zadania poprzedniego i w odpowiednim momencie (znając wymagany czas „rozruchu”) zawiadamia wykonawców następnego zadania, że powinni przygotować się do jego realizacji,
2. wykonawcy zadania następnego sami śledzą stan realizacji poprzedniego zadania, co ma tę dobrą stronę, że przejmując przedmioty odbioru, znają dokładnie ich stan i sposób wykonania.

Zastosowanie pierwszego sposobu wymaga wstępnego określenia „wymaganego czasu rozruchu”, potrzebnego wykonawcom przed rozpoczęciem swoich zadań oraz na „zmianę narzędzi i środowiska pracy”. Może to być czas potrzebny na dojazd w określone miejsce, zakończenie innych prac bieżących, wypożyczenie niezbędnego sprzętu, itp.. Każdy wykonawca, po zapoznaniu się z zakresem przydzielonego mu zadania, powinien określić o ile wcześniej chciałby być powiadomiony (bezpośrednią rozmową, telefonicznie, pocztą elektroniczną, SMS-em, itp.) przed rozpoczęciem danego zadania.

Wymagany czas wcześniejszego powiadomienia określany jest jako BUFOR ZASOBU (Resource Buffer).

Stosując drugi sposób synchronizacji zadań, bufory zasobów nie są potrzebne.

Bufory zasobów (BZ) różnią się od bufora projektu (BP) i buforów dopływów (BD) tym, że nie wydłużają ścieżek projektu. Ważna natomiast staje się lokalizacja buforów zasobów. Powinny one dotyczyć jedynie tych zadań łańcucha krytycznego, w których następuje zmiana wykonawców. Lokalizację buforów zasobów pokazano na rysunku 10b (czerwone trójkąty), przyjmując, że wszyscy wykonawcy potrzebują wyprzedzających powiadomień w przeddzień rozpoczęcia swoich zadań (BZ = 1 dzień). Beata, wykonująca zadanie E za-raz po zadaniu G, nie wymaga oczywiście wcześniejszego powiadomienia.

---

²Warto zauważyć, że jednym z powodów zachowań, określanych jako syndromu studenta (odwlekanie rozpoczynania pracy tak bardzo, jak to możliwe) było właśnie dążenie do uzyskania możliwie pełnych i aktualnych informacji o wszelkich okolicznościach realizowanych zadań.

³Dokładny czas realizacji projektu, obliczony zgodnie z regułami sumowania zmiennych losowych, wynosi T_CCPM = 90,17 dni, a bufor projektu jest nieco większy i wynosi BP = 28,17 dni.

⁴Spotyka się również określenie BUFORY ZASILAJĄCE, ale ponieważ skrót BZ wykorzystany będzie w innym zastosowaniu, pozostaniemy przy określeniu BUFORY DOPŁYWÓW.

---

Zobacz artykuły:

1. Projekt szczególna synteza ścieżek cz. 1
2. Projekt szczególna synteza ścieżek cz. 3
   

---

O Autorze

Piotr Stępień

(email: secured)

Dr Piotr Stępień - doświadczony kierownik projektów i wieloletni instruktor zarządzania projektami dla IBM. Wykładowca na Politechnice Koszalińskiej (Technologia Maszyn, Zarządzanie Projektami). Absolwent kursów w zakresie produktywnośći w Productivity Center Tokyo (Japonia). Specjalista w zakresie estymacji i harmonogramowania.

Autor licznych publikacji i opracowań z zakresu harmonogramowania i zarządzania ryzykiem. Konsultant, autor i instruktor szkoleń z zakresu "Zarządzanie Projektami" dla wielu firm i fundacji, m.in.: EXBUD; IKEA; IBM; Ministerstwo Rolnictwa; CIECH; PRUMERICA; SGH; PKO BP; POSTDATA; Lafarge Nida-Gips, PZU.

>

---

Interesuje Cię ten temat? Zapisz się na szkolenie!

http://zarzadzanieprojektami.info/LancuchKrytyczny.htm