®
© Cezary Paprocki CRM SA 2010
Strona 1 z 9
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
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
Wiedz po co coś robisz, nie
tylko zanim zaczniesz to coś robid,
ale i w trakcie, jak robił będziesz.
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.
© Cezary Paprocki CRM SA 2010
Strona 2 z 9
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,
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
Każdy Kierownik projektu ma
trzech
naturalnych
wrogów:
zespół
projektowy,
klienta
i zarząd. Szczęśliwie, tylko z tym
ostatnim musi się liczyd.
© Cezary Paprocki CRM SA 2010
Strona 3 z 9
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,
ż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
Nie za to ojciec lał syna, że
ten grał w karty, tylko za to, że się
chciał odegrad.
© Cezary Paprocki CRM SA 2010
Strona 4 z 9
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
byd zrobione i jak to powinno
wyglądad.
Ale
uwaga!
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
Nie będziesz w projekcie
wykonywał
czynności,
które
wytwarzaniu produktów nie służą.
© Cezary Paprocki CRM SA 2010
Strona 5 z 9
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.
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.
Nie bierz Jasiu wszystkiego
do buzi na raz, bo się udławisz.
© Cezary Paprocki CRM SA 2010
Strona 6 z 9
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 7 z 9
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
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
Biurokracja zabija, ale
spróbujcie na coś nie mied
podkładki.
© Cezary Paprocki CRM SA 2010
Strona 8 z 9
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 9 z 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