Sześć na dziesięć projektów IT kończy się porażką. Dlaczego?

Bo mierzymy nie to, co trzeba. I budujemy nie to, czego naprawdę potrzebujemy.

Statystyki są bezlitosne: tylko 39 proc. projektów IT spełnia kryteria sukcesu. 59 proc. mieści się w budżecie, 47 proc. kończy na czas, 44 proc. dostarcza zakładane korzyści. A nawet w tych „udanych” realizacjach – uwaga – 45 proc. zbudowanych funkcjonalności nigdy nie jest używanych.

Prawie połowa. Nigdy. To nie jest problem techniczny. To problem myślenia.

„Co chcemy zbudować” vs „jaki problem chcemy rozwiązać”

Jakub Stadnik, Head of Delivery w Scalo, wskazuje na fundamentalny błąd: projekty zaczynają się od pytania „co chcemy zbudować”, zamiast „jaki problem chcemy rozwiązać”. Zakres bywa ogólny, oderwany od realiów. Oczekiwania czasowe i budżetowe – nierealne. Brakuje właściciela biznesowego, który podejmuje decyzje. Jest za to presja na natychmiastowy start, bez fazy analizy.

I projekt zaczyna dryfować.

Sukces to nie domknięcie

Dlaczego organizacje wciąż traktują zakończenie projektu jako cel sam w sobie? Bo to najprostsze do zmierzenia. Zero-jedynkowe. Projekt się skończył – sukces. Tyle że sukces biznesowy wymaga czegoś więcej: obserwacji po wdrożeniu, rozmów z użytkownikami, analizy danych.

– Projekt można uznać za udany wtedy, gdy wspiera cele biznesowe klienta, działa stabilnie w produkcji i jest dobrze przyjęty przez użytkowników – mówi Stadnik.

Do tego dochodzi jakość współpracy: komunikacja, zarządzanie zmianą, podejście do ryzyk. I coś trudno mierzalnego, ale kluczowego – poczucie klienta, że przez cały czas był profesjonalnie zaopiekowany.

Co mierzyć, skoro budżet i harmonogram nie wystarczą?

Obok klasycznych KPI coraz większe znaczenie mają metryki jakościowe: stabilność rozwiązania, liczba incydentów po wdrożeniu, skalowalność, szybkość reakcji na zmiany. Plus wskaźniki związane z doświadczeniem użytkowników – CSAT, regularny feedback.

W dojrzałych organizacjach sukces mierzy się wpływem na cele biznesowe. Nie tym, czy zakres został „dowieziony”.

Discovery, czyli zadawanie trudnych pytań

Klucz do ograniczenia ryzyk? Dobrze przeprowadzone discovery: warsztaty z interesariuszami, rozmowy o procesach, weryfikacja założeń. Trudne pytania na początku oszczędzają czas i pieniądze później.

Stadnik podaje przykład projektu dla amerykańskiego fintechu: modernizacja platformy do obsługi transakcji. Efekt? 60 proc. redukcji kosztów, 400 proc. wzrostu wydajności. MVP w dziewięć miesięcy. Ale zaczęło się od zrozumienia, co naprawdę trzeba zmienić.

Klienci szukają partnerów, nie „rąk do kodowania”

Ostatnie lata przyniosły zmianę. Większa ostrożność kosztowa, ale też wyższe oczekiwania wobec transparentności i realnego wpływu na biznes. Klienci chcą partnerów, którzy doradzą, wskażą ryzyka, pomogą podejmować decyzje w niepewnym otoczeniu.

AI i automatyzacja przyspieszają pracę, ale podnoszą poprzeczkę jakości. Agile przestaje być metodologią – staje się sposobem myślenia opartym na transparentności i bliskiej współpracy.

Puenta? Sukces projektu IT zaczyna się długo przed pierwszą linijką kodu. Wygrywają organizacje, które traktują IT nie jak koszt czy wykonawcę, ale jak partnera w rozwoju biznesu. Bo o powodzeniu nie decyduje to, czy projekt został „dowieziony”. Decyduje to, czy naprawdę coś zmienił.