Plan gotowy. Każde zadanie rozpisane, czasy trwania oszacowane, zespół przypisany, data zakończenia ustalona. Wszyscy są zgodni. Wygląda świetnie.
A potem zderzasz się z rzeczywistością.
Dostawca się spóźnia. Ktoś choruje. Zakres po cichu się rozrasta. Zanim się obejrzysz, Twój starannie przygotowany harmonogram zaczyna dryfować — a bez zapisu punktu wyjścia niemal nie da się stwierdzić, jak daleko projekt zboczył z kursu ani dlaczego.
Właśnie do tego służy plan bazowy projektu.
Czym jest plan bazowy projektu?
Plan bazowy projektu to migawka Twojego pierwotnego planu — zatwierdzona, uzgodniona wersja harmonogramu, zakresu i budżetu, utrwalona w chwili rozpoczęcia prac. To stały punkt odniesienia. Raz ustalony, nie zmienia się (chyba że zaktualizuje go formalny wniosek o zmianę).
W zarządzaniu projektami istnieją trzy główne rodzaje planów bazowych:
- Plan bazowy harmonogramu — pierwotnie zaplanowane daty rozpoczęcia i zakończenia zadań oraz całego projektu
- Plan bazowy kosztów — pierwotny budżet, w tym oczekiwane wydatki w czasie
- Plan bazowy zakresu — zatwierdzone rezultaty i wymagania (często ujęte w WBS)
Razem tworzą one Twój plan bazowy pomiaru wykonania — standard, według którego ocenisz, jak projekt faktycznie przebiega w porównaniu z tym, jak według zapowiedzi miał przebiegać.
Dlaczego plany bazowe mają znaczenie: problem „w porównaniu z czym?”
Bez planu bazowego wszystkie Twoje aktualizacje statusu wiszą w próżni. Zadanie „trochę się spóźnia” — ale spóźnia się w porównaniu z czym? Z pierwotnym planem? Z poprawionym planem z zeszłego tygodnia? Z tym, co trzy tygodnie temu usłyszał klient?
Ta niejednoznaczność to jedno z najczęstszych źródeł nieporozumień i konfliktów w zespołach projektowych. Ludzie mają różne wyobrażenia o tym, co znaczy „zgodnie z planem”, a bez wspólnego punktu odniesienia dyskusje o statusie stają się bezproduktywne.
Plan bazowy rozwiązuje ten problem, dając wszystkim tę samą odpowiedź na pytanie „w porównaniu z czym?”.
Dzięki zapisanemu planowi bazowemu na pierwszy rzut oka widzisz: które zadania rozpoczęły się lub zakończyły później, niż pierwotnie planowano, o ile przesunął się cały harmonogram, czy obecna prognozowana data zakończenia przesunęła się względem pierwotnej i które części projektu wyprzedzają plan.
Praktyczny przykład
Załóżmy, że zarządzasz premierą produktu. Twój plan bazowy mówi, że faza projektowania kończy się 5 czerwca, programowanie rusza 6 czerwca, a produkt trafia na rynek 15 lipca.
Jest 10 czerwca. Projektowanie właśnie się skończyło — z pięciodniowym opóźnieniem. Programowanie rusza dziś zamiast 6 czerwca.
Bez planu bazowego Twój wykres Gantta pokazuje tylko „Programowanie: start 10 czerwca” — co samo w sobie wygląda w porządku. Z planem bazowym widzisz to na czerwono: projektowanie miało się zakończyć 5 czerwca, zakończyło się 10 czerwca, odchylenie wynosi 5 dni, a jeśli nic się nie zmieni, premiera przesunie się na 20 lipca.
Teraz możesz na to zareagować. Może dodasz osobę do zespołu programistów, żeby odrobić dwa z tych dni. Może zgłosisz to interesariuszom już teraz, zanim później zrobi się z tego większa niespodzianka. Tak czy inaczej, zarządzasz w oparciu o informacje, a nie zgadujesz.
Kiedy ustalić plan bazowy
Właściwy moment na ustalenie planu bazowego to chwila po zatwierdzeniu planu projektu, a przed rozpoczęciem jakichkolwiek rzeczywistych prac. Jeśli ustalisz go za wcześnie (gdy plan jest jeszcze negocjowany), utrwalisz plan, który tak naprawdę nie był ostateczny. Jeśli ustalisz go po rozpoczęciu prac, stracisz szansę na zapisanie prawdziwego punktu wyjścia.
W praktyce ustalanie planu bazowego jest często częścią formalnego procesu rozpoczęcia projektu. Gdy sponsor lub interesariusze zatwierdzą harmonogram, zamrażasz go.
Niektóre zespoły ustalają też pośrednie plany bazowe przy ważnych kamieniach milowych — na przykład ponownie ustalają plan bazowy na początku fazy 2, jeśli faza 1 zakończyła się zupełnie inaczej, niż planowano. To dopuszczalne, ale powinna to być świadoma decyzja, a nie sposób na ukrycie narastających opóźnień. Za każdym razem, gdy ponownie ustalasz plan bazowy, w zasadzie resetujesz znaczenie „zgodnie z planem”, co może maskować rzeczywiste problemy z wykonaniem.
Odchylenie od harmonogramu i wskaźnik wykonania
Gdy masz już plan bazowy, do śledzenia postępów szczególnie przydatne stają się dwie miary.
Odchylenie od harmonogramu (SV) mówi Ci, jak bardzo wyprzedzasz harmonogram lub jak bardzo jesteś za nim, w kategoriach wykonanej pracy. Ujemne SV oznacza opóźnienie — wykonano mniej pracy, niż plan bazowy przewidywał na ten moment.
Wskaźnik wykonania harmonogramu (SPI) mówi Ci, jaki jest Twój współczynnik efektywności — ile zaplanowanej pracy wykonujesz na jednostkę czasu. SPI poniżej 1,0 oznacza, że dziennie wykonujesz mniej pracy, niż planowano; SPI powyżej 1,0 oznacza, że wyprzedzasz plan.
Te miary pochodzą z metody wartości wypracowanej (EVM). Ale nie musisz wdrażać pełnego EVM, by korzystać z planów bazowych. Nawet proste porównanie na wykresie Gantta — pierwotne paski pokazane na szaro obok bieżących pasków w kolorze — daje mocną wizualną informację zwrotną o kondycji projektu.
Plany bazowe a komunikacja z interesariuszami
Plany bazowe to nie tylko wewnętrzne narzędzie zarządzania projektem. To także atut w komunikacji.
Gdy klient pyta „dlaczego to trwa dłużej, niż zakładano?”, możesz otworzyć plan bazowy i omówić, co się zmieniło: faza rozpoznania ujawniła trzy dodatkowe integracje, których nie było w zakresie, co dodało 10 dni do harmonogramu programowania. Tu byliśmy, tu jesteśmy, a tak wygląda różnica.
Takie jasne, udokumentowane wyjaśnienie buduje zaufanie — znacznie bardziej niż mgliste „coś wyskoczyło”. Chroni też Ciebie. Jeśli zakres został rozszerzony, a harmonogram skorygowany za zgodą, plan bazowy utrwala ten moment decyzji.
W cyklicznych raportach dla interesariuszy zestawienie planu bazowego ze stanem faktycznym na wykresie Gantta to jeden z najczytelniejszych sposobów przekazania statusu projektu bez długich pisemnych wyjaśnień.
Typowe błędy zespołów w pracy z planami bazowymi
Nieustalenie go w ogóle. Zaskakująco częste, zwłaszcza w mniejszych projektach, w których zespoły myślą, że „po prostu zapamiętają” pierwotny plan. Nie zapamiętują.
Zbyt częste ponowne ustalanie planu bazowego. Jeśli ustalasz plan bazowy od nowa za każdym razem, gdy harmonogram się przesuwa, tracisz możliwość śledzenia skumulowanego dryfu. Plan bazowy traci sens, bo zawsze pokrywa się z bieżącym planem.
Traktowanie planu bazowego jako celu, a nie punktu odniesienia. Plan bazowy zapisuje Twój pierwotny plan. Okoliczności się zmieniają — to normalne. Celem nie jest zawsze trzymanie się planu bazowego; celem jest rozumienie i dokumentowanie powodów, gdy się go nie trzymasz.
Ustalanie planu bazowego, zanim plan się ustabilizuje. Zamroź go, gdy plan zostanie faktycznie uzgodniony, a nie wtedy, gdy wciąż trwają negocjacje.
Jak LoopGantt obsługuje plany bazowe
W LoopGantt możesz zapisać plan bazowy w dowolnym momencie, gdy harmonogram projektu jest już ustalony. Plan bazowy jest przechowywany obok Twojego bieżącego harmonogramu, a Ty możesz włączyć wizualną nakładkę, która pokazuje pierwotnie zaplanowane paski w stonowanym kolorze za bieżącymi paskami zadań.
Dzięki temu od razu widać, które zadania wyprzedzają plan, a które za nim zostają, i o ile. Podczas przeglądu z interesariuszami albo porannego spotkania zespołu takie wizualne porównanie często opowiada całą historię szybciej niż jakikolwiek pisemny raport.
LoopGantt Pro kosztuje 5 USD miesięcznie lub 45 USD rocznie za użytkownika (cena założycielska, 14-dniowy bezpłatny okres próbny) i obejmuje śledzenie planu bazowego, harmonogramowanie na wykresie Gantta, zależności, kamienie milowe i panel portfela.
Podsumowanie
Plan bazowy projektu to pierwotny plan Twojego projektu, zatopiony w bursztynie. To nie ograniczenie ani sztywny cel — to punkt odniesienia, dzięki któremu wszystko inne da się zmierzyć.
Bez niego „zgodnie z planem” to tylko opinia. Z nim to fakt, który możesz wskazać, wyjaśnić i na jego podstawie działać.
Jeśli Twój zespół zarządzał dotąd projektami bez planów bazowych, rozwiązanie jest proste: przy następnym starcie projektu poświęć minutę na zapisanie planu bazowego, zanim ruszy pierwsze zadanie. Ta jedna minuta zaoszczędzi Ci później wielu godzin nieporozumień i sporów.