Status projektu wygląda dobrze, raporty też, a na jednym ze spotkań i tak pada: „trzeba dopłacić". Pytasz wtedy, na co poszły dotychczasowe pieniądze, i okazuje się, że nikt nie potrafi odpowiedzieć prosto, chociaż zespół pracował przez ostatnie miesiące bez przerwy. W tym tekście opisuję, skąd biorą się takie niespodzianki budżetowe, dlaczego jedna dopłata ma sens, a druga już nie, oraz o co warto zapytać, zanim budżet się skończy.
W skrócie
- „Trzeba dopłacić" zwykle nie wynika z tego, że ktoś źle policzył godziny, tylko z tego, że prawdziwy stan systemu wychodzi na jaw dopiero w trakcie pracy.
- Cztery typowe źródła to ukryte zależności, dług techniczny, większy zakres niż zakładano i awarie produkcyjne.
- Najdroższe są te projekty, które udają, że problemów nie ma, chociaż ryzyka były widoczne od dawna.
Dlaczego budżet rozjeżdża się bez ostrzeżenia
Przekroczenie budżetu w IT rzadko jest wypadkiem. Na etapie planowania widać zwykle tylko wierzchołek systemu, a prawdziwa złożoność odsłania się dopiero wtedy, gdy zespół wchodzi w szczegóły.
Pozornie prosta funkcja może wymagać zmian w kilku modułach, migracji danych albo rozplątania zależności, o których nie było w dokumentacji. Koszty nie skaczą z dnia na dzień, tylko rosną wraz z wiedzą o systemie, więc „trzeba dopłacić" brzmi jak grom z jasnego nieba, chociaż sam mechanizm jest do przewidzenia.
W złożonych projektach taka sytuacja zdarza się prawie zawsze. Pytanie więc nie brzmi, czy do tego dojdzie, ale czy dowiesz się o tym na bieżąco i zdecydujesz świadomie, czy dostaniesz rachunek dopiero po fakcie.
Cztery źródła niespodzianek budżetowych
Większość niespodzianek ma to samo podłoże: rzeczywistość systemu jest bogatsza niż plan i dokumentacja.
Ukryte zależności. Moduł, który miał działać samodzielnie, w praktyce jest podpięty do starszych części systemu. W jednym z naszych projektów logistycznych nowy system do skanowania i sortowania paczek miał być niezależny, jednak kluczowe procesy, czyli trasy, regiony i routing, wciąż wymagały starego panelu. Na starcie nikt tego nie widział, bo dokumentacja sugerowała prostszy obraz.
Dług techniczny. Brak testów, rozproszona logika, zdublowane dane, brak jednego źródła prawdy — każda z tych rzeczy z osobna wygląda jak temat techniczny, ale razem sprawiają, że nawet prosta zmiana wymaga dodatkowej pracy, zanim w ogóle da się ją wdrożyć. Dług techniczny działa jak kredyt z odsetkami: to, co dziś wygląda na oszczędność, jutro podnosi koszt kolejnych zmian.
Zakres większy niż zakładano. Czasem zakres rośnie nie z kaprysu, tylko dlatego, że analiza pokazuje prawdziwą skalę problemu. W jednym z naszych projektów, migracja logiki geograficznej na początku wyglądała jak przeniesienie danych, aczkolwiek w trakcie okazało się, że trzeba zaprojektować pełny model regionów i tras. Zakres urósł, ale klient dostał rozwiązanie, które faktycznie odłącza nowy system od starego.
Awarie produkcyjne. Incydentów nie da się odłożyć, bo biznes musi działać, a one zjadają budżet zaplanowany na rozwój. W tym samym projekcie logistycznym zdarzało się, że zespół przerywał zaplanowane prace i reagował na awarie integracji albo problemy z importem paczek. Na fakturze widać sumę godzin, ale nie widać, ile poszło na budowanie, a ile na gaszenie pożarów.
Dwie różne dopłaty, choć brzmią tak samo
Kiedy pada „trzeba dopłacić", warto zapytać: płacimy za nową wartość i rozwiązany problem, czy za błąd w zarządzaniu projektem?
Pierwszy przypadek pojawia się wtedy, gdy wejście w szczegóły odsłania coś, czego wcześniej nie dało się zobaczyć: ukrytą zależność, większy zakres albo realne ryzyko. W zamian dostajesz działającą funkcję, usuniętą przeszkodę albo uniezależnienie od starego systemu, więc decyzję podejmujesz na podstawie nowych informacji.
Drugi przypadek wygląda inaczej, chociaż komunikat jest ten sam. Pieniądze nie kupują nowej wartości, tylko gaszą skutki złych nawyków: ciągłej zmiany zakresu, raportów o aktywności zamiast o efektach, braku decyzji po stronie biznesu czy spychania integracji i migracji na koniec projektu.
Pierwszej dopłaty w złożonym systemie i tak nie unikniesz, i nie ma w tym nic złego, o ile wiesz, za co płacisz. Druga jest sygnałem, że problem leży w sposobie prowadzenia projektu, a nie w jego trudności.
O co zapytać, zanim skończą się pieniądze
Najlepszy moment na te pytania to nie chwila, w której budżet już się wyczerpał, tylko zwykły status, kiedy masz jeszcze pole manewru.
Warto zapytać dostawcę albo własny zespół:
- Na co poszły pieniądze — rozwój, utrzymanie, incydenty, usuwanie długu technicznego?
- Co odkryliśmy o systemie, czego nie było widać na starcie?
- Które ryzyka były znane od początku, a które wyszły dopiero teraz?
- Kiedy dostaniemy sygnał, że przy tym tempie zabraknie budżetu — przed czy po fakcie?
Jeśli odpowiedzi są konkretne i zgadzają się z liczbami, jest dobrze. Jeśli słyszysz, że „ciężko to teraz rozbić", to zwykle nie brak danych, tylko brak modelu, który zamienia stan projektu w decyzję na czas.
Pomaga też podział pracy na strumienie (osobno rozwój, utrzymanie i incydenty) oraz raport o tym, co faktycznie powstało, a nie o liczbie zamkniętych zadań. Bez tego łatwo uznać, że zespół mało dowozi, chociaż w rzeczywistości trzyma system przy życiu.
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 i więcej awarii.
Przy każdej takiej sytuacji warto wrócić do jednego pytania: płacimy za nową wartość, czy za błąd w zarządzaniu? W dobrze prowadzonym projekcie dodatkowy budżet nie jest niespodzianką, tylko świadomą decyzją, a prawdziwą niespodzianką jest cisza, która go poprzedza.
Pełniej opisaliśmy cztery źródła niespodzianek, listę pytań do dostawcy i ramy raportowania w artykule o tym, skąd biorą się niespodzianki budżetowe w projektach IT.
