Zbliża się termin ukończenia projektu, a Twój pracownik odpowiedzialny za wykonanie jednego z ważniejszych etapów pracy właśnie zachorował. Poza tym już wiesz, że przekroczyłeś przewidziany na ten cel budżet i na pewno nie uda się tego wykonać w zaplanowanym czasie. A jeszcze czeka Cię spotkanie z szefem, któremu będziesz musiał wyjaśnić, dlaczego po raz kolejny pojawiają się problemy. To prawdziwy horror! A przecież wcale nie musi tak być. W naszym haśle przeczytasz, jak wykorzystać prostą i skuteczną metodę zarządzania projektem, aby w przyszłości uniknąć podobnych problemów.

Dowiedz się więc:

1. Jak skrócić czas realizacji projektu o 25%?
2. W jaki sposób skutecznie kontrolować realizację projektu, aby wyeliminować niepożądane działania?
3. Jak 15% taniej wykonać zadanie, dzięki efektywniejszemu wykorzystaniu zasobów?

Firma „Wadix”, zajmująca się projektowaniem i wytwarzaniem urządzeń elektronicznych specjalnego przeznaczenia, obecnie przygotowuje się do realizacji nowego projektu.

Stworzenie tego nowego urządzenia wymaga opracowania modułu wewnętrznego (odbiornik), modułu zewnętrznego (obudowa i sterowanie), przygotowania oprogramowania testowego urządzenia oraz montażu, integracji i testowania całego urządzenia.

Kierownikiem tego projektu jest Wojtek Lewandowski, doświadczony specjalista prowadzący już w swojej karierze wiele różnych projektów. Wojtek, choć już wielokrotnie radził sobie z podobnymi projektami, to jednak stale zastanawiał się, jak można by tak zarządzać projektem, by zrealizować go w krótszym czasie, lepiej kontrolować go w trakcie realizacji oraz uniknąć problemów z budżetem, zakresem i kosztami. Po lekturze książki E.Goldratta „Łańcuch krytyczny” postanowił zastosować kilka nowych rozwiązań.

Określenie zadań w projekcie

Swoją pracę przy projekcie Wojtek rozpoczął od opracowania sieci projektu, tj. określenia poszczególnych zadań projektowych oraz zależności miedzy nimi, tak jak to zwykle realizował przy swoich projektach. Tym razem jednak postanowił zwrócić szczególną uwagę zarówno na cele projektu, jak i na włączenie członków zespołu do opracowania diagramu projektu, tak by powstał precyzyjny i zrozumiały dla wszystkich zapis.

Mając wstępny opis realizacji projektu, diagram projektu opracowany przez Wojtka i jego zespół wyglądał tak jak na rysunku 1. W tab.1 znajdują się podstawowe informacje projektowe.


Tab.1. Podstawowe informacje projektowe

Rys.1 Diagram projektu

Na podstawie tego diagramu Wojtek wyznaczył tzw. ścieżkę krytyczną, tj. najdłuższą ścieżkę zadań niezbędnych do zrealizowania projektu – ścieżkę, której zadania mają zerowy zapas czasu przy ich realizacji. Zastosował algorytm obliczający dla każdego z zadań projektu jego najwcześniejszy start i zakończenie, a następnie najpóźniejszy start i zakończenie. Te zadania, dla których najwcześniejszy i najpóźniejszy start oraz najwcześniejsze i najpóźniejsze zakończenie są sobie równe, nie mają zapasu (rezerwy) czasu i stanowią ścieżkę krytyczną.
Wyliczył w ten właśnie sposób, że najdłuższy możliwy czas realizacji tego projektu (czyli ścieżka krytyczna: S-1.1-1.2-1.3-4.1-4.2-4.3-4.4-K) to 30 tygodni.

Typowe problemy podczas realizacji projektu

W tym jednak momencie zaczął się zastanawiać, czy ten diagram może być podstawą realnego harmonogramu projektu.

W dotychczasowej praktyce projektowej miał bowiem zawsze problemy z następującymi zagadnieniami:

• określaniem czasu trwania poszczególnych zadań, które wydawały mu się zbyt długie i które nie zmuszały wykonawców do efektywnej i skoncentrowanej pracy nad tymi zadaniami,
• jak najszybszym rozpoczynaniem różnych zadań w projekcie, co powodowało zarówno dużo zamieszania, jak i – paradoksalnie - nie przyczyniało się do szybszego zakończenia tych zadań,
• dostępnością wykonawców dla opracowanego wcześniej harmonogramu, gdyż często okazywało się, że wg tego właśnie planu muszą oni wykonywać w tym samym czasie różne zadania, co było oczywiście fizyczną niemożliwością i powodowało opóźnienia w projekcie.

Dlatego też postanowił wnikliwie przeanalizować każdy z tych problemów i znaleźć dla każdego z nich działające i możliwe do zastosowania w praktyce rozwiązanie.

Szacowanie czasu trwania zadań

Analizując pierwszy z powyższych problemów, Wojtek szybko uprzytomnił sobie, że przy tradycyjnym podejściu, członkowie jego zespołu szacowali czasy trwania poszczególnych zadań, tak by zapewnić sobie blisko 100%-owe (zwykle 90%-owe) prawdopodobieństwo realizacji tych zadań projektowych na czas. A takie podejście oznaczało, że czasy były znacznie przedłużone - że w poszczególne zadania wbudowywane były znaczne rezerwy czasowe.

Co więc należałoby zrobić, by uzyskać w harmonogramie krótsze czasy realizacji zadań? Wojtek wpadł na pomysł, by poprosić członków swojego zespołu projektowego zarówno o oszacowanie czasu trwania dotychczasową „bezpieczną” metodą, jak i o „ambitne” oszacowanie czasu trwania tych zadań – takie, by prawdopodobieństwo realizacji w tym czasie wynosiło 50%!

Oznaczało to więc, że teraz podane przez nich przewidywane czasy trwania zadań projektowych są znacznie krótsze (w stosunku do pierwotnych, tzw. „bezpiecznych” szacunków) i że w co drugim przypadku mogą zostać niezrealizowane w podanym czasie.

Uwaga

Konieczne jest pokazanie zespołowi, że zarówno kierownik projektu, jak i zarząd firmy, mają świadomość takiego podejścia do szacowania czasu trwania poszczególnych zadań. Dlatego zmieniony musi być też system oceny pracowników biorących udział w projekcie: związany on musi być z realizacją całego projektu w zaplanowanym czasie, a nie z realizacją poszczególnych zadań w oszacowanym czasie!

Dopiero wtedy zaproponowana zmiana w podejściu do szacowania czasu trwania zadań ma szansę być zrealizowana w praktyce. Zmiana ta oznacza, że nie będzie negatywnych konsekwencji za ewentualne opóźnienie zadania w stosunku do oszacowania podanego w nowy sposób.

Zestawienie czasu trwania zadań dla dotychczasowego („bezpiecznego”) i nowego podejścia (skrócenie czasu trwania o połowę) przedstawia tab.2.

Tab.2. Zadania projektowe z uwzględnieniem skróconego czasu ich realizacji

Harmonogram zadań

Następnie Wojtek postanowił zająć się kolejnym problemem: jak najszybszym rozpoczynaniem różnych zadań w projekcie, co powodowało zarówno dużo zamieszania, jak i – wbrew pozorom - nie przyczyniało się do ich szybszego zakończenia.

Postanowił podejść do tego zagadnienia zupełnie inaczej: rozpoczynać te zadania „tak późno, jak to możliwe”. Dlaczego?

Kierownik projektu możne to zrobić z trzech następujących powodów:

1. chce zminimalizować liczbę prac rozpoczętych i niezakończonych,
2. chce zminimalizować groźbę ponownej realizacji poszczególnych zadań i dokonywania poprawek z tym związanych, w sytuacji gdy późniejsze rozpoczynanie zadania może zapewnić więcej informacji potrzebnych do jego realizacji,
3. chce zapewnić sobie łatwiejszą realizację tego nowego podejścia, gdyż takie podejście ułatwi w jednym z kolejnych kroków identyfikację łańcucha krytycznego.

W pierwszej chwili takie podejście wydaje się szokujące: zaczynać później coś, co może być rozpoczęte wcześniej. Jednak dla lepszego zarządzania projektem zgodnie z przyjętymi zasadami należy rozpocząć realizację zadań wtedy, gdy jest to niezbędne.

Rys.2 przedstawia diagram projektu Wojtka, uwzględniający także czas, po skróceniu czasów trwania poszczególnych zadań o połowę oraz przy uwzględnieniu jak najpóźniejszego ich rozpoczynania.

Rys.2 Diagram projektu po nowym oszacowaniu trwania zadań i ustaleniu harmonogramu realizacji projektu.

Wyeliminowanie konfliktu zasobów

Kolejny problem, którym zajął się Wojtek, to kwestia niedostępności pracowników dla opracowanego wcześniej harmonogramu, gdyż często okazywało się, że wg tego właśnie planu muszą oni wykonywać w tym samym czasie różne zadania, co było oczywiście niemożliwe i powodowało opóźnienia w projekcie.

Dlaczego tak się działo? Ponowne spojrzenie na diagram projektu przedstawiony na rys. 2 uprzytomniło mu jedną zasadniczą kwestię: ten harmonogram uwzględniał tylko czynnik czasu i zależności czasowe pomiędzy poszczególnymi zadaniami! Nie uwzględniał natomiast samych zasobów, czyli jego pracowników i zadań przez nich realizowanych!

Wniosek, do jakiego szybko doszedł był prosty: konieczne jest stworzenie wiarygodnego harmonogramu projektu, eliminującego tzw. konflikt zasobów, polegający na tym, że jego specjaliści przydzieleni są do zadań, które mieliby realizować w tym samym czasie.

Wojtek musiał więc tak przebudować swój dotychczasowy diagram projektu, by specjaliści przydzieleni do projektu nie byli zmuszeni do pracy nad dwoma zadaniami jednocześnie. Na rys.3 przedstawiono diagram projektu po usunięciu tego konfliktu zasobów.
Jak Wojtek zrobił taką eliminację konfliktu zasobów? Rozpoczął liczenie od końca diagramu projektu i analizował po kolei zadania i potrzebne do ich realizacji zasoby oraz ich obciążenie, tak by znaleźć zasoby przewidziane do jednoczesnej pracy nad kilkoma zadaniami i wyeliminować takie właśnie sytuacje. Tylko w ten sposób mógł stawiać pytania: co (jakie zadanie) trzeba wykonać, by uzyskać oczekiwany wynik, czyli produkt projektu.

Rys.3 Diagram projektu po eliminacji konfliktu zasobów

Określenie łańcucha krytycznego

Następnym etapem było określenie, które zadania wpływają na czas trwania całego projektu, biorąc pod uwagę zarówno zależności czasowe, jak i zależności zasobowe projektu. Ponieważ realizacja tych właśnie zadań warunkuje terminową realizację całego projektu, to właśnie one muszą być przedmiotem szczególnej uwagi Wojtka - kierownika projektu. W ten sposób powstaje ścieżka, która jest „wąskim gardłem” czasu realizacji projektu. Ścieżkę tę można nazwać „łańcuchem krytycznym”.

Łańcuch krytyczny to najdłuższy łańcuch zadań projektowych.

Łańcuch krytyczny w projekcie kierowanym przez Wojtka przedstawiony jest na rys. 4.

Rys. 4. Łańcuch krytyczny

Wojtek obliczył, na podstawie danych z tab.1, że łańcuch krytyczny projektu wynosi 18 tygodni. W porównaniu z obliczeniem czasu trwania projektu wg ścieżki krytycznej uzyskał skrócenie czasu trwania projektu o 12 tygodni. Po chwili analizy doszedł do wniosku, że zyskał coś jeszcze. Łańcuch krytyczny nie zmieni się bowiem w trakcie projektu, natomiast ścieżka krytyczna może się zmienić, gdyż opóźnienie zadań nieleżących na ścieżce krytycznej może spowodować wydłużenie całego projektu i tym samym powstanie nowej najdłuższej ścieżki zadań w projekcie, czyli nowej ścieżki krytycznej. A takie zmiany ścieżki krytycznej wymagają przeplanowania projektu. Zyskał więc stabilność harmonogramu projektu!

Bufory w projekcie

Dzięki temu nowemu podejściu Wojtek zapewnił sobie skrócenie czasu realizacji projektu, zmniejszenie liczby prac rozpoczętych i niezakończonych oraz stabilność harmonogramu. Jeszcze tylko jeden problem wymagał rozwiązania.

Skracając czas realizacji poszczególnych zadań, uzyskał skrócenie czasu trwania całego projektu – to bardzo dobrze. Z drugiej jednak strony zmniejszył tym samym bezpieczeństwo terminu realizacji – teraz zarówno on, jak i jego pracownicy nie mieli żadnych rezerw bezpieczeństwa! A przecież projekt – z samej definicji – jest przedsięwzięciem niepewnym, w którym wiele może się zdarzyć. Jak więc chronić się przed tymi zdarzeniami i jak zapewnić bezpieczeństwo całego projektu?

Kolejne ważne pytanie: gdzie w projekcie są miejsca, które przede wszystkim należy chronić, miejsca będące źródłem opóźnienia projektu?
Wojtek zaczął się zastanawiać, jakie mogą być źródła opóźnień w projekcie.

Trzy podstawowe zagrożenia dotyczące realizacji projektu w planowanym terminie to:

• opóźnienie zadań leżących na łańcuchu krytycznym – tutaj każde opóźnienie z dowolnego powodu spowoduje przedłużenie czasu realizacji projektu. Jeśli inżynier – Jerzy Malewski – nie zdąży zrealizować projektu modułu wewnętrznego (zadanie 2.1) w planowanym czasie, to spowoduje tym samym opóźnienie rozpoczęcia kolejnych zadań. A ponieważ są to zadania leżące na łańcuchu krytycznym – najdłuższej ścieżce zadań warunkujących czas realizacji projektu, to tym samym spowoduje to opóźnienie całego projektu;
• opóźnienie zadań leżących na ścieżkach zasilających łańcuch krytyczny (tj. zadań nieleżących na łańcuchu krytycznym). Przecież nie można rozpocząć realizacji zadania, jeśli nie jest dostępny produkt innego zadania, np. zadania zasilającego łańcuch krytyczny. Spowoduje to także opóźnienie całego projektu. Jeśli bowiem programista – Andrzej Górnik – nie zdąży z oprogramowaniem funkcji podstawowych (zadanie 1.2) w planowanym czasie, to spowoduje tym samym opóźnienie rozpoczęcia kolejnych zadań (zadanie 1.3). A ponieważ są to zadania leżące na łańcuchu krytycznym – najdłuższej ścieżce zadań warunkujących czas realizacji projektu, to tym samym spowoduje to opóźnienie całego projektu;
• opóźnienia z powodu niedostępności zasobów, mających realizować zadania należące do łańcucha krytycznego. Jeśli technik – Jerzy Mazurek – nie będzie gotowy do realizacji zadania „montaż modułu wewnętrznego” i rozpocznie go później niż zakładał harmonogram, to także wtedy projekt będzie opóźniony.

Tak więc bezpieczeństwo całego projektu zależało od zapewnienia „ochrony” przed tymi trzema sytuacjami. Można to zrobić wprowadzając do diagramu projektu tzw. bufory – rezerwy czasowe, „chroniące” projekt przed różnego typu negatywnymi niespodziankami: opóźnieniami, zdarzeniami losowymi czy nieprzewidzianymi sytuacjami.

Wojtek doszedł do wniosku, że dla każdego ze zidentyfikowanych źródeł opóźnienia projektu można wprowadzić nieco inny bufor:

• Bufor projektu: zabezpieczenie całego projektu przed opóźnieniami zadań leżących na łańcuchu krytycznym, wstawiany na koniec naszego diagramu projektu. Taki bufor projektu to nic innego jak rezerwa czasowa wprowadzana na końcu projektu, przy czym ta rezerwa wchodzi w czas realizacji projektu!
• Bufory zasilające: zabezpieczające projekt przed opóźnieniami na ścieżkach zasilających (tj. niestanowiących łańcucha krytycznego), łączących się z łańcuchem krytycznym, a więc również mogących powodować opóźnienie całego projektu. Także w tym miejscu taki bufor zasilający to rezerwa czasowa wprowadzana na końcu danej ścieżki.
• Bufory zasobów: zapewniające, że zasoby - czyli specjaliści uczestniczący w projekcie kierowanym przez Wojtka - będą odpowiednio poinformowani, że w określonym czasie powinni przystąpić do pracy nad zadaniem znajdującym się na łańcuchu krytycznym, czyli eliminujące opóźnienia projektu wynikające z niedostępności zasobów. Może być to więc coś w rodzaju „budzika”, przypominającego wykonawcy prac, że już wkrótce (za 2, 3 dni) będzie musiał przystąpić do pracy nad zadaniem leżącym na łańcuchu krytycznym. Budzikiem będzie na przykład informacja przekazana technikowi Jerzemu Mazurkowi przez kierownika projektu Wojtka, że za tydzień będzie rozpoczynał realizację zadania 1.3. Takim buforem zasobu może być także inny specjalista, który mógłby zastąpić Jerzego Mazurka w razie choroby.

Wojtkowi pozostał w tym momencie już tylko jeden problem: określenie wielkości tych buforów. Można przyjąć, że bufor równa się połowie czasu trwania zadań, które ma zabezpieczać. Diagram projektu, jaki narysował Wojtek po uwzględnieniu buforów, przedstawiony jest na rys. 5.

Rys. 5. Diagram projektu z buforami (BP: bufor projektu, BZ: bufor zasilający)

Powyższe kroki doprowadziły do powstania diagramu projektu – planu realizacji projektu, mówiącego:

• kto realizuje zadania,
• kiedy są realizowane poszczególne zadania,
• jak zabezpieczony jest projekt: zarówno jego łańcuch krytyczny i ścieżki zasilające, jak i dostępność zasobów (czyli wykonawców projektu).

Ten plan ma następujące cechy:

1. jest planem realnym do wykonania przy posiadanych zasobach,
2. stanowi najbardziej dokładną reprezentację zdolności firmy do realizacji pojedynczego projektu, gdyż uwzględnia zarówno zależności logiczne pomiędzy zadaniami (co po czym może być wykonane), jak i dostępne zasoby – specjalistów firmy i to w taki sposób, który eliminuje wspomniane uprzednio konflikty zasobów,
3. chroni klienta przed wieloma źródłami odchyleń, które nie mogą być wyeliminowane przez kierownika projektu,
4. nie zawiera niepotrzebnych zabezpieczeń (rezerw czasu),
5. jego bufory: bufor projektu i bufory zasilające chronią łańcuch krytyczny, minimalizując wpływ zmienności czasu trwania poszczególnych zadań i związaną z tym potrzebę przeplanowywania,
6. identyfikuje zasoby niezbędne do realizacji zadań, należących do łańcucha krytycznego, a więc kluczowe dla terminowej realizacji projektu,
7. zwiększa zdolność zespołu projektowego do wcześniejszego zakończenia projektu,
8. zapewnia kierownikowi projektu precyzyjną kontrolę i monitorowanie projektu.

To, co do tej pory zrobił kierownik projektu, jest planowaniem i harmonogramowaniem projektu przy zastosowaniu metody Łańcucha Krytycznego.

A jak Wojtek ma monitorować projekt metodą Łańcucha Krytycznego, wykorzystując zarządzanie buforami (ang. buffer management)? Odpowiedź na to pytanie znajdziesz w drugiej części artykułu.