PMBOK® Guide vs manual PRINCE2® – Zarządzanie integracją projektu cz. 2.2

Baner PMBOK vs PRINCE2 cz.2.

Kontynuując wątek rozpoczęty w poprzednim tekście z serii PMBOK® Guide vs. manual PRINCE2® zamierzam w tym miejscu omówić podobieństwa i różnice dotyczące drugiego z kluczowych dokumentów projektowych po karcie projektu (PMBOK® Guide), czy też założeniach projektu (PRINCE2®). Jest to dokument, który nie jest podstawą podjęcia formalnej decyzji o rozpoczęciu projektu, ale podstawą jego zorganizowania i skutecznego poprowadzenia. Mowa o planie zarządzania projektem (ang. project management plan) według PMBOK® Guide oraz dokumentacji inicjowania projektu (ang. project initiation documentation) zgodnie z metodyką PRINCE2®. 

Wyjdźmy tym razem od manualu PRINCE2®. Edycja z 2017 roku przyniosła nam sporą dawkę dodatkowych informacji nt. możliwego dostosowania metodyki do warunków prowadzenia i specyfiki projektu. Poza ujęciem tego w dwóch oddzielnych rozdziałach, każdy rozdział poświęcony jednemu z 7 procesów zawiera rozważania na ten temat. Interesujący nas fragment znajdziemy w rozdziale poświęconym procesowi inicjowania projektu (ang. initiating a project). Pierwszym krokiem tego procesu jest obecnie uzgodnienie  wymagań dotyczących dostosowania. Staną się one pierwszym elementem dokumentacji inicjowania projektu. 

W dalszej kolejności definiowane są równolegle podejścia (ang. approach) do zarządzania ryzykiem, zarządzania jakością oraz kontrolowania zmian. Każdy z nich może zawierać elementy dotyczące komunikacji pomiędzy interesariuszami projektu, które następnie są zebrane w podejściu do zarządzania komunikacją. Dalej proces inicjowania projektu zawiera dwie równoległe aktywności: ustanowienie mechanizmów sterowania projektem (ang. project controls)  i stwórz plan projektu (ang. project plan). Ta istotna równoległość wskazuje, że np. dzieląc projekt na etapy (ang. stage) jednocześnie ustanawiam kluczowe momenty monitorowania i kontroli.  

Plan projektu precyzuje oczywiście jak, kiedy i za ile wytworzymy produkt końcowy projektu (ang. project product).  Wskazówki dla jego kształtu znajdziemy w tabeli 16.10. „Plan projektu może być nieformalny lub formalny w zależności od kontekstu. Może to być pojedynczy dokument zawierający opis produktu końcowego projektu, opisy produktów (składających się na produkt końcowy projektu) oraz podejście do zarządzania korzyściami. Plan projektu może zawierać komponenty w jakimkolwiek formacie współmiernym do złożoności projektu z uwzględnieniem prostej listy odpowiedzialności, produktów, działań i dat, wykresów Gantta, lub backlogu produktu.” 

Zgodnie z tą samą tabelą dokumentacja inicjowania projektu zawiera wszystkie wyżej wymienione elementy i jeszcze jeden. Jest to uzupełnione o dane finansowe uzasadnienie biznesowe, o czym wspominałem już opisując cykl życia projektu w ujęciu metodyki PRINCE2®. „Dokumentacja inicjowania projektu może być pojedynczym dokumentem zawierającym wszystkie komponenty, zestawem oddzielnych dokumentów, lub jakąkolwiek kombinacją dokumentów i danych.” Dla porządku wymienię jeszcze raz wszystkie obowiązkowe elementy dokumentacji inicjowania projektu: podejście do zarządzania ryzykiem, podejście do zarządzania jakością, podejście do kontroli zmian, podejście do zarządzania komunikacją, mechanizmy sterowania projektem, plan projektu, doprecyzowane uzasadnienie biznesowe, dostosowanie metodyki PRINCE2®. 

W szóstej edycji PMBOK® Guide również każdy z 10 obszarów wiedzy opatrzony jest rozważaniami nt. dostosowania.  Jednak ważne wskazówki w tym zakresie znajdziemy już w rozdziale poświęconym elementom podstawowym, w sekcji 1.2.5.: Odpowiednie procesy zarządzania projektem, wejścia, narzędzie, techniki, wyjścia oraz fazy cyklu życia powinny być wybrane do zarządzania projektem. Postulowana jest zatem spora swoboda kierownika projektu w wyborze tego co będzie mu potrzebne by skutecznie prowadzić projekt. Warto przy tym pamiętać o pierwszym akapicie tej sekcji. „Zwykle kierownicy projektu stosują metodykę zarządzania projektami do swojej pracy. Metodyka to system praktyk, technik, procedur i zasad wykorzystywanych przez osoby pracujące w danej dyscyplinie. Ta definicja w jasny sposób wyjaśnia, że przewodnik (tzn. PMBOK® Guide) nie jest metodyką.”  

PMBOK® Guide proponuje nam proces: Stwórz Plan Zarządzania Projektem (ang. Develop Project Management Plan). W drugim i trzecim akapicie rozdziału poświęconego omówieniu tego procesu znajdziemy następujące wytyczne. „Plan zarządzania projektem definiuje, jak projekt jest realizowany, monitorowany i kontrolowany, oraz zamykany. Zawartość planu zarządzania projektem zależy od obszaru zastosowania oraz złożoności projektu. Plan zarządzania projektem może być ogólny lub szczegółowy. Każdy plan składający się na plan zarządzania projektem jest doprecyzowany do poziomu wymaganego przez specyfikę projektu.” 

Jakie plany mają autorzy na myśli? Spójrzmy na akapit czwarty. „Plan zarządzania projektem powinien zawierać elementy bazowe (ang. baselined); tzn. niezbędnie trzeba zdefiniować odniesienia projektu dla jego zakresu, czasu i kosztów, tak aby realizacja projektu mogła być mierzona i porównywana z tymi odniesieniami oraz by efektywność mogła być zarządzana.” Możemy zatem powiedzieć, że zgodnie z PMBOK® Guide każdy plan zarządzania projektem musi zawierać: plan bazowy zakresu, plan bazowy harmonogramu, plan bazowy kosztów. Słynny trójkąt ograniczeń projektowych musi mieć zatem swój odpowiednik w planie. 

Co dalej? Sekcja 4.2.3.1 prezentuje cały zestaw planów, które mogą wchodzić w skład planu zarządzania projektem. Jednocześnie lista ta nie jest zamknięta. Poza planami bazowymi zawiera ona jeszcze dwie generalne kategorie: pomocnicze plany zarządzania i dodatkowe komponenty. Do pomocniczych planów zarządzania zostały zaliczone plany zarządzania: zakresem, wymaganiami, harmonogramem, kosztami, jakością, zasobami, komunikacją, ryzykiem, zakupami, interesariuszami. Z kolei do komponentów dodatkowych: plan zarządzania zmianą, plan zarządzania konfiguracją, plan bazowy pomiaru efektywności, cykl życia projektu, podejście do realizacji, przeglądy zarządcze. 

Podsumowując powyższe rozważania trudno mi się nie zgodzić ze wspomnianym zdaniem nt. metodyki: PMBOK® Guide nie jest metodyką. Jako zestaw dobrych praktyk w zarządzaniu projektami pozostawia kierownikowi projektu dużo większą swobodę. Jasno wskazane jest w nim, że koniecznymi elementami planu zarządzania projektem dla każdego projektu są jedynie plany bazowe precyzujące zakres, harmonogram i koszty, do których można się odnosić w realizacji projektu. W dokumentacji inicjowania projektu zgodnej z metodyką PRINCE2® odpowiadałoby to planowi projektu. Jednak metodyka wymaga od nas również odpowiedników części planów pomocniczych (podejście do zarządzania ryzykiem, podejście do zarządzania jakością, podejście do zarządzania komunikacją) oraz komponentów dodatkowych (podejście do kontroli zmian, mechanizmy sterowania), a także ujęcia doprecyzowanego uzasadnienia biznesowego i opisu dostosowania metodyki do środowiska projektu. 

Autor: Maciej Krupa

Poprzednie wpisy z serii:

PMBOK® Guide vs manual PRINCE2® – Zarządzanie integracją projektu cz. 1
Cykl życia projektu- PMBOK® Guide vs manual PRINCE2®

Spodobał Ci się ten artykuł? Udostępnij go w mediach społecznościowych.

Facebook
Twitter
LinkedIn

Bądź na bieżąco. Zapisz się do Newslettera

Zostaw swój adres e-mail aby otrzymywać więcej informacji ze świata project managementu.

Klikając przycisk Subskrybuj akceptujesz naszą politykę prywatności

Przeczytaj również

Szkolenie PRINCE2® wprowadzi Cię w procesy zarządzania projektami. Dowiedz się...
Jak otrzymać dofinansowanie do szkoleń dla pracowników? W artykule przedstawiamy...
Zarządzanie jakością w projekcie jest niezbędne, by dostarczyć produkt zgodny...
Przewiń na górę