Ponad połowa projektów IT kończy się przekroczonym budżetem i terminem realizacji

Czy zdarzyło Ci się rozpocząć projekt IT z przekonaniem, że potrwa pół roku i zmieści się w budżecie, a rzeczywistość okazała się zupełnie inna? Według raportu Krytyczne czynniki sukcesu i porażki projektów IT w Polsce większość projektów IT niezależnie od ich wielkości kończy się przekroczeniem zakładanego budżetu i terminu realizacji. Zgodnie z budżetem zrealizowano tylko 29,71% projektów a termin został dotrzymany w przypadku 28,99% projektów.

To zjawisko nie dotyczy jedynie dużych, wielomilionowych wdrożeń, ale również mniejszych projektów systemowych.

Postanowiliśmy przyjrzeć się bliżej sytuacji, rozmawiając z przedsiębiorcami, z którymi na co dzień współpracujemy. Zapytaliśmy 13 firm z branży budowlanej, produkcyjnej i handlowej o przychodach powyżej 50 mln zł o ich doświadczenia związane z projektami IT. Wyniki są jednoznaczne. 8 na 13 badanych firm wskazało, że ich projekty znacząco przekroczyły budżet i czas realizacji. Co więcej, tyle samo przedstawicieli przedsiębiorstw przyznało, że udało się dostarczyć zaledwie ok. 50% planowanych funkcjonalności.

Takie dane jasno pokazują, że problem nie jest incydentalny, lecz systemowy. Dlaczego tak się dzieje? I jak sprawić, aby kolejne projekty IT wreszcie kończyły się sukcesem? O tym mówimy również szerzej na naszym kanale YouTube IT i Biznes.

Dlaczego tak się dzieje?

Za porażką większości projektów IT stoją bardzo podobne przyczyny.

1. Brak całościowej wizji

Wiele projektów IT startuje od przygotowania „listy funkcji” - dokumentu, w którym ktoś zebrał oczekiwania, spisał je w specyfikacji i przesłał do zespołu programistów, czy to wewnętrznych, czy zewnętrznych (Software House). Na pierwszy rzut oka wygląda to sensownie, przecież jest opisane jak system ma wyglądać.

Problem polega na tym, że taka specyfikacja ujmuje nowy projekt IT w oderwaniu od całości ekosystemu, w którym funkcjonuje firma. Każda organizacja działa w oparciu o wiele systemów, od ERP, przez CRM, po narzędzia magazynowe czy e-commerce, i to właśnie sposób, w jaki one się ze sobą łączą, decyduje o efektywności. Jeśli przed startem projektu nie zmapujemy architektury systemów oraz nie określimy priorytetów procesowych, możemy być pewni, że na etapie integracji pojawią się nieprzewidziane trudności, które znacząco wpłyną na czas i termin realizacji projektu.

2. Projekt, który nie realizuje celów

Kolejnym skutkiem braku całościowego spojrzenia na architekturę systemów i procesów w firmie jest oderwanie projektu od realnych celów biznesowych. W praktyce oznacza to, że system powstaje, ale nie odpowiada na kluczowe pytania: co chcemy osiągnąć, jakie procesy przyspieszyć, jakie koszty obniżyć, w jaki sposób zwiększyć sprzedaż.

Gdy brakuje tego punktu odniesienia, IT staje się „projektem dla projektu”. Zespół realizuje specyfikację, dostawca dowozi funkcje, ale całość nie wnosi wartości do organizacji. Zamiast narzędzia do rozwoju powstaje kosztowny produkt, który trzeba utrzymywać, choć nie wspiera strategicznych celów firmy.

3. Brak etapów wdrożenia

Częstym błędem jest próba wdrożenia wszystkiego na raz. Bez planu, bez wizji, z nadzieją, że „jakoś to będzie działać”. Firmy chcą, aby nowy system od pierwszego dnia obejmował pełną integrację, aplikację mobilną, raporty dla zarządu i automatyzację logistyki.

Tymczasem najlepsze projekty zawsze dzielą wdrożenie na etapy. Najpierw wprowadza się rozwiązania wspierające kluczowe procesy, a dopiero później kolejne funkcje. Już na etapie planowania warto przygotować roadmapę rozwoju systemu, czyli plan, który wyznacza kierunek na kilka kroków naprzód. Roadmapa daje zespołowi świadomość, jakie funkcje są ważne teraz, a które będą potrzebne w przyszłości, tak, aby obecne decyzje nie utrudniały kolejnych etapów.

Etapowe podejście ma jeszcze jedną przewagę: pozwala testować system na żywym organizmie. Firma korzysta z pierwszej części wdrożenia, sprawdza, czy rzeczywiście działa zgodnie z oczekiwaniami, a w razie potrzeby dokonuje szybkich korekt. Dzięki temu każda kolejna faza jest lepiej dopasowana do realnych potrzeb biznesu, a ryzyko kosztownych błędów znacząco maleje.

4. Zbyt optymistyczny harmonogram

Dostawcy lubią mówić: „zrobimy to w trzy miesiące”. To dobrze wygląda w ofercie, ale rzadko znajduje potwierdzenie w praktyce. Już w trakcie prac okazuje się, że integracja z ERP-em jest bardziej skomplikowana niż zakładano, a procesy w firmie wymagają przeprojektowania. Czas realizacji wydłuża się dwukrotnie, a firma czuje się oszukana - mimo że sama zgodziła się na nierealny plan.

Problem nie kończy się jednak tylko na błędnych szacunkach. Nawet jeśli harmonogram zostanie przygotowany realistycznie, często brakuje planu awaryjnego na wypadek, gdyby coś poszło nie tak. A przecież w wielu branżach, szczególnie tam, gdzie kluczowa jest sezonowość, opóźnienie wdrożenia może oznaczać nie tylko przesunięcie w czasie, ale utratę całej szansy biznesowej.

Firma, która liczyła, że system wesprze sprzedaż w okresie przedświątecznym czy w szczycie sezonu produkcyjnego, nagle zostaje z rozwiązaniem po fakcie. To wpływa nie tylko na rentowność całego roku, ale także na morale zespołu, który miał otrzymać narzędzie wspierające pracę.

Przykład z praktyki

Przejęliśmy projekt jednego z naszych klientów - firmy handlowej, która postawiła na dedykowany system e-commerce dla swojego sklepu. Wstępnie zakładano, że wdrożenie potrwa trzy miesiące. Po sześciu miesiącach prac i bez wyraźnej wizji końca klient zlecił nam audyt. Problem był poważny: zbliżał się kluczowy sezon sprzedażowy, a nowa platforma była kompletnie niegotowa.

Z audytu wynikało, że jedynie 27% funkcjonalności działało zgodnie ze specyfikacją. Co gorsza, stary system, obciążony dużym długiem technologicznym, nie był w stanie obsłużyć ruchu, jakiego spodziewał się klient. Oznaczało to realne ryzyko utraty największego źródła przychodu w całym roku.

W takiej sytuacji trzeba było działać szybko: naszym zadaniem stało się zabezpieczenie bieżącej sprzedaży i równoczesne minimalizowanie ryzyka strat. Przeczytaj pełne CASE STUDY

5. Brak osoby łączącej biznes i IT

To problem, który rzadko widać od razu, zwykle ujawnia się dopiero wtedy, gdy pierwsze elementy systemu trafiają do użytku. Najczęściej występuje w firmach, gdzie role są bardzo precyzyjnie podzielone: zarząd odpowiada za wizję i strategię („jak przejść z punktu A do A+”), a zespół IT ma ją przełożyć na rozwiązania technologiczne. Podobnie dzieje się we współpracy z zewnętrznym Software Housem. W ten sposób powstaje luka. Biznes mówi ogólnie: „chcemy rozwiązania”, które usprawni sprzedaż”, ale rzadko doprecyzowuje, jak dokładnie ma to działać. IT tłumaczy te oczekiwania na kod i technologie. Obie strony są przekonane, że się rozumieją, choć w rzeczywistości mają w głowie zupełnie inny obraz końcowego systemu.

To nie wynika ze złej woli. Programiści działają logicznie, niemal jak kod: jeśli biznes czegoś nie powiedział, traktują to jako „niepotrzebne”. Jeśli powiedział, realizują dosłownie, nawet jeśli w praktyce nie ma to sensu. Efekt? System bywa zgodny ze specyfikacją, ale nie wspiera tego, co miało być osiągnięte.

Konsekwencje są poważne i nie tylko materialne: firmy płacą za funkcje, które nie mają wartości biznesowej. Biznes uważa, że IT „nie rozumie”, a IT ma poczucie, że biznes „nie wie, czego chce”. 

Co zrobić, by projekty IT kończyły się sukcesem

Wszystkie opisane wcześniej problemy mają wspólną przyczynę: brakuje wcześniejszej, dogłębnej analizy i spojrzenia na projekt z perspektywy całej organizacji. Firmy często zaczynają od kodowania albo od listy funkcji, zamiast od pytania: jak ten system ma wspierać nasz biznes i jakie procesy naprawdę powinien usprawnić?

W dzisiejszych czasach, gdy jeden problem można rozwiązać na kilkanaście różnych sposobów technologicznych, partner technologiczny nie może być tylko „od programowania”. Software House musi pełnić rolę partnera biznesowego, który rozumie strategię firmy, jej cele i potrafi doradzić, w jaki sposób przełożyć je na rozwiązania IT. Tylko wtedy technologia przestaje być kosztem, a staje się inwestycją w rozwój.

I właśnie tu pojawiają się dwa elementy, które decydują o sukcesie projektu IT: rola CTO oraz wizja lokalna.

Wizja lokalna - fundament dobrze zaplanowanego projektu

Pierwszym krokiem, który pozwala poprowadzić projekt IT zgodnie z budżetem i harmonogramem, jest wizja lokalna. To etap, w którym zatrzymujemy się jeszcze przed rozpoczęciem wycen i koncepcji rozwiązań, i analizujemy firmę „od środka”. Rozmawiamy o tym, dlaczego w ogóle myślimy o nowym systemie: czy ma on usprawnić obsługę klientów, zwiększyć sprzedaż, a może rozwiązać problem rosnących kosztów operacyjnych? Dopiero gdy wiemy, „po co”, możemy sensownie odpowiedzieć na pytanie „jak”.

Wizja lokalna nie polega na tworzeniu kolejnej listy funkcji. To moment, w którym zespół wraz z CTO (Dyrektorem technologicznym), spędza czas w organizacji klienta, obserwuje codzienne procesy, rozmawia z pracownikami i zadaje pytania, czasem niewygodne. Dzięki temu wychodzą na jaw realne problemy, które w specyfikacji zwykle w ogóle się nie pojawiają. Przykład z praktyki

Jeden z naszych klientów planował wdrożenie platformy B2B. Wstępne wyceny zakładały wysokie koszty i rozbudowany zakres prac. Podczas wizji lokalnej okazało się jednak, że głównym problemem firmy nie był brak nowoczesnej platformy, lecz czasochłonne przyjmowanie zamówień przez handlowców drogą telefoniczną. Sama platforma B2B nie rozwiązałaby tego problemu. Dopiero zaprojektowanie rozwiązania, które uwzględniało naturalne przyzwyczajenia klientów i jednocześnie automatyzowało pracę handlowców, dało realną wartość biznesową.

CTO - most między biznesem a technologią

Drugim elementem, który decyduje o powodzeniu projektu IT, jest obecność osoby odpowiedzialnej za spójność między wizją biznesową a technologią - CTO (Dyrektor technologiczny).

CTO działa w oparciu o wnioski z wizji lokalnej. To na ich podstawie buduje architekturę systemów i koncepcję rozwiązania, wskazuje, które funkcje są priorytetem, a które można wdrożyć później. Wspiera firmę w podjęciu decyzji, czy w danym przypadku lepiej sięgnąć po gotowe rozwiązania, stworzyć coś dedykowanego czy postawić na hybrydę rozwiązań.

W wielu firmach wciąż pokutuje przekonanie, że CTO to osoba, która „zarządza programistami”. Tymczasem jego rola jest znacznie szersza. Z jednej strony rozumie język zarządu i potrafi osadzić projekt w długofalowej strategii firmy, z drugiej, przekłada te cele na język IT i koordynuje cały proces wdrożenia.

To także osoba, która potrafi powiedzieć wprost: „To rozwiązanie nie ma sensu” albo „Zróbmy to inaczej, w przeciwnym razie stracicie czas i pieniądze”. Czasem najważniejszą decyzją CTO jest odrzucenie pozornie atrakcyjnego pomysłu, który nie przyniesie wartości biznesowej.

Dzięki połączeniu wizji lokalnej i roli CTO zarząd nie musi podejmować decyzji technologicznych „w ciemno”. Ma przed sobą jasną mapę drogową projektu, opartą na realnych potrzebach biznesowych, a zespół IT dostaje klarowny kierunek. CTO staje się strażnikiem spójności i efektywności projektu, od pierwszej analizy aż po wdrożenie.

Przykład z praktyki

Jeden z naszych klientów z branży spożywczej, gdzie produkty mają zaledwie 48 godzin przydatności, zgłosił się z wizją wdrożenia systemu klasy APS (system do planowania i harmonogramowania produkcji). Po przeprowadzeniu wizji lokalnej i analizie procesów okazało się jednak, że takie podejście nie odpowiada na wszystkie potrzeby biznesowe.

CTO, pracując z zespołem i klientem, zaproponował hybrydowe rozwiązanie: system łączący funkcje APS, MES (system realizacji produkcji), ewidencji zbiorów oraz wybrane elementy CRM (system zarządzania relacjami z klientami). Dzięki temu firma nie tylko uzyskała narzędzie planujące produkcję, ale także rozwiązanie, które realnie wspiera kluczowe procesy: od zbiorów, przez logistykę, aż po obsługę klientów. Przeczytaj pełne CASE STUDY

Wycena wyższa na starcie, ta sama w praktyce.

Czy takie podejście jest droższe od zwykłej wyceny? Na pierwszy rzut oka tak. Wycena przygotowana po wizji lokalnej z udziałem CTO w 99% przypadków będzie wyższa niż ta, którą proponuje konkurencja „od ręki”. Różnica polega jednak na tym, że taka wycena jest oparta na realnych potrzebach, procesach i ograniczeniach firmy.

W praktyce koszt inwestycji okazuje się bardzo podobny, z tą różnicą, że od początku wiadomo, ile projekt faktycznie będzie kosztował. W trakcie realizacji nie pojawiają się nieprzewidziane wydatki ani kolejne dopłaty, bo wszystkie kluczowe elementy zostały uwzględnione już na starcie.

Takie podejście ogranicza ryzyko, daje zarządowi poczucie bezpieczeństwa i kontrolę nad budżetem. Zamiast projektu, który wciąż „połyka pieniądze”, firma otrzymuje dobrze zaplanowaną inwestycję w rozwój.

Podsumowanie

Projekty IT same w sobie nie muszą być ryzykowne. Ryzykowne jest dopiero podejście, w którym brakuje analizy, planu i osoby łączącej biznes z technologią. Firmy, które zaczynają od wizji lokalnej z udziałem CTO, zyskują przewidywalność, kontrolę i pewność, że technologia działa na rzecz ich strategii.

Chcesz wiedzieć, jak uniknąć błędów w projektach IT? Zobacz więcej praktycznych wskazówek na naszym kanale Youtube IT i Biznes ->

Źródło: Krytyczne czynniki sukcesu i porażki projektów IT w Polsce. Raport z badań 2016-2021 https://pti.org.pl/wp-content/uploads/2023/04/Raport_KF_do_druku_ISBN.pdf

Aneta Żych