Porównanie metodyki tradycyjnej PRINCE2 z metodą hybrydową 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ących z nimi uprawnieniami i zobowiązaniami, pełną dokumentacją projektową)
• mają za sobą długi okres rozwoju (PRINCE2, około 20+ lat, AgilePM również około 20+)

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

Metodyka AgilePM (autorstwa konsorcjum DSDM) jest przykładem podejścia „hybrydowego”, 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 z uzwinnioną metodą tradycyjnego zarządzania projekrami i zarazem „pełną” metodyką projektową, która kontroluje wszystkie znane z tradycyjnych metod zarządzania, parametry projektowe (posiada dedykowane dokumenty/produkty zarządcze do kontroli).

A teraz trochę teorii z sali wykładowej.. 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 (zakres prac projektowych, funkcjonalności),
• koszty (1 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, arrr ;/)),
• 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 PRINCE2, 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 planowania, który często mieści się w zakresie od nawet kilku dni do max miesiąca. Metoda AgilePM zaleca max okres 6 tyg., aby zapobiec min. „syndromowi studenta”). 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, analogię czy intuicję. Zasada jest prosta – mamy oszacować i zaplanować najbliższe kilka tygodni a nie wiele miesięcy pracy – krótszy okres szacowania skutkuje sprawniejszym i celniejszym 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ą.

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

Tradycyjne podejście sprawdza się bardzo dobrze w przypadku projektów mających małe prawdopodobieństwo zmiany wymagań (zakresu) w trakcie trwania projektu. A każdy praktyk w branży IT wie, że nie tędy droga… Innymi słowy w podejściu tradycyjnym bazujemy na złożeniu/hipotezie, ż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). Ufff spore wymagania, dla kogoś kto chciałby otworzyć przed nami swój portfel 🙂

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.

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

W podejściu/mentalności AgilePM (nie mylić z 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 szczegółowej analizie 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łą 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.).

“Clients don’t know what they want until they see it… and that’s not it”
Książka “Adrenaline Junkies and Template Zombies

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 (enough 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.

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.

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.

W podejściu AgilePM 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 AgilePM 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 (Lider 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.

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.