W latach 80 XX wieku Eliyahu M. Goldratt stworzył pierwsze podwaliny do systemowego podejścia do zarządzania produkcją, które nazwał Teorią Ograniczeń (Theory of Constraints – ToC). W kolejnych latach rozwijał swoją teorię znajdując jej zastosowanie w kolejnych działach firm. W 1997 roku przyszedł czas na zarządzanie projektami.

Książka „Łańcuch Krytyczny” została wydana w Polsce w 2000 roku nakładem wydawnictwa Werbel. Co ciekawe, nie jest to podręcznik, a powieść. Goldratt napisał książkę, która nie podaje tylko suchych reguł czy narzędzi, ale przede wszystkim odpowiada na pytanie dlaczego dane podejście ma szansę powodzenia.  To właśnie sprawia, że zaproponowane rozwiązania są przekonujące, a czytelnik ma ochotę od razu przetestować nowo zdobytą wiedzę.

Nie mniej jednak, nie można nie zauważyć podobieństw między łańcuchem krytycznym, a ścieżką krytyczną – od samej nazwy zaczynając, na metodzie poprawnego budowania obu kończąc. Więc jak zbudować łańcuch krytyczny?

Należy zacząć od zbudowania… ścieżki krytycznej. Dopiero na jej podstawie wykonujemy następujące czynności:

  1. Z każdego zadania zabieramy połowę czasu.
  2. Zabrany czas sumujemy i tworzymy z niego bufor, który umieszczamy w harmonogramie.

I już.

W sumie nic się nie zmieniło, ale jednak teraz czas trwania projektu jest dwukrotnie mniejszy niż początkowy. Sceptycy zapewne zaczną się irytować, bo nie da się wykonać paczki zadań w czasie dwukrotnie krótszym. Zastanówmy się jednak co znajduje się w czasie, który podajemy PM’owi?

Zasymulujmy to na podstawie przykładu kulinarnego. Ile czasu zajmie Ci wykonanie omleta? Pewnie około 15 minut? Tylko co właściwie oznacza słowo około? W większości przypadków jest to słowo – klucz, które chowa za sobą wiele czynników związanych z ryzykiem. Dodatkowo ma tu miejsce spełnianie Prawa Hofstadtera, które mówi, że wykonanie zadania zajmuje więcej czasu, niż się spodziewasz (nawet, gdy bierzesz poprawkę na Prawo Hofstadtera). Załóżmy przez chwilę różowe okulary: wszystkie zasoby są dostępne i dobre, a omlet ma być nieskomplikowany. Ile teraz zajmie jego przygotowanie? 10 minut? Musicie przyznać, że rozbieżność jest zauważalna. Jest to związane z tym, że ludzki umysł podświadomie i/lub świadomie dodaje sobie zapas czasu na nieprzewidziane warunki, szczególnie jeśli zadanie jest niedookreślone. Nie chcę się skupiać tutaj na tym jak wygląda rozkład prawdopodobieństwa wykonania w czasie zadania usmażenia omleta, gdyż wiele już o tym napisano, a chętni sięgną chociażby do książki Goldratt’a, ale chciałbym omówić możliwości dokładniejszego oszacowania czasu trwania przykładowego „projektu”. Oczywiście jest jeszcze PERT, ale załóżmy, że wykorzystany został już do stworzenia ścieżki krytycznej.

Rysunek 1. Porównanie harmonogramów projektu "omlet" w ujęciu standardowym (górny wykres) i łańcucha krytycznego (dolny wykres). Szare zadanie to jawny bufor projektu.
Rysunek 1. Porównanie harmonogramów projektu „omlet” w ujęciu standardowym (górny wykres) i łańcucha krytycznego (dolny wykres). Szare zadanie to jawny bufor projektu.

Jak widać na rysunku 1. projekt prowadzony z wykorzystaniem ToC ma niezerową szansę na skończenie się szybciej o połowę czasu. Nie mniej szansa ta jest stosunkowo mała, z tego powodu dopuszczalne jest korzystanie z bufora (w bardziej rygorystycznym podejściu bufor również skraca się o połowę, czas bufora można dodać na koniec całego projektu, lub przed zbiorczym kamieniem milowym). Podejście metody Łańcucha Krytycznego daje nam pewne korzyści, takie jak wyeliminowanie „efektu studenta”, czy bardziej klarowne zarządzanie zasobami (zakłada się, że harmonogram stworzony według ToC jest optymalizowany pod wąskie gardło – najmocniej obciążony zasób na łańcuchu krytycznym). Dla mnie jednak najistotniejsze jest klarowne zarządzanie postępami projektu i ewentualne wprowadzanie akcji korekcyjnych.

Jeśli szansa zakończenia projektu na czas jest tak niska, to po co w ogóle to robić? I tutaj pojawia się moim zdaniem najlepsze narzędzie do monitorowania zagrożenia terminu projektu – „fever chart”.  Fever chart może być przetłumaczony na język polski jako diagram monitorowania postępu. Jest to wykres monitorujący postępy pracy oraz zużycie bufora w funkcji czasu. Jak więc go zbudować?

Każdy wykres składa się z dwóch osi – pionowej, określającej poziom wykorzystania bufora łańcucha krytycznego, oraz poziomej – określającej poziom wykonania łańcucha krytycznego. Na tak przygotowaną formatkę nanosi się dwie półproste. I tutaj koncepcji jak to robić jest bardzo dużo: część PMów rysuje dwie oddzielne linie, część dwie ze wspólnym początkiem. To jaki jest kąt nachylenia linii również zależy od podejścia PM’a i od projektu. Osobiście, kiedy korzystam z tej metody rysuję linie z wspólnym początkiem w punkcie (0,0), następnie pierwszą linię rysuję tak, aby jej koniec znalazł się w 90% wykorzystania bufora przy 100% wykonania zadania, a drugą, tak aby jej koniec znalazł się w 60% wykorzystania bufora przy 100% wykonania zadania. Przykład można zobaczyć na rysunku 2.

Rysunek 2. Przykładowy fever chart wraz z przebiegiem przykładowego projektu (linia łamana - buffer consumption).
Rysunek 2. Przykładowy fever chart wraz z przebiegiem przykładowego projektu (linia łamana – buffer consumption).

Aby móc skorzystać z analizy zapasu bufora należy:

a) Zapisać estymowany czas wykonania zadania
b) Zapisać rzeczywisty (lub uaktualnioną estymację) czas wykonania zadania
c) Zmierzyć długość bufora
d) Wyliczyć procent wykorzystania bufora ze wzoru:

wzor_1

Dla przykładu, napisanie pewnej funkcji programista wycenił na 24 godziny programowania. Zgodnie z zasadą łańcucha krytycznego czas ten obcinamy o 50%, a drugą część wrzucamy do bufora. Mamy zatem czas estymowany równy 12 godzin, oraz bufor tej samej długości. W rzeczywistości zadanie zajęło programiście 16 godzin. Zatem procent wykorzystania bufora wyniesie:

wzor_2

Wykorzystaliśmy więc 33% bufora przeznaczonego na to zadanie. Czy to dużo? Postarajmy się znaleźć odpowiedź.

Rysunek 3. Diagram wykorzystania bufora w funkcji postępu projektu. Niebieską poziomą linią zaznaczono 33% wykorzystania bufora.
Rysunek 3. Diagram wykorzystania bufora w funkcji postępu projektu. Niebieską poziomą linią zaznaczono 33% wykorzystania bufora.

Jeśli wykorzystałeś 33% bufora, zakładając takie progi wykresu jak sugerowałem wcześniej to:

  • a) Jeśli projekt nie osiągnął 35% wykonania jest źle.
  • b) Jeśli projekt mieści się pomiędzy 35 a 55% wykonania – jest nie źle, ale należy monitorować postępy.
  • c) Jeżeli projekt jest już wykonany w więcej niż 55% jest dobrze, a Twój zespół znacznie wyprzedza estymowany przez siebie harmonogram.

Co nam daje to narzędzie? Dzięki takiemu podejściu do monitorowania postępu w projekcie wiemy, kiedy poprosić o dodatkowe zasoby, a kiedy ewentualnie zasoby można zwolnić – w ten sposób obniżając  całkowity koszt projektu. Nie skupiamy się na pojedynczym zadaniu, ale patrzymy bardziej holistycznie na projekt.  Łatwiej też wychwycić konieczność uruchomienia spustów(trigger’ów) – działań zaradczych z przeprowadzonej analizy ryzyka. Metoda ta może również, przynajmniej częściowo, służyć do oceny jakości pracy członków zespołu. Jeśli taka ewaluacja jest przeprowadzona prawidłowo, może sprawić, że narzędzie to będzie działało jako motywacja dla członów zespołu – zwiększy ich wydajność i pozwoli uniknąć spełnienia prawa Parkinsona (wykonywana praca rozszerza się tak, by wypełnić czas dostępny na jej ukończenie). Pomimo, że stworzenie i monitorowanie projektu przy pomocy tego narzędzia nie jest rzeczą najprostszą, w mojej ocenie zalety przewyższają wady tego narzędzia.

Reasumując, metoda Łańcucha Krytycznego nie polega na obcięciu czasu estymowanego na zadania o 50%. Jest to bardziej złożona metodyka, która dostarcza bardzo użyteczne narzędzia, jakich przykładem jest fever chart. Dodatkowo metodyka ta jest kompatybilna z innymi metodykami PM, jest do nich świetnym uzupełnieniem. Zachęcam do zapoznania się z dziełem Goldratt’a oraz dobrymi opracowaniami dostępnymi w Internecie, a także testowania nowej wiedzy w Waszych projektach.

PODZIEL SIĘ
Łukasz Paluszkiewicz
Absolwent automatyki i robotyki na Wydziale Mechanicznym Politechniki Wrocławskiej. Z projektami mniej lub bardziej związany od 5 lat. Od 3 lat pracuje na stanowisku Inżyniera do spraw projektów w firmie 3M. Ma na swoim koncie prowadzenie i uczestniczenie w wielomilionowych inwestycjach we Wrocławiu. Uczestnik wielu spotkań Dolnośląskiej Grupy Regionalnej IPMA, oraz innych eventów związanych z zarządzaniem projektami.

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ