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

Baner PMBOK vs PRINCE2 cz.3.

W poprzednim tekście porównującym PMBOK® Guide oraz manual PRINCE® zestawiłem ze sobą dwa dokumenty, tzn. plan zarządzania projektem (ang. project management plan) według PMBOK® Guide oraz dokumentację inicjowania projektu (ang. project initiation documentation) zgodnie z metodyką PRINCE2®. W szczegółach prześledziłem ich konstrukcję, by wykazać, że służą temu samemu generalnemu przeznaczeniu, jakim jest stworzenie podstawy zorganizowania i skutecznego prowadzenia projektu. Skuteczne prowadzenie projektu musi się przy tym wiązać z reagowaniem na zmiany, które w nieuchronny sposób pojawiają się w każdym działaniu projektowym.

Czy w konsekwencji dokumenty konstytuujące projekt również będą się zmieniały? Zdecydowanie tak. Owe dokumenty zawierają w sobie przecież plan projektu (metodyka PRINCE2®), czy też plany bazowe (PMBOK® Guide), a plany oczywiście się zmieniają. Prezydentowi USA Dwightowi Davisowi Eisenhowerowi, Naczelnemu Dowódcy Alianckich Ekspedycyjnych Sił Zbrojnych w Europie podczas II Wojny Światowej, przypisywane jest zdanie: „Plan jest niczym, planowanie jest wszystkim” (w oryginale: „Przygotowując się do bitwy, zawsze orientowałem się, że plany są bezużyteczne, ale planowanie jest nieodzowne”). Czy możemy sobie zatem pozwolić na swobodne podejście do dokumentów planistycznych? Zdecydowanie nie. PMBOK® Guide w odniesieniu do planu zarządzania projektem stwierdza: Nim elementy bazowe planu zostaną zdefiniowane, plan zarządzania projektem może być korygowany tak wiele razy jak to konieczne. Żaden formalny proces nie jest wymagany w tym czasie. Jednakże kiedy zdefiniowanie elementów bazowych nastąpi, to może on zostać zmieniony jedynie poprzez proces Prowadź Zintegrowaną Kontrolę Zmian (ang. Perform Integrated Change Control). W konsekwencji wnioski o zmianę będą tworzone i poddane pod decyzję, kiedy tylko zmiana jest wnioskowana. W wyniku powstaje plan zarządzania projektem, który jest stopniowo rozwijany i doprecyzowywany poprzez kontrolowane i zatwierdzane uaktualnienia aż do zakończenia projektu.

Spójrzmy zatem dokładniej na proces Prowadź Zintegrowaną Kontrolę Zmian, któremu poświęcona jest sekcja 4.6 w PMBOK® Guide. Już w pierwszym jej zdaniu czytamy, że „(…) jest to proces przeglądania wszystkich wniosków o zmianę; zatwierdzania zmian i zarządzania zmianami produktów, dokumentów projektu i planu zarządzania projektem; oraz komunikowania podjętych decyzji.” Kolejny akapit stwierdza zaś: „proces prowadzony jest od początku projektu do jego zakończenia i jest zasadniczą odpowiedzialnością kierownika projektu. Czy w metodyce PRINCE2® znajdziemy jego odpowiednik? Zdecydowanie tak. Jest nim procedura sterowania zagadnieniami i zmianami. Obejmuje ona następujące kroki:

  • Zarejestruj tzn. określ typ zagadnienia (może być to: wniosek o wprowadzenie zmian; odstępstwo, inaczej niezgodność; problem/obawa), określ jego znaczenie/priorytet, zarejestruj zagadnienie;
  • Oceń tzn. oceń wpływ na cele projektu, uzasadnienie biznesowe i profil ryzyka projektu, sprawdź znaczenie/priorytet;
  • Zaproponuj tzn. zidentyfikuj, opcje i zarekomenduj opcje;
  • Zdecyduj tzn. eskaluj w przypadku przekroczenia przyznanych uprawnień, zatwierdź, odrzuć lub odrocz rekomendowaną opcję;
  • Wdrażaj tzn. podejmij działania korygujące, aktualizuj zapisy i plany.

Kroki te ma oczywiście podjąć kierownik projektu. Czy jednak kierownik projektu jest właściwą osobą by decydować o każdym wniosku o zmianę? Zdecydowanie nie. Wspomniany powyżej krok „Zdecyduj” w procedurze zalecanej przez metodykę PRINCE2® oznacza również „eskaluj” w przypadku przekroczenia przyznanych uprawnień. Kierownik projektu, nie mając wystarczających uprawnień do wprowadzenia zmiany, będzie się zatem zwracał do komitetu sterującego, bądź wskazanej przez komitet sterujący osoby lub grupy osób pełniącej rolę „obsługi zmian” (ang. change authority). PMBOK® Guide określa podobnie: „Każdy udokumentowany wniosek o zmianę musi być zatwierdzony, odroczony lub odrzucony przez osobę odpowiedzialną, zwykle sponsora lub kierownika projektu. (…) Jeżeli jest to wskazane, to proces Prowadź Zintegrowaną Kontrolę Zmian może obejmować komitet kontroli zmian (ang. change control board)”.

Na zakończenie tej części moich rozważań przytoczę jeszcze dwa istotne cytaty, po jednym z każdej z naszych „ksiąg objawionych”. Zdanie kończące drugi akapit sekcji 4.6 PMBOK® Guide brzmi: „Stosowany poziom kontroli zmian zależy od obszaru zastosowania, złożoności konkretnego projektu, wymagań kontraktowych oraz kontekstu i środowiska, w jakim projekt jest prowadzony”. Dołóżmy do tego drugie zdanie z sekcji 11.3.2 manualu PRINCE2®: „Ważne jest, aby podejście do sterowania zmianami w projekcie wspomagało efektywne podejmowanie decyzji, a nie tworzyło niepotrzebne problemy czy biurokrację”. Zdecydowanie do takiej zgodności między obu księgami trudno coś nad to dodać.

Autor: Maciej Krupa

Poprzednie wpisy z serii:

PMBOK® Guide vs manual PRINCE2® – Zarządzanie integracją projektu cz. 2
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ż

W dobie AI i zaawansowanych modeli językowych (#LLM), otwierają się...
Niemal każdy powszechnie używany system do zarządzania projektami oferuje podobny zakres...
Jestem kierownikiem projektów od ponad 25 lat, co stanowi praktycznie całe moje dorosłe...
Przewiń na górę