Produkty procesu a produkty końcowe projektu: różnice
Każdy projekt wytwarza dwa rodzaje rezultatów: te, dla których został uruchomiony, i te, których potrzebuje, żeby zarządzać samym sobą. Pierwsze to produkty końcowe, drugie to produkty procesu, a oba są pełnoprawnymi produktami cząstkowymi: weryfikowalnymi, mającymi właściciela i przekazywanymi do odbioru. Różnica leży w funkcji i odbiorcy, a pomylenie tych dwóch typów prowadzi do realnych problemów: klient proszony o zatwierdzanie wewnętrznej dokumentacji albo produkt odebrany przez ludzi, którzy nigdy nie będą z niego korzystać. W tym artykule definiujemy oba typy, porównujemy je obok siebie, pokazujemy, gdzie rozróżnienie ma znaczenie w praktyce, i wyjaśniamy, jak kontrolować oba w jednym systemie.
Najważniejsze wnioski:
- Definicje — produkty procesu to rezultaty tworzone po to, by planować, sterować i dokumentować sam projekt; produkty końcowe to rezultaty, dla których projekt został uruchomiony.
- Przykłady — produkty procesu to m.in. plan projektu, plan bazowy harmonogramu, raporty statusu i rejestr ryzyk; produkty końcowe to system, obiekt, kampania albo wyniki testów odbiorczych.
- Różnice — produkty procesu służą odbiorcom wewnętrznym, jak sponsor i PMO; produkty końcowe trafiają do klienta lub użytkowników i są odbierane względem uzgodnionych kryteriów.
- Typowe błędy — śledzenie wyłącznie produktów końcowych zostawia projekt bez śladu decyzyjnego; nadprodukcja produktów procesu zamienia zarządzanie w raportowanie dla samego raportowania.
- Zarządzanie oboma typami — produkty końcowe potrzebują właścicieli, kryteriów odbioru i statusu widocznego przy harmonogramie; produkty procesu ścieżek akceptacji i raportów generowanych z bieżących danych.
Czym są produkty procesu?
Produkty procesu to rezultaty tworzone po to, by planować, sterować i dokumentować sam projekt: plan projektu, plan bazowy harmonogramu, raporty statusu, rejestr ryzyk, notatki decyzyjne, dokumentacja budżetowa. Bywają nazywane produktami wewnętrznymi, bo ich odbiorcy znajdują się wewnątrz organizacji. Potrzebna jest tu jedna uwaga terminologiczna: pojęciem parasolowym dla wszystkich rezultatów projektu, niezależnie od typu, są produkty cząstkowe, które omawiamy w osobnym przewodniku. W porównaniu opisywanym w tym artykule chodzi o węższą kategorię: stronę zarządczą.
Tym, co czyni te rezultaty pełnoprawnymi produktami, a nie papierologią, jest fakt, że przechodzą ten sam test co wszystko, co projekt przekazuje: każdy jest weryfikowalny, ma właściciela i ma odbiorcę, który go przyjmuje. Plan bazowy zatwierdza sponsor; raport statusu odbiera komitet sterujący. Te rezultaty istnieją po to, by decyzje zapadały na faktach, a projekt, który nie wytwarza żadnego z nich, może wciąż zbudować produkt, tylko nikt nie będzie umiał powiedzieć, na jakiej podstawie był prowadzony.
Korzystaj z pełnego dostępu do FlexiProject przez 30 dni, bez żadnych opłat
Czym są produkty końcowe projektu?
Produkty końcowe to rezultaty, dla których projekt został uruchomiony: system informatyczny, nowa funkcjonalność, obiekt budowlany, kampania marketingowa, program szkoleniowy, wyniki testów odbiorczych potwierdzające, że produkt działa. Bywają nazywane produktami zewnętrznymi, bo opuszczają projekt i trafiają do klienta lub użytkowników końcowych.
Produkty końcowe to powód istnienia budżetu. Są odbierane względem kryteriów uzgodnionych przed rozpoczęciem pracy, zwykle przez klienta, właściciela produktu lub użytkowników, a ich przekazanie zamyka podstawową obietnicę projektu. Projekt może być wzorowy w planach i raportach, ale jeśli produkty końcowe nie przejdą odbioru, żadna dyscyplina zarządcza tego nie uratuje. Dlatego status odbioru wart jest osobnego śledzenia: we FlexiProject przy zadaniu na harmonogramie widać ikonę ze statusem powiązanego produktu, więc różnica między zadaniem wykonanym a produktem odebranym jest widoczna na pierwszy rzut oka.
Produkty procesu a produkty końcowe: porównanie
| Produkty procesu | Produkty końcowe | |
| Cel | Planowanie, sterowanie i dokumentowanie projektu | Dostarczenie rezultatów, dla których projekt uruchomiono |
| Typowi odbiorcy | Sponsor, komitet sterujący, PMO | Klient, właściciel produktu, użytkownicy końcowi |
| Przykłady | Plan projektu, plan bazowy, raporty statusu, rejestr ryzyk | System, funkcjonalność, obiekt, kampania, wyniki testów odbiorczych |
| Odbiór | Zatwierdzenie wewnętrzne, często formalną ścieżką | Odbiór względem kryteriów uzgodnionych z klientem |
| Kiedy powstają | Przez cały projekt, od inicjacji do zamknięcia | Głównie w realizacji, przekazywane na końcach etapów i przy zamknięciu |
Z tabeli wynikają dwie rzeczy. Po pierwsze, oba typy przechodzą ten sam test produktu cząstkowego: weryfikowalność, właściciel, odbiór. Różnica dotyczy funkcji i odbiorcy, nie rangi, a traktowanie produktów procesu jak papierologii drugiej kategorii to sposób, w jaki organizacje tracą ślad decyzyjny. Po drugie, zdrowa proporcja między typami nie jest stała. Regulowany projekt farmaceutyczny zasadnie wytwarza więcej rezultatów zarządczych niż dwuosobowy projekt marketingowy, a proporcja powinna wynikać z profilu ryzyka projektu, nie z uniwersalnego szablonu.
Dlaczego to rozróżnienie ma znaczenie
Różni odbiorcy i różne ścieżki odbioru
Każdy typ podąża inną drogą do odbioru. Produkty procesu są zatwierdzane wewnętrznie: sponsor podpisuje plan bazowy, komitet sterujący odbiera raporty, PMO sprawdza zgodność ze standardami. Ta wewnętrzna droga może być formalna: we FlexiProject plan bazowy i kluczowe dokumenty zatwierdza się ścieżką akceptacji, więc podpis sponsora jest zdarzeniem zapisanym w systemie, a nie ustaleniem z korytarza. Produkty końcowe odbiera klient lub użytkownicy, według kryteriów zapisanych przed rozpoczęciem pracy. Problemy zaczynają się, gdy drogi się mieszają: klient proszony o zatwierdzenie wewnętrznego rejestru ryzyk marnuje czas wszystkich, a produkt ogłoszony jako odebrany przez zespół, który go zbudował, bez podpisu klienta, to spór czekający na fakturę.
Typowe błędy w kontroli obu typów
Pierwszy błąd to śledzenie wyłącznie produktów końcowych. Produkt powstaje, ale nie ma zatwierdzonego planu, planu bazowego ani zapisu decyzji, więc gdy przychodzi audyt, przekazanie odpowiedzialności albo spór, projekt nie ma czym pokazać, jak był prowadzony. Drugi błąd jest odwrotny: nadprodukcja produktów procesu, aż zarządzanie staje się raportowaniem dla samego raportowania, a zespół spędza więcej czasu na dokumentowaniu pracy niż na pracy. Oba błędy mają wspólne źródło, którym jest kopiowanie listy rezultatów z szablonu zamiast wyprowadzenia jej z realnego ryzyka projektu i potrzeb interesariuszy.
Jak te dwa typy nazywa PRINCE2
Rozróżnienie opisane w tym artykule ma w PRINCE2 formalne nazwy: produkty zarządcze dla strony projektowej i produkty specjalistyczne dla strony produktowej, każdy ze swoim opisem i kryteriami jakości. Jeśli Twoja organizacja pracuje w PRINCE2 albo chcesz spojrzeć na ten sam podział od strony metodyk, zobacz nasze porównanie produktów cząstkowych (PMBOK) z produktami projektu (PRINCE2).
Sprawdź wszystkie funkcje FlexiProject, korzystaj 30 dni za darmo!
Jak kontrolować oba typy w jednym systemie
Oba typy potrzebują innej mechaniki, ale powinny żyć w jednym miejscu. We FlexiProject produkty końcowe definiuje się w module Produkty: każdy z opisem, kryteriami odbioru, terminem i właścicielem, powiązany z zadaniami i kamieniami milowymi, które go wytwarzają. Produkty procesu zyskują z innej strony. Cykliczne raporty statusu są generowane z bieżących danych projektu, co zdejmuje z listy ręcznych obowiązków najbardziej czasochłonny rezultat zarządczy, a rejestr ryzyk prowadzony w systemie zamiast w arkuszu jest zawsze aktualny na przegląd, bez zbierania wkładów mailem. Efekt: oba typy mają nazwanych właścicieli i widoczny status, bez równoległego arkusza dla żadnego z nich.
Produkty procesu a produkty końcowe: najczęstsze pytania
Czy raport statusu to produkt procesu, czy produkt końcowy?
Produkt procesu. Dokumentuje stan prac dla odbiorców wewnętrznych i wspiera decyzje sterujące. Częścią produktu końcowego stałby się tylko w rzadkim przypadku, gdy samo raportowanie jest zamówioną usługą.
Czy produkty procesu to to samo co produkty wewnętrzne?
W praktyce pojęcia pokrywają się niemal całkowicie. Ściśle rzecz biorąc, nazwa produkty procesu pochodzi od tego, kiedy powstają, czyli w procesie zarządzania, a produkty wewnętrzne od tego, kto je odbiera. Większość rezultatów kwalifikuje się pod obie nazwy, dlatego etykiety używane są zamiennie.
Kto odbiera każdy z typów?
Produkty procesu są odbierane wewnętrznie: przez sponsora, komitet sterujący lub PMO. Produkty końcowe odbiera klient, właściciel produktu lub użytkownicy końcowi, względem kryteriów uzgodnionych z góry. Rozdzielenie obu ścieżek odbioru zapobiega większości sporów przy przekazaniu.
Czy jeden rezultat może być jednocześnie produktem procesu i produktem końcowym?
Tak. Klasycznym przypadkiem jest dokumentacja użytkownika: powstaje w trakcie projektu jak każdy rezultat zarządczy, ale jest dostarczana razem z produktem i służy użytkownikom końcowym. Rozstrzyga odbiorca końcowy. Jeśli otrzymuje ją klient lub użytkownicy, traktuj ją jak produkt końcowy z kryteriami odbioru.
Produkty procesu i produkty końcowe dzielą rezultaty projektu według funkcji i odbiorcy: jedne istnieją po to, by prowadzić projekt, drugie są tym, dla czego projekt uruchomiono. Oba typy zasługują na pełne traktowanie jak produkty cząstkowe, z właścicielami, weryfikowalnością i zdefiniowaną ścieżką odbioru, bo projekt zaniedbujący którąkolwiek stronę płaci za to: bez produktów procesu nie ma śladu decyzyjnego, a bez odebranych produktów końcowych nie ma rezultatu.
Rozróżnienie jest przy tym praktyczne, a nie akademickie, bo każdy typ podąża inną drogą do odbioru i służy innym odbiorcom. System PPM, który obsługuje obie mechaniki w jednym miejscu, tak jak FlexiProject z modułem Produkty dla produktów końcowych oraz ścieżkami akceptacji i automatycznymi raportami statusu dla produktów procesu, utrzymuje obie strony w polu widzenia bez podwajania pracy administracyjnej.
