Procesy - Zamykanie Projektu / Processes - Project Closure

Celem procesu Zamykanie Projektu jest przede wszystkim zweryfikowanie akceptacji dla produktów, wykonywane przez użytkownika. Tutaj także uzyskujemy zapewnienie że klient jest w stanie wspierać produkty danego projektu. Dokonujemy w procesie Zamykanie Projektu przeglądu dla efektywności realizacji projektu. 
Nie mniej ważne cele to między innymi ocena zrealizowanych korzyści i aktualizacja prognoz dla korzyści. Zamknięcie Projektu pomaga nam również w zapewnieniu rozpatrzenia wszelkich nierozwiązanych zagadnień i ryzyk jak również zaleceń dla działań następczych.
Istotnym celem tego procesu jest także zaplanowanie przeglądu korzyści.

Cyt. " proces Zamykanie Projektu służy do wskazania ustalonego punktu, w którym zostanie potwierdzona akceptacja produktu końcowego projektu oraz potwierdzenia, że cele określone w pierwotnej Dokumentacji Inicjowania Projektu zostały osiągnięte, albo że projekt nie ma już nic więcej do wniesienia"

Co ważne :
- proces Zamykanie Projektu jest realizowany również wtedy gdy projekt zamykany jest przedwcześnie;
- cechą charakterystyczną projektu jest skończony czas trwania;
- zakończenie projektu powoduje koniec odpowiedzialności zespołu zarządzania projektem;
- dokumentowania wymagają wszelakie działania następujące, dotyczące przekazywanych produktów;
- zakończenie projektu przekazuje również odpowiedzialność na stronę klienta, za jego produkty.

Proces Zamykanie Projektu zawiera/może zawierać w sobie poniższe czynniki :

• Przygotowanie planowego zamknięcia;
• Przygotowanie przedwczesnego zamknięcia;
• Przekazywanie produktów;
• Ocenianie projektu;
• Rekomendowanie zamknięcia projektu.

To był ostatni przeze mnie opisany proces występujący w metodologii Prince2

Procesy - Sterowanie Etapem / Processes - Stage Management

To jest "sól tej ziemi" (kolejna ?) - tutaj praca Kierownika Projektu jest zdefiniowana. W procesie Sterowanie Etapem znajduje się najwięcej zadań dla Kierownika, ponieważ ten proces polega na: 
- przydzielaniu pracy i jej monitorowaniu;
- raportowaniu Komitetowi Sterującemu o postępach w projekcie;
- podejmowaniu działań korygujących (mieszczących się w tolerancji);
- tutaj obsługuje się również pojawiające się zagadnienia.

Polecam mój wielkiej urody szkic- w którym widać umiejscowienie opisywanego procesu, wśród innych procesów, takich jak :

• Przygotowanie Projektu;
• Zarządzanie Strategiczne Projektem;
• Zarządzanie Końcem Etapu.

Komu to potrzebne - jak już wspomniałem powyżej - głównie Kierownikowi Projektu, dla codziennego zarządzania etapem. Używany jest do zarządzania każdym etapem realizacyjnym, ale można go użyć dla skomplikowanego etapu inicjowania (gdy mamy do czynienia z bardzo dużym projektem).

Dzięki temu procesowi Kierownik Projektu może kontrolować i definiować pracę Kierowników Zespołów, ustalając przy tym odpowiednie tolerancje. Należy wspomnieć o tym, że Kierownik Zespołu może być jednocześnie Kierownikiem Projektu (jeśli projekt nie jest zbyt skomplikowany), tutaj PRINCE2 zezwala na łączenie ról. Jeśli tak się stanie, Kierownik ma dwie role i odpowiada za wykonanie Grupy Zadań.

...na co mi to...

1. by uniknąć "pełzania zakresu", czyli zmian które nie posiadają kontroli;
2. by umożliwić skupienie się na tym co najważniejsze dla projektu - PRODUKT;
3. kontrola, kontrola, kontrola - zagadnień oraz ryzyk;
4. pomaga w przeglądzie Uzasadnienia Biznesowego;
5. daje zapewnienie tego, że zespół zarządzania projektem skupia się na jego realizacji (projektu) w ramach przydzielonych tolerancji, oraz zgodnie z ustalonymi nakładami osiągając zamierzoną jakość.

Występują w opisanym powyżej procesie następujące działania :

- Zezwalanie na wykonanie Grupy Zadań;

- Przeglądanie stanu Grupy Zadań;

- Odbieranie zakończonych Grup Zadań;

- Przeglądanie stanu etapu;

- Raportowanie Okresowe;

- Wychwytywanie i analizowanie zagadnień i ryzyk;

- Przekazywanie zagadnień i ryzyk

A to wszystko zamyka i spaja Podejmowanie Działań Korygujących...

Procesy - Zarządzanie Końcem Etapu / Processes - End of Stage Management

Oczywiście i ten Proces ma służyć Komitetowi Sterującemu, ale nie tylko. A po cóż on temu Komitetowi, jest on potrzebny z paru powodów :

• Komitet Sterujący musi w jakiś sposób dokonywać przeglądu osiągnięcia celów bieżącego etapu;
• Komitet Sterujący musi w jakiś sposób dokonywać przeglądu uaktualnionego Planu Projektu;
• W jakiś sposób (właśnie dzięki Zarządzaniu Końcem Etapu) Komitet zatwierdza Plan następnego Etapu;
• Jest to "narzędzie" dzięki któremu łatwo jest potwierdzić dalszą zasadność biznesową projektu i tak zwaną "akceptowalność" ( poziom dopuszczalnych ) ryzyk
• Tutaj jest miejsce na stwierdzenie sytuacji nadzwyczajnej i opracowanie Raportu Nadzwyczajnego oraz Planu Nadzwyczajnego, który zatwierdzany jest jak Plan Etapu

Czego jeszcze możemy oczekiwać od Procesu Zarządzanie Końcem Etapu - na pewno przeglądu i uaktualnienia Dokumentacji Inicjowania Projektu.

Mała dygresja  - DIP to :

1. Opisy ról i struktury zespołu zarządzania projektem;
2. Uzasadnienie Biznesowe;
3. Plan Projektu;
4. Strategie Zarządzania (są to strategie zarządzania : Konfiguracją, Jakością, Komunikacją, Ryzykiem);
5. Mechanizmy sterowania Projektem;
6. Opis (definicja) projektu i jego forma realizacji;
7. Opis dostosowania metodyki (bo PRINCE2 jest skalowalny - prawda ;) ?)

Bardzo istotnym jest również zarejestrowanie informacji i doświadczeń w odpowiednich rejestrach - będą one pomocne przy realizacji dalszych etapów ( i możliwe że przy innych projektach).

A po co ten proces Kierownikowi Projektu ? Jest on konieczny dla Uzyskania zezwolenia na rozpoczęcie Kolejnego Etapu.

To czy projekt jest skoncentrowany na osiągnięciu celu i uzasadniony biznesowo, jest każdorazowo potwierdzane właśnie tym procesem. 

Należy również pamiętać,że decyzja o zaniechaniu kontynuowania projektu nie jest porażką.

Tutaj raportowanie zakończenia etapu da nam odpowiedź , czy otrzymamy akceptację Planu Etapu / Planu Nadzwyczajnego - oczywiście raport należy rozesłać wszelakim interesariuszom.

Procesy...Zarządzanie Strategiczne Projektem / Programme Management

Jesteśmy na saaaamej górze...kto by tu nie chciał siedzieć ?

Tak PRINCE2 mówi o tym że Zarządzanie Strategiczne umożliwia przyjęcie odpowiedzialności przez Komitet Sterujący, ale przecież to jest właśnie ta "śmietanka z tortu".

To właśnie dzięki temu procesowi Komitet jest w stanie podjąć kluczowe decyzje, deleguje uprawnienia, takie jak bieżące zarządzanie projektem ( kierownikowi).

Zarządzanie strategiczne polega na weryfikacji i kontroli czy dany projekt pozostaje zasadny, polega również na upewnieniu się że istnieje przepływ informacji między poziomami zarządzania. Dzięki temu procesowi Komitet Sterujący jest w stanie przeglądać korzyści projektowe (czyli CLUE zabawy w projekt;)).

Zarządzanie Strategiczne jako proces rozpoczyna sie zaraz po Przygotowaniu Projektu, i dzięki Tolerancjom Komitet Sterujący jest w stanie działać we wspomnianym procesie, jednocześnie powodując jak najmniejszą ingerencję. 

Nie chodzi o to by Komitet interesował się nawet najmniejszym etapem i cząstką projektu, dzięki delegacji uprawnień i przypisaniu odpowiednich tolerancji, może zająć się innymi projektami - dzięki temu doglądając kilku naraz

Komitet Sterujący, dzięki procesowi Zarządzanie Strategiczne Projektem zezwala na :
- zainicjowanie projektu;
- realizację projektu;
- realizację Planu Etapu, lub Planu Nadzwyczajnego;
- podejmowanie decyzji doraźnej
- zamknięcie projektu

Procesy - o nie, znowu ? - Przygotowanie Projektu

Procesy to działania , mogą one być realizowane po sobie (dobrze widać to w ujęciu Kaskadowym) lub równolegle (wtedy uzyskujemy wartość Lean). 

Na co to komu, otóż jest to Proces "wejściowy" - występujący przed projektem, dzięki któremu możemy zaoszczędzić sporo środków, jeśli na jego etapie unikniemy jak najwięcej błędów. Zgodnie z filozofią "odchudzonego" zarządzania - błędy wykryte we wczesnej fazie kreują najmniej kosztów na końcu.

Dzięki takiemu procesowi, jak np. Przygotowanie Projektu w PRINCE2, powinniśmy uzyskać możliwość uniknięcia realizowania nieprzemyślanych projektów. Jest to wstępne sito, które pozwoli nam zracjonalizować początkowe idee. 

Tutaj też dowiemy się, czy opisany wstępnie projekt jest wart realizacji, także otrzymamy zapewnienie, że istnieje uzasadnienie biznesowe dla zainicjowania takiego projektu.

Co nam daje jeszcze proces Przygotowanie Projektu ? Między innymi informację, o tym że :

- zweryfikowano wszelakie , różne od siebie sposoby realizacji danego projektu (łącznie z tym, żeby go nie realizować...);

- opisano role i przypisano osoby, "nawet" te z Komitetu Sterującego danym projektem;

- nie stracimy czasu na realizację czegoś co ma błędne "wstępne" założenia, np. dotyczące czasu, terminów, ograniczeń etc.;

- będziemy przeglądać doświadczenia, jak również założymy dziennik doświadczeń - czyli Lessons Learned.

Całość "ubiera się" zgrabnie w produkt zarządczy zwany nie inaczej jak : Założenia Projektu


Na końcu tej "gry wstępnej" należy postarać się o to by zaplanować etap inicjowania. W tym miejscu kończy się więc etap przed projektem.

...i ja też kończę ;)

Produkt / Product – to wszystko przez niego ten cały PRINCE2

No bo gdyby go nie było, to by PRINCE2 nie było… tak mądrym wstępem pragnę zacząć. Czymże jest produkt – niby każdy wie. Wie pan, wie pani…wie społeczeństwo…ale jak się okazuje nie do końca. Koncentracja na produkcie w podejściu PRINCE2 jest bardzo dobrze opisana – jako „clue” całej tej zabawy.

Zależnie od klienta – poziomu odbioru – produktu widzimy specyfikację i określenie produktu finalnego i cząstkowego.  To od klienta zależy, jaki produkt będzie dla niego odpowiedni, od klienta zależą również tolerancje dla niego na różnych zakresach.

Zależnie od kryteriów jakościowych wiemy jak dobrze jest opisany produkt – dzięki temu powinniśmy wiedzieć czy będzie on odpowiadał opisowi produktu końcowego.

To Opis Produktu mówi nam o wszelakich właściwościach wytwarzanego przez nas produktu, niezależnie od tego czy produktem będzie: dokument, decyzja, kubek do kawy, kosiarka, impreza charytatywna, koncert, czy też książka… etc.

Dlaczego jest to tak istotne – jest to zdrowe podejście dla wszelakich metodyk Agile, przyczyną działań powinien być produkt końcowy, choć jak pisałem w Agile PM – akceptuje się czasem inny jego wygląd , dla sprostania „stałym” funkcjom „trójkąta”. To i tak musi to być zawsze produkt akceptowalny przez interesariuszy, oraz ogólnie rzecz biorąc rynek/odbiorcę, czyli klienta (w rozumieniu pejoratywnym).

Wszech (po) mocne procesy w Prince2 / All (Bundy) mighty processes in accordance to Prince2

Oj tak, Procesy - kto by się nimi przejmował - ja na pewno "Pan Proces" ;), polecam lekturę :

Oczywiście - All Rights Reserved

Etapy / Stages

Etapy etapami, Panie Kierowniku, ale my jesteśmy w czarnej ...

Jak jest "ZAZWYCZAJ"

Panie Kierowniku - tym razem naprawdę...damy radę...

Jak powinno być

Zdefiniowane role i obowiązki / Roles Defined.

Zdefiniowane role i obowiązki pojawiają się w każdym projekcie, jako kolejne z koniecznych pryncypiów.

Jest koniecznym i standardowym podejściem w metodologii PRINCE2, ustanowienie jasnych zakresów obowiązków, choć dopuszcza się czasem przy założeniu, że projekt jest niewielki – łączenie ról. Standard zaleca jednak by role pozostały rozdzielone w taki sposób, aby umożliwić przepływ danych i rozdział kompetencji, dając tym samym pracującym ludziom wszystkie potrzebne narzędzia do wykonywania swoich obowiązków.

Istotnym jest zdefiniowanie interesariuszy – z punktu widzenia „koncepcji ruchu” – są to ludzie, których „zawsze coś rusza”, w odniesieniu do projektu. Czyli mają na projekt wpływ lub projekt na nich wpływa – w konsekwencji wywołując ruch.

Mówi się często o TRZECH stronach interesu w projekcie :

Cykl życia Uzasadnienia Biznesowego / Business Justification Lifecycle - Yes We Can !

Business Justification Lifecycle - PRINCE2 variation

Korzystanie z doświadczeń / Lessons Learned.

Tak jest to jedno z siedmiu pryncypiów według PRINCE2, które jest koniecznym by projekt był realizowany w zgodzie z metodyką.  W języku angielskim używa się czasem pojęcia „Lessons”, ponieważ to właśnie doświadczenia, te Lekcje z „pola walki” są najistotniejszymi dla powodzenia realizacji projektu. Jeśli już raz udało nam się przetrzeć szlaki i wykarczować las niebezpieczeństw i terminów oraz zazębiających się zadań oraz ułożyć z tego spójną drogę przez proces prowadzenia projektu. Logicznym jest, że prawdopodobnie uda nam się za drugim i trzecim razem. 

Choć praktycy powtarzają, że każdy projekt jest inny, każdy ma inne uwarunkowania. Najistotniejsze jest jednak z punktu widzenia tego pryncypium to, że dzięki doświadczeniu unikamy popełniania tych małych błędów. Ponieważ nawet największa podróż zaczyna się od pierwszego kroku. Ważnym jest by nie skręcić kostki na samym początku i uniknąć stałych niebezpieczeństw, które towarzyszą każdemu przedsięwzięciu biznesowemu.

Jeśli realizujemy mały projekt w ramach małego przedsięwzięcia, zazwyczaj korzystamy z notatnika albo innej formy bazy danych, bardziej nieformalnej. Korporacyjne podejście jest bardziej usystematyzowane. To cała gałąź „ Lessons Learned” osnuta jest w ideologię, politykę i opasłe systemy informatyczne do przechowywania danych i doświadczeń, po to by wykorzystać je podczas kolejnej działalności, kolejnego „startu” projektu. Ma to swoją drugą stronę medalu taką, że często ilość danych przerasta czytelnika / odbiorcę, co w gruncie rzeczy prowadzić może do zniechęcenia i zaniechania korzystania z takiego źródła. 

Negatywne efekty - to popełnianie tych samych błędów przy każdym projekcie, brak motywacji do poprawiania działań.