Jak nadzorować projekt IT po stronie klienta — bez projektowego teatru

W projekcie realizowanym przez zewnętrznego dostawcę łatwo założyć, że skoro po jego stronie jest Project Manager, klient nie potrzebuje własnego nadzoru. To błąd wynikający z pomieszania dwóch różnych odpowiedzialności.

Kierownik projektu dostawcy organizuje pracę wykonawcy. Odpowiada za jego zespół, dostępność specjalistów, plan realizacji i rentowność kontraktu. Klient potrzebuje natomiast osoby, która pilnuje, czy powstające rozwiązanie nadal wspiera cel biznesowy, czy zmiany są świadome, czy organizacja dostarcza decyzje na czas i czy rezultat nadaje się do odbioru.

Te role mogą dobrze współpracować. Nie są jednak zamienne.

Co właściwie oznacza nadzór po stronie klienta

Nadzór nie polega na kontrolowaniu każdego zadania dewelopera. Klient nie musi codziennie wchodzić do kodu ani prowadzić mikro-zarządzania zespołem.

Chodzi o utrzymanie odpowiedzi na siedem pytań:

1. Jaki rezultat biznesowy ma dostarczyć projekt?
2. Co jest w aktualnym zakresie i jakie są priorytety?
3. Co rzeczywiście działa i zostało zaakceptowane?
4. Co pozostało oraz ile potrwa i będzie kosztować?
5. Jakie ryzyka i zależności mogą zmienić plan?
6. Jakich decyzji potrzebuje zespół i kto ma je podjąć?
7. Na jakiej podstawie klient odbierze rozwiązanie?

Jeżeli organizacja potrafi regularnie i wiarygodnie odpowiedzieć na te pytania, projekt jest sterowalny — nawet gdy pojawiają się odchylenia.

1. Jedna osoba utrzymuje pełny obraz

W typowej firmie zarząd pilnuje budżetu, użytkownicy opisują potrzeby, IT odpowiada za bezpieczeństwo i integracje, dział prawny patrzy na umowę, a dostawca zarządza realizacją. Każdy widzi fragment projektu.

Potrzebny jest właściciel obrazu całościowego: klient-side PM, Product Owner albo inna jednoznacznie umocowana osoba. Nie musi samodzielnie podejmować wszystkich decyzji, ale powinien wiedzieć, kto je podejmuje, zebrać potrzebne informacje i dopilnować zamknięcia tematu.

Najgorszy model to odpowiedzialność rozproszona bez właściciela. Wtedy opóźniona decyzja zawsze jest „po czyjejś stronie”, ale nigdy po stronie konkretnej osoby.

2. Zakres ma wersję bazową i priorytety

Projekt potrzebuje linii bazowej: zaakceptowanego obrazu zakresu, budżetu, terminu, założeń i odpowiedzialności. Nie po to, aby zamrozić zmianę, lecz aby wiadomo było, względem czego ocenia się jej wpływ.

Zakres powinien być powiązany z priorytetami. MoSCoW, mapowanie procesu albo inna prosta metoda wystarczą, jeśli pomagają odróżnić warunek uruchomienia od pomysłu, który może poczekać.

Bez priorytetów każdy interesariusz broni swojego elementu, a projekt próbuje zrealizować wszystko jednocześnie.

3. Postęp jest pokazywany, a nie tylko raportowany

Raporty są potrzebne, ale nie zastąpią demonstracji. Regularnie należy pokazywać działające procesy na środowisku testowym, korzystając z danych i ról zbliżonych do rzeczywistych.

Najlepszą jednostką postępu nie jest liczba zamkniętych ticketów, tylko sprawdzalny rezultat biznesowy. Przykład: „pracownik może utworzyć reklamację, skierować ją do serwisu, zaakceptować koszt i poinformować klienta” mówi więcej niż „ukończono 82% modułu reklamacji”.

Demo powinno kończyć się konkretnym zapisem:

• co pokazano;
• co działało;
• jakie są otwarte problemy;
• co uznano za zaakceptowane;
• jakie decyzje są potrzebne.

4. Decyzje mają właściciela i termin

Projekt może być blokowany nie tylko przez wykonawcę. Brak odpowiedzi klienta dotyczącej danych, procesu, priorytetu albo interpretacji wymagania potrafi zatrzymać kilka osób na wiele dni.

Warto prowadzić prosty rejestr decyzji: temat, dostępne warianty, rekomendacja, osoba decyzyjna, termin i rozstrzygnięcie. Decyzje o dużym wpływie powinny zawierać także konsekwencje dla budżetu, terminu i ryzyka.

To ogranicza późniejsze dyskusje pod tytułem „kto i kiedy to ustalił” oraz pozwala zobaczyć, czy opóźnienia decyzyjne stają się wzorcem.

5. Zmiany nie wchodzą bocznymi drzwiami

Każda znacząca zmiana zakresu powinna zostać oceniona przed rozpoczęciem pracy. Minimum to opis potrzeby, klasyfikacja, wpływ i decyzja.

Nie każda zmiana musi zwiększać budżet. Można zastąpić nią mniej ważny element albo przesunąć ją do kolejnego etapu. Nie można natomiast udawać, że kolejna praca nie wpływa na żaden parametr projektu.

Więcej o tym mechanizmie przeczytasz w artykule o scope creep.

6. Ryzyka są powiązane z działaniem

Rejestr ryzyk nie powinien być cmentarzem zdań typu „możliwe opóźnienie integracji”. Użyteczny wpis wskazuje:

• zdarzenie i jego przyczynę;
• możliwy wpływ;
• prawdopodobieństwo lub poziom ekspozycji;
• właściciela;
• działanie zapobiegawcze;
• sygnał, po którym wiadomo, że ryzyko się materializuje.

Najważniejsze ryzyka powinny pojawiać się w raporcie statusowym. Jeżeli ryzyko nie prowadzi do działania, decyzji albo świadomej akceptacji, jego zapisanie niewiele zmienia.

7. Budżet jest zestawiany z rezultatem i prognozą

Samo „wydaliśmy 60% budżetu” nie mówi, czy projekt jest w dobrej sytuacji. Trzeba wiedzieć, jaka część najważniejszego zakresu została ukończona i jaki jest koszt pozostałej pracy.

Minimalny obraz finansowy obejmuje:

• budżet bazowy;
• wydatki i zobowiązania;
• koszt zaakceptowanych zmian;
• prognozę kosztu dokończenia (ETC);
• prognozę całkowitego kosztu;
• zakres, który mieści się w tej prognozie.

Jeżeli budżet i zakres nie spotykają się w jednym raporcie, zarząd widzi dwie połowy prawdy.

8. UAT i odbiór zaczynają się przed końcem projektu

Kryteria odbioru nie powinny powstawać tydzień przed ostatnią fakturą. Najlepiej definiować je razem z wymaganiami, a scenariusze UAT przygotowywać, gdy kluczowe procesy są już dostatecznie stabilne.

Po stronie klienta trzeba ustalić:

• kto reprezentuje poszczególne grupy użytkowników;
• jakie procesy są krytyczne dla uruchomienia;
• jakie dane testowe będą potrzebne;
• jak klasyfikowane są błędy, luki i nowe pomysły;
• które problemy blokują odbiór;
• kto podejmuje decyzję o akceptacji warunkowej albo odrzuceniu.

Odbiór to proces dowodowy, nie ceremonia kończąca harmonogram.

Minimalny raport dla zarządu

Dobry raport można zmieścić na jednej lub dwóch stronach. Powinien odpowiadać na pytania, a nie pokazywać liczbę odbytych spotkań.

Obszar	Minimalna informacja
Cel i zakres	Czy nadal realizujemy uzgodniony rezultat i co się zmieniło?
Postęp	Co działa i zostało zaakceptowane od ostatniego raportu?
Termin	Jaka jest aktualna prognoza i z czego wynika?
Budżet	Ile wydano, jakie są zobowiązania i ETC?
Ryzyka	Które trzy ryzyka mają największy wpływ i co z nimi robimy?
Decyzje	Jakie decyzje są potrzebne, od kogo i do kiedy?
Odbiór	Czy kryteria i przygotowanie UAT nadążają za realizacją?

Jeżeli raport nie prowadzi do żadnej decyzji, prawdopodobnie jest kroniką aktywności, a nie narzędziem zarządzania.

Jak często prowadzić nadzór

Częstotliwość zależy od tempa i ryzyka projektu. W krótkim, intensywnym wdrożeniu potrzebna może być praca kilka razy w tygodniu. W stabilnej realizacji wystarczy cotygodniowy przegląd operacyjny i miesięczny raport zarządczy.

Nie chodzi o maksymalną liczbę ceremonii. Chodzi o to, aby czas między pojawieniem się problemu a decyzją był krótszy niż czas, w którym problem zdąży stać się kosztowny.

Kiedy niezależne wsparcie ma największy sens

• firma nie ma własnego doświadczonego PM-a albo Product Ownera;
• projekt realizuje zewnętrzny dostawca;
• zaangażowanych jest kilka działów, spółek lub systemów;
• inwestycja jest krytyczna dla operacji albo klientów;
• zakres, budżet lub termin zaczynają się rozjeżdżać;
• zarząd potrzebuje informacji niezależnej od raportu wykonawcy;
• zbliża się odbiór, a kryteria nie są gotowe.

Niezależny nadzór nie powinien tworzyć dodatkowej wojny między klientem a dostawcą. Dobrze prowadzony daje wykonawcy szybsze decyzje i stabilniejsze priorytety, a klientowi — wcześniejszą informację o ryzyku i możliwość świadomego zarządzania inwestycją.

Zobacz, jak wygląda usługa nadzoru projektu IT po stronie klienta albo umów pierwszą rozmowę.