Jak w szybki sposób zrozumieć, do czego służą procesy PMBOK® Guide (i zwiększyć szansę na zdanie PMP®)

utworzone przez Marcin Żmigrodzki

Pytania na egzaminie PMP^® formułowane są sytuacyjnie. To znaczy zamiast pytania o definicję, raczej spotkacie pytania o sposób zachowania się w określonej sytuacji. Na przykład zamiast pytania „Czym jest karta kontrolna?” będzie pytanie „Otrzymałeś informację, że ostatnia partia produktów była obarczona wadami. Przeanalizowałeś kolejne kroki produkcyjne i dowiedziałeś się, że każda operacja jest precyzyjnie monitorowana. Z jakiego raportu najprawdopodobniej skorzystasz?”

W związku z powyższym w trakcie dyskusji z uczestnikami jednego ze szkoleń przygotowujących do PMP^® uświadomiłem sobie, że istnieje olbrzymi problem ze zrozumieniem, czemu służą i w jakich sytuacjach bywają pomocne wybrane procesy PMBOK^® Guide. Przy odrobinie wysiłku każdy „wykuje na blachę” stronę 61, ale aby zrozumieć przeznaczenie owej książki, trzeba umieć sobie wyobrazić rzeczywiste sytuacje, w których jej poszczególne zagadnienia okazują się użyteczne. To tak, jakby wyryć wszystkie wzory z podręcznika do statystyki i wierzyć, że podróże samolotem są mniej bezpieczne od jazdy samochodem, albo, że szczepionki są szkodliwe i nieskuteczne, bo dziecko znajomego ma autyzm.

Poniżej lista przykładowych sytuacji. Na końcu tego artykułu znajdziecie ich rozwiązania i komentarze moje do nich. Pytanie do każdej z tych sytuacji jest takie samo:

Jaki proces zastosujesz w danej sytuacji i jaką technikę z PMBOK^® Guide?

1. Podpisujesz umowę z dostawcą, uzgodniona cena kontraktu to 100 000 $, a w razie szybszego wykonania dostawca otrzyma dodatkowo 1 000 $ za każdy dzień przyśpieszenia. Przy okazji pytanie, jaki to typ kontraktu.
2. W projekcie Abelardo okazało się, że partia produkcyjna wybrana do próby nie spełnia wymogów jakościowych. Postanawiasz  zlecić przejrzenie parametrów pracy maszyn.
3. W tym samym projekcie Abelardo szef produkcji wskazał jednak, że próba nie była reprezentatywna, bo pobrana z tylko 1 z 10 maszyn, choć ty pobrałeś ją zgodnie z procedurą. Zgadzasz się z nim i wspólnie z działem jakości postanawiacie zmodyfikować procedurę.
4. Dwóch członków zespołu w projekcie Rutger pokłóciło się o sposób przydzielania zadań. Nikt nie chce wykonywać zadań monotonnych. Zatem podejmujesz decyzję, aby inaczej rozdzielić zadania.
5. Jednak reszta zespołu projektu Rutger podpowiada, że konflikt między nimi ciągnie się od wielu lat i z tego względu nikt ich wcześniej nie angażował do wspólnego projektu. Ty jesteś nowym pracownikiem organizacji o tym mogłeś nie wiedzieć. Zamiast zmieniać rozdział zadań decydujesz się mediować w tej sprawie.
6. Klient w twoim projekcie Roar ciągle zmienia zdanie. Ty zaś, ponieważ nie masz wielkiej decyzyjności, posłusznie rejestrujesz wszystkie zgłoszenia i analizujesz informację o ich wpływie na plany projektu.
7. W tymże projekcie Roar dyrektor technologii poprosił, abyś tylko do niego wysyłał raporty z lista zgłoszonych żądań zmian. Oznacza to usunięcie z adresatów tego raportu samego klienta, ale szef każe, to to robisz.
8. W projekcie Roar, klient wściekł się, gdy dowiedział się, że nie dostanie od razu listy zmian, a dopiero po jej akceptacji przez dyrektora technologii. Twój szef stwierdził, że masz to załatwić. Decyzji dyrektora technologii nie da się zmienić. Zatem teraz musisz po prostu umówić się z klientem na spotkanie i załagodzić sytuację.
9. Klient w projekcie Roar ewidentnie się obraził i oznajmił, że w takim razie zakończy współpracę po bieżącym etapie. Po sprawdzeniu okazało się, że faktycznie umowa na to zezwala. Twój szef poprosił o opracowanie scenariusza jak najoptymalniejszego wyjścia z tej sytuacji. Zabierasz się natychmiast za to zadanie.
10. W projekcie Roar szef obejrzał twój scenariusz awaryjny i powiedział, żebyś wysłał go do dyrektora technologii oraz dyrektora handlowego i zapytał, co oni na to. Przygotowujesz piękną prezentację i wysyłasz do wszystkich zainteresowanych.
11. Dyrektor handlowy również zdenerwował się, za twoimi plecami spotkał się z klientem projektu Roar i ustalił, że inny zespół wykona ten projekt do końca. Będzie to zewnętrzna firma. Od następnego miesiąca ten projekt nie będzie już twoim zmartwieniem. Teraz musisz jedynie posprzątać.
12. W projekcie konstrukcyjnym jeden z twoich podwykonawców. Regularnie się spóźnia z oddawaniem swoich prac. Co tydzień prosisz go o prognozę zakończenia, obiecuje, że skończy w ciągu najbliższych kilku dni, a następnie tydzień później okazuje się, że nadal nie zakończył prac i przekazuje ci kolejną prognozę. Sytuacja powtarza się od 5 tygodni. Postanawiasz pojechać do niego i bezpośrednio od jego pracowników zebrać dane dotyczące postępu prac.
13. Klient chce zamówić rozwiązanie, jednak nie ma wiedzy, jak miałoby działać. Jest jedynie świadom swojej potrzeby biznesowej. Uznał, że najlepszym sposobem jest wyciągnięcie wiedzy od dostawców. Postanawiasz zorganizować specjalne spotkanie z potencjalnymi dostawcami, aby zebrać ich wiedzę.
14. Dział marketingu zgłosił mnóstwo zastrzeżeń do nowego pomysłu na projekt, który właśnie miał być zatwierdzony. W toku analiz okazało się, że uprzednio w ogóle nie skonsultowano koncepcji z kilkoma ważnymi działami, więc zatwierdzenie projektu odłożono. Teraz musisz na nowo przemyśleć, z kim ponownie konsultować koncepcję.
15. W trakcie projektu tworzenia systemu informatycznego spotkałeś z kierownikiem innego projektu. Powiedział ci w sekrecie, że technologia, której użyli jest bardzo niestabilna i trzeba poczekać na jej nową wersję albo wykonać mnóstwo testów i obejść błędów. Okazuje się, że również w twoim projekcie ma ona być użyta za 2 miesiące. Postanawiasz przyglądać się bliżej tej sytuacji.
16. W projekcie, który prowadzisz okazało się, że w trakcie kontroli jakości produktów pojawiły się błędy. Cięcia metalu nie są wykonane dostatecznie równo i precyzyjnie. Analiza wskazała jako źródło problemu niedoświadczonych pracowników. Postanawiasz zaradzić temu przez doszkolenie ludzi.
17. W twoim projekcie doszły cię sygnały, że zespół stracił zapał do pracy. Powodem jest rosnąca liczba zmian zakresu. Klient za nie płaci, bo jest zadowolony z pracy, ale ludzie nie widzą końca projektu i ich to irytuje. Decydujesz przerwać prace na dwa dni, wyjechać z nimi w góry i trochę się rozerwać, a przy okazji podyskutować o dalszej koncepcji realizacji projektu.

Taki przypadków można mnożyć godzinami. Na jednym ze szkoleń cały dzień analizowaliśmy głównie tego typu sytuacji i na koniec dnia uczestnicy uznali, że dopiero teraz rozumieją, dlaczego PMBOK^® Guide jest tak złożony i po co są te wszystkie procesy. Co tylko utwierdziło mnie, że taka metoda nauki jest faktycznie efektywna.

Odpowiedzcie sobie na pytanie, które procesy PMBOK^® Guide byłyby uruchomione w każdej z tych sytuacji oraz jakie techniki. Warto przed tym wykuć na pamięć sławną stronę 61 z tabelką obszarów wiedzy i grup procesów. Wpiszcie w Google „PMBOK^® Guide page 61″ a zobaczycie, co to za strona. Więcej o tym, jak odkodowywać PMBOK^® Guide możecie przeczytać w poprzednim wpisie.

Poniżej zamieszczam moją interpretację odpowiedzi. Pamiętajcie jednak, że podane wyżej przypadki są króciutki i odarte z kontekstu, zatem kilka odpowiedzi może okazać się właściwych zależnie od przyjętych założeń. Grunt, aby za udzieloną odpowiedzią stało dobre rozumienie PMBOK® Guide.

1. Proces – Conduct Procurements. Typ kontraktu to FPIF – fixed price incentive fee. Komentarz – w tym procesie zawiera się umowy.
2. Proces – Control Quality. Technika – np. Control Chart. Komentarz – to jest po prostu kontrola jakości.
3. Proces – Plan Quality Management. Komentarz – zmiana standardów to inaczej przeplanowanie jakości.
4. Proces w aspekcie planowania – Estimate Activity Resources, w aspekcie koordynacji Direct and Manage Project Work. Komentarz – przypisania zadań do ludzi w planie dokonuje się w Estimate…, zaś na bieżąco wskazania, kto, co dzisiaj robi to Direct and Manage …
5. Proces – Manage Project Team. Komentarz – to jest rozwiązywanie konfliktów, więc wspomniany wcześniej proces jest adekwatny.
6. Proces – Perform Integrated Change Control. Technika – Change register. Komentarz – identyfikacja żądań zmian (Change Requests) odbywa się w tym procesie.
7. Proces – Plan Communications Management. Komentarz – zmiana adresatów komunikacji to zmiana planu komunikacji.
8. Proces – Manage Stakeholder Engagement. Komentarz – łagodzenie napięć z interesariuszami odbywa się w tym procesie.
9. Proces – Perform Integrated Change Control. Komentarz – ten proces odpowiada za analizę wpływu zmian na projekt.
10. Proces – Manage Communications. Komentarz – rozsyłanie informacji odbywa się w tym procesie.
11. Proces – Close Procurements oraz Close Project or Phase. Komentarz – aby posprzątać, trzeba wykonać oba procesy grupy zamykania.
12. Proces – najpierw Control Schedule, a potem Monitor and Control Project Work. Komentarz – tu zakładamy bezpośrednią obserwację prac w kontekście opóźnień, czyli zbieramy Work Performance Data od ludzi, a potem interpretujemy to, czyli tworzymy Work Performance Information.
13. Proces – Conduct Procurements. Technika – Bidder conference. Komentarz – spotkania z dostawcami są w tym procesie.
14. Proces – Identify Stakeholders. Komentarz – kontekst wskazuje na inicjację projektu, a w inicjacji mamy tylko dwa procesy.
15. Proces – Identify Risks, a potem Control Risks. Komentarz – nowe ryzyko do monitorowania.
16. Proces – Develop Project Team. Komentarz – szkolenia ludzi są w tym procesie.
17. Proces – również Develop Project Team. Technika – Team-building, np. Massawa :). Komentarz – podobnie, jak motywowanie.

I pamiętajcie PMBOK^® Guide 6 staje się zwinny, co oznacza, że będzie bardziej opasły. O jakieś 100 stron bardziej. A wszystkich zainteresowanych certyfikatem PMP^® zapraszamy na nasze szkolenie przygotowujące.

PMI, PMBOK, PMP, PMI-ACP, PgMP, PfMP are registered mark of the Project Management Institute, Inc.