Deliverable, po polsku produkt dostarczalny, to konkretny i mierzalny wynik pracy projektowej, który zespół wytwarza i przekazuje klientowi lub sponsorowi zgodnie z uzgodnionymi kryteriami jakości i terminem. Może mieć charakter materialny lub niematerialny, ale zawsze daje namacalny dowód wykonanej pracy i służy do weryfikacji postępu projektu. Sam produkt to jeszcze nie wszystko. Dopiero powiązanie go z celami biznesowymi zmienia listę ukończonych zadań w mierzalne rezultaty biznesowe.

Rodzaje produktów dostarczalnych – podział według odbiorcy

Najczęściej stosowany podział opiera się na tym, kto jest odbiorcą danego produktu. Deliverables zewnętrzne trafiają do klienta lub sponsora i to one zwykle podlegają formalnemu odbiorowi. Deliverables wewnętrzne powstają na potrzeby samego zespołu i wspierają realizację projektu, choć rzadko są przekazywane na zewnątrz.

• Zewnętrzne – gotowe oprogramowanie, raport końcowy, dokumentacja użytkownika, wdrożone środowisko produkcyjne;
• Wewnętrzne – Karta projektu, Specyfikacja Funkcjonalna, plan projektu, prototypy i makiety interfejsów.

W praktyce projekty IT łączą oba typy. Wewnętrzna specyfikacja techniczna prowadzi do zewnętrznego deliverable w postaci działającego Minimum Viable Product (MVP), który przekazujesz do oceny interesariuszom.

Deliverable a milestone – dwie różne rzeczy

Te dwa pojęcia bywają mylone, choć opisują różne rzeczy i uzupełniają się nawzajem. Deliverable to wytworzony produkt lub dokument, czyli konkretna substancja potwierdzająca wykonanie pracy. Milestone to punkt w harmonogramie sygnalizujący osiągnięcie istotnego etapu projektu. Kamień milowy mówi o momencie w czasie, produkt dostarczalny o rzeczywistym efekcie. Osiągnięcie kamienia milowego zwykle zbiega się z przekazaniem jednego lub kilku deliverables, ale samo w sobie nie jest jeszcze wytworem. Szersze omówienie zależności między nimi znajdziesz w opracowaniu Manage Milestone Managing Deliverables – PMI.

Jak powiązać deliverables z mierzalnymi rezultatami biznesowymi

Licząc same ukończone zadania, mierzysz aktywność zespołu, a nie wartość, którą dostaje sponsor. Żeby pokazać realny wpływ projektu, powiąż każdy istotny produkt dostarczalny z konkretnym wskaźnikiem KPI. Wtedy zamiast raportować, że wdrożyliście nowy moduł płatności, raportujesz, o ile skrócił się czas realizacji transakcji i jak zmienił się wskaźnik porzuceń koszyka.

Do typowych wskaźników, z którymi łączysz deliverables, należą:

• wzrost przychodów przypisany nowej funkcji lub produktowi;
• oszczędności kosztów z automatyzacji lub wycofania starego systemu;
• wskaźnik adopcji, czyli odsetek użytkowników korzystających z wdrożonej funkcji;
• poprawa satysfakcji klientów mierzona badaniem lub liczbą zgłoszeń.

Taki układ zmienia rozmowę z zarządem. Sponsor nie dopytuje, ile stron dokumentacji powstało, tylko sprawdza, czy wdrożony deliverable ruszył wskaźnik, na którym mu zależy. Przy tym łatwiej też uzasadnić kolejne inwestycje w projekt.

Deliverables w projektach zwinnych – przyrosty i wczesna weryfikacja

W metodykach zwinnych, na przykład w Scrumie, produkty dostarczalne powstają iteracyjnie. W kolejnych sprintach zespół wytwarza przyrosty produktu, które można przekazać do oceny znacznie wcześniej niż na koniec całego projektu. Dzięki temu interesariusze weryfikują wartość na bieżąco, a Ty korygujesz kierunek prac, zanim koszty zmian urosną. Żeby jasno określić, kiedy przyrost jest gotowy do przekazania, stosuj Definition of Done.

Deliverables w projektach finansowanych ze środków UE

W projektach dofinansowanych z funduszy unijnych, na przykład w programie Horyzont Europa, deliverables mają status formalnego wymogu umownego. Ich terminowe dostarczenie warunkuje wypłatę kolejnych transz finansowania, dlatego opóźnienie lub odrzucenie produktu potrafi wstrzymać cały przepływ środków. W tym kontekście rozróżnienie między deliverable a milestone nabiera dodatkowego znaczenia praktycznego, co szczegółowo opisano w poradniku Deliverables vs Milestones in Horizon Europe – EMDESK.

Dobre praktyki zarządzania deliverables

Każdy produkt dostarczalny powinien mieć jasno zdefiniowane kryteria akceptacji, przypisanego właściciela oraz termin realizacji. Kryteria najlepiej zapisać w formacie SMART, żeby nie dało się ich interpretować na dwa sposoby. Brak któregokolwiek z tych elementów jest główną przyczyną sporów przy odbiorze prac, bo klient i zespół inaczej rozumieją, co miało zostać dostarczone. Do tego dochodzi kilka sprawdzonych zasad:

• powiązanie deliverables ze strukturą podziału prac (WBS), żeby każdy produkt wynikał z zaplanowanego zakresu;
• wersjonowanie artefaktów dla zachowania historii zmian i uniknięcia sporów o obowiązującą wersję;
• formalny proces odbioru zakończony podpisem akceptacyjnym klienta, który jednoznacznie potwierdza przyjęcie prac.

Uporządkowane podejście do produktów dostarczalnych przekłada się na przewidywalność projektu i mniejsze ryzyko konfliktów. Więcej przykładów i szablonów znajdziesz w opracowaniach What Are Project Deliverables? Definition & Examples – Asana oraz What Are Project Deliverables in Project Management? – Atlassian.

FAQ

Czym różni się deliverable od milestone?

Deliverable to wytworzony produkt lub dokument, a milestone to punkt w harmonogramie sygnalizujący osiągnięcie etapu. Kamień milowy zwykle potwierdzasz ukończeniem jednego lub kilku deliverables, ale sam w sobie nie jest wytworem.

Jak sprawdzić, czy deliverable przyniósł efekt biznesowy?

Przypisz produktowi konkretny wskaźnik KPI jeszcze przed rozpoczęciem prac, na przykład wzrost przychodów, oszczędności kosztów albo wskaźnik adopcji. Po przekazaniu deliverable porównujesz wartość wskaźnika z poziomem wyjściowym.

Co powinno zawierać dobre kryterium akceptacji?

Kryterium powinno być konkretne i mierzalne, najlepiej w formacie SMART, z jednoznacznym warunkiem spełnienia. Dopisz właściciela odpowiedzialnego za odbiór oraz termin, do którego produkt ma być gotowy.