Mity metodyki PRINCE2
Michał Orman - 1 maja 2010
Po skończonym kursie Zarządzanie projektami metodyką PRINCE2 i niejako w ramach przygotowania do egzaminu PRINCE2 Foundation (a w dalszej perspektywie PRINCE2 Practitioner) wdałem się ostatnio w kilka dyskusji na temat tej metodyki. Jedną z nich można prześledzić w komentarzach do mojego poprzedniego wpisu opisującego podstawowe koncepcje metodyki PRINCE2.
Zauważyłem, że wokół PRINCE2 narosło sporo mitów. Wynikają one głównie z małej znajomości tej metodyki i nie do końca precyzyjnych informacji ją opisujących, jakie można znaleźć w sieci. Powoduje to, że ludziom wydaje się, że jest to metodyka nadmiernie zbiurokratyzowana, którą można stosować jedynie w wielkich korporacjach i projektach produkujących stosy dokumentów, których i tak nikt nie czyta. Niniejszym wpisem postanowiłem nieco rozświetlić mroki tej metodyki, tak aby przedstawić ją z bardziej przyjaznej perspektywy.
Mity metodyki PRINCE2
Mity powstają na temat każdej metodologi, frameworka, technologii czy platformy. Zwykle służą one jako usprawiedliwienie do nie wprowadzania czegoś nowego i pozostawania tam gdzie się jest (a z moich obserwacji wynika, że pozostawanie tam gdzie się jest często równoważne jest nie robieniu niczego). Ludzka natura zakodowała w nas wrodzoną obawę przed wprowadzaniem zmian, zatem nie dziwi taki stan rzeczy.
PRINCE2 nie jest tutaj żadnym odstępstwem od reguły. Wokół tej metodyki również narosło kilka mitów, które za chwilę postaram się obalić.
1. PRINCE2 jest nadmierne zbiurokratyzowanie
Mit ten jest najczęstszym poglądem na temat metodyki PRINCE2. Muszę przyznać, że przed tym jak ją poznałem, również postrzegałem tą metodykę jako nadmiernie zbiurokratyzowaną. Faktem jest, że metodyka ta wprowadza wiele procesów, różnych rodzajów dokumentów (wniosków, rejestrów, raportów, dzienników etc.). Jednakże to, że w tej metodyce występuje tak wiele artefaktów, nie oznacza, że jest ona zbiurokratyzowana. Poziom biurokratyzacji determinuje projekt (a dokładnie poziom formalizmu jaki jest w projekcie wymagany).
Kluczowa tutaj okazuje się być jedna z podstawowych zasad metodyki PRINCE2 (tzw. pryncypium):
Dostosowanie do warunków projektu.
W dużych projektach, realizowanych dla administracji publicznej albo z dofinansowaniem UE będziemy potrzebować dużego poziomu formalizmu, w przypadku mniejszych już nie. Może być tak, że raport (np. Raport Końcowy Etapu) wymagany w jednym projekcie w formie dokumentu może być w innym zrealizowany w formie maila lub nawet słownie. Wszystko zależy od konkretnych wymagań projektu. Wniosek z tego jest taki, że to nie PRINCE2 determinuje poziom biurokracji, a konkretne wymagania projektowe. To co PRINCE2 nakazuje to zdefiniowanie podczas Inicjowania Projektu w jakiej formie należy przygotować dany dokument, tak aby Kierownik Projektu albo Kierownicy Zespołów wiedzieli jak mają go utworzyć i nie musieli się ciągle dopytywać.
2. PRINCE2 opisuje szczegółowe techniki i aspekty specjalistyczne
To jest mit na który ja się złapałem. Idąc na szkolenie miałem nadzieję poznać konkretne podejścia do różnych aspektów zarządzania projektami informatycznymi (takich jak szacowanie nakładu pracy). Okazało się, że nie dość, że takich „konkretów” nie było to i same projekty nie dotyczyły projektów informatycznych.
PRINCE2 to metodyka ogólna i nie dostarcza ona konkretnych rozwiązań mówiących jak należy zarządzać budżetem, ryzykiem czy w jaki sposób dostarczać produkty projektu. Metodykę tą trzeba połączyć z konkretnymi rozwiązaniami dotyczącymi realizacji poszczególnych aspektów. Czy to jest źle? W moim przekonaniu nie.
Ogólność tej metodyki objawia się nie tylko tym, że można ją stosować do różnych typów projektów. Ogólność polega także na tym, że można integrować tę metodykę z konkretnymi aspektami zarządzania projektem, które posiada już organizacja. Realizujecie projekty za pomocą Scruma? Proszę bardzo, róbcie to dalej a ponad tym możecie nadbudować solidną organizację jaką można utworzyć wdrażając metodykę PRINCE2.
Generalnie idea jest taka, że PRINCE2 bierze pod uwagę, że organizacja może posiadać już pewną politykę dotyczącą tego jak na przykład zarządzać jakością w projektach (być może jest ona już związana z jakimiś wymaganiami np. ISO). Może też się zdarzyć sytuacja, że konkretny projekt będzie miał jakieś specyficzne wymagania, narzucone np. przez klienta. PRINCE2 nie każe tego wszystkiego zmieniać czy duplikować. Metodyka ta sugeruje, aby wykorzystać już istniejące w organizacji procedury i zintegrować je z metodyką. Wystarczy po prostu zidentyfikować konkretne artefakty (procesy, dokumenty) metodyk już wdrożonych w organizacji jako artefakty PRINCE2.
Metodyka PRINCE2 nie mówi jak należy zarządzać jakością czy ryzykiem (chociażby dlatego, że każdy będzie miał swoją opinię i best practices w tym jak to robić). Metodyka ta mówi jedynie, że należy to robić, ponieważ skutecznie prowadzi to do sukcesu projektu. Należy tutaj uważać, ponieważ dostosowanie do warunków projektu nie upoważnia nas do zrezygnowania z realizacji któregoś z aspektów zalecanych przez PRINCE2 (np. zarządzania jakością). Pominięcie jednego jest równoważne z nie używaniem metodyki PRINCE2 i nie można mieć potem do niej pretensji o niepowodzenie projektu. Z drugiej strony niezbyt roztropne jest nie posiadanie w organizacji polityki zarządzania jakością.
3. PRINCE2 nadaje się tylko do dużych projektów
W opinii wielu osób PRINCE2 to metodyka nadająca się jedynie do zarządzania dużymi projektami. Opinia ta w dużej części wynika z błędnego postrzegania tej metodyki jako zbiurokratyzowanej i formalnej (co opisywałem powyżej). Prawda jest taka, że metodyka ta jest na tyle ogólna, że nadaje się do prowadzenia każdej wielkości projektu. Kluczem jest odpowiednia organizacja (co w kontekście PRINCE2 oznacza podział ról i obowiązków).
W skrajnym przypadku do zarządzania projektem w PRINCE2 możemy oddelegować 2 osoby. Pierwsza z nich Przewodniczący zajmowałaby się Zarządzaniem Strategicznym, druga, czyli Kierownik Projektu, bieżącymi sprawami projektowymi (tzw. Zarządzaniem Operacyjnym). No i potrzebny jest oczywiście Zespół, który będzie realizował zadania. Kierownik Projektu pełniłby w takiej organizacji jednocześnie rolę Kierownika Zespołu, a także mógłby realizować typowe zadania projektowe (poza zadaniami zarządczymi z racji pełnienia roli Kierownika Projektu).
Jak widać nawet do bardzo małych projektów da się dostosować organizację PRINCE2. Trzeba jednak się zastanowić, czy taki podział ról i obowiązków zapewni projektowi odpowiednią decyzyjność i skuteczność. Być może ilość obowiązków nałożona na Kierownika Projektu jest zbyt duża. PRINCE2 sugeruje, aby po każdym etapie dokonać przeglądu organizacji projektu celem przeanalizowania, czy taka struktura organizacji nadal pozwala na odpowiednie zarządzanie projektem. Metodyka ta w niemal każdym aspekcie nakazuje przegląd procedur i upewnienie się, że są one nadal skuteczne a w razie potrzeby odpowiednie ich zmodyfikowanie. W tym kontekście PRINCE2 adaptuje się do warunków projektu wraz z czasem, w miarę jak coraz lepiej poznajemy specyfikę projektu.
4. W PRINCE2 zespołowi narzuca się harmonogram
Ten punkt odniosę konkretnie do specyfiki projektów informatycznych. Wśród programistów można zauważyć pewną cechę. Jeżeli metodykę zarządzania projektem nie nazwiemy „lekką”, albo „agile’ową” to od razu wyobrażają sobie oni sytuację, w której analityk z 15 letnim doświadczeniem pisania w Cobolu i 150 udanymi integracjami CORBY siada i nakreśla zakres i czas realizacji systemu informatycznego w Rails’ach rodem z Web 2.0. Programiści następnie zmuszani są do wykonania jego pobożnych życzeń i męczenia się z implementowaniem wszystkich bloków i strzałek jakie analityk nakreślił w projekcie aplikacji.
PRINCE2 doskonale zdaje sobie sprawę z tego, że co innego jest dorysować blok i strzałkę w projekcie, a co innego jest to zaimplementować. Metodyka ta nakazuje reprezentowanie interesów wszystkich najważniejszych interesantów projektu, czyli biznesu (tych co wydają swoje pieniądze na projekt), użytkowników (tych którzy korzystają w jakikolwiek sposób z produktów projektu), oraz dostawców (w tym dostawców oprogramowania, czyli de facto Zespołów realizujących zadania). Interesy te reprezentowane są już na najwyższych szczeblach organizacji projektu, czyli w Komitecie Sterującym, który zajmuje się Zarządzaniem Strategicznym w projekcie. Oczywiście nie panuje tam demokracja, ponieważ tylko biznes wykłada swoje pieniądze na projekt, więc ma prawo mieć decydujące zdanie we wszystkich kwestiach, ale taka organizacja gwarantuje, że interesy wszystkich członków zespołu projektowego są brane pod uwagę już od samego początku realizacji projektu.
Dodatkowo PRINCE2 zaleca planowanie na wielu poziomach. Najpierw tworzy się ogólny Plan Projektu, który definiuje podstawowe wymagania co do Produktu Końcowego Projektu. Dalej tworzony jest Plan Etapu dla kolejnego etapu, a następnie każdy Zespół ma prawo stworzenia własnego Planu Zespołu.
Taka wielopoziomowość planowania ma wiele sensu. Faktem jest, że im planujemy na krótszy okres tym nasz plan jest bardziej wiarygodny. Specjalnie z tego powodu PRINCE2 wprowadza termin Horyzontu Planowania. Horyzont ten określa okres na jaki należy utworzyć plan aby był on wiarygodny. Im plan jest niższego poziomu tym jego Horyzont jest krótszy, a tym samym plan jest bardziej wiarygodny. Wynika z tego, że najbardziej wiarygodnym planem jest Plan Zespołu, stąd też PRINCE2 wprowadza zasadę, iż plan niższego poziomu może podważyć plan wyższego poziomu. Metodyka ta deklaruje odpowiednie procedury jakie trzeba podjąć w takim przypadku, ale nie są one tutaj istotne. Istotne jest to, że nawet jeżeli Zespołowi zostanie narzucony wyssany z palca i mało wiarygodny plan, ma on możliwość opracowania planu, który podważy ten narzucony. Oczywiście Przewodniczący Komitetu Sterującego może ostatecznie narzucić plan Zespołowi (na swoją odpowiedzialność). Służy to temu, aby Zespół nie podważał w nieskończoność planów, w których ustalaniu nawiasem mówiąc brał udział. Można też rozwiązać Zespół i powołać nowy, więc jak widać wyjść z takiego impasu jest dużo, ponieważ główną cechą PRINCE2 jest zapewnienie decyzyjności w projekcie.
5. PRINCE2 definiuje mnóstwo nowych bytów i artefaktów
Generalnie jak ludzie patrzą na diagramy przedstawiające różne procesy metodyki PRINCE2 odnoszą wrażenie, że jest to wielki wór do którego wrzucono pełno dziwnych rzeczy i wymyślono do tego jakąś ideologię. Prawda jest taka, że PRINCE2 nie wymyśla niczego nowego, a ludzie odnoszący takie wrażenie po prostu nie byli świadomi tego co wchodzi w skład zarządzania projektem (wbrew pozorom skutecznego zarządzania projektem nie można nauczyć się tylko na bazie doświadczeń stricte programistycznych, ale to temat na inną dyskusję).
PRINCE2 nie tworzy nowych bytów. Metodyka ta po prostu pokazuje jak zebrać i zorganizować to z czego wszyscy już korzystamy (a przynajmniej powinniśmy) w swoich projektach. PRINCE2 mówi o potrzebie dostarczania produktów. Czy realizujecie projekt, którego celem nie jest dostarczenie produktu (usługi etc.)? PRINCE2 mówi o potrzebie zarządzania budżetem, jakością czy ryzykiem. Czy realizujecie projekty w których nie zarządza się tymi aspektami? Jeżeli wasza odpowiedź brzmi tak, to albo nie jesteście świadomi tego co w waszym projekcie się dzieje, albo wasz projekt jest na dobrej drodze do porażki. Oczywiście nie zarządzania którymkolwiek z aspektów PRINCE2 nie jest warunkiem koniecznym niepowodzenia projektu, ale projekt taki jest na dobrej drodze do spektakularnej klapy.
Podsumowując PRINCE2 nie wymyśla koła od nowa. Metodyka ta po prostu pozbierała dobre praktyki związane z zarządzaniem projektami (z jakichś 30 lat) i pokazuje jak to wszystko skutecznie zorganizować. Nie ma tutaj rzeczy, o których nie będzie mowy na pierwszym lepszym szkoleniu na temat zarządzania projektem. Inaczej może to być tylko nazwane i zorganizowane.
6. Aby korzystać z PRINCE2 trzeba przyswoić dużo wiedzy
Faktem jest, że aby wdrożyć metodykę PRINCE2 w organizacji potrzeba zapoznać się z sporą ilością wiedzy. Jednakże, nie jest prawdą, że trzeba tę wiedzę posiadać, aby móc być członkiem zespołu projektu realizowanego z wykorzystaniem tej metodyki.
W PRINCE2 należy dokonać, już na samym początku projektu, odpowiedniego rozdziału ról i obowiązków. Podział ten winien zostać udokumentowany w taki sposób aby każdy członek zespołu projektowego wiedział jakie są jego obowiązki oraz uprawnienia. W tym kontekście nie potrzebuje on żadnej wiedzy na temat PRINCE2, ponieważ wszystko czego potrzebuje ma zdefiniowane w odpowiednim dokumencie. Oczywiście takiego dokumentu nie trzeba tworzyć z każdym nowym projektem, można stworzyć taki jeden dla całej organizacji i odpowiednio zaadaptować go do specyfiki konkretnego projektu.
To, że generalnie wiedza na temat PRINCE2 nie jest wymagana, aby na przykład być Kierownikiem Zespołu, nie zaprzecza temu, że lepiej takową wiedzę posiadać. PRINCE2 zaleca przeprowadzenie stosownych szkoleń dla poszczególnych ról, tłumaczących im stosowną terminologię oraz podstawowe koncepcje i zasady. Oczywiście takie szkolenie powinno być dostosowane do wymagań piastowanej roli, tak aby Kierownik Projektu nie musiał zapoznawać się z teorią na temat bycia Przewodniczącym w projekcie. Generalnie wystarczy, że w organizacji jest klika osób bardzo dobrze zaznajomionych z PRINCE2 i będą oni w stanie odpowiednio wdrożyć pozostałych pracowników w kwestiach bezpośrednio z nimi związanych, a nie całą teorią PRINCE2.
Podsumowanie
Mam nadzieję, że tym wpisem udało mi się rozwiać chociaż część mitów dotyczących metodyki PRINCE2. Mam też nadzieję, że udało mi się przedstawić tę metodykę jako bardziej przyjazną i przede wszystkim rozsądną. Metodyka ta nie została wymyślona jako twór narzucający sto tysięcy procedur i dokumentów. Metodyka ta została pomyślana jako zbiór ogólnych zasad dających się łatwo wdrożyć i zintegrować z już istniejącymi procedurami w organizacji. W tym względzie jest to metodyka bardzo uniwersalna.
PRINCE2 w bardzo dużym stopniu opiera się na korzystaniu z doświadczeń. Już sama metodyka nie tworzy nowej teorii, ale wykorzystuje to co przez ostatnie 30 lat wymyślono. Na każdym kroku sugeruje też, aby spisywać doświadczenia i wykorzystywać to co już zostało kiedyś zrobione, tak aby po raz 50 nie tworzyć szablonu tego samego dokumentu z tym samym opisem. Jest to metodyka bardzo praktyczna i oszczędnościowa jeżeli chodzi o pracę. Jej generalna idea brzmi:
Rób tak mało jak to jest tylko konieczne, ale nie mniej!
Warto się do niej stosować.
http://michalorman.pl/blog/2010/05/mity-metodyki-prince2/
Michał Orman
Full stack software developer, konsultant IT.
Niekwestionowany full stack developer, architekt rozwiązań IT, project manager, entuzjasta Agile z biznesowym zacięciem, który lubi robić rzeczy do końca. Prawdziwy człowiek orkiestra, którego największymi zaletami są nieustanne dążenie do perfekcji, produktywność, dbanie o najwyższą jakość wyprodukowanego oprogramowania. Obecnie programuje w Ruby on Rails i JavaScript, ale do listy znanych mu technologii bez wątpienia można dopisać Java/J2EE. Tworzył aplikacje mobilne na platformę Android, systemy wbudowane w C/C++. Zapalony wyznawca zasad SOLID lubiący proste rozwiązania oraz czysty kod. Do swojego portfolio technologicznego również może dodać Unix/Linux, VIM oraz Git.
michalorman.com
Comments