Jedną z technik oferowanych przez PRINCE2 jest tzw. planowanie oparte na produktach (product based planning). Wyobraźmy sobie projekt uruchomienia schroniska młodzieżowego. W projekcie trzeba przede wszystkim wyremontować budynek po dawnej szkole podstawowej i wstawić wyposażenie. Przy podejściu opartym na produktach pierwszym krokiem powinno być zdefiniowanie tego, co chcemy uzyskać na końcu, czyli mówiąc fachowo końcowego produktu.
W naszym przykładzie po krótkiej analizie okazało się, że nie wystarczy dokonać remontu szkoły, trzeba jeszcze uzyskać szereg pozwoleń, zatrudnić personel, uruchomić funkcjonowanie schroniska, no i w końcu spowodować, aby przyszli do nas turyści. Bo to, jak się okazało po rozmowie z inwestorem (czyli sponsorem projektu), jest dla niego głównym celem. Projekt ma pozwolić zarobić pieniądze. I nagle w toku kolejnych rozmów i analiz zakres zaczął nam się rozrastać. Zatem produktem końcowym jest funkcjonujące schroniska, zrealizowana akcja promocyjna i postawiona witryna internetowa z interesującymi treściami.
PRINCE2 proponuje tutaj zastosować prostą technikę zwaną planowaniem opartym na produktach, w której rezultacie powstaje tzw. diagram następstwa produktów. W omawianym projekcie mógłby wyglądać następująco:
Na diagramie następstwa produktów prostokątami oznacza się produkty projektu (dobrą praktyką jest pisać o nich w trybie dokonany, np. zakupiona choinka, a nie choinka), kółkami produkty, które są dostępne niezależnie od projektu, a strzałkami zależności między produktami, czyli co trzeba wykonać po czym.
Jak widać, aby możliwe było otwarcie schroniska potrzeba innych produktów, niż aby zakończyć cały projekt. Z drugiej strony nie ma sensu robić większości rzeczy dopóki nie uzyska się pozwolenia na budowę.
Diagram następstwa produktów ma kilka zadań:
- Pokazuje ogólną logikę i zakres projektu – już wiemy, że pewnych rzeczy nie ma co zaczynać od razu i że projekt to nie tylko prace budowlane. Widzimy też zależności z innymi projektami oraz zasobami organizacji, w omawianym przykładzie jest to kupiony teren.
- Komunikuje owa logikę i zakres interesariuszom projektu – dużo łatwiej rozmawia się z kadrą zarządzającą za pomocą przejrzystego diagramu niż długiej wypunktowanej listy. Ów diagram może zostać użyty również do pokazania zależności między projektami i elementami ich zakresów. Przykładowo przydaje się, gdy planujemy większą zmianę strategiczną, czyli program. Czasem też zarząd rzuci ogólne hasło typu „wdróżmy CRM”, które dopiero musi zostać rozbite na główne produkty i zależności między nimi, aby okazało się, że mamy do czynienia nie z jednym projektem, a pięcioma powiązanymi ze sobą.
- Pozwala na zaplanowanie zakresu i przygotowanie tzw. wbs (struktury podziału prac) – o tym napisano w następnym rozdziale. Warto tylko przytoczyć rozróżnienie między produktem a zadaniem: zadanie to wysiłek poświęcony w czasie, aby dostarczyć produkt, produkt zaś to coś, co powstaje w efekcie realizacji jednego lub więcej zadań, coś namacalnego. Poziom komitetu sterującego to decyzje o produktach, a nie o zadaniach, zaś zadania powinny być omawiane niżej – na poziomie kierownika projektu, kierownika zespołu, czy też poszczególnych wykonawców.
