Poniedziałek, przegląd statusu w programie wymiany systemu obsługi zamówień. Project manager klienta pokazuje wykres spalania i pyta, dlaczego integracja z magazynem przesunęła się o dwa sprinty. Delivery manager dostawcy odpowiada, że zespół czekał na decyzję w sprawie formatu danych. Analityk klienta mówi, że decyzja zapadła dziesięć dni temu, tylko nikt jej nie przekazał zespołowi dostawcy. Obie strony mają rację i obie mają swój raport statusowy. Raporty się różnią.
Za kwadrans spotkanie się kończy z trzema zadaniami do wykonania i bez odpowiedzi na najważniejsze pytanie: kto w tym projekcie decyduje o terminie i kto odpowiada, gdy termin nie zostanie dotrzymany. Formalnie są dwie osoby z „manager” w tytule. W praktyce odpowiedzialność rozmyła się dokładnie w miejscu, w którym się spotykają.
Ten artykuł jest dla Program Managerów i kierowników projektów, którzy pracują z zewnętrznym zespołem albo właśnie wybierają dostawcę. Broni tezy, z którą wielu dostawców się nie zgodzi: w projekcie z zewnętrznym zespołem rozliczanym za czas pracy odpowiedzialność za wynik projektu zostaje u klienta i nie da się jej kupić razem z delivery managerem. Delivery manager dostawcy jest wartością tylko wtedy, gdy ma własny, wyraźnie oddzielony zakres: obsadę, ciągłość i jakość pracy ludzi dostawcy. Gdy dubluje pracę project managera klienta, staje się narzutem, za który klient płaci dwa razy: w fakturze i w czasie decyzji.
Czym różni się delivery manager od project managera i skąd to zamieszanie?
Project manager to najstarsza i najlepiej opisana z tych ról. Odpowiada za projekt jako całość: cel, zakres, harmonogram, budżet, ryzyka, komunikację z interesariuszami i odbiór. Ma ją w swoim słowniku każda metodyka zarządzania projektami, od PRINCE2 po standardy PMI, i wokół niej zbudowano całą ścieżkę certyfikacji, którą opisaliśmy w artykule o certyfikacie PMP.
Delivery manager jest rolą młodszą i znacznie mniej jednoznaczną. W firmach produktowych i w administracji publicznej oznacza zwykle osobę, która dba o sposób pracy zwinnego zespołu. Brytyjski GOV.UK Service Manual (aktualizacja z 6 listopada 2023 roku) opisuje delivery managera jako kogoś, kto przygotowuje zwinne środowisko pracy zespołu, usuwa przeszkody blokujące postęp i pomaga zespołowi coraz samodzielniej organizować własną pracę. Priorytety, cel usługi i akceptację historyjek ten sam dokument przypisuje osobnej roli product managera.
W firmach usługowych, czyli u dostawców IT, ten sam tytuł oznacza często coś innego: osobę po stronie dostawcy, która odpowiada za relację z klientem i za to, żeby dostawca dotrzymywał tego, co obiecał. Obsada, rotacja, zastępstwa, rozliczenia, jakość pracy konsultantów, eskalacje kontraktowe. Bywa, że ta osoba nazywa się account managerem, service delivery managerem albo engagement managerem. Zakres jest podobny.
Zamieszanie bierze się stąd, że oba znaczenia spotykają się w jednym projekcie. Klient słyszy „delivery manager” i rozumie „ktoś, kto dowiezie projekt”. Dostawca mówi „delivery manager” i ma na myśli „ktoś, kto pilnuje naszej części umowy”. Jeśli nikt tego nie doprecyzuje na początku, każda strona zakłada, że druga trzyma ster.
Dlaczego odpowiedzialności za wynik projektu nie da się przenieść na dostawcę w body leasingu?
Bo odpowiedzialność idzie za prawem do decyzji. W body leasingu specjalista dołącza do zespołu klienta i pracuje według jego procesów i priorytetów. Tak to opisuje każda rzetelna oferta tego modelu, w tym nasza strona body leasingu: pracą specjalisty kieruje klient, a dostawca odpowiada za dobór, umowę, rozliczenia i ciągłość obsady. Skoro klient ustala, co zespół robi w tym tygodniu, to klient odpowiada za to, czy we właściwej kolejności powstaje właściwa rzecz.
Ten sam mechanizm działa w każdym rozliczeniu za czas pracy, także wtedy, gdy dostawca przysyła cały zespół. Dostawca sprzedaje czas i kompetencje, a nie rezultat. Może zobowiązać się do jakości pracy, dostępności i szybkiej wymiany, ale nie do tego, że funkcja będzie gotowa na koniec kwartału, bo nie kontroluje zakresu, priorytetów ani decyzji, od których zależy termin. Jeśli dostawca miałby za termin odpowiadać, musiałby te decyzje przejąć, a wtedy to już nie jest body leasing, tylko projekt o określonym zakresie.
Stąd pierwsza praktyczna konsekwencja. Delivery manager dostawcy, który obiecuje „dowieźć projekt”, obiecuje coś, czego w tym modelu nie może zapewnić. Nie dlatego, że jest słaby, tylko dlatego, że nie ma do tego uprawnień. Może przyspieszyć obsadę, załatwić zastępstwo, poprawić jakość pracy konkretnej osoby. Nie może zdecydować, że integracja z magazynem jest ważniejsza od nowego modułu raportów.
Druga konsekwencja jest mniej oczywista. Klient, który kupuje delivery managera w przekonaniu, że przenosi ryzyko projektu, przestaje inwestować we własnego project managera. Rola po stronie klienta zostaje obsadzona „przy okazji”, przez kogoś, kto ma też inne obowiązki. Wtedy dwie role nie dublują się, tylko obie są niepełne: delivery manager nie ma prawa do decyzji, a osoba po stronie klienta nie ma czasu na ich podejmowanie.
Jeśli chcesz przenieść ryzyko na dostawcę naprawdę, potrzebujesz innego modelu umowy, w którym dostawca dostaje zakres i odpowiada za rezultat. Ma on swoją cenę, o czym piszemy w tekście o tym, kto naprawdę płaci za przeniesienie ryzyka w fixed price. Kupienie dodatkowej roli tego nie zastąpi.
Co mówią Scrum, PRINCE2 i standardy PMI o tym, kto prowadzi projekt?
Warto zajrzeć do źródeł, bo każde z nich rozwiązuje problem inaczej, a zespoły mieszają te podejścia bez świadomości, że ich założenia się wykluczają.
Scrum Guide w wersji z listopada 2020 roku nie zna roli project managera w ogóle. Definiuje trzy odpowiedzialności w zespole Scrum: Developers, Product Owner i Scrum Master. Mówi wprost, że w zespole Scrum nie ma podzespołów ani hierarchii, że Product Owner jest jedną osobą, a nie komitetem, i że to on odpowiada za maksymalizowanie wartości produktu. Scrum nie mówi nic o dostawcy i kliencie. Jeśli połowa deweloperów pochodzi od dostawcy, Scrum traktuje ich jak członków tego samego zespołu, a nie osobną strukturę z własnym kierownikiem. Delivery manager dostawcy, który prowadzi „swoją” część zespołu, jest z tego punktu widzenia właśnie takim podzespołem.
PRINCE2 podchodzi do sprawy odwrotnie i, co istotne dla tego tematu, przewiduje relację z dostawcą wprost. W komitecie sterującym projektu zasiadają trzy role: przedstawiciel biznesu (Executive), przedstawiciel użytkowników (Senior User) i przedstawiciel dostawców (Senior Supplier). Project manager prowadzi projekt na co dzień i raportuje do komitetu. Za wytworzenie produktów odpowiadają kierownicy zespołów (Team Manager), którzy mogą pochodzić z organizacji zleceniodawcy albo od zewnętrznego dostawcy. Najnowsza, siódma edycja PRINCE2 ukazała się w 2023 roku; prawa do metodyki należą do PeopleCert, który w 2021 roku przejął AXELOS.
To jest najbliższy oficjalny odpowiednik delivery managera dostawcy: kierownik zespołu po stronie dostawcy, który odpowiada za wytworzenie uzgodnionych pakietów prac, a nie za projekt. Projekt ma jednego project managera i jeden komitet, w którym dostawca ma głos, ale nie ma ostatniego słowa.
Standardy PMI przeszły w ostatnich latach dużą zmianę. Siódma edycja PMBOK Guide z 2021 roku zastąpiła dziesięć obszarów wiedzy dwunastoma zasadami, a ósma edycja z 2025 roku przeszła na sześć zasad i siedem obszarów wykonania (performance domains). Zmiana formy nie zmieniła jednego narzędzia, które jest tu najważniejsze: macierz RACI, nazywana też macierzą przypisania odpowiedzialności, była opisywana zarówno w piątej edycji PMBOK z 2013 roku, jak i w siódmej z 2021 roku. Jej sens polega na tym, żeby przy każdej czynności było wiadomo, kto ją wykonuje, a kto odpowiada za wynik.
Wniosek z porównania jest prosty. Scrum rozpuszcza rolę kierownika w zespole i Product Ownerze, bez podzespołów i hierarchii. PRINCE2 ma jednego project managera, a kierownicy zespołów, także ci od dostawcy, pracują pod nim. Narzędzie RACI z tradycji PMI służy właśnie temu, żeby odpowiedzialność za wynik nie rozkładała się na dwie osoby. Model „PM klienta plus DM dostawcy, obaj odpowiedzialni za projekt” nie ma oparcia w żadnym z tych źródeł. Jest wynikiem negocjacji handlowej, a nie projektu organizacji.
Za co odpowiada project manager po stronie klienta?
Najprościej: za wszystko, czego klient nie może oddać, bo od tego zależy jego biznes. Zakres i jego zmiany. Plan wydań i kamienie milowe, które obiecano zarządowi albo klientom końcowym. Budżet i jego zużycie. Ryzyka projektu jako całości, łącznie z ryzykami po stronie innych działów i innych dostawców. Komunikacja z interesariuszami, którzy nie siedzą na daily. Odbiór prac i decyzja, że coś jest gotowe.
Do tego dochodzi zadanie, które w projektach z zewnętrznym zespołem jest najczęściej niedoszacowane: zapewnienie, że decyzje zapadają na czas. Zespół dostawcy, nawet bardzo dobry, nie podejmie decyzji o formacie danych, regułach biznesowych czy priorytetach, bo nie ma do tego mandatu. Każde pytanie bez odpowiedzi to czas, za który klient płaci, a zespół pracuje nad czymś mniej ważnym albo czeka. Program Manager, który mierzy tylko tempo zespołu, a nie mierzy czasu od pytania do decyzji, patrzy na połowę problemu.
W projekcie zwinnym część tych obowiązków przejmuje Product Owner po stronie klienta, który decyduje o kolejności prac w backlogu. Nie zmienia to istoty sprawy: niezależnie od nazw ról po stronie klienta musi być ktoś, kto ma prawo i czas, żeby decydować. Jeśli nie wiesz, czy po stronie klienta potrzebny jest raczej analityk biznesowy, czy systemowy, żeby te decyzje przygotować, pomoże tekst o tym, kogo zatrudnić: analityka biznesowego czy systemowego.
Czego project manager klienta robić nie powinien? Zarządzać umową dostawcy od środka: pilnować, czy konsultant ma właściwego przełożonego u dostawcy, rozwiązywać sprawy kadrowe ludzi dostawcy, negocjować zastępstwa na urlopy. To nie jego pracodawca i nie jego narzędzia. Jeśli robi to sam, to znaczy, że rola po drugiej stronie nie działa albo jej nie ma.
Za co odpowiada delivery manager po stronie dostawcy?
Za to, żeby dostawca dotrzymywał obietnic, które da się zmierzyć niezależnie od wyniku projektu. Pięć obszarów wraca w każdym takim zakresie.
Obsada. Dobór ludzi do ról, które klient opisał, w uzgodnionym czasie. W ARDURA pierwsze CV trafia do klienta w ciągu 12–72 godzin, a standardowy proces do rozpoczęcia pracy trwa 2 tygodnie. Ktoś po stronie dostawcy musi te terminy dotrzymać i reagować, gdy profil okazuje się trudniejszy, niż zakładano.
Ciągłość i zastępstwa. Urlopy, choroby, odejścia, zmiany projektów wewnątrz dostawcy. To obszar, w którym delivery manager zarabia na swoją stawkę albo nie. W ARDURA obowiązuje gwarancja wymiany specjalisty w ciągu pierwszych 2 tygodni bez dodatkowych kosztów i zastępstwo w 5 dni roboczych, jeśli specjalista odejdzie w trakcie współpracy. Gwarancja w umowie to jedno, a ktoś, kto ją wykona, zanim klient o to poprosi, to drugie.
Jakość pracy ludzi dostawcy. Nie jakość produktu, bo za nią odpowiada cały zespół pod kierownictwem klienta, tylko to, czy konsultant pracuje na poziomie, za który klient płaci: czy rozwija się, czy przestrzega standardów klienta, czy reaguje na informację zwrotną. Delivery manager zbiera tę informację i działa, zanim klient straci cierpliwość.
Rozliczenia i formalności. Ewidencja czasu, faktury, zgodność z umową, poufność, dostępy, kwestie bezpieczeństwa po stronie dostawcy. Rzeczy nudne, ale każda z nich potrafi zatrzymać projekt na kilka dni.
Eskalacje kontraktowe. Gdy coś nie działa na poziomie umowy, a nie zadania, klient potrzebuje jednego adresu po stronie dostawcy, który ma uprawnienia do decyzji: zmiana osoby, zmiana liczby osób, zmiana warunków.
Zwróć uwagę, czego na tej liście nie ma. Nie ma priorytetów, zakresu, planu wydań ani odbioru. Delivery manager może w nich doradzać, bo widzi zespół z bliska i zna jego tempo, ale decyzje należą do klienta. W ARDURA tę funkcję w body leasingu pełni opiekun klienta po naszej stronie, który monitoruje współpracę, zbiera informację zwrotną i reaguje, gdy coś nie działa, a pracą specjalisty kieruje klient. To świadomy podział, a nie oszczędność.
Jak wygląda macierz RACI dla projektu z zewnętrznym zespołem?
Macierz RACI to najprostsze narzędzie, które zmusza obie strony do nazwania, kto co robi. Cztery litery: R (Responsible) wykonuje pracę, A (Accountable) odpowiada za wynik i go zatwierdza, C (Consulted) jest pytany o zdanie przed decyzją, I (Informed) dostaje informację po decyzji. W praktyce stosuje się zasadę, że przy każdej czynności jest dokładnie jedno A. Część autorów traktuje ją jako regułę, część jako zalecenie, ale w projekcie z dwiema organizacjami jej złamanie jest najprostszym przepisem na spór.
Poniższa macierz opisuje typowy projekt w rozliczeniu za czas pracy, w którym dostawca dostarcza kilkuosobowy zespół, a klient kieruje jego pracą. Kolumny klienta i dostawcy są rozdzielone celowo.
| Czynność lub decyzja | Sponsor klienta | Project manager klienta | Delivery manager dostawcy | Zespół dostawcy (tech lead) |
|---|---|---|---|---|
| Cel, zakres i budżet projektu | A | R | I | C |
| Priorytety prac i kolejność w backlogu | A (lub Product Owner) | R | C | C |
| Harmonogram, kamienie milowe, plan wydań | I | A/R | C | C |
| Definicja ukończenia i standardy jakości | I | A | C | R |
| Ryzyka projektu jako całości | I | A/R | C | C |
| Raport postępu dla zarządu | I | A/R | C | I |
| Dobór i wymiana specjalistów dostawcy | I | C | A/R | I |
| Ciągłość obsady: urlopy, zastępstwa, odejścia | — | I | A/R | C |
| Rozwój i ocena pracy ludzi dostawcy | — | C | A/R | R |
| Ewidencja czasu i rozliczenia | — | A (akceptacja godzin) | R | R |
| Odbiór prac | A | R | I | C |
| Eskalacje na poziomie umowy | A | R | R | I |
Trzy rzeczy w tej tabeli są ważniejsze od pozostałych. Po pierwsze, delivery manager dostawcy nie ma ani jednego A w wierszach dotyczących projektu. Ma wszystkie A w wierszach dotyczących obsady i ludzi. Po drugie, project manager klienta ma A przy akceptacji godzin, bo to klient płaci za czas pracy i to klient wie, czy był on wykorzystany na właściwe rzeczy. Po trzecie, w eskalacjach kontraktowych obie strony mają R, a A ma sponsor klienta, bo ostatecznie to on decyduje, czy umowę zmienić, czy zakończyć.
Jeśli w Twoim projekcie delivery manager dostawcy ma A przy harmonogramie albo przy priorytetach, a dostawca rozlicza się za czas pracy, macierz pokazuje sprzeczność, której nie rozwiąże żadne spotkanie statusowe: ktoś jest rozliczany z decyzji, których nie może podjąć.
Kiedy delivery manager dostawcy jest wartością?
Wtedy, gdy jego praca daje klientowi coś, czego project manager klienta nie zrobi albo zrobi gorzej. Pięć sytuacji spełnia ten warunek. Podobną granicę odpowiedzialności wyznacza się dla architekta rozwiązań na kontrakcie, a ciągłość składu warto mierzyć tak, jak opisuje tekst o rotacji specjalistów w outsourcingu.
Dostawca odpowiada za rezultat. W projekcie o stałym zakresie albo stałej cenie dostawca przejmuje decyzje o tym, jak dowieźć uzgodniony zakres, i potrzebuje do tego własnego kierownika projektu. Wtedy po stronie dostawcy pracuje w istocie project manager, niezależnie od tytułu na wizytówce, a po stronie klienta zostaje rola właściciela umowy i odbiorcy. To uczciwy podział, pod warunkiem że wszyscy go tak nazywają.
Zespół dostawcy jest duży i różnorodny. Gdy od dostawcy pochodzi kilka osób w różnych rolach (programiści, testerzy, DevOps, analityk), liczba spraw kadrowych, zastępstw i rozmów o rozwoju rośnie szybciej niż liczba osób. Fred Brooks w „The Mythical Man-Month” (1975) zwrócił uwagę na prostą arytmetykę: liczba kanałów komunikacji w grupie n osób wynosi n(n−1)/2. Pięć osób to 10 kanałów, dziesięć osób to już 45. Ktoś po stronie dostawcy, kto bierze część tej komunikacji na siebie, realnie odciąża klienta.
W projekcie pracuje kilku dostawców. Wtedy każdy z nich potrzebuje jednego punktu kontaktu, który zna jego zobowiązania i potrafi je wyegzekwować wewnątrz własnej firmy. Project manager klienta koordynuje projekt, a delivery managerowie odpowiadają za swoje części. Ten układ opisujemy szerzej w tekście o jakości i ryzyku w projektach z wieloma dostawcami.
Obsada często się zmienia. Projekt, który skaluje się w górę i w dół co kwartał albo wymaga rzadkich kompetencji na krótko, wymaga ciągłego zarządzania obsadą. Bez osoby po stronie dostawcy, która robi to proaktywnie, project manager klienta spędza połowę czasu na rekrutacji, której nie miał prowadzić.
Klient nie ma kogo postawić w roli project managera. To jedyna sytuacja, w której zastąpienie roli klienta rolą dostawcy jest rozsądne, ale wymaga uczciwego nazwania: klient nie kupuje delivery managera, tylko wynajmuje project managera, który będzie pracował po jego stronie, w jego imieniu i z jego mandatem. Taka osoba powinna mieć w macierzy RACI kolumnę klienta, a nie dostawcy, i raportować do sponsora klienta, a nie do swojego pracodawcy.
Kiedy delivery manager staje się kosztem narzutu?
Wtedy, gdy klient płaci za rolę, która przekazuje informacje zamiast podejmować decyzje. Najłatwiej to zobaczyć na liczbach.
Przykład ilustracyjny oparty na cenniku ARDURA: senior project manager kosztuje 1 520–2 080 PLN netto za dzień, senior backend developer 1 440–2 080 PLN. Przyjmijmy środki przedziałów (1 800 PLN i 1 760 PLN) oraz 21 dni roboczych w miesiącu. Trzech seniorów backend to około 110 900 PLN miesięcznie. Delivery manager na pół etatu, fakturowany osobno, to około 18 900 PLN, czyli około 17% kosztu zespołu. Przy ośmiu seniorach zespół kosztuje około 295 700 PLN, a ten sam pół etat to około 6%.
Te liczby nie mówią, że delivery manager jest drogi. Mówią, że przy małym zespole musi on dawać dużo, żeby się zwrócić. Przy trzech osobach musiałby przyspieszyć pracę zespołu o mniej więcej jedną szóstą albo oszczędzić klientowi równowartość kilku dni pracy w miesiącu, żeby wyjść na zero. Jeśli jego wkład to cotygodniowy raport, który powtarza dane z narzędzia do zarządzania zadaniami, i obecność na spotkaniach, na których i tak jest project manager klienta, nie wyjdzie.
Narzut ma też drugą, ukrytą część: czas decyzji. Każdy dodatkowy pośrednik między zespołem a osobą, która decyduje, wydłuża drogę pytania. Gdy deweloper dostawcy pyta o regułę biznesową delivery managera, ten pyta project managera klienta, a ten analityka, odpowiedź wraca po dwóch dniach zamiast po dwóch godzinach. W body leasingu specjalista powinien pytać bezpośrednio osobę po stronie klienta, która zna odpowiedź. Delivery manager w tej ścieżce nie powinien w ogóle stać.
Typowe sygnały narzutu są dość powtarzalne. Delivery manager nie ma uprawnień do decyzji kadrowych u dostawcy i każdą sprawę „sprawdza z centralą”. Raport delivery managera i raport project managera klienta różnią się w liczbach, a nikt nie wie, który jest prawdziwy. Delivery manager prowadzi własne spotkania planistyczne z ludźmi dostawcy, równoległe do planowania klienta. Zespół dostawcy dostaje zadania z dwóch źródeł.
Narzut wcale nie musi pojawić się w fakturze jako osobna pozycja. Często delivery manager jest „wliczony w stawki”. To wygodne, ale nie zwalnia z pytania, co ta rola robi. Jeśli jest wliczona, płacisz za nią w każdej godzinie każdego specjalisty. Warto więc wiedzieć, czy dostawca ma ją w ofercie jako wartość, czy jako koszt własny, który przerzuca na klienta. Wskaźniki, którymi da się to ocenić, zbiera hasło wskaźniki efektywności (KPI) w body leasingu.
Jak model umowy zmienia podział ról między klientem a dostawcą?
Model umowy przesądza, kto ma prawo do decyzji, a więc i to, gdzie powinna leżeć odpowiedzialność. Poniższa tabela zbiera trzy najczęstsze układy.
| Model współpracy | Kto odpowiada za wynik projektu | Rola po stronie dostawcy | Kiedy osobny delivery manager ma sens |
|---|---|---|---|
| Body leasing (1–4 specjalistów w zespole klienta) | Klient (project manager i sponsor) | Opiekun klienta: obsada, zastępstwa, rozliczenia | Rzadko; zwykle wystarcza opiekun klienta |
| Zespół dedykowany w rozliczeniu za czas pracy | Klient, przy aktywnym udziale tech leada dostawcy | Delivery manager lub kierownik zespołu w sensie PRINCE2 | Gdy zespół ma kilka ról i często zmienia skład |
| Projekt o stałym zakresie lub stałej cenie | Dostawca w granicach zakresu, klient za cel biznesowy i odbiór | Project manager dostawcy | Zawsze, ale nazwany wprost project managerem |
W pierwszym wierszu delivery manager w pełnym wymiarze jest zwykle przerostem formy. Specjaliści pracują w zespole klienta, w jego narzędziach i rytmie, a sprawy dostawcy da się załatwić w krótkim, regularnym kontakcie z opiekunem klienta. W drugim wierszu rola zaczyna mieć sens, ale trzeba pilnować, żeby nie przejęła decyzji projektowych. W trzecim jest konieczna, ale wtedy uczciwie nazywa się project managerem i odpowiada za zakres, a klient ma swojego kierownika umowy, który odbiera rezultaty i pilnuje celu biznesowego.
Problem zaczyna się wtedy, gdy umowa jest z pierwszego albo drugiego wiersza, a oczekiwania z trzeciego. Klient płaci za czas pracy, ale oczekuje, że dostawca „dowiezie”. Dostawca wystawia delivery managera, żeby te oczekiwania obsłużyć, ale nie dostaje prawa do decyzji. Po kilku miesiącach obie strony są rozczarowane, choć każda robi dokładnie to, co jest w umowie.
Sposób pracy zespołu też ma znaczenie. W Scrumie miejsce na osobnego kierownika ludzi dostawcy w zespole praktycznie nie istnieje, bo zespół ma być jeden, bez podzespołów. W Kanbanie, gdzie rola zespołu bywa bardziej usługowa, a praca przepływa w sposób ciągły, łatwiej wyznaczyć granicę, za którą odpowiada dostawca. Jak wybrać sposób pracy do rodzaju zadań, opisujemy w tekście Kanban czy Scrum.
Jakie sygnały pokazują, że role się dublują albo że nikt nie trzyma steru?
Program Manager zwykle dowiaduje się o problemie z podziałem ról za późno, bo objawy wyglądają na problemy z wydajnością zespołu. Warto patrzeć na kilka sygnałów, które pojawiają się wcześniej.
Dwa raporty statusowe o tym samym. Jeśli project manager klienta i delivery manager dostawcy przygotowują osobne raporty dla różnych odbiorców, prędzej czy później liczby się rozjadą. Jeden raport, jedno źródło danych, jedna osoba odpowiedzialna za jego treść. Delivery manager może dopisać część o obsadzie i ciągłości.
Zespół dostawcy pyta „kogo mam zapytać?”. To pytanie pojawia się, gdy specjaliści dostawcy mają dwóch przełożonych w sprawach zadań. Zasada powinna być jednoznaczna: w sprawach pracy pytasz osobę po stronie klienta, w sprawach zatrudnienia i rozwoju osobę po stronie dostawcy.
Czas od pytania do decyzji rośnie. To wskaźnik, którego większość projektów nie mierzy, a który najlepiej pokazuje, czy po stronie klienta ktoś trzyma ster. Wystarczy oznaczać w narzędziu zadania zablokowane na decyzję i liczyć, ile dni w nich spędzają. Jeśli średnia rośnie z miesiąca na miesiąc, problem nie leży w zespole dostawcy.
Eskalacje idą okrężną drogą. Gdy sponsor klienta dowiaduje się o problemie z obsadą od zarządu dostawcy, a nie od project managera, znaczy to, że informacja nie przeszła przez miejsce, w którym powinna. Zwykle dlatego, że delivery manager raportuje do swojej firmy, a project manager klienta nie wie, że jest problem.
Nikt nie przyznaje się do opóźnienia. Najbardziej wymowny sygnał. Na pytanie „dlaczego się spóźniamy?” każda strona wskazuje drugą, i często obie mają częściową rację. To dokładnie ten moment z otwarcia artykułu. Odpowiedzią nie jest lepsza komunikacja, tylko jedna litera A w macierzy RACI przy harmonogramie.
Kiedy te sygnały się pojawiają, warto zrobić krótką retrospektywę współpracy, a nie tylko pracy zespołu. Godzina z project managerem klienta, delivery managerem dostawcy i sponsorem, z macierzą RACI na ekranie, zwykle wystarcza, żeby zobaczyć, gdzie leży sprzeczność.
Co zapisać w umowie i w pierwszym tygodniu współpracy?
Podział ról ustalony na spotkaniu i niezapisany przetrwa do pierwszej zmiany osoby po którejś stronie. Warto więc zamienić go w dokumenty, i to krótkie.
W umowie albo załączniku o sposobie współpracy:
- kto po stronie dostawcy jest osobą kontaktową w sprawach obsady i jakie ma uprawnienia (zmiana osoby, zastępstwo, zmiana liczby osób) bez konsultacji z zarządem dostawcy;
- terminy reakcji: ile czasu ma dostawca na przedstawienie kandydata, na zastępstwo przy odejściu, na wymianę osoby, która nie pasuje do zespołu; w ARDURA są to 12–72 godziny na pierwsze CV, gwarancja wymiany w ciągu pierwszych 2 tygodni i zastępstwo w 5 dni roboczych;
- czy rola delivery managera albo opiekuna klienta jest wliczona w stawki, czy fakturowana osobno, i jaki ma wymiar czasu;
- okres wypowiedzenia i zasady zmniejszania zespołu; w ARDURA zmniejszenie zespołu wymaga 30-dniowego okresu wypowiedzenia, bez kar umownych;
- format i częstotliwość raportu dostawcy w sprawach, za które dostawca odpowiada: obsada, ciągłość, zastępstwa, sprawy otwarte.
W protokole z pierwszego tygodnia:
- macierz RACI w wersji dla tego projektu, z nazwiskami, a nie tylko rolami;
- jedno źródło prawdy o zadaniach i postępie, z którego korzystają obie strony;
- ścieżka pytań: do kogo specjalista dostawcy zwraca się w sprawach merytorycznych, a do kogo w sprawach zatrudnienia;
- ścieżka eskalacji w trzech krokach: na poziomie zespołu, na poziomie project managera i delivery managera, na poziomie sponsora i zarządu dostawcy, z czasem na reakcję na każdym poziomie;
- termin pierwszego przeglądu współpracy, najlepiej po 4–6 tygodniach, z pytaniem wprost: czy podział ról działa tak, jak go zapisaliśmy.
Dwie rzeczy łatwo przeoczyć. Pierwsza: kto zastępuje project managera klienta podczas jego nieobecności. Bez tego dwa tygodnie urlopu oznaczają dwa tygodnie, w których delivery manager dostawcy de facto prowadzi projekt, bo nikt inny nie podejmuje decyzji. Druga: kto po stronie klienta dba o wdrożenie nowych osób z zespołu dostawcy w sprawy domenowe. Dostawca może przygotować człowieka technicznie, ale nie zna reguł biznesowych klienta.
Jak przejść od obecnego układu do jasnego podziału bez wymiany ludzi?
Większość Program Managerów nie zaczyna od zera. Projekt już trwa, role są obsadzone, a podział odpowiedzialności wykształcił się sam. Zmiana nie wymaga wymiany ludzi, tylko nazwania tego, co jest, i poprawienia kilku miejsc.
Krok pierwszy: spisz stan faktyczny. Weź tabelę RACI z tego artykułu i wypełnij ją tak, jak projekt działa dziś, a nie tak, jak powinien. Poproś project managera klienta i delivery managera dostawcy, żeby zrobili to osobno. Różnice między dwiema wersjami pokażą, gdzie strony mają inne założenia.
Krok drugi: znajdź wiersze z dwoma A albo bez A. To są miejsca, w których projekt traci czas. Dla każdego z nich zdecyduj, kto ma prawo do decyzji w tym modelu umowy. Jeśli umowa jest w rozliczeniu za czas pracy, decyzje projektowe przechodzą do klienta, a decyzje o ludziach dostawcy do dostawcy.
Krok trzeci: policz, ile kosztuje rola dostawcy i co daje. Jeśli delivery manager jest fakturowany osobno, zestaw jego koszt z tym, co realnie robi w obszarach z jego kolumny: obsada, ciągłość, jakość pracy ludzi, rozliczenia. Jeśli większość jego czasu idzie na rzeczy z kolumny project managera klienta, masz dwie opcje: przenieść te zadania do klienta i zmniejszyć wymiar roli albo świadomie uznać, że wynajmujesz project managera, i przenieść tę osobę do kolumny klienta z pełnym mandatem.
Krok czwarty: ujednolić raportowanie. Jeden raport, jedno źródło danych. Część dostawcy w tym raporcie to obsada, ciągłość i sprawy otwarte po jego stronie. Wskaźniki, które warto w nim śledzić, wynikają z obu kolumn: dla klienta tempo dostarczania i czas od pytania do decyzji, dla dostawcy czas obsadzenia roli, czas zastępstwa i stabilność składu.
Krok piąty: sprawdź po miesiącu. Wróć do macierzy i zapytaj zespół dostawcy, czy wie, kogo pytać o co. Jeśli odpowiedzi się zgadzają, podział działa. Jeśli nie, wróć do kroku drugiego.
Taka zmiana zwykle nie wymaga renegocjacji umowy, tylko aneksu albo protokołu, i trwa kilka tygodni. Rzadko ktoś na niej traci. Delivery manager, który przestaje dublować project managera, ma więcej czasu na to, za co odpowiada jego firma. Project manager klienta odzyskuje kontrolę nad decyzjami, za które i tak był rozliczany.
Jak ocenić propozycję dostawcy, który w ofercie ma delivery managera?
Na etapie wyboru dostawcy warto zadać kilka pytań, które szybko pokazują, czym w danej ofercie jest delivery manager.
Jaki jest zakres tej roli, punkt po punkcie? Dobra odpowiedź zawiera obsadę, ciągłość, zastępstwa, jakość pracy ludzi dostawcy i rozliczenia. Odpowiedź „dba o sukces projektu” jest sygnałem ostrzegawczym, bo w modelu rozliczenia za czas pracy dostawca nie ma narzędzi, żeby to zapewnić.
Jakie decyzje może podjąć sam, bez konsultacji z zarządem dostawcy? Jeśli nie może sam zdecydować o wymianie osoby albo o zastępstwie, jego wartość dla klienta jest ograniczona do przekazywania wiadomości.
Ile projektów prowadzi równolegle i jaki wymiar czasu ma u Ciebie? Delivery manager z kilkunastoma klientami nie będzie aktywnie zarządzał Twoją obsadą, tylko reagował na eskalacje. To może wystarczyć przy małym zespole, ale wtedy nie płać za niego jak za pełną rolę.
Czy rola jest wliczona w stawki, czy fakturowana osobno? Obie odpowiedzi są w porządku, ale dają inne punkty odniesienia. Przy osobnej fakturze zestawiasz koszt roli z korzyścią. Przy wliczeniu w stawki porównujesz stawki całych ofert, a nie tylko stawki specjalistów.
Kto raportuje do kogo? Jeśli delivery manager raportuje wyłącznie do swojego przełożonego u dostawcy, a do Ciebie przysyła tylko status, informacja o problemach dotrze do Ciebie później niż do zarządu dostawcy. Warto ustalić, że w sprawach Twojego projektu informuje Cię równolegle.
To nie są pytania podchwytliwe. Dostawca, który ma przemyślaną rolę delivery managera, odpowie na nie od ręki. Dostawca, który dodał tę rolę do oferty, żeby wyglądała pełniej, będzie odpowiadał ogólnikami.
Jakie są kluczowe wnioski?
Delivery manager i project manager to nie dwie nazwy tej samej roli i nie dwie połowy jednej odpowiedzialności. Project manager odpowiada za projekt. Delivery manager dostawcy odpowiada za to, jak dostawca dostarcza ludzi i ich pracę. W projekcie z zewnętrznym zespołem rozliczanym za czas pracy pierwsza rola zostaje u klienta, bo klient ma prawo do decyzji, od których zależy wynik, i nie da się jej kupić razem z dodatkową pozycją w ofercie.
Zapamiętaj pięć rzeczy. Po pierwsze, odpowiedzialność idzie za prawem do decyzji: kto decyduje o priorytetach i zakresie, ten odpowiada za termin. Po drugie, ani Scrum, ani PRINCE2 nie przewidują dwóch równorzędnych kierowników jednego projektu; PRINCE2 daje dostawcy rolę kierownika zespołu, a nie projektu. Po trzecie, rozpisz macierz RACI z oddzielnymi kolumnami klienta i dostawcy i pilnuj, żeby przy każdej decyzji było jedno A. Po czwarte, policz koszt delivery managera wobec wielkości zespołu: przy trzech osobach pół etatu to około 17% kosztu, przy ośmiu około 6%, a to zmienia rachunek. Po piąte, jeśli po stronie klienta nie ma kto prowadzić projektu, wynajmij project managera do kolumny klienta, z jego mandatem, zamiast liczyć, że delivery manager dostawcy wypełni tę lukę.
Jeśli budujesz zespół z zewnętrznymi specjalistami i chcesz od początku ustawić podział odpowiedzialności, zobacz, jak działa body leasing w ARDURA: specjaliści pracują pod Twoim kierownictwem, opiekun klienta po naszej stronie odpowiada za obsadę i ciągłość, a w razie potrzeby możemy dołożyć do zespołu także project managera. Stawki dla wszystkich ról, łącznie z project managerem, są w cenniku, a o konkretny skład zespołu możesz zapytać nas bezpośrednio.