Analiza ryzyka związanego ze zmianą metodyki zarządzania projektami na podstawie porównania PMBOK i PRINCE2

Z tematem zarządzania projektami mamy do czynienia niemalże codziennie – w pracy przy wykonywaniu obowiązków na rzecz konkretnego zlecenia dla klienta, w domu, planując remont, podczas planowania wakacyjnych podróży, czy robiąc zakupy w sklepie na imprezę okolicznościową. Stąd też rosnące zainteresowanie tą dziedziną.

Istnieją różne podejścia do zarządzania projektami i każda firma wybiera sposób najbardziej odpowiadający jej polityce, a także strukturze wewnętrznej, bądź opracowuje swoją własną metodykę opartą na jednej z wiodących praktyk. Jednym z najbardziej popularnych sposobów zarządzania projektami jest ten oparty na PMBOK, który stanowi świetną bazę wiedzy na temat każdego z obszarów związanych z prowadzeniem projektów. Panuje ogólne przekonanie, iż prowadzenie projektu przez certyfikowanego specjalistę PMI jest kluczem do sukcesu.

Potrzeba rynku spowodowała, iż większość przedsiębiorstw zmieniła model swojej działalności na typowo projektowy. Wymagało to nie tylko zmiany w organizacji pracy (w stosunku do formy, do której już w danym przedsiębiorstwie się przywykło), jak również mogło wymagać pewnej restrukturyzacji w celu osiągnięcia największej efektywności działań.

Przyjrzyjmy się bliżej dwóm popularnym metodykom – PMBoK i PRINCE2 – i spróbujmy zidentyfikować różne formy ryzyka związane ze zmianą jednej z tych metodyk zarządzania projektami na drugą.

Wprowadzenie do PMI i PRINCE2

PMI, czyli Project Management Institute, jest międzynarodową organizacją zrzeszającą menedżerów projektów. W 1981 założony został projekt Ethics Standards Accreditation (ESA), zbierający procedury oraz założenia teoretyczne w celu wsparcia dla osób zaangażowanych w zarządzanie projektami.

W 1983 roku opublikowano rezultaty owego projektu zawierające m.in. podstawy norm obejmujące 6 obszarów wiedzy:

• zakres,
• koszty,
• czas,
• jakość,
• zasoby ludzkie,
• komunikacja.

W 1987 roku opublikowano pierwsza edycję PMBOK^[1], będącą zbiorem terminów, wskazówek i najlepszych praktyk w zarządzaniu projektami.

PRINCE2, czyli PRojects IN Controlled Environments, jest metodyką zarządzania projektami opartą na pozytywnych i negatywnych doświadczeniach uzyskanych przez kierowników projektów z krajów anglosaskich.

Początkowo PRINCE wskazywany był jako zbiór najlepszych praktyk zarządzania projektami informatycznymi. W 1996 powstał PRINCE2 jako ogólna metoda zarządzania projektami niezależna od dziedziny biznesowej zastosowania^[5].

Oba podejścia mają wielu zwolenników i są z powodzeniem stosowane do zarządzania projektami na całym świecie.

Definicja projektu wg PMI i PRINCE2

Przyjrzyjmy się definicji projektu według standardu PMI i metodyki PRINCE2:

PMI

Projekt to tymczasowa działalność podejmowana w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi bądź osiągnięcia unikalnego rezultatu^[1].

Projekt, będący zatem tymczasową działalnością, ma na celu dostarczenie unikalnego wyrobu, unikalnej usługi bądź unikalnego rezultatu.

W podejściu PMI wydzielone są role i zadania w projekcie, ale protokoły współpracy pomiędzy nimi nie są jasno określone.

PRINCE2

Projekt to organizacja tymczasowa, powołana w celu dostarczenia jednego lub więcej produktów biznesowych według uzgodnionego uzasadnienia biznesowego^[2].

Projekt jest zatem tymczasową organizacją, której celem jest dostarczenie co najmniej jednego produktu biznesowego według uzgodnionego uzasadnienia biznesowego, a jako organizacja musi mieć jasno stwierdzoną strukturę i podział zadań, odpowiedzialności i obowiązków. Jasno zdefiniowane są również role, ich powiązania i odpowiedzialność a także sposób w jaki powinna odbywać się ich współpraca podczas realizacji projektu.

Metodyka PRINCE2 dba o to, by produkt przyczynił się do osiągnięcia zamierzonych korzyści ustalonych wcześniej w uzasadnieniu biznesowym, gdyż inaczej jest on bezużyteczny.

W PMBOK, sukcesem będzie samo dostarczenie produktu w pewnej formie (wyrób, usługa, rezultat). Co jednak idzie za tym dalej? Czy przyniesie to organizacji jakąkolwiek korzyść materialną bądź niematerialną?

Organizacja struktury projektowej i podział zadań

Organizacji projektu według PMBOK

Rysunek 1 przedstawia strukturę organizacji projektu według PMBOK. Widać na nim wszystkich interesariuszy projektu z wyszczególnieniem zespołu projektowego.

PMBOK, jako zbiór dobrych praktyk, jest kierowany głównie do kierowników projektów już na poziomie wytwórczym. Opisuje procesy, a także sposób w jaki się łączą. Opisuje także role i relacje między nimi w projekcie. Przedstawia narzędzia i techniki, które mogą być wykorzystane, lecz nie traktuje jasno o sposobie, w jaki powinny być zastosowane.

Według PMBOK:

Kierownik Projektu to osoba wyznaczona przez organizację dla osiągnięcia celów projektu^[3].

Z powyższej definicji, można odnieść wrażenie iż to Kierownik projektu ma pełną władzę w projekcie.

Model Procesowy PRINCE2

Dla porównania, na rysunku 2 przedstawiony został model procesowy PRINCE2.

Możemy na nim wyróżnić 4 jasno zarysowane poziomy zarządzania:

1. Kierownictwo Organizacji lub Programu
2. Zarządzanie strategiczne Projektem
3. Zarządzanie operacyjne
4. Dostarczanie Produktów

Sposób, w jaki PRINCE2 traktuje poziomy zarządzania i istniejące między nimi powiązania, sprawia iż interesy Organizacji i zarządzania Programem są blisko związane z zarządzaniem projektem na poziomie projektu oraz z zarządzaniem technologią na poziomie Dostarczania Produktów^[5].

Kierownik projektu jest osobą, która koncentruje się na codziennym zarządzaniu projektem. Posiada uprawnienia do prowadzenia projektu w imieniu Komitetu Sterującego w ramach ograniczeń ustanowionych przez ten komitet^[6].

Jest odpowiedzialny za wszystkie procesy z wyłączeniem Zarządzania Strategicznego. Kierownik Projektu jest rolą jednoosobową, zarządzającą projektem w ramach przydzielonych jej uprawnień, podczas gdy Przewodniczący projektu jest głównym decydentem i jest ostatecznie odpowiedzialny za sukces projektu.

Metodyka PRINCE2 opisuje procesy obecne podczas zarządzania projektem, ich powiązania a także jasno stwierdza, jak każdy z omówionych procesów powinien przebiegać. Metodyka wymaga między innymi stwierdzenia, kto i kiedy powinien wytwarzać, a kto zatwierdzać dokumentację projektu i jak powinna ona wyglądać jeszcze przed rozpoczęciem prac.

PRINCE2, ze swoją jasno stwierdzoną strukturą organizacyjną, podaje zatem gotowy sposób prowadzenia projektu bez względu na dziedzinę, podczas gdy PMBOK zdaje się być bardziej odpowiedni do zdobycia kompetencji w każdym z Obszarów Wiedzy.

Procesy i Grupy Procesów w PMI vs. Tematy, Procesy i pryncypia PRINCE2

Porównując strukturę i procesy przedstawione w PMBOK i PRINCE2, zauważymy, iż wykazują one pewne cechy wspólne (Tabele 1 i 2).

Nie sposób nie zauważyć, że Tematy w PRINCE2 zdają się być pokrewne obszarom wiedzy w PMBOK.

Różnica polega na ujęciu tematu, jak w przypadku tematu zmiana i obszarów zarządzanie zakresem i integracją w projekcie. Zarządzanie komunikacją zawarte jest w temacie plany. PRINCE2 nie omawia żadnych kwestii związanych z zarządzaniem zasobami ludzkimi. Porusza jednak temat uzasadnienia biznesowego, którego brakuje w PMBOK.

Również procesy mają swoje odpowiedniki w obu przypadkach. PMBOK zdaje się jednak omawiać zagadnienia bardziej szczegółowo.

WBS vs. PBS

Metodyka PRINCE2 skierowana jest na dostarczenie produktów biznesowych projektu zgodnie z ustaleniami uzasadnienia biznesowego. Stąd też naturalny zdaje się być podział prac ze względu na produkty – PBS^[7]. W ten sposób, menedżer projektu, może przejąć pełną kontrolę nad dostarczaniem produktów cząstkowych, a w perspektywie – produktów końcowych projektu.

Podział ten jest tym bardziej naturalny, jeśli weźmiemy pod uwagę, iż PRINCE2 wywodzi się z zarządzania projektami informatycznymi. Tutaj bowiem trudno jest jasno stwierdzić szczegółowe zadania, nie mając konkretnego podziału danego systemu informatycznego na moduły. Z punktu widzenia menedżera projektu nie jest ważne, jakie kroki trzeba podjąć w celu wytworzenia danego produktu, gdyż jest to zadanie poziomu wytwórczego, a nie zarządczego projektu. Menedżer skupia się zatem na tym, aby zdefiniowane produkty o ustalonej jakości były dostarczone w ustalonym czasie.

PMBOK sugeruje natomiast użycie WBS^[8]. O ile jest to podejście wygodne na poziomie wytwórczym projektu, o tyle na poziomie zarządczym projektów złożonych może wygenerować niepotrzebne koszty związane ze zbyt skomplikowanym planowaniem. Dodatkowo, menedżerowi projektu nie posiadającemu doświadczenia w danej dziedzinie, trudno będzie stworzyć zbliżony do rzeczywistości WBS, co może obarczyć plan projektu dużym błędem, nie tylko związanym z oszacowaniem czasu, ale i dodatkowymi kosztami prowadzenia projektu. Dla nowych i skomplikowanych projektów, zaplanowanie konkretnych prac, ich sekwencji i zależności, może również przysporzyć kierownikowi projektu sporych problemów, a co za tym idzie – wydłużyć czas analizy i planowania oraz obarczyć projekt dodatkowym ryzykiem.

Trójkąt projektu – PRINCE2 vs. PMBOK

Zarówno PMI jak i PRINCE2 wyodrębniają 6 parametrów projektu, którymi trzeba zarządzać:

Z tabeli 3 wynika, iż oba podejścia skupiają się na takich samych 5 parametrach. Jednak, podczas gdy PMI skupia się na Zasobach, PRINCE2 koncentruje się na Korzyściach, spodziewanych przy realizacji projektu.

Różnica ta ma swoje podłoże w założeniach – metodyka PRINCE2 skierowana jest do poziomu zarządczego projektu, podczas gdy podejście zaprezentowane w PMBOK kierowane jest do menedżerów projektu. Stąd też nacisk na inne obszary zainteresowań.

Okazuje się jednak, że podejście do omawianych wyżej parametrów nie jest takie samo w obu przypadkach.

Podczas, gdy dla PRINCE2 w tzw. trójkąt projektu wpisują się stałe czas, koszt i jakość, a zmienny pozostaje zakres, według PMBOK są to odpowiednio czas, koszt i zakres, a zmienna jest jakość. Jak wiadomo, w trójkącie projektu, zmiana jednego parametru, pociąga za sobą zmianę innych parametrów z owego trójkąta. Powyższe rozważania zobrazowane zostały na rysunkach 3 i 4.

Z rysunku 3 wynika, iż według PRINCE2 zmiana czasu realizacji projektu bądź kosztów będzie miała wpływ na zakres produktu, gdyż jakość dostarczanych produktów jest jasno stwierdzona i pozostaje niezmienna. Innymi słowy: zwiększenie kosztów wytwarzania bądź zwiększenie czasu dostarczenia produktów będzie miało wpływ na dostarczenie mniejszej ilości produktów o uzgodnionej jakości.

Według PMBOK (Rysunek 4) zmiana w czasie realizacji bądź kosztach będzie miała wpływ na jakość, gdyż zakres jest w tym przypadku traktowany jako suma uzgodnionych prac. Stąd też, zmieniając czas bądź koszty, zmniejszamy bądź zwiększamy jakość dostarczonych produktów.

Wniosek

Z powyższego zestawienia wynika, iż przechodząc z modelu zarządzania według PMBOK na PRINCE2 ryzykujemy, iż może nie zostać dostarczona założona ilość produktów projektu (zakres produktu końcowego może ulec zmianie). Mamy za to pewność, że dostarczone produkty będą cechowały się uzgodnioną wcześniej jakością.

Analiza ryzyka PRINCE2 vs. PMBOK

Ryzyko w PMI

Według standardu PMI ryzyko to niepewne zdarzenie lub stan, który, jeśli się zdarzy, ma wpływ na co najmniej jeden z celów projektu.

Z powyższej definicji wynika, iż ryzyko może być zdarzeniem negatywnym (zagrożeniem) bądź pozytywnym (szansą).

Ryzyko dzielone jest dalej na:

• Techniczne – związane z tworzeniem produktu projektu, jego możliwościami technicznymi, jakością, efektywnością itp.
• Zarządcze – odnoszące się do wszystkich czynności związanych z procesem zarządzania, a więc planowaniem, monitorowaniem planów, mechanizmami zlecania i rozliczania prac itp.
• Organizacyjne – związane np. z brakiem właściwego finansowania, nieokreślonymi zależnościami pomiędzy projektami w realizujących je organizacjach czy konfliktami wykorzystania zasobów w tych organizacjach
• Zewnętrzne – odnoszące się do zmian w środowisku, w którym działa projekt lub mają być wykorzystywane jego produkty. Najczęściej spotykanym przykładem ryzyka zewnętrznego jest zmiana potrzeb klienta, ale można tu także zaliczyć problemy z zatrudnieniem czy zmianą warunków rynkowych. Ryzyka zewnętrzne trudno poddają się minimalizacji^[11].

W PMBOK ryzyku, jako jednemu z obszarów zarządzania, poświęcone zostało 6 procesów:

1. Planowanie zarządzania ryzykiem – proces definiowania w jaki sposób przeprowadzone będą czynności związane z zarządzaniem ryzykiem w projekcie oraz zapewnienie że poświęcone mu zostaną należyte zasoby i czas. Proces ten pomaga ustalić m.in. jakie metody, narzędzia i techniki zostaną użyte, a także definiuje poszczególne role i związaną z odpowiedzialność.
2. Identyfikowanie ryzyka – proces mający na celu określenie, które ryzyka mają wpływ na projekt a także opisujący ich charakterystykę.
3. Przeprowadzenie jakościowej analizy ryzyka – proces, w którym wyodrębnionym ryzykom nadawane są priorytety ze względu na prawdopodobieństwo i wpływ na projekt oraz wyodrębniane są  te ryzyka, którymi powinno się dalej kontrolować.
4. Przeprowadzenie ilościowej analizy ryzyka – dokonanie analizy numerycznej zidentyfikowanego ryzyka mającego wpływ na cele projektu.
5. Zaplanowanie reakcji na ryzyko –proces mający na celu przygotowanie opcji i konkretnych akcji aby zwiększyć szanse i zredukować zagrożenia celów projektu.

Monitorowanie i kontrola ryzyka to proces wdrożenia przygotowanych uprzednio działań, śledzenie wykonania tych działań oraz kontrola statusu ryzyk projektowych^[12].

Opisując reakcje na ryzyko, w odniesieniu do planowania reakcji na nie, w PMBOK wymieniane są:

1. Dla ryzyka negatywnego (zagrożenia)
   1. Unikanie
   2. Przeniesienie
   3. Zmniejszenie / redukcja szansy wystąpienia ryzyka, bądź jego skutków
   4. Akceptacja  (głównie plany awaryjne jako aktywna technika)
2. Dla ryzyka pozytywnego (szansy)
   1. Wykorzystanie
   2. Współdzielenie
   3. Zwiększanie prawdopodobieństwa wystąpienia / wzmocnienie szansy
   4. Akceptacja

Ryzyko w PRINCE2

W metodyce PRINCE2 ryzyko jest jednym z tematów i definiowane jest jako

(…) niepewne zdarzenie lub zbiór zdarzeń, które w przypadku ich wystąpienia, będą mieć wpływ na osiągnięcie celów. Miarą ryzyka jest iloczyn prawdopodobieństwa wystąpienia dostrzeżonego zagrożenia lub szansy oraz wielkości jego/jej wpływu na cele^[8]

Gdzie zagrożenie jest zdarzeniem niepewnym mogącym mieć niekorzystny wpływ na cele, a szansa oznacza zdarzenie niepewne mogące mieć korzystny wpływ na cele.

Zalecana w metodyce PRINCE2 procedura zarządzania ryzykiem obejmuje pięć kroków:

1. Identyfikuj – identyfikowane są ryzyka mające wpływ na cele projektu, a następnie odnotowywane są w Rejestrze Ryzyka razem z ich właścicielami (Właściciel ryzyka, to osoba odpowiedzialna za zarządzanie, monitorowanie i kontrolowanie wszystkich aspektów przypisanego jej konkretnego ryzyka).
2. Oceniaj –  każde zidentyfikowane ryzyko poddawane jest analizie. Oceniane jest prawdopodobieństwo wystąpienia, wpływ na cele, a także bliskość (czas, w którym ryzyko może się zmaterializować).
3. Planuj – przygotowanie działań zarządczych w reakcji na zidentyfikowane ryzyko, przy czym kluczowym czynnikiem podczas wyboru reakcji będzie bilansowanie kosztów wdrożenia reakcji oraz prawdopodobieństwa i skutków dopuszczenia do wystąpienia ryzyka^[8].
4. Wdrażaj – celem tego kroku jest zapewnienie, aby w razie wystąpienia danego ryzyka, została podjęta odpowiednia reakcja na ryzyko.
5. Komunikuj – krok ciągle realizowany w trakcie życia projektu, mający na celu zapewnienie, aby informacje o zagrożeniach oraz szansach były przekazywane zarówno wewnątrz projektu jak i interesariuszom zewnętrznym. Ryzyko jest komunikowane w ramach produktów zarządczych takich jak Raport z Punktu Kontrolnego, Raport Okresowy, Raport Końcowy Etapu, Raport Końcowy Projektu oraz Raport Doświadczeń zgodnie ze zdefiniowaną uprzednio Strategią Zarządzania Komunikacją.

Planując reakcję na ryzyko według omawianej metodyki, kierownik projektu może zastosować jedną z poniższych technik:

1. Dla ryzyka negatywnego (zagrożenia)
   1. Unikanie
   2. Redukowanie
   3. Plan rezerwowy – przygotowany dla działań mających na celu redukcję skutków zagrożenia, które będą podjęte na wypadek materializacji ryzyka
   4. Przeniesienie
   5. Akceptowanie – świadoma decyzja o braku reakcji (w przypadku, gdy powstrzymanie się od działania na ryzyko jest bardziej ekonomicznie uzasadnione niż jakakolwiek reakcja)
   6. Współdzielenie – podział strat zgodny z podjętymi uprzednio ustaleniami w relacji z dostawcami.
2. Dla ryzyka pozytywnego (szansy)
   1. Współdzielenie – podział zysków zgodny z podjętymi uprzednio ustaleniami w relacji z dostawcami.
   2. Wykorzystanie
   3. Wzmocnienie prawdopodobieństwa wystąpienia lub/i wzmocnienie jego skutków
   4. Odrzucenie – świadoma decyzja o braku reakcji (w przypadku, gdy powstrzymanie się od działania na ryzyko jest bardziej ekonomicznie uzasadnione niż jakakolwiek reakcja)

Identyfikacja czynników ryzyka

Zmiana metodyki zarządzania projektem w przypadku nowych projektów w firmie, a zwłaszcza w przypadku projektów będących w realizacji, jest projektem sama w sobie.

W organizacji, w której przywykło się realizować projekty według konkretnej metodyki, można napotkać opór ze strony kierowników projektów w stosunku do innych metodyk, co jawi się jako pierwsze zagrożenie mogące mieć wpływ na czas realizacji projektu.

Po pokonaniu ewentualnego oporu ze strony kadry zarządzającej, trzeba również pamiętać o stosownych szkoleniach, mających na celu przygotowanie kierowników projektów do korzystania z wprowadzanej w firmie metodyki. Mamy tutaj do czynienia z następnym ryzykiem. Stosownie przygotowane szkolenie może w skutkach długofalowych podnieść efektywność pracy przy realizacji projektu, ale może także ją spowolnić, jeśli kierujący projektami nie posiądą wiedzy w dostatecznym zakresie, bądź niewłaściwie zrozumieją zasady i procedury w obszarze zarządzania kluczowym dla realizacji swojego projektu.

W przypadku projektów będących w fazie realizacji, trzeba zastanowić się, w jaki sposób przeprowadzić zmianę metodyki zarządzania i czy w ogóle jest ona możliwa do wprowadzenia w danej fazie bądź w ogóle. Potrzeba takiej zmiany może być wymogiem ze strony organizacji związanym np. ze zmianą polityki firmy. Trzeba jednak mieć na uwadze, czy taka zmiana rzeczywiście przyczyni się do jakichkolwiek korzyści w danym przypadku. Biorąc pod uwagę poziom wytwórczy danego projektu, należy zapewnić ciągłość wytwarzania produktów danego projektu bez wprowadzania niepotrzebnych zakłóceń związanych np. z wprowadzeniem nowych narzędzi do raportowania wymaganych podczas pracy z nową metodyką, bądź związanych ze zmianą protokołu odbioru produktów cząstkowych czy zmianą ich kryteriów akceptacji.

Ryzyko na przykładzie wybranych obszarów zarządzania projektami

Przyglądając się omówionym wcześniej zagadnieniom, możemy również wskazać potencjalne ryzyko na przykładzie wybranych obszarów zarządzania projektami.

Biorąc pod uwagę samą definicję roli kierownika projektu według PMBOK i PRINCE2, możemy spodziewać się, iż kierownicy projektów mogą być niechętni do zmiany metodyki z PMBOK na PRINCE2 z powodu dużego stopnia dowolności w działaniu, jaki daje im aktualna forma projektu. Zmieniając metodykę na PRINCE2, kierownik projektu musiałby liczyć się z ograniczeniem swojej roli w projekcie, jak również przekazaniu pełnej odpowiedzialności za projekt przewodniczącemu.

Zmiana metodyki niesie ze sobą zmianę przyjętych standardów, procesów i protokołów komunikacji.

Analizując samą ilość dokumentów i ich formę, możemy liczyć się z zagrożeniami związanymi z utratą pewnych informacji w fazie przejścia.

Zwracając uwagę na różnice procesowe pomiędzy danymi metodykami, możemy również spodziewać się pewnych problemów organizacyjnych. Pomijając fakt iż „przyzwyczajenie jest drugą naturą człowieka”,  może dojść do sytuacji, gdy np. pewne ścieżki komunikacji nieformalnej, które spotykały się uprzednio z aprobatą, mogą w nowym stanie rzeczy wprowadzić chaos.

Zarządzanie zmianą w projekcie informatycznym – przykłady

Omówmy dla przykładu poniższy przypadek zarządzania zmianą w projekcie informatycznym.

Dla ułatwienia procesu i oszczędności czasu, ze względu na zaufanie do pracownika i wiarę w jego wiedzę, praktykę i zdolności, w pewnej firmie przyjęło się, iż ma on zezwolenie na wprowadzanie zmian niebędących zmianami kluczowymi w danym systemie komputerowym, budowanym na potrzeby klientów. Klienci są klientami wewnętrznymi firmy. Jeden z nich, poprosił o wprowadzenie zmian w interfejsie graficznym. Biorąc pod uwagę specyfikę danej branży, jest to zmiana potrzebna tylko temu jednemu klientowi, ale system, zgodnie z założeniami, ma tę samą formę dla wszystkich.

Wprowadzona zmiana, mimo iż może zająć niewiele czasu, może przyczynić się do odrzucenia przez użytkowników omawianego systemu ze strony innych klientów.

Powyższa sytuacja jest nie do przyjęcia w metodyce PRINCE2, gdzie wszelkie potrzeby zmiany są odpowiednio notowane i obsługiwane w procedurze Sterowania Zagadnieniami i Zmianami, a sam sposób obsługi zagadnień definiowany jest w Strategii Zarządzania Konfiguracją, która opisuje, między innymi, role i obowiązki związane ze sterowaniem zagadnieniami i zmianami.

Zagrożenia wynikające ze zmiany metodyki z PMI na PRINCE2

Tabela 4 ukazuje zestawienie wybranych ryzyk związanych ze zmianą metodyki zarządzania projektem z PMI na PRINCE2.

Biorąc pod uwagę ilość czynników, które trzeba wziąć pod uwagę podczas wdrożenia nowej metodyki zarządzania projektami w organizacji, dobrym pomysłem zdaje się być stworzenie listy punktów do zweryfikowania podczas wprowadzania omawianej zmiany (Tabela 5).

Dla porównania przyjrzyjmy się również tabeli 6, w której przedstawione zostały przykłady ryzyka związanego ze zmianą metodyki zarządzania z PRINCE2 na PMI.

Zagrożenia wynikające ze zmiany metodyki z PRINCE2 na PMI

Punkt odniesienia

Omówione w powyższych tabelach zagadnienia pokazują, że zmiana metodyki niesie ze sobą duże ryzyko dla zarządzania projektem.

Ciekawe jest zagadnienie manipulowania zakresem i jakością w projekcie. Na podstawie tabel 4 i 6 widzimy, iż mogą być one zagrożeniem i szansą zarówno przy zmianie metodyki z PMI na PRINCE2 jak i z PRINCE2 na PMI.

Jak w większości przypadków związanych z zarządzaniem, wszystko zależy od punktu odniesienia.

Mając na uwadze na przykład kontrakt rządowy na budowę odcinka drogi, który musi być oddany do użytku w terminie przed ważnymi wydarzeniami o znaczeniu światowym, kierownicy projektu mają inaczej ustalone priorytety niż w przypadku opracowywania projektu informatycznego mającego obsługiwać część administracji państwowej.

W pierwszym przypadku, manipulując zakresem w przypadku napotkania problemów (jak ma to miejsce w przypadku PRINCE2) mógłby zostać oddany do użytku krótszy odcinek drogi. Nie spełniłoby to jednak oczekiwań klienta w najmniejszym stopniu, gdyż nie rozwiązano by w ten sposób problemów komunikacji samochodowej. Alternatywnie, można by zmniejszyć zakres dodatkowych prac związanych na przykład z miejscami obsługi podróżnych itp. co pozwoliłoby rozwiązać problemy komunikacyjne, ale wpłynęłoby negatywnie na komfort podróżowania.

Przy takich założeniach, najlogiczniejsze wydaje się manipulowanie jakością. Pozwoliłoby to na oddanie całego odcinka drogi, wraz z całą uzgodnioną infrastrukturą. Trzeba się jednak liczyć z obniżoną wytrzymałością i wyższymi kosztami utrzymania, związanymi z potrzeba szybszych i częstszych remontów w przyszłości.

Podsumowanie

Na podstawie powyższego zestawienia mogę stwierdzić, że rzeczywiście „diabeł tkwi w szczegółach”. Porównując same definicje projektu i roli kierownika projektu, zobrazowane zostały implikacje wynikające z różnic w ich ujęciu według omawianych metodyk.

Zmiana metodyki zarządzania projektem obarczona jest ryzykiem nie tylko w obszarze organizacji projektu, ale także w obszarze zmiany procesów.

Podsumowując, wiedza zawarta w PMBOK nadaje się doskonale do nauki o każdym z obszarów wiedzy, lecz nie jest tak efektywna w bezpośrednim zastosowaniu jako metodyka zarządzania projektem.

PRINCE2 jest gotową metodyką, którą można zastosować do każdego projektu, bez względu na jego dziedzinę. Nie jest jednak tak obszerny w odniesieniu do technik, które można zastosować w każdym z obszarów projektu.Obie metodyki zdają się uzupełniać nawzajem

Bibliografia i źródła

[1] Project Management Body of Knowledge

[2] PRINCE2^TM – Skuteczne Zarządzanie Projektami; drugie wydanie polskie Crown Copywright 2010

[3] A Guide to the Project Management Body Of Knowledge – fourth edition, str. 13; tłumaczenie autora

[4] PRINCE2 – Process Model [ILX , 2009, PL].pdf – http://miroslawdabrowski.com/downloads/PRINCE2/Reference%20cards/

[5] Comparing PRINCE2 with PMBOK; R. Max. Wideman; AEW Services, Vancouver, BC, Canada, 2002; str. 4; tłumaczenie autora

[6] PRINCE2^TM – Skuteczne Zarządzanie Projektami; drugie wydanie polskie Crown Copywright 2010; str 40

[7] Product Breakdown Structure – ang. Podział ze względu na produkty

[8] Work Breakdown Structure – ang. Podział prac ze względu na zadania

[9] Źródło: 4.bp.blogspot.com

[10] Źródło: 2.bp.blogspot.com

[11] Źródło: sybena.pl

[12] Zarządzanie ryzykiem w małych projektach, Mirosław Prywata