PRINCE2® + Agile PM® – jak je połączyć?

PRINCE2® + Agile PM®

W świecie zarządzania projektami odbywa się ostatnio pojedynek. Na ringu stoją: stary mistrz PRINCE2®, a po drugiej stronie pretendent Agile PM. Stary mistrz ma za sobą lata doświadczenia i wielu zagorzałych wielbicieli. Kandydat na mistrza jest niewątpliwie zwinny i zdobywa szybko nowych i fanatycznych wyznawców. Pytanie kto wygra?

Obie metody wywodzą się z IT, jednak obie wykraczają już poza zastosowania w informatyce i mogą być swobodnie stosowane do projektów w innych obszarach.

PRINCE2®

PRINCE2® to metodyka i standard zarządzania projektami stworzony w Wielkiej Brytanii, oraz rozwijany od 1975 roku.

Licencja: skills®

Jest metodyką, zgodnie z jej definicją, tzn. zbiorem zasad dotyczącym zarządzania projektami, określającym, co, w jakiej kolejności i kto będzie robił, by projektem zarządzać.

Jest standardem, ponieważ została zaakceptowana przez rząd Wielkiej Brytanii, jako standard stosowany do zarządzania projektami finansowanymi z budżetu Państwa. Również w Polsce, duże organizacje sektora publicznego stosują PRINCE2® np. NBP, NCBiR.

Preferowana przez administrację publiczną i postrzegana czasami (ze względu na nieudolne jej wdrożenia) jako biurokratyczna, „ciężka” i mało przyjazna.

Często zarzuca się jej zbytnią dokumentację, pomijając jednak fakt, że podręcznik mówi o produktach zarządczych (nie dokumentach), które mogą mieć również postać ustną lub nieformalną.

W rzeczywistości może być stosowana zarówno do małych, jak i wielkich projektów, ponieważ jest skalowalna tzn. możliwa do dostosowania w zależności od rozmiaru i środowiska.

Dużą zaletą PRINCE2® jest kompleksowość, ponieważ dokładnie opisuje role w projekcie, oraz produkty zarządcze nie definiowane w innych metodach.

Elementy konstrukcyjne PRINCE2® to:

1. procesy – działania opisujące zarządzanie projektem,
2. tematy – obszary, którymi trzeba się w projekcie zająć,
3. pryncypia – zasady, których trzeba przestrzegać zarządzając projektem,
4. sposób dopasowania PRINCE2® do konkretnego projektu i jego otoczenia.

Zarządzanie projektem PRINCE2® zakłada, że wymagania dotyczące produktu powinny być określone jeszcze przed projektem, ale termin ukończenia i budżet dzięki tolerancji nie musza być określone sztywno. Oznacza to, że możemy się spodziewać przekroczenia budżetu i czasu w projekcie. Dodatkowo na jakość też możemy nałożyć tolerancję, więc zakładamy, że wytworzony produkt nie musi w 100% spełniać oczekiwań, bo odchylenia od wymagań są dopuszczalne.

Metoda jest własnością AXELOS.

Agile

Termin agile bierze się od Manifestu Agile (Manifest Zwinnego Wytwarzania Oprogramowania), który został podpisany w 2001 roku przez przedstawicieli metodyk zwinnych takich jak: programowanie ekstremalne, scrum, Dynamic Systems Development Method, Adaptive Software Development, Crystal Clear, Feature Driven Development, Pragmatic Programming.

Sam Manifest o następującym brzmieniu:

„Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy:

Ludzi i interakcje ponad procesy i narzędzia.
Działające oprogramowanie ponad obszerną dokumentację.
Współpracę z klientem ponad formalne ustalenia.
Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej.”

Sugeruje, że istotne jest nie tylko to co „ludzkie”, ale również to, co ludziom pozwala pracować w sposób skuteczny i zorganizowany.

Jednym z podstawowych założeń projektów agile’owych jest to, że uzgodniony czas, budżet i jakość projektu są nieprzekraczalne. Parametrem, który pozwala nam na zarządzanie projektem jest w takim razie zakres wymagań.

To założenie jest zupełnie dopasowane do dzisiejszych czasów kiedy znacznie ważniejsze jest to, by wprowadzić na rynek produkt (choćby nie posiadał wszystkich możliwych do wyobrażenia wymagań) szybciej niż konkurencja i w przeznaczonym na to wcześniej budżecie, niż dostarczyć produkt spełniający wszystkie wymagania, ale po tym jak zrobi to konkurencja. Rynek nie wybacza opóźnień, bo konkurencja chętnie przejmie nasz udział w rynku.

DSDM Atern

Jedną z wymienionych metod jest Dynamic Systems Development Method (w skrócie DSDM).

Historia DSDM (protoplasta Agile PM) sięga roku 1994 co pokazuje, że w obu przypadkach mamy do czynienia ze sprawdzoną i sprawdzoną metodą. Ostatnia wersja metody z 2007 roku została nazwana DSDM Atern.

Atern jest skrótem od Arctic Tern co po polsku oznacza rybitwę popielatą. Rybitwa ta chętnie współpracuje i  może pokonywać duże odległości.  Z tego względu została wykorzystana do uosabiania wielu cech DSDM np. ustalania priorytetów i chęci do współpracy.

Metoda wyróżnia się tym, że nie tylko uwzględnia filozofię agile, ale również dobrze opisuje sposób zarządzania projektem nie koncentrując się wyłącznie na metodach pracy zespołu.

Agile PM®

Podzbiór DSDM Atern opisujący projekt z perspektywy Kierownika Projektu został zebrany w podręcznik „Agile Project Management version 1.1.” i jest on podstawą certyfikacji do poziomu Foundation lub Practitioner.

 

Licencja: skills®

Licencja: skills®

W samym podręczniku znajdziemy takie elementy konstrukcyjne jak:

• filozofia- czyli to, że „każdy projekt musi być dopasowany do jasno określonych celów strategicznych i koncentrować się na wczesnym dostarczeniu prawdziwych korzyści biznesowi”,
• pryncypia – 8 pryncypiów podkreślających to, jakie nastawienie musi mieć i utrzymać zespół by dostarczać (produkty i korzyści) w sposób ciągły,
• procesy – określające kroki realizowane w projekcie w celu wytworzenia odpowiednich produktów i przekazania ich do użytkowania,
• ludzie – opisuje role i ich odpowiedzialności z uwzględnieniem biznesu, odpowiedzialnych za zarządzanie, oraz dostawcy,
• produkty – definiujące ok. 20 produktów definiujących aspekty zarządcze, biznesowe, oraz techniczne projektu,
• praktyki – techniki, które w projekcie mogą zostać zastosowane takie jak: priorytetyzacja MoSCoW, warsztaty, timeboxing, itd.

Wygląda więc, że sporo aspektów projektu jest dobrze zdefiniowane, co może się wydawać zaskakujące dla osoby spodziewającej się po metodyce zwinnej zupełnej swobody działania.

Agile PM jest własnością Agile Business Consortium.

 

Co wybrać?

Stojąc przed wyborem metody realizacji projektu moglibyśmy się zastanawiać, która lepiej odpowiada naszym potrzebom.

Poniższa tabela może nam pomóc.

Co do czego?
PRINCE2®	Agile PM®
·         znana specyfikacja	·         produkt może zostać dookreślony w trakcie projektu
·         termin realizacji może zostać przekroczony	·         termin realizacji nieprzekraczalny
·         budżet może zostać przekroczony	·         budżet nieprzekraczalny
·         obniżenie jakości jest dopuszczalne	·         jakość nie może zostać obniżona
·         projekty od prostych do wielkich	·         ograniczona liczba uczestników maksymalnie 85 osób

 

Jeżeli technologia wytworzenia produktu jest znana, a na dodatek dokładnie wiemy jak ten produkt ma wyglądać/jakie cechy posiadać, to wtedy lepszym wyborem wydaje się podejście tradycyjne, czyli PRINCE2®.  Mógłby on być również dobrym wyborem jeżeli nie mamy do czynienia z przedsięwzięciem, którego data ukończenia jest ograniczona przez czynniki zewnętrzne, tak jak np. ogłoszona publicznie data realizacji EURO 2012 w Polsce.
Z drugiej strony, jeżeli wymagania mogą być określone na początku projektu tylko w zarysie, a potem doprecyzowane przez wytworzeniem produktu, to dobrym rozwiązaniem wydaje się agile. Kiedy termin projektu jest nieprzekraczalny, a budżet nie może zostać powiększony to dzięki redukowaniu wymagań i koncentracji na tych, które są najważniejsze, możemy zmieścić się w ograniczeniach.

Jak połączyć PRINCE2® i Agile PM®

Agile wydaje się ostatnio panaceum na problemy związane ze stosowaniem sformalizowanych metod w tym PRINCE2®.

Okazuje się jednak, że możemy nie tylko stosować te metody zamiennie. Porównanie obu metod pozwala wyciągnąć wniosek, że agile nie jest tylko alternatywą dla PRINCE2®, a może stać się on dobrym jego uzupełnieniem. Właśnie w możliwości łączenia obu metodyk upatruje się dużych korzyści, co stoi w sprzeczności z koncepcją „jedno, albo drugie”.

Niektóre z elementów konstrukcyjnych są do siebie podobne i można je z powodzeniem łączyć.

5 porad, jak sprawnie połączyć PRINCE2®® z Agile PM (na podstawie „Agile Project Management: Running PRINCE2™ projects with DSDM™ Atern™”)

1. PRINCE2® opisuje sposób zarządzania projektem, nie definiując jednak w jaki sposób produkty specjalistyczne będą wytwarzane, a Agile PM dobrze sobie z tym radzi, więc połączenie obu metod da większą kontrolę nad zarządzaniem projektem, pozwalając jednocześnie na dostarczenie produktów w zdefiniowanym wcześniej czasie i koszcie,

2. PRINCE2® opisuje role w projekcie, jednak najniżej opisaną rolą w strukturze jest Kierownik Zespołu. Zakłada się, że sposób zdefiniowania struktury zespołu jest odpowiedzialnością dostawcy. W Agile PM definiujemy role związane z wytworzeniem produktów specjalistycznych zarówno po stronie biznesu, jak i dostawcy, więc w tym obszarze mamy kolejną korzyść,

3. Procesy obu z metodyk uzupełniają się nawzajem, a Agile PM definiuje również to, co dzieje się pod procesem Zarządzanie Dostarczaniem Produktów w PRINCE2®,

4. Techniki wymieniane w podręczniku PRINCE2® mogą zostać uzupełnione o te zdefiniowane w Agile PM, które odzwierciedlają filozofię agile takie jak warsztaty, priorytetyzacja, modelowanie, oraz timeboxing,

5. Produkty definiowane w PRINCE2® to wyłącznie produkty zarządcze, a produkty specjalistyczne nie są definiowane w standardzie, jednak i tutaj z pomocą przychodzi Agile PM definiując produkty z perspektywy biznesu, zarządzania i technicznej.

 

Wiele organizacji dzięki temu połączeniu nie musi porzucać wdrożonego w organizacji PRINCE2®, by nagle stosować modny ostatnio agile. Te organizacje mogą nadal stosować wdrożony PRINCE2® dodając dodatkowo DSDM Atern, by uzyskać korzyści wynikając ze stosowania agile takie jak dostarczanie produktów w nieprzekraczalnym budżecie, jakości i czasie, co w dzisiejszych konkurencyjnych czasach może być bardzo ważne.

Licencja: skills®

Korzyścią ze stosowania PRINCE2® z kolei będzie to, że metoda zarządzania projektem będzie zrozumiała nie tylko dla osób zaangażowanych w wytworzenie produktów, ale również decydentów, którzy w organizacji decydują o inwestycjach w zarządzanie projektami.

Bibliografia:

Agile Project Management Handbook Version 1.1 TSO 2012

PRINCE2™ – Skuteczne zarządzanie projektami,  TSO 2010

Agile Project Management: Running PRINCE2™ projects with DSDM™ Atern™, TSO 2007

 

Uznanie znaków towarowych:

PRINCE2® jest zarejestrowanym znakiem handlowym Kancelarii Premiera Wielkiej Brytanii – UK Cabinet Office.
Agile Project Management™  jest znakiem handlowym APM Group Limited.

 Artykuł został opublikowany w Computerworld w 2013 roku 

Szkolenia listopad 2024

pon.poniedziałek	wt.wtorek	śr.środa	czw.czwartek	pt.piątek
2828 października 2024	2929 października 2024	3030 października 2024	3131 października 2024	11 listopada 2024●(1 wydarzenie) Dzień wolny: WSZYSTKICH ŚWIĘTYCH Close Dzień wolny: WSZYSTKICH ŚWIĘTYCH Dzień wolny 1 listopada 2024 iCal Kalendarz Google
44 listopada 2024	55 listopada 2024	66 listopada 2024	77 listopada 2024	88 listopada 2024
1111 listopada 2024●(1 wydarzenie) Dzień wolny: ŚWIĘTO NIEPODLEGŁOŚCI Close Dzień wolny: ŚWIĘTO NIEPODLEGŁOŚCI Dzień wolny 11 listopada 2024 iCal Kalendarz Google	1212 listopada 2024	1313 listopada 2024	1414 listopada 2024	1515 listopada 2024
1818 listopada 2024	1919 listopada 2024	2020 listopada 2024	2121 listopada 2024	2222 listopada 2024
2525 listopada 2024	2626 listopada 2024	2727 listopada 2024	2828 listopada 2024	2929 listopada 2024

Jak zwinnie i tradycyjnie zarządzać ryzykiem

Ryzyko

Ryzyko i zarządzanie nim jest opisywane w wielu książkach. Jedną z nich jest standard zatwierdzony przez Rząd Wielkiej Brytanii czyli Management of Risk (w skrócie M_o_R®).

Podręcznik opisuje zarządzanie ryzykiem z punktu widzenia całej organizacji identyfikując cztery perspektywy:

1. Strategiczną – dotyczącą ryzyk dotyczących „być albo nie być organizacji” czyli jej długookresowego przetrwania
2. Programu – biorącą pod uwagę zdarzenia mogące mieć wpływ na wprowadzanie zmian w organizacji w dłuższej perspektywie
3. Projektu – dotycząca realizacji przedsięwzięć w krótkiej perspektywie
4. Operacyjna – mająca na celu zapewnienie ciągłości funkcjonowania organizacji, oraz jej bieżącego funkcjonowania.

W tym artykule zajmiemy się ryzykiem w perspektywie projektu, analizując na czym polega różnica pomiędzy tradycyjnym, a zwinnym zarządzaniem ryzykiem.

Tradycyjne zarządzanie ryzykiem w projekcie omówimy na podstawie PRINCE2®.

Zarządzanie ryzykiem w PRINCE2®

PRINCE2® to metodyka i standard zarządzania projektami stworzony w Wielkiej Brytanii, oraz rozwijany od 1975 roku. Metoda jest własnością AXELOS.

Licencja: skills®

Elementy konstrukcyjne PRINCE2® to:

1. procesy – działania opisujące zarządzanie projektem,
2. tematy – obszary, którymi trzeba się w projekcie zająć,
3. pryncypia – zasady, których trzeba przestrzegać zarządzając projektem,
4. sposób dopasowania PRINCE2® do konkretnego projektu i jego otoczenia.

Jednym z tematów jest Ryzyko, które opisuje jak należy ryzykiem w projekcie zarządzać.

Standard definiuje ryzyko jako zdarzenie lub zdarzenia, które mogą mieć wpływ na realizację naszych celów. Cele te różnią się w zależności o której perspektywie mówimy.

Na dodatek sama definicja ryzyka nie mówi jaki ten wpływ na cele ma być:

• Jeśli jest on negatywny ryzyko takie nazywamy zagrożeniem,
• Jeśli jest on pozytywny wtedy ryzyko takie nazywamy szansą lub okazją.

Oznacza to, że ryzyko może być również czymś pozytywnym czymś co może nam również pomóc w osiągnięciu celów. A to oznacza, że zamiast się ryzyka wystrzegać możemy również go aktywnie poszukiwać. To wymaga jednak zmiany nastawienia i postrzegania ryzyka.

Nie jest to bez sensu, jeśli weźmiemy pod uwagę fakt, że niektóre części organizacji takie jak „marketing” i „sprzedaż” odpowiedzialne są za wyszukiwanie w otoczeniu organizacji właśnie okazji i szans. Chociaż nie nazywamy tego zarządzaniem ryzykiem to właśnie o to chodzi.

Zarządzanie ryzykiem polega na:

1. Identyfikowaniu – czyli nazwaniu i opisaniu ryzyka w taki sposób, by było tak samo rozumiane przez osoby, które tego ryzyka dotyczą,
2. Ocenianiu – określeniu jak istotne jest dla nas dane ryzyko, by można było dobrać w dalszym kroku odpowiednie reakcje,
3. Planowaniu – czyli dobraniu odpowiednich reakcji,
4. Wdrożeniu – określeniu, kto te reakcje wdroży i zrealizowaniu ich tak by wpłynąć na zidentyfikowane ryzyko.

Działania te realizowane są w sekwencji, jednak powinny być powtarzane cyklicznie. Kolejnym działaniem, które realizowane jest w trakcie ww. kroków jest komunikacja. Polega ona na  informowaniu odpowiednich osób o stanie ryzyka lub skuteczności podjętych działań. Co ma zwłaszcza znaczenie, jeśli to ryzyko wpływa na cele innych np. ryzyko projektu może wpływać na cele strategiczne organizacji.

Takie przykłady jak niezamknięcie dachu nad Stadionem Narodowym w trakcie meczu Polska – Anglia podczas opadów deszczu pokazują nam, że te kroki mają znaczenie, a brak komunikacji może być bardzo bolesny dla wizerunku organizacji (nawet kraju), który ryzykiem nieumiejętnie zarządza.

Identyfikacja

Pierwszym i kluczowym krokiem na drodze do zarządzania ryzykiem jest Identyfikacja ryzyka. Jest ona o tyle istotna, że bez odpowiedniego zauważenia ryzyk (nie tylko zagrożeń, ale też okazji) nie można odpowiednio nim zarządzać.

Jest bardzo istotne by identyfikując ryzyko odpowiednio je nazwać. Czasami zamiast ryzyka (czyli zdarzenia, które może wystąpić) wymieniamy jego skutek np. mówimy, że ryzykiem jest przekroczenie budżetu. Problem z tak zidentyfikowanym ryzykiem polega na tym, że nie można na nie właściwie zareagować, bo jak można zareagować na przekroczenie budżetu, skoro może je spowodować dziesiątki różnych zdarzeń. Mogą to być np. awaria urządzenia lub wzrost kosztów jednostkowych.  Na każde z tych zdarzeń będziemy reagować inaczej, więc mówiąc o ryzyku musimy właśnie dotrzeć do nich. Jeszcze lepiej byłoby dotrzeć do przyczyn samego zdarzenia, bo dzięki temu będziemy mogli określić na ile prawdopodobne wystąpienia takiego ryzyka jest.

Staramy się więc dojść do takiego ciągu „przyczyna – zdarzenie(ryzyko) – skutek” by być w stanie ocenić ryzyko i odpowiednio na nie zareagować. Na przykład: „ponieważ dachu nad Stadionem Narodowym nie można zamknąć kiedy pada deszcz – to jeśli zacznie padać deszcz przy otwartym dachu – nie będziemy mogli go zamknąć i będziemy musieli przerwać mecz”.

Nie należy w tym kroku zapominać również o szansach/okazjach do zidentyfikowania np. „ponieważ robimy wiele zakupów – jeśli uzyskamy rabat od dostawcy – to obniżymy budżet tego projektu”. To czy będziemy chcieli takie okazje identyfikować i nimi zarządzać zależy jednak w dużej mierze od tego czy system wynagrodzeń w organizacji premiuje nas za to by zarządzać okazjami czy raczej każe nas za brak zarządzania zagrożeniami. Moje obserwacje pokazują jednak, że zarządzanie okazjami jest w mniejszym stopniu premiowane i częściej się o nim zapomina.

Ocena

Kolejnym krokiem jest ocena ryzyka w trakcie której ocenia się trzy parametry:

• Prawdopodobieństwo – jak możliwe jest wystąpienie ryzyka,
• Wpływ – czyli skutki wystąpienie ryzyka np. na czas, koszt, zakres,
• Bliskość – określająca kiedy danego ryzyka możemy się spodziewać.

Wszystkie te cechy są ważne, ponieważ dopiero razem pokazują, jak istotne jest dane ryzyko. Na przykład moglibyśmy powiedzieć, że ryzyko awarii samolotu w trakcie jego lotu jest bardzo istotne. Jednak kiedy spojrzymy na prawdopodobieństwo zobaczymy, że nie jest wysokie (samoloty sprawdza się przed wylotem), chociaż wpływ takiej awarii w locie byłby dla nas tragiczny. W przypadku awarii samochodu w trakcie jazdy prawdopodobieństwo jest już większe (zależy od wieku samochodu, marki i jego stanu technicznego), jednak wpływ będzie mniejszy jeśli możemy się zatrzymać. Czyli te dwa parametry razem, prawdopodobieństwo i wpływ – pokazują istotność. Dodatkowy parametr bliskości pokazuje, kiedy się ryzyka możemy się spodziewać, a kiedy nie ma ono już dla nas znaczenia, bo nie może się zmaterializować np. ryzyko spóźnienia się na pociąg kiedy już w tym pociągu siedzimy.

Ocena może jeszcze oceniać łączny wpływ wszystkich ryzyk na dany projekt, co może nam pomóc w oszacowaniu budżetu ryzyka.

Planowanie

Planowanie ryzyka polega na określeniu odpowiednich reakcji na zidentyfikowane ryzyka (zarówno zagrożenia jak i szanse).

Z zagrożeniami możemy sobie poradzić za pomocą następujących reakcji:

• Unikać – jeżeli ich wpływ byłby zbyt duży do zaakceptowania możemy wyeliminować elementy powodujące ryzyko,
• Redukować – zmniejszając prawdopodobieństwo wystąpienia danego ryzyka lub jego wpływ,
• Przenieść zarządzanie ryzykiem na stronę trzecią np. wykupując polisę ubezpieczeniową w ramach której ubezpieczyciel zobowiązuje się do zarządzania ryzykiem w zamian za składkę,
• Akceptować – jeżeli nic z ryzykiem nie możemy zrobić np. wybuch 3 wojny światowej lub ryzyko nie jest warte reakcji np. kupowanie 2-giego pendrive’a na wypadek, gdyby właśnie kupiony nie zadziałał,
• Współdzielić – na przykład realizując przedsięwzięcie z innym sponsorem współdzielimy ryzyka, które go dotyczą,
• Przygotować plan rezerwowy – czyli plan, który zrealizujemy tylko i wyłącznie wtedy jeśli ryzyko się zmaterializuje. Na taki plan będziemy musieli zarezerwować czas i pieniądze (nazywane budżetem ryzyka). Jeśli ryzyko się nie zmaterializuje plan nie zostanie wykorzystany.

Reakcje dotyczące szans to:

• Wykorzystanie – polegające na wykorzystaniu okazji np. jeśli istnieje okazja, że dostaniemy rabat po prostu o niego prosimy,
• Wzmocnienie, które nie tylko wykorzystuje szansę, ale również wzmacnia ją i tak np. dzięki uzyskanemu rabatowi możemy oddać pieniądze na inne inwestycje, osiągając dodatkowe korzyści,
• Współdzielenie – współfinansując przedsięwzięcie współdzielimy również okazje związane z nim czyli np. korzyści, które możemy uzyskać,
• Odrzucenie – reakcja budząca największe kontrowersje jednak najbardziej popularna, bo stosujemy ją na co dzień. Każdy z nas ma szansę wygrania w grach losowych, ale tylko część z nas wykorzystuje ją, podczas gdy reszta tą okazję odrzuca.

Po określeniu reakcji trzeba jeszcze określić kto te reakcje wdroży, ale tym zajmujemy się w kolejnym kroku.

Wdrożenie

Wdrożenie polega na określeniu odpowiedzialności za wdrożenie wybranych reakcji, przy czym możemy tutaj wyróżnić 2 role:

1. Właściciela ryzyka – tego kto ryzykiem zarządza.
2. Wykonawcy reakcji na ryzyko – tego kto realizuje uzgodnione działania.

Możemy więc ustalić, że Kierownik Projektu będzie konkretnym ryzykiem zarządzał czyli np. monitorować jego prawdopodobieństwo, a kiedy ryzyko się zmaterializuje zleci wcześniej określone osobie wykonanie reakcji.

W tym kroku chodzi również o monitorowanie skuteczności działań i podejmowanie innych reakcji jeśli zastosowane nie przyniosły skutku.

Komunikacja

Oznacza, że wcześniej zidentyfikowanym interesariuszom przekazujemy informacje nt. ryzyk, ich stanu, oraz podjętych działań.

Tak opisany cykl w podejściu tradycyjnym do zarządzania projektami ma na celu „zapanowanie nad ryzykiem” i sprawienie by poziom ryzyka był dla projektu akceptowalny.

Licencja: skills®

Teraz spojrzymy jak wygląda zarządzanie ryzykiem w podejściu zwinnym do zarządzania projektem.

Zarządzanie ryzykiem w Agile PM

Termin agile bierze się od Manifestu Agile (Manifest Zwinnego Wytwarzania Oprogramowania), który został podpisany w 2001 roku przez przedstawicieli metodyk zwinnych takich jak: programowanie ekstremalne, scrum, Dynamic Systems Development Method, Adaptive Software Development, Crystal Clear, Feature Driven Development, Pragmatic Programming.

Niektóre z metod nie odnoszą się do zarządzania ryzykiem, dlatego spojrzymy na tą, która mówi o nim w największym stopniu czyli Dynamic Systems Development Method (w skrócie DSDM).

Podzbiór DSDM Atern opisujący projekt z perspektywy Kierownika Projektu został zebrany w podręcznik „Agile Project Management version 1.1.” Agile PM. Agile PM jest własnością Agile Business Consortium.

Jednym z opisanych w podręczniku obszarów na które zwinne zarządzanie projektem ma wpływ książka wymienia Zarządzanie ryzykiem.

Ta część podręcznika zaczyna od zaznaczenia, że niektóre przyczyny ryzyk wynikające z tradycyjnego zarządzania projektem mają mniejszy wpływ na projekt zwinny tzn.:

• „Biznes” nie wie czego dokładnie chce – w podejściu zwinnym zakładamy, że do rozwiązania dochodzimy przyrostowo, więc to nie stanowi wielkiego zagrożenia,
• „Biznes” zmienia zdanie – ponieważ wymagania definiujemy w trakcie projektu to też nie będzie mieć negatywnego wpływu,
• Nie posiadanie w 100% zatwierdzonego rozwiązania – w projekcje zwinnym posiadanie takiego rozwiązania dopiero wprowadziłoby ryzyko ponieważ nie moglibyśmy zarządzać wymaganiami w celu zrealizowania projektu we wcześniej zdefiniowanym czasie i koszcie,
• Brak akceptacji dla produktu końcowego – współpraca z klientem zakłada ciągłe określanie wymagań i akceptowanie ich częściowego spełnienia, więc zatwierdzenie produktu końcowego jest również łatwiejsze,
• Późne dostarczenie produktu – w podejściu zwinnym zakładamy, że to co jest nieprzekraczalne to czas i koszt, a zarządzanie polega na odpowiednim redukowaniem wymagań.

Z drugiej jednak strony identyfikuje się 4 konkretne ryzyka i określa reakcje, które pozwalają nimi zarządzać:

• Brak dostępności biznesu w trakcie projektu – bez zaangażowania biznesu określenie wymagań nie będzie możliwe, więc oczekuje się, że dostępność biznesu zostanie zagwarantowana na początku projektu poprzez spisanie wewnętrznej umowy,
• Posiadanie jednoznacznie określonej specyfikacji wymagań na początku projektu – uniemożliwia redukowanie wymagań, a tym samym nie pozwalają zarządzać projektem tak by budżet i czas nie zostały przekroczone. W tym przypadku sugeruje się omówienie podstaw podejścia zwinnego z biznesem.
• Oczekiwanie 100% rozwiązania powoduje, że tak jak w podejściu tradycyjnym musimy dostarczyć wszystkie wymagania co zwiększa prawdopodobieństwo przekroczenia czasu i budżetu, więc niweczy korzyści wynikające z podejścia zwinnego. Należy to również omówić z biznesem na początku projektu.
• Zmienianie składu osobowego w trakcie projektu doprowadzi do tego, że w zespole od 5 do 9 osób cześć uzgodnień nie będzie pamiętanych przez zespół, który będzie tracił wiedzę na temat wymagań.

Wydaje się, że książka wymienia najważniejsze ryzyka. Trzeba wziąć jednak pod uwagę, że nie dostajemy przepisu na radzenie sobie z pozostałymi ryzykami, które nie zostały wymienione. Zaskakujące jest również to, że pomimo tego, że na samym początku pojawia się definicja ryzyka to nie obejmuje ona szans/okazji mówiąc tylko o zagrożeniach. Co zaskakuje o tyle, że właśnie od podejścia zwinnego spodziewany się wykorzystywania okazji.

Licencja: skills®Licencja: skills®

Podsumowanie

Właściwe zarządzanie ryzykiem jest kluczem do skutecznego zarządzania projektem. To dzięki niemu będziemy w stanie przewidzieć zagrożenia i wykorzystać okazje, ułatwiając realizację projektu. Nie może to być jednak obszar niedodefiniowany, ani spontaniczny, bo będziemy mieli do czynienia z „gaszeniem pożarów”, które wynika właśnie z braku zarządzania ryzykiem.

Literatura w podejściu tradycyjnym jak i zwinnym opisuje zarządzanie ryzykiem, więc możemy skorzystać z gotowych sugestii. Pewnie nie zdziwi nas jednak fakt, że w podejściu tradycyjnym ok. 20 lat starszym przepis jest bardziej dopracowany.

Bibliografia:

Agile Project Management Handbook Version 1.1 TSO 2012 Agile PM

PRINCE2™ – Skuteczne zarządzanie projektami,  TSO 2010 PRINCE2®

Zarządzanie Ryzykiem: Przewodnik dla praktyków, TSO 2007

Uznanie znaków towarowych:

PRINCE2® i M_o_R® są zarejestrowanymi znakami handlowymi Axelos.
Agile PM  jest znakiem handlowym APM Group Limited.

Artykuł został opublikowany w Computerworld w 2014 roku

Szkolenia listopad 2024

pon.poniedziałek	wt.wtorek	śr.środa	czw.czwartek	pt.piątek
2828 października 2024	2929 października 2024	3030 października 2024	3131 października 2024	11 listopada 2024●(1 wydarzenie) Dzień wolny: WSZYSTKICH ŚWIĘTYCH Close Dzień wolny: WSZYSTKICH ŚWIĘTYCH Dzień wolny 1 listopada 2024 iCal Kalendarz Google
44 listopada 2024	55 listopada 2024	66 listopada 2024	77 listopada 2024	88 listopada 2024
1111 listopada 2024●(1 wydarzenie) Dzień wolny: ŚWIĘTO NIEPODLEGŁOŚCI Close Dzień wolny: ŚWIĘTO NIEPODLEGŁOŚCI Dzień wolny 11 listopada 2024 iCal Kalendarz Google	1212 listopada 2024	1313 listopada 2024	1414 listopada 2024	1515 listopada 2024
1818 listopada 2024	1919 listopada 2024	2020 listopada 2024	2121 listopada 2024	2222 listopada 2024
2525 listopada 2024	2626 listopada 2024	2727 listopada 2024	2828 listopada 2024	2929 listopada 2024

Projekt czy program – oto jest pytanie?

Projekt

Projekt zgodnie z definicjami to wg.:

• PRINCE2®: „tymczasowa organizacja powołana w celu wytworzenia jednego lub większej liczby produktów biznesowych, zgodnie z uzgodnionym Uzasadnieniem Biznesowym”
• PMBOK®Guide: „tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego, produktu lub rezultatu”

Obie definicje podkreślają, że celem projektu jest wytworzenie produktu. Trudno byłoby oceniać sukces projektu tylko na podstawie tego, czy produkt powstał, bo większość projektów ostatecznie produkt tworzy. Gdy robi to po czasie i przekraczając budżet  – trudno to jednak nazwać sukcesem.

Z tego względu dodatkowo ważne jest, żeby produkt został wytworzony w uzgodnionym wcześniej czasie, oraz w ramach uzgodnionego budżetu. Cele te (zakres/produkt, czas, koszt) łącznie nazywamy w literaturze (PMBOK®Guide) – trójkątem projektu. Sama nazwa i koncepcja może trochę zaciemniać o co tak naprawdę chodzi w projekcie, więc spróbujemy to wyjaśnić.

Inwestor (nazywany Sponsorem lub Przewodniczącym) inwestuje swoje pieniądze, by wytworzyć jakiś produkt np. dom i oczekuje, że zostanie to zrobione w terminie na który się umówił z budującym, za pieniądze jakie na ten produkt przeznaczył i w ramach uzgodnionych prac.

Tutaj pojawia się jeszcze dodatkowy element jakim są uzgodnione kryteria jakościowe (potocznie nazywane jakością). Zakres prac mówi o tym jakie prace należy wykonać np. pomalować ściany, ale o tym jakim kolorem mówią już kryteria jakościowe, których spełnienie jest dodatkowym celem projektu.

Dla inwestora/Sponsora/Przewodniczącego jest jednak jeszcze jeden znacznie ważniejszy cel jakim są korzyści. Bez korzyści (finansowych lub pozafinansowych) realizacja projektu i inwestowanie w niego pieniędzy nie miałoby dla niego sensu. Korzyści rzadko w całości są osiągane w trakcie projektu, bo większość pojawia się po jego zakończeniu, ale to nie oznacza, że nie należy ich cały czas analizować, żeby wiedzieć czy realizacja inwestycji nadal ma sens.

Kolejnym celem projektu (wg. PRINCE2®) jest odpowiedni poziom ryzyka i wcale nie oznacza to najniższego poziomu ryzyka. Niektórzy inwestorzy akceptują wysoki poziom ryzyka wiedząc, że wiąże się z nim adekwatnie większy poziom korzyści, a co za tym idzie, większy zwrot z inwestycji. Oznacza to, że inwestor oczekuje, że poziom ryzyka będzie taki, jaki on chce – co w przypadku niektórych organizacji (np. banki inwestycyjne), oznacza poziom odpowiednio wysoki.

Podsumowując – kiedy chcemy wytworzyć produkt, w określonym czasie, budżecie, spełniając kryteria jakościowe, przy zdefiniowanym poziomie ryzyka, oraz uzyskać większość korzyści – wybierzmy zarządzanie projektem. Jeden ze standardów zarządzania projektami: PRINCE2®, PMBOK®Guide lub agile’owy DSDM Atern – może nam w tym zdecydowanie pomóc.

Program

Podręcznik MSP® (Managing Succesful Programmes w wersji polskiej Skuteczne Zarządzanie Programami) określa program jako:

„tymczasową, elastyczną organizację stworzoną do koordynowania, zarządzania strategicznego i nadzorowania wdrożenia zbioru powiązanych projektów i działań, celem uzyskania rezultatów i korzyści związanych ze strategicznymi celami organizacji.”

Wygląda na to, że program to po prostu zbiór projektów, którymi zarządzamy razem. Dodatkowo, w odróżnieniu od portfela projektów w którym projekty mogą być powiązane tylko wspólnym budżetem,  projekty w programie mają jeszcze cel strategiczny, który je wiąże ze sobą. Przykładowo, celem programu może być np. zdobycie 10% udziału w rynku w ciągu najbliższych 3 lat. Podczas, gdy portfel projektów może być tylko powiązany budżetem organizacji z którego jest finansowany.

Wśród najbardziej rozpoznawalnych programów można podać: program lotów kosmicznych Challenger lub Apollo, reformy w sektorze publicznym np. reforma emerytalna, lub restrukturyzacje i fuzje w sektorze prywatnym. Do programów zalicza się również Sektorowe Programy Operacyjne (np. SPO RZL) inwestujące środku unijne w projekty wpisujące się w cele programu.

Jednak wytwarzaniem produktów zajmują się samodzielnie projekty, więc czym zajmują się zarządzający programem?

Sama definicja programu mówi (jeszcze oprócz projektów) o działaniach, które po wytworzeniu produktów powodują przekazanie ich do użytkowania, oraz spowodowanie, żeby przyniosły one spodziewane korzyści w programie i po jego zakończeniu.

Jeżeli chcemy jednak nie tylko wytworzyć produkty, ale chcemy również, żeby docelowo organizacja, (której jesteśmy właścicielem lub zarządzającym) działała i wyglądała inaczej to samo zarządzanie projektem nie wystarczy. To, że produkt został wytworzony przez projekt nie oznacza, że będzie użytkowany w organizacji i że jego stosowanie spowoduje zmiany w zachowaniu pracowników. Do tego potrzebujemy bardziej skomplikowanej metody, czyli zarządzania programem.

Ogólnie mówiąc, zarządzanie programem oznacza powodowanie, żeby zmiana w organizacji się powiodła i do tego wykorzystuje się szereg elementów (na podstawie MSP®):

• Pryncypia – określające zasady, które trzeba uwzględnić by zwiększyć szansę powodzenia programu,
• Przebieg transformacji – opisujący procesy służące do zarządzania programem,
• Tematy Ładu – które opisują obszary zarządzania programem, którymi trzeba się zająć.

Wśród tych najbardziej odzwierciedlających istotę zarządzania programem znajduje się np. Temat Wizja. Rolą tego tematu jest opisanie przyszłości jako pocztówki z przyszłości. Chodzi o zwięzłe a jednocześnie przekonywujące przekazanie obrazu przyszłości tym w program zaangażowanym tak, by czuli się do jego realizacji zmotywowani i wspierali go. Zresztą zarządzanie programem nie oznacza tylko brania pod uwagę tylko tych w niego zaangażowanych.

Kolejny temat Przywództwo i angażowanie interesariuszy zajmuje się określeniem, na kogo program wpływa, kto może wpływać na program, oraz kto może się postrzegać za takiego na kogo program wpływa, czyli zidentyfikowaniem interesariuszy.  Na przykład w przypadku reformy emerytalnej byłyby to Ministerstwo Pracy i Polityki Społecznej, ZUS i OFE, ale przede wszystkim jednak sami ubezpieczeni. Temat Przywództwo i angażowanie interesariuszy określa interesariuszy, a następnie określa strategię angażowania ich tak, by cały program chcieli wspierać i byli przekonani do korzyści z niego wynikających dzięki odpowiedniej komunikacji.

Dodatkowo ważnym aspektem tego tematu jest również przywództwo, które jest w szczególności istotne w przypadku, gdy organizacja jest prowadzona w niepewną przyszłość. Osoby zaangażowane w program czułyby się znacznie bardziej pewne wiedząc, że ich losy zawodowe, oraz przyszłość organizacji jest w dobrych rękach, więc osoby zarządzające programem muszą się wykazać umiejętnością pociągania za sobą innych.

Dodatkowo temat Koncepcja i dochodzenie do Modelu Docelowego pozwala w dosyć szczegółowy sposób opisać jak będzie konkretnie organizacja wyglądała w przyszłości, oraz zdefiniować w jakich krokach do tego stanu dojdziemy.

Nie bez znaczenia w programie są również takie tematy jak:

• Organizacja – definiująca strukturę organizacyjną programu,
• Zarządzanie Realizacją Korzyści – pozwalającą na zarządzanie korzyściami,
• Planowanie i kontrola – opisujący sposób planowania i sterowania realizacją programu,
• Uzasadnienie Biznesowe – pozwalające określić korzyści i koszty programu jako mechanizm monitorowania jego zasadności,
• Zarządzanie ryzykiem i rozwiązywanie problemów – którego nazwa sama się tłumaczy,
• Zarządzanie jakością – które koncentruje się na jakości procesów zarządzania.

Jednak pojawiają się one również w podobnej postaci w zarządzaniu projektem, więc są w pewnym sensie Kierownikom Projektów znane.

Podsumowanie

Może się wydawać, że projekt od programu różni się wielkością i czasem realizacji. To z pewnością jest prawdą, ale istotną różnicą jest również to co chcemy za pomocą tych przedsięwzięć osiągnąć. W jednym przypadku jest to wytworzony produkty, a w drugim zmiana w organizacji, która jest trwała i w długiej perspektywie przyniesienie korzyści (finansowe i pozafinansowe). W związku z tym i sposób zarządzania jest inny. Pokrótce mówiąc zarządzający projektem myślą o tym, co jeszcze należy wytworzyć, a zarządzający programem o tym, z kim trzeba porozmawiać i kogo jeszcze do zmian przekonać.

PRINCE®, PRINCE2®, M_o_R®, P3O®, MSP® są zarejestrowanymi znakami handlowymi AXELOS Limited

PMI, CAPM®, PMP®, PMBOK® są zarejestrowanymi znakami handlowymi Project Management Institute

Artykuł został opublikowany w Magazynie Zarządzanie Projektami w 2013 roku