Skąd się biorą opóźnienia w projektach informatycznych?

Grzegorz Papaj, 12 czerwca 2019

Opóźnienia na projektach
Opóźnienia na projektach

Przekroczenie terminu jest w projektach informatycznych zjawiskiem dość powszechnym. Jak wynika z badania PMresearch.pl, aż 61% projektów oddawanych jest po czasie, zaledwie 33% w terminie, i tylko 6% przed terminem. Tym samym ocena skuteczności realizacji projektów przez zamawiających najczęściej jest dość niska.
Z czego wynikają późnienia w projektach? Dowiedz się, o czym warto pamiętać, aby projekt programistyczny został zrealizowany o czasie.


Wyzwania po stronie wykonawcy?

W przypadku opóźnień na projekcie najczęściej obwiniany jest wykonawca. Zwykle słusznie, ale jednak nie zawsze, o czym napiszemy dalej. Teraz jednak przyjrzyjmy się najczęstszym błędom popełnianym przez dostawców usług programistycznych.

Większość przyczyn opóźnień pojawia się jeszcze przed przystąpieniem do realizacji projektu informatycznego, czyli podczas wstępnej analizy. Na tym etapie należy oszacować ile pracy i czasu będzie wymagane, aby projekt został zrealizowany z sukcesem tj. w założonym zakresie, terminie i budżecie. Wiadomym jest, że tego typu prognozy są zawsze tylko przybliżeniem i ich precyzja maleje wraz ze wzrostem wielkości projektu. Czyli szanse na poprawne oszacowanie zmniejsza skala przedsięwzięcia. Oczywiście ryzyko błędu szacowania powiększa również brak doświadczenia w realizacji podobnych projektów. Przez „podobne projekty” rozumieć należy nie tylko specyfikę biznesową czy technologiczną systemu. Istotna jest również jego skala, ponieważ wykonawca systemy na 10.000 użytkowników stoi przed zupełnie innymi wyzwaniami niż twórca systemu, z którego korzysta 100 użytkowników.

Osobny problem stanowi niedoszacowanie trudności i złożoności przedsięwzięcia. To częsty błąd początkujących programistów, którzy często nie doceniają złożoności przedstawionego przed nimi problemu. Jeśli w zespole brak doświadczonych specjalistów, którzy mierzyli się już z podobnymi projektami, szansa już nawet nie na opóźnienie, lecz na całkowitą porażkę projektu rośnie dramatycznie.

Dość często zdarza się, iż klienci uparcie twierdzą, iż ich projekt „jest mały i nieskomplikowany”. W ten sposób (mniej lub bardziej świadomie) naciskają na dostawcę, próbując obniżyć cenę realizacji. Niestety nawet doświadczonym programistom zdarza się ulec sugestiom klientów, przyjmując pod presją klienta szacowanie optymistyczne zamiast realistycznego. Prowadzi to do minimalizowania (lub nawet całkowitego pomijania) stosowanych zwykle przy szacowaniach marginesów bezpieczeństwa. W efekcie podczas realizacji powstają nie tylko opóźnienia lecz również liczne napięcia na linii klient-wykonawca, gdy obie strony wzajemnie zarzucają sobie winę. Do najczęściej niedoszacowanych aspektów projektów informatycznych należą choćby wszelkiego rodzaju integracje z zewnętrznymi systemami oraz nieuwzględnienie obciążeń systemu wynikających np. z dużej liczby użytkowników lub rekordów w bazie danych.

Z kolei opóźnienia na etapie tworzenia projektu programistycznego często są powodowane problemami komunikacyjnymi. Mogą one wystąpić zarówno wewnątrz zespołu programistycznego (lub przy większych projektach pomiędzy zespołami), jak i na linii klient-wykonawca. Chociaż wydawać by się mogło, że w tym drugim przypadku wina leży po obu stronach, to jednak nie zawsze tak jest. W końcu to wykonawca rutynowo prowadzi projekty, więc to on ponosi większą odpowiedzialność za większość problemów komunikacyjnych. Doświadczony wykonawca powinien je wykryć już na wczesnym etapie i wprowadzić działania prowadzące do usprawnienia komunikacji z klientem. Przykładem takich działań jest choćby prowadzenie projektu w metodyce Scrum czy w pokrewnych metodykach programowania zwinnego (agile).

Na niedotrzymanie terminu realizacji projektu wpływają oczywiście także „standardowe problemy”, pojawiające się podczas realizacji, a niestety nie zawsze możliwe do przewidzenia i do uniknięcia. Mają one różną naturę – może to być choroba kluczowego członka zespołu, odkryty przy realizacji niebagatelny problem techniczny czy też luka w dostarczonej przez klienta specyfikacji. To właśnie im ma zapobiegać stosowanie wspomnianych wcześniej marginesów bezpieczeństwa w szacunkach czasów i kosztów.


Wyzwania po stronie klienta?

Choć klientom zwykle trudno przyjąć to do wiadomości, opóźnienia w realizacji projektu informatycznego mogą być spowodowane również ich działaniami lub zaniechaniami. Najczęstsze problemy dotyczą sfery komunikacyjnej. Nie dość szczegółowe określenie potrzeb zwiększa błąd przy szacowaniu czasu (i kosztów), rodząc dodatkowo napięcia podczas realizacji. Często wynika to z bagatelizowania przez klienta wiedzy specjalistycznej, jaką on sam posiada. Dla zamawiającego spora część aspektów wiedzy dziedzinowej, rzutujących na ostateczny kształt systemu informatycznego, jest oczywista. Należy jednak pamiętać, że nawet najlepszy programista może kompletnym laikiem w obszarze biznesowym klienta. Chociaż zespół programistów wie jak wykonać dany system od strony technicznej, to jednak zawsze klient jest tu specjalistą. Brak dostatecznego zaangażowania oraz błędne założenie, że niektóre kwestie „są oczywiste”, to prosta droga do niewłaściwej implementacji, a co za tym idzie do znaczących opóźnień.

Kolejną częstą trudnością podczas realizacji projektu jest niezdolność klienta od podejmowania kluczowych decyzji. W miarę postępu prac przed zespołem projektowym pojawia się szereg wyborów o charakterze nie tylko technicznym lecz biznesowym. O ile w kwestiach technicznych można zdać się na ekspertyzę wykonawcy, to w kwestiach biznesowych klient ma już trudniej. Decyzję, które z możliwych rozwiązań zrealizować, powinien podjąć znający specyfikę swego biznesu klient. Niestety często podejmowanie takich decyzji zajmuje klientowi bardzo dużo czasu. Nierzadko wymagane jest zaangażowanie wielu osób, a czasem również godzenie oczekiwań różnych grup interesu (np. różnych działów). W efekcie zdarza się, że prace w niektórych obszarach rozwoju systemu muszą być wstrzymane. Sytuacja taka może wynikać z nieprzemyślenia koncepcji biznesowej, którą ma realizować system. Niekiedy także do koordynacji projektu po stronie klienta delegowana jest osoba o niepełnej mocy decyzyjnej. W tym miejscu warto jeszcze raz podkreślić, że doświadczony wykonawca powinien zminimalizować opóźnienia wynikające z braku decyzyjności klienta. Ale w wielu przypadkach nadal są one nie do uniknięcia.

Wbrew pozorom członkowie zespołów programistycznych zauważają także, że opóźnienia wynikają z brak zaangażowania klienta, co wyraża się na różne sposoby. Poza wspomnianym brakiem zdolności decyzyjnych klienci przyczyniają się do opóźnień np. nie dostarczając na czas obiecanych, a z punktu widzenia developmentu, kluczowych informacji lub komponentów systemu. Może to być np. serwer do hostowania systemu, dane dostępowe, API umożliwiające integrację z innymi programami lub specyficzny sprzęt, z którym ma współpracować system.

Jeszcze innym przykładem braku zaangażowania jest unikanie testowania wczesnych prototypów. Choć może to być zajęcie czasochłonne, to daje nieocenione korzyści również klientowi. Wczesna konfrontacja wyobrażeń wykonawcy z oczekiwaniami zamawiającego pozwala uniknąć nieporozumień już w pierwszych fazach powstawania systemu. Oczywiście opóźnienia mogą wystąpić także na etapie testów końcowych. Jeśli klient nie testował prototypów, to jest to właśnie moment, kiedy zaczyna się uczyć systemu. Często dopiero wówczas odkrywa, że testy klienckie systemu informatycznego są dużym przedsięwzięciem i nie da się ich zrealizować w jedno popołudnie.


Niestety bez względu na źródło opóźnień, w ślad za nimi idą konsekwencje. Najczęściej są to szkody biznesowe wynikające z opóźnionego uruchomienia systemu, ale czasem również różnego rodzaju niedociągnięcia i problemy wywołane tworzeniem systemu „na szybko”. W skrajnych przypadkach może to prowadzić do powstania „rozgrzebanego” systemu.