Projekt dowieziony. System zawiódł. O czym naprawdę jest Project Delivery Excellence

W wielu organizacjach projekty formalnie posuwają się naprzód. Harmonogram się zgadza, budżet „na ten moment” wygląda bezpiecznie, a statusy świecą się na zielono. Ludzie mniej więcej wiedzą, co, na kiedy i za ile mają dowieźć. Po drodze pojawia się jednak napięcie. Zespół zaczyna pracować dłużej, decyzje się przeciągają, a coraz więcej energii pochłania „utrzymywanie kontroli” zamiast dostarczania wartości. Projekt ostatecznie zostaje zamknięty – a sukces? Sukces jest na slajdzie, czasem nawet w systemie. W samej organizacji jednak, jego koszt ujawnia się dopiero później.

---

PDE nie pyta, czy projekt się udał. Pyta, czy organizacja potrafi dowozić projekty w sposób powtarzalny, przewidywalny i niewymagający bohaterstwa. Bez gaszenia pożarów i liczenia nadgodzin. Bez udawania, że wszystko jest w porządku. 

Wszystko gotowe… tylko po co?

Kick‑off wygląda jak setki innych. Zakres ustalony, timeline rozrysowany, narzędzia przygotowane. W pewnym momencie ktoś zadaje pytanie, które rzadko pojawia się w agendzie: „A po co właściwie robimy ten projekt?” Zapada cisza, a po chwili padają odpowiedzi, które w projektach IT słyszy się od lat: bo biznes chce, bo konkurencja, bo mamy budżet. Projekt rusza dalej, bo formalnie wszystko się zgadza. I to właśnie ten moment, w którym delivery excellence jeszcze się nie zaczęło.

Bez jasno zdefiniowanego celu projekt bardzo szybko zaczyna żyć własnym życiem. Backlog puchnie, bo każdy ticket „ma sens”. Zespół dowozi kolejne elementy, ale coraz trudniej powiedzieć, czy cokolwiek realnie się zmienia – poza rosnącą liczbą zadań oznaczonych jako done.

Ten sam projekt, ale z mierzalnym celem

W jednym z projektów e‑commerce problem wydawał się pozornie prosty: klienci porzucali koszyk. Zamiast zaczynać od długiej listy usprawnień, zespół zatrzymał się na chwilę i nazwał rzecz wprost: chcemy skrócić czas przejścia klienta od koszyka do checkoutu. Dopiero wtedy pojawiły się dane – nie jako KPI do prezentacji, ale jako punkt odniesienia do każdej decyzji backlogowej. Sprawdzono, ile średnio trwa checkout od wejścia do finalizacji płatności, na którym etapie użytkownicy rezygnują i ile kroków faktycznie muszą wykonać, aby dokończyć zakup.

Zespół świadomie skupił się na metrykach pilnujących sensu projektu:

• czasie checkoutu mierzonym end‑to‑end,
• procencie porzuconych koszyków na poszczególnych krokach,
• realnym użyciu funkcjonalności po wdrożeniu.

Jednocześnie przestano ekscytować się tym, co dobrze wygląda w raporcie na SteerCo, ale niewiele mówi o wartości:

• liczbą dostarczonych feature’ów,
• procentem zrealizowanego scope’u,
• liczbą zamkniętych ticketów.

Dzięki temu szybko okazało się, że część zaplanowanych funkcjonalności nie skraca checkoutu ani o sekundę, a inne – wcześniej uznawane za kosmetyczne – eliminują cały krok w procesie. Backlog przestał być listą życzeń. Stał się narzędziem do realizacji celu. I to był pierwszy realny moment, w którym delivery excellence zaczęło się wydarzać.

Zielony status, który nie mówi całej prawdy

Na statusach projekt wciąż wyglądał dobrze. Problem w tym, że plan bardzo rzadko mówi cokolwiek o przyszłości. Dlatego zespół przestał patrzeć wyłącznie na to, ile zadań zamknięto w ostatnim sprincie. Zamiast tego zaczął obserwować, jak zmienia się tempo pracy w czasie. Przez kilka iteracji velocity było „w normie”, ale trend pokazywał stopniowy spadek. Do tego zadania coraz dłużej przechodziły od rozpoczęcia do zakończenia, a część z nich regularnie blokowała się na zależnościach.

Kluczowe stały się:

• trend velocity lub throughput, a nie pojedynczy sprint,
• czas przepływu pracy od start do done,
• liczba i długość blokad.

Te dane nie wywołały paniki – dały coś znacznie cenniejszego: czas na decyzję. Rozmowa zeszła z poziomu „czy damy radę?” na „co zmieniamy: zakres, kolejność czy oczekiwania czasowe?”. Decyzja zapadła, zanim projekt wszedł w tryb gaszenia pożarów.

Ryzyko, które nie zaskakuje

W projektach bez delivery excellence, ryzyka najczęściej „wybuchają nam prosto w twarz”. We wspomnianym projekcie zespół zaczął patrzeć na nie inaczej. Nie interesowało go tylko, co może pójść nie tak, ale także kiedy po raz pierwszy było to widać i jak długo czekano z decyzją. Regularnie wracano do trzech prostych obserwacji:

• ile ryzyk zgłoszono, zanim się zmaterializowały,
• jak długo trwało przejście od pierwszego sygnału do decyzji,
• ile krytycznych tematów pojawiło się dopiero na końcówce.

Zmiana języka z „czy to już problem?” na „jakie mamy scenariusze, jeśli to się wydarzy?” sprawiła, że ryzyka zaczęły być rozpoznawane wcześniej, a rozmowy stały się spokojniejsze. a statusy zrobiły się nudne. 

Jakość oraz niewinne koszty

Presja czasu zrobiła swoje. Najpierw drobne skróty, potem odkładane testy, a na końcu – „poprawimy po wdrożeniu”. Przez chwilę wszystko wyglądało dobrze, aż do momentu, w którym coraz większa część pracy zespołu zaczęła iść na poprawki. Jakość stała się widoczna dopiero wtedy, gdy ktoś zestawił dane z kilku kolejnych release’ów:

• rosły reworki oraz liczba defektów po wdrożeniu,
• wydłużał się czas zamykania błędów krytycznych.

To nie był problem braku staranności. To był efekt tego, że wcześniej jakość nie była mierzona w kontekście delivery. Dopiero od momentu rozpoczęcia jej pomiarów rozmowy o zakresie i terminach zaczęły wyglądać inaczej.

Budżet przez długi czas się zgadzał. Na dalszym etapie wyszło jednak, że coraz większa jego część idzie na poprawki, obejścia i utrzymanie rozwiązań, które miały być „na chwilę”. Koszty nie eksplodowały nagle, lecz narastały po cichu. Zespół przestał patrzeć tylko na burn rate i zaczął pytać: ile kosztują rework, opóźnienia oraz rozwiązania tymczasowe. 

Budżet przestał być liczbą „na dziś” – zaczął mówić coś o przyszłości projektu.

Ludzie i narzędzia

Najbardziej niewygodny moment przyszedł wtedy, gdy ktoś spojrzał na tempo pracy zespołu w dłuższym okresie, np. 3–6 miesięcy. Było nierówne. Sprinty heroiczne przeplatały się z tymi, w których ledwo domykano zakres. Do tego większość decyzji przechodziła przez jedną osobę (oczywiście PM‑a). Zamiast mówić o zaangażowaniu, zespół zaczął patrzeć na:

• stabilność tempa pracy,
• nadgodziny jako trend,
• koncentrację decyzji w jednej roli.

To był sygnał, że projekt jedzie na kredycie energetycznym zespołu. Delivery excellence zaczęło się tam, gdzie uznano ludzi za realne ograniczenie systemu, a nie niewyczerpany zasób.

Narzędzia w tym projekcie się nie zmieniły. Zmienił się sposób ich używania. Dashboard przestał pokazywać tylko zielony status – zaczął pokazywać trendy, zależności i miejsca, w których praca się blokuje. Dane przestały być „do raportu”. Stały się punktem wyjścia do rozmowy. Bo narzędzia same z siebie nie robią delivery excellence. Mogą je jednak skutecznie zabić, jeśli służą tylko do uspokajania sumienia.

To nie projekt zawodzi. To system

Projekty rzadko wykładają się przez jeden błąd. Dzieje się tak dlatego, że system dowożenia przestaje działać: powoli, po cichu, niemal niezauważalnie. Gdy projekt jedzie już tylko dlatego, że ktoś bierze na siebie za dużo, pracuje za długo albo gasi pożary cudzym kosztem, nie mamy do czynienia z delivery excellence. Mamy do czynienia z systemem, który chwilowo działa… bo ludzie podtrzymują go heroicznie na swoich barkach. PDE polega na zbudowaniu takiego sposobu pracy, w którym:

• problemy widać wcześniej,
• decyzje zapadają szybciej, niż narasta chaos,
• jakość i koszty wracają do rozmowy zanim zrobi się drogo,
• projekty nie potrzebują bohaterów, żeby dojechać do końca.

Jak zacząć wprowadzać go w życie? Nie od nowej metodyki. Nie od narzędzi. I na pewno nie od „lepszych ludzi”. Zacznij od kilku prostych przesunięć:

• wybierz jeden cel projektu i trzy metryki, które realnie go opisują,
• rozmawiaj o trendach, nie o kolorach statusów,
• mierz czas reakcji na problemy, nie tylko fakt ich wystąpienia,
• oddziel jakość od nadziei, a ludzi od bohaterstwa.

I najważniejsze, PDE nie polega na tym, że wszystko działa idealnie. Polega na tym, że gdy coś zaczyna się psuć, widzisz to wcześniej i reagujesz ograniczając koszty. To dlatego jedne organizacje dowożą projekty spokojnie, a inne w bólach. Różnica nie leży w ambicjach ale w systemie. Jest jednak dobra wiadomość: system też da się zmienić.