„Trzeba dopłacić”. Skąd biorą się niespodzianki budżetowe w projektach IT

Status projektu od miesięcy świeci na zielono. Zespół pracuje pełną parą, raporty wyglądają porządnie, faktury wpływają regularnie. A potem, najczęściej przy okazji rozmowy o terminie, pada jedno zdanie: „trzeba dopłacić”. Pytasz, na co poszły poprzednie pieniądze, i okazuje się, że nikt nie potrafi odpowiedzieć w prosty sposób.

W tym artykule pokazujemy, skąd biorą się te niespodzianki i jak odróżnić zdrową dopłatę za nową wartość od dopłaty za błąd w zarządzaniu projektem.

Niespodzianka rodzi się z różnicy między tym, co widać, a tym, co jest

Przekroczenie budżetu rzadko jest wypadkiem. Najczęściej to skutek tego, że na etapie planowania widać tylko wierzchołek systemu, a prawdziwa złożoność odsłania się dopiero podczas prac.

Badanie McKinsey i Oxford pokazało, że duże projekty IT przekraczają budżet średnio o 45 procent. Dane dotyczą dużych wdrożeń, ale wzorzec powtarza się przy każdej skali. Trudno wycenić coś, czego jeszcze nie widać. Pozornie prosta funkcja potrafi wymagać zmian w wielu mikroserwisach, migracji danych albo przebudowy istniejących zależności, a okazuje się to dopiero wtedy, gdy ktoś wejdzie w szczegóły.

Dlatego „trzeba dopłacić” brzmi jak grom z jasnego nieba, choć nim nie jest. Koszty nie skaczą z dnia na dzień. Rosną w miarę, jak zespół poznaje system od środka. Pytanie nie brzmi, czy taka sytuacja się zdarzy, bo w złożonych projektach zdarza się prawie zawsze. Pytanie brzmi, czy dowiadujesz się o tym na bieżąco i decydujesz świadomie, czy dostajesz rachunek po fakcie.

Cztery źródła niespodzianek, które wychodzą dopiero w trakcie

Większość niespodzianek budżetowych ma to samo podłoże: rzeczywistość systemu jest bogatsza niż dokumentacja i plan. Poniżej cztery wzorce, które najczęściej widzimy w projektach, w tym w jednym z projektów logistycznych, do którego będziemy się odwoływać.

System okazuje się bardziej splątany, niż mówiła dokumentacja

Pierwsze źródło to ukryte zależności. Moduł, który miał działać samodzielnie, w praktyce trzyma się na połączeniach ze starszymi częściami systemu.

W tym projekcie logistycznym nowy system do skanowania i sortowania paczek miał docelowo działać niezależnie. W praktyce był silnie uzależniony od starego panelu. Kluczowe procesy, takie jak zarządzanie trasami, regionami i routingiem paczek, wciąż wymagały komunikacji ze starym systemem. Na etapie planowania nikt tego nie widział, bo dokumentacja sugerowała prostszy obraz.

Efekt jest zawsze podobny. Funkcja, którą wyceniono jako drobną, dotyka wielu miejsc naraz. Zamiast jednej zmiany robisz pięć, plus migrację danych, plus rozplątanie zależności, których nie było w planie. To nie błąd estymacji. To koszt wiedzy, której na starcie po prostu nie było.

Dług techniczny wystawia rachunek

Drugie źródło to dług techniczny, który blokuje nowe funkcje. Klient płaci wtedy nie tylko za nową funkcję, ale też za usunięcie przeszkód, bez których nie da się jej bezpiecznie wdrożyć.

W tym samym projekcie rozwój wielokrotnie zatrzymywał się o problemy istniejące od lat: brak testów automatycznych, rozproszoną logikę biznesową, duplikację danych między mikroserwisami, brak jednego źródła prawdy dla paczek i powracające awarie produkcyjne. Każda z tych rzeczy z osobna wygląda na „temat techniczny”. Razem sprawiają, że nawet prosta zmiana wymaga dodatkowej pracy, zanim w ogóle można ją wdrożyć.

Dług techniczny działa jak kredyt z odsetkami. Pominięte testy i pisanie na skróty wyglądają na oszczędność w bieżącym sprincie, a od pewnego momentu podnoszą koszt każdej kolejnej zmiany. Jeśli poprawki są coraz droższe i nikt nie umie wyjaśnić dlaczego, to zwykle właśnie to.

Rzeczywisty zakres biznesowy jest większy, niż wyglądał

Trzecie źródło to zakres, który rośnie nie z kaprysu, tylko dlatego, że analiza odsłania prawdziwą skalę problemu. To zupełnie co innego niż dorzucanie funkcji „przy okazji”.

Dobry przykład to migracja logiki geograficznej. Na początku temat wyglądał jak zwykłe przeniesienie danych. W trakcie analiz okazało się, że dotychczasowy model regionów, stref, obszarów i tras jest niekompletny i nie pozwala odłączyć starego panelu. Trzeba było zaprojektować pełny model geograficzny i dopiero potem zmigrować dane.

Zakres urósł, to prawda. Ale dzięki temu klient dostał rozwiązanie, które faktycznie uniezależnia nowy system od starego. To jest dopłata, która kupuje realną wartość, a nie łata błąd. Różnica jest zasadnicza i wrócimy do niej w dalszej części.

Produkcja nie czeka na roadmapę

Czwarte źródło to awarie i incydenty produkcyjne. Są konieczne biznesowo, ale zjadają budżet, który miał pójść na rozwój.

W projekcie logistycznym zdarzały się sytuacje, gdy zespół musiał przerwać zaplanowane prace i natychmiast reagować na problemy blokujące operacje, na przykład awarie integracji albo problemy z importem paczek. Nikt tego nie planował, a jednak trzeba było działać od ręki, bo na drugim końcu były realne przesyłki i realni klienci.

Każda taka godzina to godzina, która nie poszła na cel projektu. Na fakturze tego nie widać, bo widać tylko sumę godzin. Dlatego rozwój, utrzymanie i incydenty trzeba pokazywać osobno. Bez tego łatwo o złą diagnozę: „zespół dowozi za mało”, podczas gdy zespół po prostu utrzymywał system przy życiu.

Dwa rodzaje „trzeba dopłacić”: nowa wartość albo błąd w zarządzaniu

Kiedy słyszysz „trzeba dopłacić”, najważniejsze pytanie brzmi: płacimy za nową wartość biznesową albo usunięcie realnego problemu, czy za błąd w zarządzaniu projektem? To dwie zupełnie różne sytuacje, choć komunikat jest ten sam.

1. Pierwszy rodzaj to dopłata zdrowa. Pojawia się, bo wejście w szczegóły systemu odsłoniło coś, czego nie dało się zobaczyć wcześniej: ukrytą zależność, większy zakres, realne ryzyko. Dostajesz za nią coś konkretnego: działającą funkcję, usuniętą przeszkodę, uniezależnienie od starego systemu. Decyzję podejmujesz świadomie, na podstawie nowych informacji.
2. Drugi rodzaj to dopłata, która pokrywa błąd w prowadzeniu projektu. Tu pieniądze nie kupują nowej wartości, tylko gaszą skutki złych nawyków.

Najczęstsze z nich:

• Ciągła zmiana zakresu zamiast skupienia na celu. Projekt co tydzień skręca w inną stronę, a każda zmiana kierunku ma cenę, której nikt nie liczy.
• Nietransparentny dostawca. Raporty mówią o aktywności, nie o wartości, a o problemach dowiadujesz się późno.
• Brak decyzji po stronie biznesu. Zespół czeka, temat wisi, a koszt utrzymania gotowości i powrotu do kontekstu rośnie.
• Zwlekanie z wyjściem na produkcję. Im później wdrożenie, tym więcej niespodzianek naraz i tym drożej je naprawić.
• Złe decyzje na poziomie architektury. Wybór, który upraszcza dziś, potrafi podnieść koszt każdej kolejnej zmiany.
• Odkładanie najtrudniejszych tematów. Zewnętrzne integracje, migracje i ryzykowne zależności spychane na koniec wracają jako kryzys, gdy nie ma już zapasu czasu ani budżetu.

Pierwszego rodzaju dopłaty nie da się całkiem uniknąć i nie ma w niej nic złego, o ile widzisz, za co płacisz. Drugi rodzaj to sygnał, że problem leży w sposobie prowadzenia projektu, a nie w jego złożoności.

Najdroższe projekty udają, że problemów nie ma

Prawdziwe ryzyko prawie zawsze wychodzi dopiero podczas pracy. Różnica między dobrym a złym projektem polega na tym, czy mówi się o nim głośno, czy chowa pod dywan.

Najdroższe projekty to te, które udają, że problemów nie ma.

To jest istota transparentności. Więcej o tym, czego warto wymagać od dostawcy w temacie kosztów, piszemy w artykule o transparentności kosztów w projekcie software.

Jak zamienić niespodziankę w świadomą decyzję

Niespodzianka znika, gdy budżet jest powiązany z zakresem, ryzykiem i realnym stanem systemu, a nie tylko z listą godzin. Nie potrzebujesz do tego rozbudowanej maszyny raportowej, wystarczy kilka rzeczy ustalonych od początku.

Od pierwszego tygodnia warto wymagać:

• Podziału pracy na strumienie. Osobno rozwój, osobno utrzymanie, osobno incydenty. Bez tego nie odróżnisz budowania od gaszenia pożarów.
• Rejestru ryzyk z konsekwencjami. Nie lista techniczna, tylko ryzyka przełożone na koszt i decyzję: co akceptujemy, co eliminujemy teraz, co odkładamy.
• Reguły dla zmian zakresu. Każda zmiana dostaje jedną z trzech etykiet: mieści się w zakresie, zastępuje coś innego, albo podnosi koszt lub przesuwa termin.
• Raportu o wartości, nie o aktywności. Co dowieziono, co zaakceptowano, co zmieniło prognozę, jakie ryzyka wpływają na koszt.
• Wczesnego sygnału. Umowy, że usłyszysz „przy tym tempie i zakresie ryzykujemy przekroczenie”, zanim pieniądze się skończą.

Pomaga też kolejność pracy. Najtrudniejsze tematy, czyli zewnętrzne integracje, migracje i ryzykowne zależności, warto brać wcześnie, a nie spychać na koniec. To samo dotyczy wyjścia na produkcję: im szybciej coś realnie działa, tym mniej niespodzianek kumuluje się na finiszu. Jeśli chcesz szybko ocenić, czy twój projekt zmierza w stronę takiej niespodzianki, pomocna będzie autodiagnoza „Czy twój projekt płonie?”, a do rozmowy z zarządem o rosnącym koszcie mamy gotowe ramy komunikowania problemów w projekcie IT.

Podsumowanie

„Trzeba dopłacić” najczęściej oznacza, że rzeczywisty stan systemu okazał się inny niż ten widoczny na starcie: więcej zależności, więcej długu technicznego, większy zakres, więcej awarii.

Dlatego przy każdej dopłacie warto zadać jedno pytanie: czy płacimy za nową wartość biznesową albo usunięcie realnego problemu, czy za błąd w zarządzaniu projektem? To zasadnicza różnica. Pierwsze jest naturalną ceną poznawania złożonego systemu. Drugie to skutek zmiennego zakresu, braku decyzji i chowania problemów pod dywan.

W dobrze prowadzonym projekcie dodatkowy budżet nie jest niespodzianką. Jest świadomą decyzją, podjętą na podstawie informacji, które pojawiły się dopiero po wejściu w szczegóły.

Słyszysz „trzeba dopłacić” i nie wiesz, gdzie zniknęły pieniądze?

Robimy krótkie audyty projektów IT. Sprawdzamy raporty, sposób rozliczania i to, jak dostawca pokazuje ryzyka i koszt decyzji. Po kilku dniach wiesz, gdzie przecieka budżet i co konkretnie zmienić w modelu współpracy.

Umów 30 minut rozmowy bez slajdów i prezentacji. Opowiedz, gdzie znikają pieniądze, a my powiemy, od czego zacząć.