Przyjrzyjmy się tradycyjnym projektom (porównanie PRINCE2 oraz AgilePM)

Przyjrzyjmy się tradycyjnym projektom (porównanie PRINCE2 oraz AgilePM)

W dzisiejszym artykule porównamy dwa podejścia w zarządzaniu projektami – tradycyjne (sekwencyjno-kaskadowe) i zwinne. Przyjrzymy się konkretnym aspektom zarządzania w oparciu o dwie dobrze znane, przeciwstawne metodyki.

Różnice pomiędzy podejściem zwinnym a tradycyjnym można rozpatrywać w kilku kategoriach począwszy od kultury pracy, a skończywszy na sposobach planowania i szacowania. Przyjrzymy się bliżej metodyce PRINCE2, dziś przez niektórych nazywaną „tradycyjną” oraz metodyce AgilePM, postrzeganej jako „zwinna”. Oba podejścia dobrze reprezentują swoje kategorie m.in. dlatego, że:

  • są niezależne od domeny projektowej – są stosowane zarówno w projektach IT jak i innych,
  • są pełnoprawnymi metodykami (posiadają definicję projektu, zestaw ról i idące z nimi uprawnienia i zobowiązania, pełną dokumentację projektową)
  • mają za sobą długi okres rozwoju (PRINCE2 około 20+ lat, AgilePM również około 20+)

PRINCE2

PRINCE2 jest przykładem podejścia sekwencyjno-kaskadowego, którego obecnym właścicielem jest AXELOS Ltd – nowo powstała spółka, która przejęła prawo własności od brytyjskiego OGC w 2013 roku.

W metodyce PRINCE2 wyróżniamy 6 aspektów efektywności/kontroli projektu. Innymi słowy 6 zmiennych, które musimy nieustannie kontrolować w celu utrzymania projektu na kursie (w granicach tolerancji według PRINCE2). Należą do nich:

  • zakres (zakres prac projektowych),
  • koszty (podzielone na 3 budżety: budżet projektu, budżet zmiany, budżet ryzyka/zarządzania ryzykiem),
  • terminy (terminy projektu, terminy etapów, terminy Grupy Zadań),
  • jakość (cechy, właściwości, wymagania funkcjonalne produktów: funkcjonalność, waga, kolor etc.),
  • ryzyko (zarządzanie ryzykiem w postaci zabezpieczania się przed zagrożeniami a zwiększaniem szans),
  • korzyści (oczekiwane korzyści wynikające z użytkowania dostarczonych produktów).

Każdy z powyższych 6 aspektów wymaga określenia ich wartości w postaci mierzalnej (liczb, procentów, dat etc.) już na początku projektu. Jest to naturalne, oczekiwane, spodziewane i całkowicie uzasadnione podejście w PRINCE2. Skoro planujemy projekt na najbliższe kilka lat czy miesięcy, musimy ustalić pewne „zasady gry”, w obrębie których będziemy się poruszać.

AgilePM

Metodyka AgilePM (autorstwa konsorcjum DSDM) jest przykładem podejścia „zwinnego”, a konkretnie podejścia iteracyjno-przyrostowo-adaptacyjnego (więcej na ten temat w dalszej części artykułu).

AgilePM wyróżnia 7 aspektów zarządzania projektem (dział 20.2 z oficjalnego podręcznika AgilePM), jednak nie wymaga (również nie oczekuje z uwagi na jej elastyczność) ich precyzyjnego określenia przed rozpoczęciem projektu, jak ma to miejsce w PRINCE2.

Oznacza to, że mamy do czynienia ze „zwinną” i zarazem „pełną” metodyką projektową, która w przeciwieństwie do np. Scruma bierze pod uwagę  wszystkie parametry projektowe (posiada dedykowane dokumenty/produkty zarządcze do kontroli). Choć ścisła kontrola nie jest zjawiskiem naturalnym w projektach zwinnych, to należy podkreślić fakt, że AgilePM jest metodą a nie metodyką. Nie jest po prostu zestawem dobrych praktyk, narzędziem czy techniką, ale pełną metodą, która łączy w sobie zarządzanie projektami z dostarczaniem produktów. Stąd też AgilePM, jako jedna z niewielu dostępnych na rynku metod, jest kategoryzowana jako metoda hybrydowa. Występują w niej elementy kontroli i nadzoru – charakterystyczne dla metodyk procesowych takich jak PRINCE2, ale również elementy organizacji zespołów i wytwarzania produktów – pobrane z framework’a Scrum.

Jeżeli chodzi o kwestię kontroli parametrów projektowych, zarządzanie nimi jest inne w porównaniu ze stylem tradycyjnym (więcej na ten temat w dalszej części artykułu).

AgilePM wyróżnia 7 aspektów zarządzania projektem:

  • cechy (funkcjonalności produktu, zakres prac projektowych),
  • koszty (jeden budżet),
  • zasoby (dodatkowy parametr, który w PRINCE2 kryje się pod kosztami, tutaj wyróżniamy zasoby, które są niezbędne i trudne do zastąpienia – mowa tutaj przede wszystkim o zdolnościach i ludziach – eksperci, specjaliści etc.),
  • czas (terminy projektu, terminy przyrostów, terminy Timeboxów (według polskiego tłumaczenia Okienek Czasu)),
  • jakość (cechy, właściwości, wymagania funkcjonalne produktów jak również jakość procesu prowadzenia projektu i dojrzałości AgilePM w organizacji),
  • ryzyko (zarządzanie ryzykiem w postaci zabezpieczania się przed zagrożeniami a zwiększaniem szans),
  • korzyści biznesowe (oczekiwane korzyści wynikające z użytkowania dostarczonych produktów).

Z powyższego wynika, że AgilePM nie pomija żadnych parametrów projektowych, które są obecne w klasycznym modelu PRINCE, jednak promuje inne podejście przy zarządzaniu nimi. Podobnie jak w PRINCE2 każdy z elementów wymaga odpowiedniej kontroli, jednak nie jest wymagane precyzyjne oszacowanie wszystkich parametrów. Dzieje się tak dlatego, że projekty AgilePM (czy też ogólnie Agile) charakteryzują się krótkim horyzontem dokładnego planowania, który często mieści się w zakresie od tygodnia (dla przykładu inna zwinna metodyka SAFe, autorstwa Deana Leffingwella posiada taki krótki okres dostarczania produktów i planowania) do około max 6 tygodni (AgilePM zaleca max okres 6 tyg., aby zapobiec min. „syndromowi studenta”; dla Scruma jest to 30 dni). Dzięki krótkim okresom planowania pracy, po których biznes otrzyma pierwsze wyniki, szacowanie wymienionych wcześniej 7 aspektów jest bardziej celne – nawet w oparciu o doświadczenie czy intuicję (mowa o tzw. „Cone of Uncertainty”). Zasada jest prosta – mamy oszacować najbliższe kilka tygodni a nie wiele miesięcy – krótszy okres szacowania skutkuje bardziej efektywnym oraz celnym szacowaniem.

Kolejna różnica polega na tym, że projekt AgilePM jest kierowany tzw. Wizją przedstawiającą ogólne cele, które ma osiągnąć projekt (produkt zarządczy, którego właścicielem jest tzw. Wizjoner Biznesu). To Wizja przedstawia ogólne oczekiwania i potrzeby klienta, które będziemy precyzować w ramach rozwoju projektu.

Przyjrzymy się temu jak obie metodyki interpretują parametry zakresu oraz czasu (które wliczając koszty są krytyczne w większości projektów) i jak nimi zarządzają.

Cechy / Zakres / Funkcjonalności

Zakres: co wchodzi w skład projektu, co mamy wykonać, co mamy dostarczyć.
Innymi słowy zakres to całkowita suma produktów.

Podejście tradycyjne

Tradycyjne podejście sprawdza się bardzo dobrze w przypadku projektów mających małe prawdopodobieństwo zmiany wymagań (zakresu) w trakcie trwania projektu. Innymi słowy w tym podejściu bazujemy na złożeniu, że klient „wie czego chce” już na samym początku projektu (Etap Inicjowania PRINCE2 – produkt zarządczy Opis Produktu Końcowego Projektu) i potrafi to wyrazić w czytelnych, jednoznacznych, ścisłych, mierzalnych wymaganiach (znane jako „kryteria akceptacji” w PRINCE2).

Zakładamy również, że wymagania klienta są tożsame z potrzebami klienta. Jest to naturalne założenie w projektach tradycyjnych, wymagania = potrzeby. Nie ma w tym ani niczego złego, ani dobrego, to po prostu charakterystyka projektów tradycyjnych, które mają kontrolowane/sterowane podejście do zmian. Każda zmiana musi być formalnie kontrolowana zgodnie z obowiązującą w PRINCE2 procedurą sterowania zagadnieniami i zmianami (do tego dochodzi również zestaw dokumentacji i dodatkowych ról: Strategia Zarządzania Konfiguracją, Rejestr Zagadnień, Obsługa Zmian etc.). To podejście sprawdza się dobrze w przypadkach kiedy klient zna i rozumie swoje potrzeby oraz gdy te potrzeby nie zmienią się znacząco podczas trwania projektu – co jednak nie zawsze jest możliwe do osiągnięcia.

Podsumowując:

PRINCE2 prezentuje tzw. „formalny model zmiany”. Zmiany są kontrolowane, sterowanie i zarządzane, gdyż wychodzimy z założenia, że potrafimy stosunkowo dobrze zaplanować/przewidzieć przebieg projektu tak, aby zmian było jak najmniej już podczas jego realizacji. Jeśli proces realizacji projektu PRINCE2 przebiegał z małą ilością zmian – daje to sygnał (KPI) o dobrze zaplanowanym projekcie PRINCE2.

Dzieje się tak dlatego, że projekt PRINCE2 charakteryzuje paradygmat procesu oraz BDUF (big design up front). Im mniej zmian w procesie prowadzenia projektu od czasu jego rozpoczęcia – tym plany oraz pierwotna specyfikacja były bardziej dokładnie określone. W PRINCE2 zakładamy, że jest to możliwe  do spełnienia – „klient wie czego chce”. Jednak coraz częściej widzimy, że są 3 rzeczy, których możemy być pewni w naszym życiu: „podatki, zmiany i śmierć„, co na świat projektowy przekłada się na „budżet, zmiana i zamknięcie projektu (pozytywne czy też przedwczesne)”.

Podejście Agile

W podejściu/mentalności Agile zakładamy, że klienci naturalnie nie wiedzą czego chcą i jako dostawcy musimy zrozumieć ich prawdziwe potrzeby, kwestionując przedstawione nam pierwotne wymagania już na samym początku projektu (i również nieustannie podczas trwania całego projektu). Naszym zadaniem jest dogłębna analiza funkcji, jakie ma realizować końcowy produkty, wykraczając poza jego cechy i właściwości.

“PEOPLE DON’T KNOW WHAT THEY WANT UNTIL YOU SHOW IT TO THEM” STEVE JOBS [1955 – 2011]

Oznacza to nieustanne zadawanie pytań – Dlaczego coś jest potrzebne? Czy jest to niezbędne? Czy możemy wykonać to inaczej? Dlatego też każde nowe przedstawione wymaganie w metodyce AgilePM ma najniższy z możliwych priorytetów – Won’t, który oznacza, że nie będzie ono realizowane. Dopiero po dogłębnej analizie (ale nie takiej która trwa wiele tygodni czy miesięcy) podejmowana jest wspólna (biznes i dostawca) decyzja czy rzeczywiście ta nowa funkcjonalność umożliwi uzyskanie większej wartości. Nieustannie analizujemy przez cały czas trwania projektu nowo zebrane wymagania (a w szczególności pod koniec Przyrostów/Sprintów, gdzie prezentujemy kolejną część dostarczonego produktu). Pierwotne wymagania określone przy starcie projektu mogą ulec zmianie między innymi na podstawie wyciągniętych wniosków z faktycznego wglądu w dostarczenie produktu (zamiast slajdowiska PowerPoint, dashobardów, KPI, EWI etc.) To zjawisko nazywane adaptacyjnością jest dostosowywaniem się do nowych wymagań klienta, czy też adaptowaniem się projektu do zmieniających się warunków i priorytetów biznesowych.

Oznacza to, że w podejściu Agile zbieranie wymagań jest ciągłą, nieustanną czynnością będącą integralną częścią cyklu projektu. W Agile mówimy o współpracy dwóch stron – klienta i dostawcy w procesie deklarowania i rozwoju wymagań, a precyzowanie wymagań polega przede wszystkim na wyciąganiu wniosków z wizualnych modeli, interaktywnych prototypów czy innej formy interaktywnej współpracy (warsztaty facylitowane, brainstorming etc.). Ten model promuje podejście partner-partner niż klasyczne klient-dostawca (nawet jeśli mówimy o odrębnych podmiotach prawnych).

“CLIENTS DON’T KNOW WHAT THEY WANT UNTIL THEY SEE IT …AND THAT’S NOT IT” KSIĄŻKA “ADRENALINE JUNKIES AND TEMPLATE ZOMBIES

Podsumowując:

AgilePM prezentuje tzw. „lekki model zmiany”. Zmiany są nieuniknione, promowane, rekomendowane, zalecane (ang. embrace the change), gdyż wychodzimy z założenia, że nie potrafimy wszystkiego przewidzieć ani określić konkretnych wymagań przy starcie projektu, a jedynie ogólną Wizję. Wraz z rozwojem projektu wizja będzie się klarować jako coraz bardziej czytelne i mierzalne wymagania.

Dzieje się tak dlatego, że projekt AgilePM charakteryzuje paradygmat adaptacyjny (zmiana) oraz EDUF (enought design up front). Zmiana jest nieunikniona i niezbędna, aby móc dostarczyć wartość, która jest ponad korzyściami. Wartość jest subiektywna i zależna od odbiorcy, tak więc w celu  zrozumienia prawdziwych potrzeb klienta i dostarczenia wartości zmiany będą niezbędne.

PRINCE2
(właściciel AXELOS Ltd)
AgilePM
(właściciel konsorcjum DSDM)
 rodzajmetodykametoda
 typsekwencyjno-kaskadowoiteracyjno-przyrostowo-adaptacyjna
 stylmiejscami nakazowacałkowicie rekomendacyjna
 kierowanaplanemzmianą
 paradygmatprocesowyadaptacyjny (zmiana)
 szczegółowe wymaganiaokreślone z góry (BDUF)odkrywane w trackie (EDUF)
 podejście do zmianyzmiana jest kontrolowanazmiana jest nieunikniona, zalecana
 model zmiany„formalny”„lekki”

Case study

W ramach pracy nad projektem, jako Project Manager i Team Leder byłem odpowiedzialny za zaprojektowanie architektury i użyteczności aplikacji mobilnej. Jej docelową platformą był system Android (Jelly Bean) oraz iOS (6+) w formatach komórka oraz tablet.

Projekt był prowadzony w modelu Agile (bez narzuconej metodyki) i jedynymi wymaganiami, które otrzymaliśmy była lista 23 niesprecyzowanych punktów funkcjonalności. Jest to klasyczne i całkowicie naturalne w projektach Agile. W celu sprecyzowanie wizji oraz potrzeb klienta, pierwsze „wewnętrzne prototypy” zostały wytworzone odręcznie w ramach pracy kartka + ołówek + iPhone Stencil Kit (http://www.uistencils.com/collections/frontpage/products/iphone-stencil-kit) + A4 iPhone Template. Kolejna iteracja prototypów – „zewnętrzne prototypy” powstały już w narzędziu FluidUI (https://www.fluidui.com/), dzięki któremu klient mógł zobaczyć w bardzo wczesnej fazie projektu jak może wyglądać końcowa wersja aplikacji.

Podczas interaktywnej rozmowy klient-dostawca przez Skype klient mógł „na żywo” umieszczać komentarze na stworzonym prototypie, co weliminowało problem z błędną interpretacją tekstowej dokumentacji wymagań.

Zanim rozpoczęły się prace (co może być zaskakujące) pierwotna lista wymagań zmalała do 21 (podczas prezentacji prototypu). Klient zrozumiał, że cześć pierwotnie oczekiwanych funkcjonalności dostarcza oczywiście korzyści, ale znikomą wartość. Kilka funkcjonalności najprawdopodobniej nie byłoby używanych z uwagi na ich małą wartość. Dzięki temu ryzyko dostarczania tzw. „fat-software”, gdzie z większości przerośniętych funkcjonalności oprogramowania faktycznie używa się 20 – 40% z nich … a płaci się, za pełen zestaw zamówionych, zostało zmniejszone.

Podsumowanie:

W tym przypadku podejście Agile nie było narzucone, równie dobrze moglibyśmy wybrać podejście PRINCE2 czy jakiekolwiek inne. Jednak z uwagi na brak sprecyzowanych i konkretnych wymagań przy rozpoczęciu projektu, po wstępnej rozmowie z klientem wspólnie zdecydowaliśmy się na podejście iteracyjne (rozwijaliśmy w iteracjach produkt od prototypu do finalnej aplikacji) i adaptacyjne (po każdej iteracji precyzowaliśmy wymagania), co jest typowe dla projektów Agile.

Terminy / Czas / Harmonogram

Terminy: daty w jakich realizowany jest projekt.

Podejście tradycyjne

W mojej skromnej karierze, w większości projektów, z którymi miałem przyjemność pracować czas był elementem krytycznym, często wręcz głównym czynnikiem oceniającym sukces projektu.

W PRINCE2 zakres czasowy projektu określany jest już na samym początku projektu. W procesie Inicjowanie Projektu (IP) powstaje produkt zarządczy o nazwie Plan Projektu, który swym zakresem obejmuje cały projekt – czy to kilka miesięcy czy też wiele lat. Oznacza to, że w tym podejściu polegamy na założeniach i przewidywaniach. Plany nie ulegną znaczącym zmianom m.in. pod kątem terminów/dat. Zakładamy, że obecne informacje, które mamy do dyspozycji i które wykorzystamy do planowania są prawdziwe i aktualne, co pozwoli nam na celne oszacowanie terminów (oczywiście w granicach dozwolonych odchyleń/tolerancji – +/- kilka dni/tygodni). Innymi słowy, mamy z grubsza zaplanowany cały projekt – od początku do końca w postaci ogólnego harmonogramu, bez wchodzenia w szczegóły. Ta cecha PRINCE2 nazywana jest kaskadowością, ponieważ planujemy ile Etapów wystąpi w projekcie, które będą następować jeden po drugim i do których zgodnie z metodyką PRINCE2 już nie wrócimy – raz wytworzone, sprawdzone i odebrane produkty traktowane są jako zakończone, a wszystkie zakończone produkty Etapu w skrócie pozwalają na zakończenie Etapu.

Z kolei każdy kolejny Etap wchodzący w skład Planu Projektu nie jest szacowany dogłębnie, gdyż planowanie czynności, które mają wydarzyć się np. za dwa lata, nie miałoby najmniejszego sensu. Jednak najbliższy (kolejny) Etap jest zawsze szczegółowo planowany przed jego rozpoczęciem – tą cechę PRINCE2 nazywamy sekwencyjnością, gdyż zestaw czynności związanych z planowaniem Etapu powtarzamy dla każdego Etapu osobno (uwzględniając aktualne informacje, ryzyka, zagadnienia etc.).

W ramach Etapu planowane są Grupy Zadań (zlecenia prac dla podwykonawców – Kierowników Zespołów) oraz Plany Zespołów (opcjonalne, opisujące bardzo szczegółowo pracę zespołów), które wspólnie są najniższym i najdokładniejszym poziomem planów.

Oznacza to, że projekt PRINCE2 jest całościowo planowany w modelu kaskadowym, a cyklicznie, przed startem kolejnego Etapu, sekwencyjnie planujemy kolejny Etap – zgodnie z cyklem prezentowanym w metodyce PRINCE2: Planuj -> Deleguj -> Monitoruj -> Kontroluj, który jest niczym innym jak cyklem Deminga dostosowanym do potrzeb metodyki PRINCE2.

Podsumowując:

PRINCE2 prezentuje podejście sterowne planem (ang. plan-driven). Plany są szczegółowe i swym zakresem obejmują często wielomiesięczne zakresy (metodyka nie definiuje zakresu czasowego określającego długość etapów – jednak w praktyce są to często okresy wielomiesięczne). Jeśli przypatrzymy się modelowi polskich przetargów, które w sposobie prowadzenia mocno odzwierciedlają myślenie PRINCE2 lub czasem wręcz jawnie oczekują od dostawcy stosowania się do tej metodyki – to całościowy zakres czasu na cały projekt jest już z góry ustalony i narzucony przez klienta, czy też Unię Europejską w przypadku dofinansowanych projektów. Jest to typowa charakterystyka w projektach sterowanych planem. (an. plan-driven)

Dzieje się tak dlatego, że projekt PRINCE2 charakteryzuje wcześniej wspomniany paradygmat procesu, z którego wynika stworzenie Planu Projektu.

Case study

W ramach innego projektu, w którym miałem przyjemność uczestniczyć, za zadanie otrzymaliśmy dostarczenie systemu CMSa opartego o platformę Liferay CE (obecnie w Polsce wdrożona m.in. w Uniwersytecie Jagiellońskim). Syl zarządzania nie był narzucony z góry, jednak z uwagi na charakterystykę publicznych przetargów dofinansowanych z Unii, projekt opatrzony był stosunkowo dużą ilością formalizmów i dokumentacji technicznej opisującej decyzje architektoniczno-technologiczne.

Jak każdy dofinansowany projekt, ten również miał narzucone z góry, nieprzekraczalne terminy i niestety zamknięty budżet zmiany ustalony na bagatela … 0zł. W takim narzuconym odgórnie modelu, bez jakiejkolwiek elastyczności, wybór podejścia zwinnego mija się z celem. Projekt formalnie nie posiada absolutnie żadnej elastyczności w 6/7 aspektach efektywności. Jedynie w zależności od podejścia dostawcy i jego otwartości zmiany mogą być wprowadzone lub nie – jednak nie mogą obejmować żadnych kosztów (co prawda w praktyce są na to rozwiązania mniej lub bardziej formalne). Naturalnie wybraliśmy model PRINCE2, który był wspierany początkowo przez zestaw niezależnych dokumentów: word, excel etc. a z biegiem czasu wspieraliśmy się oprogramowaniem P2Ware w wersji 5.

Podsumowanie:

W tym przypadku podejście PRINCE2 nie było narzucone, ale brak formalnej elastyczności (ustalonego, nie zerowego budżetu zmian) przekreślił stosowanie podejścia zwinnego. Do tego dochodzą kwestie dokumentacyjne, które w przypadku PRINCE2 i jego kontroli projektu stanowią idealne potwierdzenie dla organu finansującego projekt (Unia), że projekt jest pod kontrolą. Dodatkowo mamy na to dowody w postaci zatwierdzonych dokumentów projektowych.

Podejście Agile

W podejściu Agile promowane jest planowanie „najpóźniej jak to tylko możliwe”. Plany są odkładane do momentu, kiedy jest to niezbędne. Plany nie są wyrocznią i absolutną ścieżką, której musimy się bezwzględnie trzymać. W porównaniu do metodyk tradycyjnych plany ulegają stosunkowo częstym zmianom z uwagi na dynamizm rozwoju projektu zwinnego. Comiesięczne przyrostowe dostarczanie produktów kończy się retrospektywą – wyciągnięciem wniosków z ostatnio wykonanej pracy i zaplanowaniem następnego, krótkiego – kilkutygodniowego okresu czasu – zwanego w metodyce AgilePM Okienkiem Czasu (według oficjalnego tłumaczenia, ang. Timebox).

Innymi słowy, plany w Agile naturalnie podlegają większej dekompozycji. Są krótsze w horyzoncie planowania, co skutkuje większą ilością krótszych etapów zarządczych. W trakcie planowania uczestniczy nie tylko sam Kierownik Projektu, lecz również Lider Zespołu wraz z zespołem, któremu przewodzi (w metodyce AgilePM zespoły nazywane są Zespołami Budowy Rozwiązania, ang. Solution Development Team). W samym zespole znajduje się dedykowany dla niego, przedstawiciel biznesu – tzw. Ambasador Biznesu. Oznacza to, że podczas planowania zaangażowanie jest trójstronne:

  • biznes (Ambasador Biznesu),
  • zarządzanie (Kierownik Projektu),
  • wytwórstwo/dostarczanie produktów (Kierownik Zespołu wraz z zespołem).

W przypadku kiedy projekt angażuje kilka Zespołów Budowy Rozwiązania, prace mogą być wykonywane równolegle. Dwa Okienka Czasu są wykonywane równocześnie przez niezależne zespoły. Podczas końcowego okresu czasu danych Okienek Czasu prace są synchronizowane i konsolidowane w celu dostarczenia działającego produktu/prototypu, który jest wynikiem pracy kilku/kilkunastu zespołów.

Podsumowując:

AgilePM prezentuje podejście sterowane zmianą (ang. change-driven). Zmiany są nieuniknione, promowane, rekomendowane, zalecane (ang. embrace the change), co skutkuje również tym, że plany podlegają częstym aktualizacjom. Natomiast z uwagi na to, że planujemy najpóźniej jak się da, nie ma potrzeby cyklicznego aktualizowania dokumentacji w celu wprowadzania najnowszych informacji planistycznych. Jako, że planujemy na bardzo krótkie okresy czasu (2 do 6 tyg., max), prawdopodobieństwo dużych zmian wpływających zasadniczo na projekt jest zminimalizowane, co zwiększa stabilność i efektywność pracy zespołów.

PRINCE2
(właściciel AXELOS Ltd)
AgilePM
(właściciel konsorcjum DSDM)
 rodzajmetodykametoda
 typsekwencyjno-kaskadowoiteracyjno-przyrostowo-adaptacyjna
 stylmiejscami nakazowacałkowicie rekomendacyjna
 kierowanaplanemzmianą
 paradygmatprocesowyadaptacyjny (zmiana)
 szczegółowe wymaganiaokreślone z góry (BDUF)odkrywane w trakcie (EDUF)
 podejście do zmianyzmiana jest kontrolowanazmiana jest nieunikniona, zalecana
 model zmiany„formalny”„lekki”
 projektsterowny planem (plan-driven)sterowny zmianą (change-driven)
 horyzont planowaniaczęsto wielomiesięczny2 do 6 tyg.
 planujeKierownik Projektu dla Projektu i Etapu
Kierownik Projektu dla Grupy Zadań
Kierownik Zespołu dla Planu Zespołu
(strony: zarządzanie + wytwarzanie)
Kierownik Projektu, Kierownik Zespołu (wraz Ambasadorem Biznesu), Zespół
(strony: biznes + zarządzanie + wytwarzanie)
 zatwierdza planyKierownik Projektu, Kierownik Zespołu (wraz Ambasadorem Biznesu), Zespół
(strony: biznes + zarządzanie + wytwarzanie)
Kierownik Projektu, Ambasador Biznesu wraz z Zespołem
(strony: biznes + zarządzanie + wytwarzanie)

Informacje dodatkowe

Na koniec warto wspomnieć o bardzo ciekawym porównaniu, które przeprowadził Ludwig Deconinck (trener AgilePM i PRINCE2). Skonfrontował on pryncypia PRINCE2 z pryncypiami AgilePM. Według jego porównania (z którym również się zgodzę) wszystko jest zależne od ludzi i ich nastawiania do pracy – mentalności. Całość podsumował stwierdzeniem „It’s all about the mindset”, które celnie podsumowuje istotę różnić w obu podejściach:

Źródło: http://www.beprojectized.be/downloads.php?name=projectmanagementprinciples.pdf&id=12