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ę ;)

Pryncyp 7 - dmy - Dostosuj Metodykę do warunków projektu / Just adjust your methodology to project environment

To jest, że tak powiem "Last but not Least" z pryncypiów, zarazem mój ulubiony. PRINCE2 nakazuje, by metodykę dostosować do warunków projektu. Zacna to teza, i trafne stwierdzenie. Nie jest to co prawda "unikanie odpowiedzialności" za niepowodzenia projektu, ale raczej "krojenie na miarę potrzeb".

Co bierzemy pod uwagę:

1. Warunki konkretnego projektu - czy chodzi nam o wykształcenie pięknego ABS, czy też o zdobycie medalu mistrzostw świata, tak jak pisałem wcześniej. Warunki są różne projekty są jeszcze bardziej zróżnicowane - chodzi o to by PRINCE2 dostosować, ale dlaczego PRINCE2...może lepiej Agile PM - ten jest jeszcze bardziej "giętki", nie posiada wad w postaci opasłych ram formalnych. pamiętajmy, zawsze możemy użyć metodyki Kaskady (Waterfall), ona sprawdza się w środowiskach nieskomplikowanych z ustalonymi z góry i przewidywalnymi "zmiennymi".

2. Rozmiar Projektu, jasne jest tutaj stanowisko metodologii, ponieważ opisuje ona jak bardzo można "ścisnąć" dokumentację dla mniejszego projektu, które role można łączyć etc. natomiast w przypadku wielkiego projektu, PRINCE2 dostarcza wszelkich instrumentów do kontroli i pomocy w jego realizacji zgodnie z założonym Uzasadnieniem Biznesowym.

3. Złożoność Projektu, metodologia daje nam wybór ilości faz projektu, daje nam możliwość w podziale produktów na produkty cząstkowe. To wszystko umożliwia sprawne zarządzanie nawet najbardziej złożonymi projektami gdy oprzemy się na metodologii.

4. Znaczenie Projektu, wiadomo że dla każdego Kierownika Projektu jego projekt jest najważniejszy, jest nieco inaczej z Komitetem Sterującym, który może brać udział i rozdzielać swój czas pomiędzy inne projekty. Tutaj zarządzanie tolerancjami, odpowiedzi zdefiniowanie ról i obowiązków pomaga zaoszczędzić czas decydentom - definiując zarazem znaczenie konkretnego projektu.

5. Możliwości i Ryzyko, metodyka PRINCE2 w przypadku ryzyka odsyła nas do odrębnego działu -  MOR (Management Of Risk). Gdybyśmy jednak chcieli znać podstawy i pragnęli zabezpieczyć się w podstawowy ( często wystarczający ) sposób, ryzyko jesteśmy w stanie "ogarnąć" również przy pomocy dostępnych w PRINCE2 / Agile metodologii. Każdy projekt ma inne możliwości, myślę że ten truizm jest jasny sam w sobie.

Dodam jeszcze tylko, że metodykę PRINCE2 można stosować w każdej kulturze pod warunkiem spełnienia wszystkich siedmiu pryncypiów.

To w jaki sposób metodykę dostosowano do warunków danego projektu powinno być opisane w DIP, czyli Dokumentacji Inicjowania Projektu.

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).

Jeden z Siedmiu Wspaniałych – Zarządzanie z wykorzystaniem Tolerancji / one of the Seven the Greatest – Management with usage of tolerances.

Po co nam tolerancja, wg. mnie tolerancje są najlepszym, co znajdziemy w metodyce ( lub ewentualnie musimy znaleźć) w Prince2.

Tolerancje pomagają nam w zdefiniowaniu ryzyka, pomagają w określeniu czy jesteśmy już blisko celu, czy ciągle daleko.

W Prince2 uprawnienia przekazywane są razem z tolerancjami dla sześciu wskaźników, pomagających określić stopień wykonania planu. Oczywiście w odpowiednim poziomie. Są to już cytowane.

Dla każdego z nich ustalone tolerancje mówią nam, kiedy powinno się eskalować problem. Przekroczenie tolerancji dla poszczególnych wskaźników powinno ( no chyba że ktoś np. Kierownik Projektu  to „czajnik” – i zaczaja problemy J) skupić uwagę naczelnego Kierownictwa oraz Komitetu Sterującego. W Agile natomiast, tolerancje traktowane są nieco bardziej po macoszemu. W wartości istotnej - takiej jak ZAKRES, możemy mieć nieoczekiwany efekt projektu, ale to właśnie dzięki temu projekt często jest skuteczny i uzasadniony biznesowo.

Tak jak na poniższym trójkącie.

Stałe i Zmienne - czyli "z czym możemy poszaleć" w podejściach do zarządzania projektami

Jest to porównanie zakresów, ale i tolerancji. Widać tutaj bardzo dobrze co można zmienić w podejściu standardowym – KASKADA, a co jest zmienną w podejściu AGILE. 

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ć

Zarządzanie etapowe / Stages and management

Trudno sobie wyobrazić PRINCE2 bez etapów, to dzięki nim dokładnie widać jak ruch w projekcie generuje przyrost – w najgorszym wypadku przyrost kosztów i niespełnionych oczekiwań ;).

Podział projektu na etapy pozwala na zdefiniowanie bardzo ważnego czynnika, czyli tolerancji. To dzięki tolerancji wiemy tak naprawdę czy projekt jest jeszcze w zakresie i w realnej fazie ukończenia go z zyskiem.

Etapy już raz rozrysowałem, na szkicu tej pięknej urody widać dokładnie jak Projekt może zostać podzielony. Oczywiście tutaj wspomina się jedynie o etapach projektu, inne ważne etapy, dzięki którym da się mierzyć postępy to etapy Techniczne.

Etapy techniczne i etapy zarządcze pozwalają na pomiar Postępów. Te z kolei są monitorowane na poziomie – Projektu – Etapu i Grupy Zadań

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ń. 

A torcik znacie ? / Do you recognize that cake ?

Co mówi PRINCE2 na temat słodyczy... / What PRINCE2 says about sweets...

Ruch w biznesie - movement within business

Jak zapewne wiecie zasadność biznesowa,  jest bardzo istotnym czynnikiem PRINCE2 opisuję ja jako „pryncypium”. Ni mniej ni więcej, należy się jej 100% uwagi bo to klient musi dbać o swój biznes i dostawca również robi to dostarczając swój produkt na czas. Nieodzownym jednak czynnikiem jest badanie tej ZasadnościBiznesowej – czy jest ona CIĄGŁA.

Brak Ciągłości w najlepszym wypadku może spowodować wyjście poza zakres lub , zbliżenie się do tolerancji (czasu, lub zasobów pieniężnych) w najgorszym może jak najbardziej prowadzić do klęski. 

Ponieważ PRINCE2 definiuje SIEDEM PRYNCYPIÓW, brak jakiegokolwiek z nich eliminuje nasz projekt z rozpatrywania go, jako projekt oparty na wspomnianej metodologii.  Nie wyklucza go jednak z zarządzania metodami bardziej zwinnymi… ale to już całkiem inna bajka. 

Pamiętać należy jedno, by weryfikować i sprawdzać czy zasadność biznesową istnieje, czy na każdym etapie realizacji jest sens ciągnąć projekt dalej. Ponieważ okazać się może, że takowy będzie miał rację bytu w formie, jakiej jest (AGILE), a dalszy rozwój przyniesie tylko większe straty lub zysk, który nie pokryje alokowanych kosztów.

Ruch wewnętrzny - internal movement

Zapewne już znacie wszystkie szczegóły dotyczące podstawowej zależności – Planuj – Deleguj – Monitoruj – Kontroluj. 

coś na kształt koła Deminga

To jest specyfika w zarządzaniu projektem, która świetnie się wpisuje w koło Deminga.  Ruszając się wewnątrz projektu musimy pamiętać o parametrach efektywności projektu. PRINCE2 jasno je deklaruje, jest ich sześć:

- Koszty;

- Terminy;

- Jakość;

- Zakres;

- Ryzyko;

- Korzyści;

Mając na uwadze te zależności, łatwo określić siły wpływu wewnątrz każdego projektu. Są to siły przeciwstawne, ponieważ silnie powiązane, mają niesamowity – nieodzowny wpływ na powodzenie naszego przedsięwzięcia.

Jest to podstawowa logika:  Jakość ma wpływ na Koszty, Koszty na terminy, Zakres ma wpływ na Ryzyko a wszystko zależne jest za zwyczaj od Korzyści, etc..

Niezależnie od tego jak będziecie zabierali się do projektów ważnym jest by nie zapominać o wewnętrznych siłach współdziałających w waszym „specyficznym” projekcie. Od tego powinno zależeć wasze podejście i wybór właściwej ścieżki zarządzania: przecież niekoniecznie musi być  Agile, skoro PRINCE2 daje radę, a może właśnie adaptacja podejścia Klasycznego Kaskadowego lub właśnie SCRUM da radę. 

Jak się ruszać - How to move - Come muoversi

Ruch w ujęciu pejoratywnym powinien się kojarzyć ze zmianą stanu skupienia, albo co najmniej przeniesieniem sił w układzie – ciało – masa – prędkość.

Jeśli mówimy o zarządzaniu projektami, wiadomym jest, że ruch jest nieodzownym czynnikiem zmiany, i dla projektów ta właśnie zmiana jest kluczowym czynnikiem przyrostu wartości projektu w czasie.

Nie jest łatwo ukierunkować ruch, dla osiągnięcia korzyści, a co więcej nie jest prostym zrobić to w taki sposób by tę korzyść osiągnąć jak najszybciej. Każdy, kto ma w zamierzeniu, choć najmniejszy projekt – powinien go ulepszać. Ciągłe ulepszanie jest niesamowitym narzędziem, prostym a jednak bardzo efektownym. Nie chodzi o to żeby codziennie walczyć ze zmianą, by codziennie szukać ulepszeń dla rozwiązań działających, lecz by się im przyglądać.

Wychodząc z założenia, że niektóre z największych wynalazków zostały odkryte całkowicie przez przypadek, należy przyjąć technikę „oderwania”, odlepienia się na chwil parę od problemu - próby spojrzenia na niego z innej perspektywy. Dlatego podstawowe dzisiejsze pytanie – jak się ruszać – jest tak istotne. Będąc liderem projektu ważne jest to by być wszędzie, w miarę możliwości spoglądając na działania poboczne ( nie chodzi jednak o to by zabierać innym osobom pracę i przeszkadzać im w działaniach, – lecz by nabrać ogólnego poglądu). Nie można być kierownikiem projektu patrząc jedynie na „słupki”, aczkolwiek tego typu praktyki bywają czasem stosowane przez wielkie korporacje. W ten sposób nie da się „ogarnąć” całości projektu.

Dla mnie, „jakość” ruchu w ujęciu zarządzania projektami ma swój główny ciężar położony na sprecyzowanym zarządzaniu poszczególnymi etapami, ale w ujęciu „holistycznym”. Tak jak mówi SCRUM – krótkie spotkania, szybka wizja oraz podjęcie decyzji. Człowiek powinien czerpać ze swoich instynktów w dobie agresywnego konsumpcjonizmu – jest to bardzo przydatny czynnik, pozwalający przetrwać. Nie ma tutaj znaczenia czy polujemy na dzikie zwierzę, czy walczymy z terminami i kosztami zagrożonego projektu.

Movement as its definition should be correlated with a change of a matter, or at least with movement of forces in relation – body – mass – speed.

If we are going to talk about project management it is obvious, that movement is something crucial for change, and for projects, and this change is an key factor for increase of project value in time.

It is not easy to steer such movement, to see progress, what is more it isn’t easy to do it in such way to gather income (Incrementation) in possible fastest way. Everyone who has in scope , even the smallest project – should consider make it better. Continuous Improvement, is an magnificent tool, simple yet effective. It is not about fighting with change on everyday basis , to search improvements  for solution that works fine, it is about observing.

Taking into account fact that some of the greatest inventions were done by mistake, it is important to take under consideration technique  of “severance”, disengagement for a few moments from an issue – just to take a look on it from a different angle. Therefore today stated question  - how to move – is so important. Being an Project Leader it is important to be everywhere, having possibility to take a look on side actions and side effects ( it is not about taking other peoples job, and creating  an disturbance – but to get a wider glimpse). You can not be Project Leader, and check only rough charts, yet such practices are sometimes accepted by corporations. In such way it is difficult to understand whole projects.

For me “quality” of movement in scope of project management has its vast importance in precised management of forthcoming stages, but in a “holistic” way. As it is defined by SCRUM  - short meetings, quick vision and decision. Men should derive from its instincts in times of an aggressive  consumerism – it is a very useful factor, allowing to survive. It is not important whether we are hunting for an wild animal or we are fighting with dates and costs of project in danger.