SWO Finops

Rozliczanie pracy project managera w projektach IT - dlaczego pozycja „PM" pojawia się na fakturze

Pytanie „za co właściwie płacę project managerowi?” pada w rozmowach z klientami regularnie i jest pytaniem uzasadnionym. Mniejsze organizacje, które nie mają doświadczenia z dużymi wdrożeniami, zakładają, że projekt informatyczny to przede wszystkim praca zespołu wykonawczego — konfiguracja, kod, testy — a rola kierownika projektu ogranicza się do koordynacji spotkań. W tym założeniu tkwi jedno z najkosztowniejszych nieporozumień w branży.

Odpowiedź na to pytanie warto dać wprost, zanim pojawi się pierwsza faktura. Poniżej wyjaśniamy, jaką pracę obejmuje zarządzanie projektem, jak wygląda struktura godziny projektowej, jakie modele rozliczeń są dostępne oraz który z nich rekomendujemy w typowych scenariuszach.

Rola project managera w projekcie IT

Zakres obowiązków kierownika projektu wykracza daleko poza organizację spotkań i prowadzenie kalendarza. Project Manager jest partnerem klienta, który pomaga przełożyć cele biznesowe na realny plan wdrożenia. W projekcie wdrożeniowym odpowiada on za trzy obszary, których nie przejmie zespół techniczny.

Kontrola zakresu i budżetu

Każda zmiana wymagań zgłoszona w trakcie realizacji — a zmiany zgłasza praktycznie każda organizacja — bez formalnego procesu staje się nieudokumentowanym „drobnym rozszerzeniem”, wycenianym doraźnie i bez decyzji klienta. Project manager nazywa zmianę, wycenia ją przed realizacją i przedstawia do zatwierdzenia. Nie jest to biurokracja, lecz mechanizm ochrony budżetu.

Odpowiedzialność za harmonogram i zamknięcie projektu

Projekty pozbawione zarządzania rzadko kończą się spektakularną porażką. Znacznie częściej rozmywają się w czasie: tydzień opóźnienia, nieodbyte spotkanie, dwa nierozstrzygnięte nieporozumienia. Według badań Standish Group za 57% niepowodzeń projektów IT odpowiadają problemy komunikacyjne. Rolą Project Managera jest utrzymanie tej komunikacji w ryzach – nie tylko z jedną osobą reprezentującą klienta, ale pomiędzy wszystkimi uczestnikami projektu. W praktyce oznacza to współpracę z wieloma interesariuszami: sponsorem projektu, zarządem, użytkownikami biznesowymi, działem IT, księgowością, sprzedażą, konsultantami, developerami, a niekiedy również zewnętrznymi dostawcami. Każda z tych grup ma własne cele, priorytety i perspektywę. Zadaniem Project Managera jest połączenie ich w jeden spójny plan działania oraz utrzymanie wspólnego kierunku projektu.

Bez harmonogramu, roadmapy działań i utrzymania odpowiedniego rytmu projektu trudno przewidzieć zarówno termin zakończenia wdrożenia, jak i moment osiągnięcia zakładanych korzyści biznesowych oraz zwrotu z inwestycji. Jednocześnie zespół projektowy nie jest w stanie skutecznie planować zasobów na najbliższe sprinty, miesiące, lata. Dlatego Project Manager planuje kolejne etapy projektu, przygotowuje decyzje do podjęcia i dba o to, aby projekt nie zatrzymywał się z powodu braku informacji lub opóźnionych uzgodnień.

W tym ujęciu zarządzanie projektem nie jest kosztem dodatkowym, lecz formą ubezpieczenia realizacji projektu dla wszystkich zaangażowanych stron. Oszczędności w tym obszarze ujawniają swój rzeczywisty rachunek dopiero przy pierwszym poważnym problemie.

Tłumaczenie potrzeb biznesowych na wymagania techniczne

Sformułowanie „system ma wysyłać raport do przełożonego w piątek o 17:00″ jest oczekiwaniem biznesowym, nie specyfikacją. Kierownik projektu przekłada je na wymaganie, identyfikuje przypadki brzegowe (dni wolne, kolizje z innymi procesami) i weryfikuje spójność z pozostałą częścią rozwiązania. Bez tego kroku zespół deweloperski uzupełnia luki własnymi założeniami, co jest najdroższą formą programowania.

Odpowiedzialność za zamknięcie projektu

Sformułowanie „system ma wysyłać raport do przełożonego w piątek o 17:00″ jest oczekiwaniem biznesowym, nie specyfikacją. Kierownik Projektu przekłada je na wymaganie, identyfikuje przypadki brzegowe (dni wolne, kolizje z innymi procesami) i weryfikuje spójność z pozostałą częścią rozwiązania. Czyli „łączy tzw. kropki” i pilnuje, by wszystkie strony projektu rozumiały konsekwencje swoich decyzji. Bez tego kroku, zespół deweloperski uzupełnia luki własnymi założeniami, co jest najdroższą formą programowania.

W ujęciu utrzymania komunikacji z interesariuszami w ryzach i odpowiedniej reakcji w czasie, zarządzanie nie jest kosztem dodatkowym, lecz formą ubezpieczenia realizacji projektu dla wszystkich zaangazowanych stron. Oszczędności w tym obszarze ujawniają swój rzeczywisty rachunek dopiero przy pierwszym poważnym problemie.

Struktura godziny projektowej

Źródłem nieporozumienia jest najczęściej założenie, że faktura obejmuje wyłącznie „godziny konsultanta”. W praktyce każda prawidłowo prowadzona godzina projektowa składa się z kilku elementów.

  • Delivery - ok. 70%:

    Konfiguracja, integracje, kod, testy. Praca widoczna dla klienta.

  • Zarządzanie (PM/PMO) - ok. 12%:

    Planowanie, zarządzanie ryzykiem, koordynacja dostawców. Praca niewidoczna do momentu, w którym jej zabraknie.

  • Komunikacja - ok. 8%:

    Statusy, demo, ustalenia z zespołem klienta. Są to również godziny po stronie zamawiającego, nie tylko wykonawcy.

  • Analiza - ok. 6%:

    Doprecyzowanie zakresu, scenariusze użycia, decyzje projektowe. Obszar, w którym oszczędność przynosi największy zwrot — pod warunkiem że następuje przed kodowaniem, a nie po nim.

  • Administracja - ok. 4%:

    Rejestr zmian, raportowanie, definiowanie zadań. Element rutynowy, ale niezbędny.

Wymienione czynności nie są dodatkiem do projektu — to one decydują o jego domknięciu. Można je ująć w jednej, wyższej stawce godzinowej albo wykazać osobno, natomiast nie da się ich uniknąć. Dostawca deklarujący, że takich kosztów nie ponosi, po prostu wkalkulował je w cenę bez informowania o tym klienta.

Przejrzystość rozliczeń a model „czarnej skrzynki"

Rzeczywista różnica między dostawcami nie polega na tym, czy klient płaci za zarządzanie projektem, ponieważ płaci zawsze. Polega na tym, czy dostawca to pokazuje.

Część firm ujmuje cały narzut w jednej stawce konsultanta i wystawia fakturę z pojedynczą pozycją. Rozwiązanie jest wygodne i nie generuje sporów, ale pozostaje nieprzejrzyste. Podejście odwrotne zakłada niższą stawkę bazową i wykazanie każdej godziny z przypisaną kategorią oraz artefaktem.

Warto zauważyć paradoks: to przejrzystość bywa oceniana krytycznie. Klient otrzymujący fakturę z jedną pozycją nie ma o co pytać. Klient, który widzi wiersz „PM — 6h”, zgłasza zastrzeżenia. Koszt i zakres pracy pozostają identyczne; różnica sprowadza się do tego, że jednemu przedstawiono pełne rozliczenie, a drugiemu nie.

Modele rozliczeń

Nie istnieje jeden uniwersalnie właściwy model. Istnieją cztery, a wybór należy do klienta i powinien wynikać z tego, jak organizacja chce czytać fakturę.

Stawka łączona (Blended Rate):

Cały narzut zarządczy zawarty w jednej stawce godzinowej. Faktura obejmuje jedną pozycję. Zaleta: maksymalna prostota rozliczenia i brak konieczności wyjaśniania struktury kosztów zarządowi. Wada: stawka jest wyższa, ponieważ narzut musi zostać uwzględniony, a klient nie ma wglądu w strukturę kosztu. Rozwiązanie dla organizacji, które przedkładają prostotę faktury nad kontrolę kosztów.

Transparentny model Time & Material:

Niższa stawka bazowa oraz osobne, nazwane pozycje: Delivery, PM, Komunikacja, Analiza. Zaleta: pełny wgląd w koszty, kontrola w cyklu tygodniowym oraz możliwość świadomego ograniczania wybranych kategorii, na przykład liczby spotkań. Wada: więcej pozycji do weryfikacji i wyższe wymagania wobec dyscypliny raportowej dostawcy. Rozwiązanie dla organizacji, które chcą rozumieć strukturę kosztu i przedstawiać ją zarządowi.

Ryczałt za zarządzanie:

Prace merytoryczne rozliczane w modelu Time & Material, zarządzanie jako stała opłata miesięczna, zwykle w przedziale 8–15% wartości projektu. Zaleta: przewidywalny koszt zarządzania i brak sporów o pojedyncze godziny. Wada: ryczałt obowiązuje również w okresach o niższej intensywności prac. Rozwiązanie stosowane w większych, długoterminowych projektach z koordynacją wielu zespołów; standard w praktyce firm takich jak Accenture czy Deloitte.

Stała cena (Fixed Price):

Zamrożony zakres, stała cena, ryzyko przekroczeń po stronie dostawcy. Zaleta: pełna przewidywalność budżetu; klient płaci za rezultat, nie za nakład pracy. Wada: konieczność precyzyjnego zdefiniowania zakresu przed rozpoczęciem prac, każda zmiana wymaga aneksu, a bufor ryzyka jest wliczony w cenę. Rozwiązanie dla zakresów stabilnych i dobrze zdefiniowanych.

Kluczowa jest przy tym jedna obserwacja: stawka łączona i transparentny model Time & Material prowadzą do tej samej kwoty końcowej. Ta sama suma zostaje raz ukryta w jednej liczbie, a raz rozbita na nazwane kategorie. Pytanie nie dotyczy więc tego, ile klient zapłaci, lecz tego, czy chce to zobaczyć.

Zasady raportowania

Nawet dobrze dobrany model rozliczeń nie zabezpiecza przed sporem, jeżeli nie towarzyszy mu rzetelne raportowanie. W praktyce sprawdzają się cztery zasady.

  • Cykl tygodniowy zamiast miesięcznego.

    Sześć godzin pracy PM w raporcie tygodniowym jest tematem do rozmowy. Dwieście godzin na koniec miesiąca jest tematem do sporu.

  • Konkret zamiast opisów zbiorczych.

    Nie „prace PM", lecz „Sprint planning, protokół #23; rejestr ryzyk R-07". Pozycja nazwana jest pozycją weryfikowalną.

  • Artefakt przypisany do każdej pozycji.

    Spotkanie - protokół. Analiza - notatka. Zarządzanie - zaktualizowany plan. Brak śladu oznacza brak pozycji na fakturze.

  • Cotygodniowa akceptacja klienta.

    Brak akceptacji oznacza brak fakturowania. Eliminuje to niespodzianki na koniec okresu rozliczeniowego.

Rekomendacje

Doświadczenie pokazuje, że źródłem konfliktu rzadko jest sam model rozliczeń. Jest nim brak decyzji o modelu na starcie. Klient rozpoczyna projekt z niewypowiedzianym założeniem, że płaci wyłącznie za pracę wykonawczą, po czym otrzymuje fakturę z pozycją „PM”. Nawet jeżeli zasady współpracy zostały wcześniej omówione, rozmowa przestaje wtedy dotyczyć pieniędzy, a zaczyna dotyczyć zaufania – a tego nie odbudowuje się tabelą kosztów.

Dlatego pytanie o model rozliczeń powinno paść na pierwszym spotkaniu, przed przygotowaniem oferty, równie naturalnie jak pytanie o budżet i termin: czy klient woli jedną stawkę godzinową obejmującą wszystkie elementy, czy pełny rozkład kosztów z niższą stawką bazową i wyodrębnionym zarządzaniem.

Rekomendowanym wariantem, sprawdzającym się w większości projektów, jest transparentny model Time & Material. Oferuje najszerszy wgląd w strukturę kosztów, umożliwia bieżącą kontrolę zakresu i pozwala świadomie zarządzać poszczególnymi kategoriami prac. Klient preferujący prostotę rozliczenia otrzyma stawkę łączoną i nigdy nie zobaczy spornej pozycji; klient oczekujący kontroli otrzyma pełne rozliczenie. Projekt i jego cena pozostają te same – różnicę robi jedno pytanie zadane we właściwym momencie.

Przejrzystość nie oznacza wyższego kosztu. Oznacza większą kontrolę – pod warunkiem że klient wybrał ją świadomie, a nie odkrył na fakturze.