Pryncypia zarządzania projektami w ujęciu metodyki PRINCE2.

Transkrypt

1 Pryncypia zarządzania projektami w ujęciu metodyki PRINCE2. Metodyka PRINCE2, która jest niczym innym jak tylko zbiorem najlepszych praktyk w zarządzaniu projektami, zbiorem ujętym w system spójnych, wewnętrznie niesprzecznych procesów i zasad, ma u swojego podłoża zbiór siedmiu pryncypiów. Mają one charakter uniwersalny, to znaczy nie zależą od rodzaju projektu i środowiska, w którym projekt jest realizowany, na przestrzeni wielu lat sprawdziły się w praktyce i dają zespołom projektowym poczucie pewności i zaufania do podejmowanych decyzji. Opis metodyki PRINCE2 zawiera stwierdzenie, że projekt, który narusza pryncypia nie jest na pewno zgodny z metodyką PRINCE2, ponieważ to właśnie rzeczone pryncypia stanowią fundament metodyki. Czym są zatem te pryncypia? Projekt powinien mieć zawsze aktualne uzasadnienie, dla którego jest realizowany To mądra życiowo zasad mówiąca, że byd może na początku wszystko miało sens i wyglądało wspaniale, ale w trakcie, kiedy zmieniły się okoliczności, potrzeby, oczekiwania Wiedz po co coś robisz, nie tylko zanim zaczniesz to coś robid, ale i w trakcie, jak robił będziesz. i warunki, niekoniecznie nasze przedsięwzięcie powinno byd dalej ciągnięte. Byd może lepiej jest je przerwad i nie ponosid bezsensownych kosztów. W metodyce PRINCE2 zasada ta jest realizowana poprzez zastosowanie pojęcia Uzasadnienia Biznesowego. Uzasadnienie Biznesowe jest bowiem w swoim założeniu szczerą i dokładną odpowiedzią na pytanie: po co to wszystko robimy, co z tego będziemy mieli, jakie będą korzyści vis a vis koszty? Przymiotnik biznesowe sugeruje wprawdzie, że mowa jest o pieniądzach, ale w istocie mowa jest o wszystkich korzyściach i kosztach. Jakich? Ano społecznych, kulturowych, politycznych i wszystkich innych z jakimi mamy do czynienia w konkretnej sytuacji. W szczególności koszty związane z realizacją projektu (jego budżet) są tylko jedną z wielu pozycji po stronie kosztów w Uzasadnieniu Biznesowym. Ale Uzasadnienie Biznesowe to nie tylko koszty vs korzyści. To również Ryzyko! Byd może nasz pomysł jest niesłychanie atrakcyjny ale zważywszy Cezary Paprocki CRM SA 2010 Strona 1 z 9 PRINCE2 Jest zarejestrowanym znakiem handlowym Office of Government Commerce w Zjednoczonym Królestwie i innych krajach. Swirl logo Jest znakiem handlowym Office of Government Commerce.

2 zagrożenia z nim związane to może lepiej nie? Inną istotną cechą podejścia stosowanego w metodyce PRINCE2 jest to, że Uzasadnienie Biznesowe nie jest prawdą objawioną tylko prognozą. Oczywiście staramy się aby nasze prognozy były jak najlepsze i wiarygodne, ale na przykład przyszłe koszty eksploatacji produktów projektu i przyszłe korzyści, z natury rzeczy są tylko prognozą właśnie. No a skoro to prognoza to w miarę rozwoju sytuacji i w miarę tego jak pozyskujemy nowe informacje nasza prognoza powinna byd aktualizowana. I taka właśnie jest metodyka PRINCE2, która mówi, że Uzasadnienie Biznesowe powinno byd stale, w cyklu życia projektu, aktualizowane i powinno na bieżąco odzwierciedlad jego stan faktyczny. Korzyśd z takiego podejścia jest i taka, że na koniec projektu Uzasadnienie Biznesowe jest całkiem niezłym obrazem faktycznych rezultatów projektu. Całkiem niezłym, bo przecież przyszłe koszy i korzyści (te po zakooczeniu projektu) są dalej prognozą, wprawdzie już niezłą, bo horyzont planistyczny krótszy, ale dalej tylko prognozą. No to kiedy wiadomo na pewno czy to był sukces czy porażka? Odpowiedź w weryfikacji zrealizowanych korzyści, we wskazanym konkretnie czasie, po zakooczeniu projektu. Zaraz po zakooczeniu, miesiąc po zakooczeniu, kilka lat po zakooczeniu. Wszystko zależy od natury projektu. Metodyka PRINCE2 adresuje to zagadnienie w ten sposób, że nakłada na zespół projektowy obowiązek przygotowania odpowiedzi na pytanie, jak, kto i kiedy takiego przeglądu dokona i kogo rezultatach poinformuje. W metodyce PRINCE2 nazywa się to Plan Przeglądu Korzyści. Role i związana z nimi odpowiedzialność są zdefiniowane Wyobraźmy sobie, że każda rola oraz związane z nią obowiązki i uprawnienia to taki zestaw sznurków, za które może pociągad osoba pełniąca daną rolę i jeżeli za któryś z tych sznurków pociągnie, to coś się w projekcie stanie (decyzja, Każdy Kierownik projektu ma trzech naturalnych wrogów: zespół projektowy, klienta i zarząd. Szczęśliwie, tylko z tym ostatnim musi się liczyd. raport, etc.). Sztuka polega na tym, aby tak rozdzielid między role wszystkie sznurki, żeby z jednej strony nie było sznurków bezpaoskich, bo inaczej to mamy problemy niczyje typu: Stary to co z tym robimy. A ja nie wiem to nie moja sprawa. W rezultacie chodzimy od Annasza do Kajfasza, a sprawa nie załatwiona, bo przecież niczyja. Z drugiej strony należy zadbad, aby nie było sznurków wspólnych, bo inaczej mamy spory kompetencyjne typu: Stary co się wtrącasz w nie swoje sprawy? Dobrze by też by było, aby sznurki od danej roli nie biegły do tej roli właśnie (pętla), bo wtedy zaczynamy byd sędzią we własnej sprawie, co stanowi poważne zagrożenie dla projektu. Bo przecież wobec kogo będziemy tak wyrozumiali, jak wobec siebie? No to jak to wszystko poukładad? Metodyka RINCE2 definiuje podstawowy zestaw ról w projekcie wraz ze standardowymi zakresami obowiązków i uprawnieo oraz ze strukturą, w której będą występowały. Należy pamiętad, że zespół projektowy nie jest dany raz na zawsze. W miarę rozwoju sytuacji, wyzwao przed którymi będzie stawał projekt i jego zespół, zmian oczekiwao i otoczenia, struktura zespołu powinna byd tak modyfikowana, aby w Cezary Paprocki CRM SA 2010 Strona 2 z 9

3 każdym momencie, jak najlepiej adresowad potrzeby zarządcze projektu. W PRINCE2 weryfikacja zespołu musi byd przeprowadzona przynajmniej na koniec każdego etapu zarządczego, co wcale nie wyklucza zmian w trakcie. Byle mądrze i adekwatnie. Inną ciekawą cechą metodyki jest to, że nie definiuje się ról, których nazwa zaczyna się od Zastępca. Powie ktoś: A jak kierownik zachoruje, pojedzie na urlop to wtedy co?. To proste. W sytuacji, w której Kierownik Projektu nie jest w stanie z jakichkolwiek powodów pełnid swoich obowiązków, Komitet Sterujący mianuje nowego Kierownika Projektu. No ale przecież on nie wie o co chodzi Po pierwsze Komitet Sterujący nie jest zazwyczaj tak głupi, żeby mianowad kogoś spoza otoczenia dotychczasowego Kierownika, a po drugie, przecież projekt jest porządnie opisany a wszystkie informacje gromadzone na bieżąco i aktualne, co oznacza, że nowy przeczyta, ewentualnie kogoś zapyta i już wie. Notabene, w dobrze poukładanym świecie Kierownik Projektu to nie stanowisko, tylko czasowa rola, a to oznacza, że na urlop się idzie jak się projekt skooczy. Inną ciekawą cechą metodyki PRINCE2 jest to, że struktura zarządcza projektu jest całkowicie niedemokratyczna. Jednoosobowe odpowiedzialności, pionowy schemat, żadnej demokracji. No dobrze, ale przecież mamy KOMITET Sterujący! To prawda, ale Komitet Sterujący podejmuje decyzje poprzez wypracowanie konsensusu, a w przypadku gdy nie jest to możliwe, decyzje podejmuje jednoosobowo Przewodniczący, Capo di tutti Capi, właściciel Uzasadnienia Biznesowego, człowiek odpowiedzialny osobiście za sukces projektu. A tak na marginesie to w komentarzach do metodyki PRINCE2 można wyczytad i takie oto stwierdzenie cyt. Istotnie Komitet Sterujący podejmuje decyzje poprzez wynegocjowanie konsensusu, a nie poprzez głosowanie, tym nie mniej zaleca się aby liczba członków Komitetu Sterującego była nieparzysta. No i gadaj z takimi. Wykorzystuj doświadczenia Projekty dotyczą różnych branż, różnią się skalą, ryzykiem, są realizowane w różnych środowiskach, mają różnych interesariuszy. Okazuje się jednak, Nie za to ojciec lał syna, że ten grał w karty, tylko za to, że się chciał odegrad. że wiele doświadczeo pozyskanych w jednym projekcie przydaje się jak obszył w innym. Czy aby na pewno? No bo co na przykład łączy projekt budowy mostu z projektem wdrożenia systemu informatycznego? No chodby to, że w każdym z tych projektów jeżeli poddamy Kierownika Projektu presji czasu, to pierwsze co najprawdopodobniej poświęci, to jakośd. Nie do kooca zachowane reżimy technologiczne, odbiory techniczne wcale albo po łebkach, brak audytów, sprawdzeo krzyżowych no bo przecież nie ma czasu! Doświadczenie znane setkom i tysiącom Cezary Paprocki CRM SA 2010 Strona 3 z 9

4 kierowników projektów, jednak jakimś dziwnym trafem rzadko obecne w portfelu decydentów. Doświadczenia należy zbierad, doświadczeniami należy się dzielid. Łatwo powiedzied, trudniej zrobid. Jest w nas jakaś niechęd do dzielenia się doświadczeniami. To co zdobyliśmy w wielkim nieraz trudzie, opłacając potknięciami, nietrafionymi decyzjami i wstydem, składa się na naszą przewagę konkurencyjną. Jest niesłychanie cennym zasobem, którym nie chcemy się dzielid, bo niby dlaczego? Niech i inni doświadczą trudów nauki. Trudno jest dyskutowad, czy taka postawa jest słuszna, czy nie w wymiarze jednostki, jednak w wymiarze organizacji jest to zagrożenie wręcz śmiertelne, bo powtarzane błędy są kosztem, którego można by przecież uniknąd! Metodyka PRINCE2 adresuje ten problem jasno i wyraźnie. Zanim się weźmiesz za projekt popatrz na doświadczenia innych, co coś takiego robili. Może im cos nieźle wyszło, a co my też moglibyśmy zrobid i co takiego zrobili, że coś się nie udało, czego i my za wszelką cenę powinniśmy unikad. I dalej, jak kooczysz jakiś etap projektu lub cały projekt, to podsumuj czego się nauczyłeś i podziel się tym z innymi oraz rozejrzyj się za nowymi doświadczeniami bo może jakieś się właśnie pojawiły. W sensie formalnym powstają Raporty Doświadczeo W ten sposób rodzą się bazy doświadczeo, wspólny obszar wiedzy zdobytej przez zespoły. Rośnie potencjał organizacji do podejmowania coraz śmielszych i ambitnych wyzwao. Skup się na produktach Wszyscy wiemy, że zanim zaczniemy, musi byd wiadomo co ma Nie będziesz w projekcie byd zrobione i jak to powinno wykonywał czynności, które wyglądad. Ale uwaga! wytwarzaniu produktów nie służą. Sformułowanie co ma byd zrobione oznacza co ma powstad, a nie jakie działania należy podjąd. Często spotyka się sformułowania: Celem naszego projektu jest. Tym czasem projekty nie realizują celów. Projekty wytwarzają produkty. Te produkty mogą byd materialne lub niematerialne (np. zmiana postawy określonej grupy ludzi) ale zawsze są to produkty. Ktoś te produkty weźmie, zacznie je eksploatowad i w jakiś czas po zakooczeniu projektu zrealizuje założone cele. A jak to jest w metodyce PRINCE2? Po pierwsze produkty muszą byd takie aby dało się zrealizowad to co jest zapisane w Uzasadnieniu Biznesowym projektu. Po drugie produkty muszą byd tak określone aby: było wiadomo co to jest (opis), znane były kryteria odbioru (jakie mają byd żeby można było z czystym sumieniem podpisad fakturę), jak przeprowadzimy odbiór (ten techniczny bo parzcież inaczej odbiera się most a inaczej moduł oprogramowania), wreszcie jakie zasoby będą potrzebne do przeprowadzenia odbioru (ludzie o określonych kwalifikacjach, wyposażenie, infrastruktura etc.). Koniecznie należy zwrócid uwagę na to, że metodyka PRINCE2 jest tworem Cezary Paprocki CRM SA 2010 Strona 4 z 9

5 spójnym i dobrze poukładanym, a w związku z tym jest w niej wiele elementów adresujących poszczególne pryncypia zarządzania projektami. Jak to wygląda w przypadku produktów projektu? Produkty specyfikuje Główny Użytkownik. No oczywiście nie sam. Stoi za nim cały zespół ekspertów, który przygotowuje odpowiednie dokumenty, ale to Główny Użytkownik firmuje je własnym nazwiskiem. Produkty muszą byd tak pomyślane, aby wszyscy, a w szczególności Przewodniczący Komitetu Sterującego, byli przekonani, że pozwolą na osiągnięcie korzyści zapisanych w Uzasadnieniu Biznesowym. Główny Dostawca zaś powinien byd przekonany, że potrafi zorganizowad odpowiednie zasoby, które pozwolą rzeczone produkty wytworzyd i to z kosztem jak przewidziano w Uzasadnieniu Biznesowym. Jeżeli okaże się, że coś w takiej układance nie pasuje to należy ją ułożyd od nowa. Kiedy produkty już powstaną to Główny Użytkownik rozpocznie ich eksploatację i w rezultacie zrealizuje korzyści oczekiwane przez Przewodniczącego, co przybliży całą organizację do osiągnięcia założonych celów strategicznych. A co jeśli spuścimy z oka produkty. Ano jak zwykle. Niekooczące się dyskusje i spory przy odbiorach, kolejne podejścia do sprawy, niekontrolowane zmiany, zakres projektu zmienia się w meandrującą rzekę, pojawia się ogólne niezadowolenie. A więc? Parafrazując jedną ze znanych wypowiedzi Prezydenta Clintona, chciało by się powiedzied: Przede wszystkim produkty głupcze! 1 Zarządzaj z wykorzystaniem etapów Zespół: Przygotowaliśmy bardzo dobry, szczegółowy, dwuletni plan. Szef: Tak? A możecie mi pożyczyd waszej kryształowej kuli? No właśnie. Jaką wartośd ma w projekcie długoterminowe planowanie, planowanie na wysokim poziomie szczegółowości, skoro jedyne co w projekcie pewne to zmiany? Nikt oczywiście nie próbuje w ten sposób negowad przydatności planowania. W każdej z kilkuset książek o zarządzaniu projektami można znaleźd co najmniej kilka argumentów na to, że plan musi byd. Ale. Nie bierz Jasiu wszystkiego do buzi na raz, bo się udławisz. Należy mądrze rozstrzygnąd jak daleko i w jakich szczegółach taki plan ma jeszcze sens. Zdrowy rozsądek podpowiada, że może udałoby się podzielid całe przedsięwzięcie na jakieś mniejsze, łatwiej strawne fragmenty i widząc całośd, planowad szczegóły z etapu na etap. I tu dochodzimy do metodyki PRINCE2, która wprowadza pojęcie etapów zarządczych. Formalnie rzecz biorąc, etap zarządczy to pewien zamknięty zbiór działao w projekcie, poprzedzony i zamknięty decyzją strategiczną. 1 W oryginale było: "It's the economy, stupid". Hasło wymyślił doradca Prezydenta Bill a Clintona James Carville na potrzeby walki wyborczej z George m H. W. Bush em. Cezary Paprocki CRM SA 2010 Strona 5 z 9

6 Mówiąc prościej należy zastanowid się czy nie dałoby się całego projektu podzielid na takie etapy, żeby po wykonaniu jednego, można było się spokojnie na chwilę zatrzymad, ocenid sytuację i podjąd decyzję strategiczną: kontynuowad lub przerwad przedsięwzięcie. Przy czym decyzja o nie kontynuowaniu oznacza, że to co do tej pory zrobiliśmy dalej ma sens i będzie wykorzystane. Jest to tak zwany logiczny podział na etapy zarządcze. Na przykład byłoby bardzo niemądrze gdybyśmy podzielili projekt tak, że w pierwszym etapie zarządczym zrobimy dajmy na to filary mostu i to z tym założeniem, że potem zastanowimy się czy warto kontynuowad projekt i ewentualnie dorobid jezdnię. To oczywisty nonsens. Oprócz takiego logicznego podziału stosuje się również podziały wynikające z realności horyzontów planistycznych lub z obecności jakiegoś istotnego ryzyka, które gdyby się zmaterializowało będzie implikowało radykalne zmiany w projekcie. Metodyka PRINCE2 wymaga aby w projekcie były przynajmniej dwa etapy zarządcze. Pierwszy to przygotuj (zaplanuj) całe przedsięwzięcie a drugi to wykonaj. Oczywiście to wykonaj może byd dzielone dalej na etapy zarządcze zgodnie z zasadami pokazanymi wyżej. A zalety takiego podejścia? Nie angażujemy wszystkich środków na raz. Plany są bardziej wiarygodne, łatwiej je realizowad i kontrolowad. Ryzyko projektu jest utrzymywane na akceptowalnym poziomie. Planowanie kolejnego etapu jest przeprowadzane w oparciu o doświadczenia poprzedniego, a więc dokładniejsze i lepiej osadzone w realiach. Decydenci mają ułatwianą kontrolę i sterowanie projektem. Mają takie momenty, w których mogą się rozejrzed i podjąd dobrze przemyślaną decyzję Zarządzaj odchyleniami Szefie, to co z tym robimy?, Szefie, jest taki problem., Szefie, czy szef może to jakoś No i na co nam taki Kierownik Projektu? Przecież jest to osoba całkowicie niedecyzyjna. Tak naprawdę jest on, często całkiem nieźle opłacanym, przekaźnikiem informacji i tylko przekaźnikiem. Pytanie tylko, czy to przypadkiem nie szefa zasługa. Czy to przypadkiem nie jest tak, że szef powiedział Będziesz Kierownikiem Projektu, ale nie dał żadnych uprawnieo, bo delegowanie kompetencji w organizacji, gdzie wszyscy są zazdrośni o władzę, po prostu nie funkcjonuje? Kierownikowi Projektu płaci się za to, że podejmuje decyzje, rozwiązuje problemy i zarządza w trybie operacyjnym całym projektem wedle reguł, które uzgodnił na początku z decydentami. Sami decydenci zaś angażują się w projekt tylko w tych wyjątkowych i rzadkich przypadkach, kiedy sprawy przerastają Kierownika Projektu, jego zakres uprawnieo, zasoby, którymi dysponuje, etc. A jak to jest w metodyce PRINCE2? Dbaj o szefa swego, możesz mied gorszego. Cezary Paprocki CRM SA 2010 Strona 6 z 9

7 Po pierwsze Kierownik Projektu musi mied ściśle zdefiniowany zakres obowiązków. Ten warunek jest jeszcze łatwo realizowalny przy założeniu, że nie pojawią się zapisy w stylu oraz inne polecenia przełożonego, a decydenci zrozumieją, że zatwierdzenie planu, który ma zrealizowad Kierownik Projektu oznacza przekazanie do wyłącznej dyspozycji Kierownika Projektu wszystkich zasobów, koniecznych do wykonania zaplanowanych prac. Drugi warunek jest już trudniejszy. Plan mianowicie, powinien byd opatrzony tolerancjami (zatwierdzanymi wraz z całym planem) i dopóki kierownik potrafi utrzymad etap w tolerancjach, to nie zawraca głowy szefom. Tolerancje mogą byd w teorii na wszystko co się da zmierzyd, a w praktyce, co jest oczywiste, na czas i budżet, ale i na jakośd, zakres prac, ryzyko czy korzyści. Dlaczego ten warunek jest trudniejszy? No bo mamy coś, co się mądrze nazywa uwarunkowaniem kulturowym. Jeżeli mówimy wykonawcy, że ma wykonad pracę w dwa tygodnie ale dajemy mu tolerancję plus/minus dwa dni, to kiedy nam odda pracę? No oczywiście, że po szesnastu dniach! I to, jak będziemy mieli szczęście. W budżecie obowiązuje zaś złota zasada, która mówi: każdy budżet będzie zawsze w stu procentach wykonany. A przecież kiedy robimy coś dla siebie, to tolerancjami zarządzamy zazwyczaj bardzo dobrze, chod niejednokrotnie intuicyjnie. Na przykład, gdy budujemy dom, to mówimy, że wprawdzie kosztorys opiewa na tyle to a tyle, ale zostawiamy sobie jakąś niewielką rezerwę, bo zawsze może wyjśd coś nieprzewidzianego i będzie jak znalazł. Chronimy tę rezerwę jak możemy, by gdyby udało się zaoszczędzid to kupimy sobie fajne meble do salonu. To w projekcie budowa domu tolerancje funkcjonują, a w projekcie budowa skomplikowanego systemu informatycznego nie? Ten problem wymaga w mojej ocenie pogłębionych badao. I wreszcie trzeci warunek. W projekcie powinny byd zdefiniowane zasady (procedura) eskalacji problemu na wyższy poziom zarządzania, czyli inaczej rzecz ujmując, wszystkim wiadomo kiedy i w jakich okolicznościach należy problem eskalowad wyżej a kiedy należy załatwid go samemu. Jaka korzyśd z takiego podejścia? Decydenci nie musza się angażowad w codzienne zarządzanie projektem. W zasadzie ich obecnośd jest widoczna w punktach decyzyjnych, związanych z podziałem projektu na etapy zarządcze oraz w tych wyjątkowych sytuacjach, kiedy sprawy przerastają Kierownika Projektu. Przy czym ta ostatnia sytuacja jest tym rzadsza im większy zakres swobody (tolerancje, uprawnienia) ma Kierownik Projektu. Zasady zarządzania są dopasowane do sytuacji, w której są wykorzystywane Bardzo często w projektach obserwuje się podejście, w którym na jednym biegunie zespół poświęca większośd, jeśli nie całośd, swojej uwagi postępowaniu zgodnemu z Biurokracja zabija, ale spróbujcie na coś nie mied podkładki. przyjętą metodyką zarządzania, a wszelkiego rodzaju szablony i formatki są jego sensem istnienia, na drugim zaś zasady są wprawdzie deklarowane, ale nikt ich nie przestrzega na froncie ciężkich walk z otaczająca rzeczywistością. Panie, mnie tu się wali, a pan mi coś o zasadach eskalacji Cezary Paprocki CRM SA 2010 Strona 7 z 9

8 bredzi!. To oczywiste, że w małym projekcie trwającym tydzieo lub dwa i kosztującym kilkadziesiąt tysięcy nikt nie będzie proponował rozbudowanego systemu raportów okresowych. Ale gdy budujemy elektrownię to spróbujcie nie mied wszystkiego na piśmie! Już same obowiązujące przepisy dadzą zatrudnienie kilkudziesięciu osobom w zespole projektowym. W metodyce PRINCE2 mówi się, że zasady sterowania (podejmowania decyzji) w projekcie powinny byd dostosowane do: Środowiska, w którym projekt jest realizowany (przepisy, zwyczaj, kultura, polityka, interesariusze), Skali projektu (budżet, czas trwania, zakres prac), Złożoności (nowe technologie, niesprawdzone rozwiązania, duża liczba oczekiwanych zmian), Istotności (projekt o znaczeniu krytycznym dla inwestora lub przeciwnie, mający jedynie znaczenie pomocnicze w ramach jakiegoś większego programu), Możliwości (zasoby, wiedza, zdolnośd do wpływania na projekt i otoczenie), Ryzyka (okazje i zagrożenia oraz ich prawdopodobieostwo i ewentualny skutek, poziom ryzyka zagregowanego, koszty obsługi ryzyka). Jeżeli na przykład Kierownik Projektu jest osobą z niewielkim doświadczeniem, a środowisko jest mało przewidywalne, to będziemy dążyli do dzielenia projektu na większą liczbę etapów zarządczych z rozdzielającymi je punktami decyzyjnymi, zawężając jednocześnie tolerancje (uprawnienia Kierownika Projektu) dla każdego etapu. Innym aspektem skalowalności metodyki jest stosowanie standardowej terminologii. Mówi się, że metodyka porządkuje działania dzięki temu, że wszyscy posługują się tym samym językiem. To prawda. Ale. Wiele środowisk wykształciło swoja własną terminologię i wprowadzenie tam na siłę nowej, skutkuje odrzuceniem metodyki. Tymczasem w PRINCE2 nie jest istotne jak się co nazywa (np. nazwa roli). Ważne jest to, co się pod danym pojęciem kryje. Przecież nikt przy zdrowych zmysłach w projekcie budowlanym nie nazwie inżyniera kontraktu przewodniczącym przeglądu jakości i zadowoli się tym, że de facto pod tymi nazwami kryje się z grubsza ten sam zakres obowiązków. I wreszcie niezwykle cenne może się okazad twórcze podejście do pewnych obowiązków wynikających z modelu procesowego metodyki PRINCE2. Ot chodby taki przykład. Wiadomo, że raport okresowy musi byd, bo inaczej decydenci wpadają w nerwowy stan niepewności. Ma on zazwyczaj formę pisemną. Jeszcze pół biedy, jak jest krotki. Ale jak to jest przydługa epistoła, uwypuklająca nasze sukcesy i zaciemniająca nasze wpadki, to zaczyna się problem. Inna bieda z Cezary Paprocki CRM SA 2010 Strona 8 z 9

9 takim raportem jest taka, że trafia on zazwyczaj do wąskiego grona, składającego się głównie z naszych szefów. Tymczasem od lat wiadomo, że komunikacja w projekcie jest jednym z istotnych czynników sukcesu, a najskuteczniejsza jest wtedy gdy jest osobista. Co zrobił pewien zespół? Częstotliwośd raportowania zespół miał ustaloną na co dwa tygodnie. W związku z tym raz na dwa tygodnie wszyscy zainteresowani (włącznie z najwyższym kierownictwem) zbierali się i omawiali wszystkie istotne, bieżące sprawy w projekcie. Na takich spotkaniach decydenci mogli i podejmowali również adekwatne decyzje w trybie podejmowania decyzji doraźnych (patrz metodyka PRINCE2). Z całego spotkania był sporządzany formalny protokół, który umieszczony w dokumentacji projektu, pełnił rolę raportu okresowego. Fajne? I to tyle o pryncypiach. Czytelnikowi zostawiam dostrzeżenie wzajemnych powiązao opisanych wyżej pryncypiów i tego jak razem tworzą pewien spójny obraz dobrze, to znaczy mądrze i logicznie, zarządzanego projektu. Chciało by się powiedzied: Tak powinno byd w każdym projekcie! Cezary Paprocki Cezary Paprocki CRM SA 2010 Strona 9 z 9