Jak wygląda realizacja projektów IT w Polsce? Wdrożenia systemów ERP, CRM, BI, DMS w okresie 2016-2023

Od wielu lat, na świecie prowadzone są badania dotyczące realizacji projektów IT. Co ciekawe, większość projektów nie spełnia swoich oczekiwań. Niedotrzymywane terminy, problemy z jakością, przekroczenia budżetu, niezadowolenie klientów – to tylko niektóre z przyczyn niepowodzeń.

Dlaczego tak się dzieje? Czego możemy się nauczyć z poprzednich projektów, aby zwiększyć powodzenie przyszłych?

Na te pytania od lat szuka odpowiedzi Jim Johnson, założyciel Standish Group. Wraz ze swoim zespołem od wielu lat prowadzi cykliczne badania, które dostarczają nam cennych informacji na temat przyczyn niepowodzeń związanych z wdrażaniem projektów IT. Raport CHAOS przygotowywany przez Standish Group pokazuje, że nadal znacząca liczba projektów IT kończy się w niepowodzeniami.

Przyczyny niepowodzeń projektów IT są tematem złożonym. Mogą być spowodowane przez czynniki wewnętrzne, takie jak niejasne wymagania, braki w zarządzaniu projektami lub niewystarczające zasoby. Mogą być również spowodowane przez czynniki zewnętrzne, takie jak zmiany w otoczeniu biznesowym lub nieprzewidziane zdarzenia.

Jak wygląda realizacja projektów IT w Polsce? Zapraszam do lektury wyników moich badań, które mam nadzieję, że skłonią kadrę zarządzającą firm do własnych wniosków i refleksji w tym temacie.

W ramach badań postawiłem sobie następujące pytanie:

Ile projektów IT kończy się sukcesem, częściowym sukcesem lub porażką?

Metodyka badań

• badane projekty IT polegały na wdrożeniu systemów ERP, CRM, BI, DMS
• badania były prowadzone w okresie 2016 – 2023
• badania prowadziłem wykorzystując metodę ankietowa poprzez rozmowę telefoniczną, spotkania, lub korespondencję mailową
• badania prowadziłem wśród przedsiębiorstw średnich i dużych zgodnie z definicją UE
• respondentami byli kierownicy projektów, CFO, CIO, członkowie zarządu, prezesi, właściciele firm
• budżety badanych projektów IT znalazły się w przedziale od 50 000 do 2 mln PLZ
• ograniczenia badawcze:
• ograniczona próbka badawcza, która nie jest próbka reprezentatywna dla całkowitej liczby średnich oraz dużych przedsiębiorstw w Polsce
• ograniczony okres badawczy, zawężony do 8 lat
• firmy na terytorium Polski z kapitałem polskim i zagranicznym
• badania dotyczyły systemów informatycznych przeznaczonych do kastomizacji, nie zaś pisanych od podstaw
• przedstawione badania z racji wymienionych ograniczeń mogą stanowić badania pilotażowe do szerszych badan w tym zakresie

Tabela 1. Definicje projektów stosowane w badaniach

Tabela 2. Rezultaty badań 

Poniżej na wykresach 1-3 przedstawiono rezultaty badań wykorzystania metodyki zwinnej i sekwencyjnej w trzech grupach badanych projektów zakończonych sukcesem, częściowym sukcesem oraz porażką. 

Wykres 1. Struktura wykorzystania metodyk w projektach zakończonych sukcesem 

Wykres 2. Struktura wykorzystania metodyk w projektach zakończonych częściowym sukcesem

Wykres 3. Struktura wykorzystania metodyk w projektach zakończonych porażką

Finansowanie projektu IT

Na rysunku 4-6 przedstawiono rezultaty badań dot. metody wyceny i rozliczenia realizacji projektów (stały budżet versus budżet zmienny wyliczony jako iloczyn stawki godzinowej pracy konsultanta oraz czasu spędzonego na realizacji zadania-projektu) w trzech grupach badanych projektów zakończonych sukcesem, częściowym sukcesem oraz porażką.

Sposób rozliczenia realizacji projektów był uzgadniany na etapie sprzedażowej. Wyróżniono w badania dwa sposoby rozliczenia tj. 

• Stały budżet finansowy projektu IT. Oferta zawierała szczegółowo określony zakres funkcjonalny i technologiczny projektu oraz stały budżet realizacji zadań projektowych. Zakres projektowy został określony w procesie sprzedaży w ramach oddzielnych warsztatów dostawcy oraz odbiorcy. 

• Budżet zmienny projektu IT. Oferta zawierała ogólnie określony zakres funkcjonalny i technologiczny projektu określony w ramach oddzielnych warsztatów dostawcy oraz odbiorcy lub w ramach wstępnej analizy funkcjonalnej lub PoC. Strony określiły szczegółowy harmonogram projektu. Strony uzgodniły, iż będą się rozliczać w oparciu o raportowany miesięcznie czas spędzony na realizacji konkretnych zadań projektowych z harmonogramu. W takim podejściu w chwili rozpoczęcia projektu IT nie są znane precyzyjnie całkowite koszty wdrożenia, a jedynie szacowane kwoty.

Wykres 4. Struktura budżetów wdrożeniowych w projektach zakończonych sukcesem w ujęciu procentowym

Wykres 5. Struktura budżetów wdrożeniowych w projektach zakończonych częściowym sukcesem w ujęciu procentowym

Wykres 6. Struktura budżetów wdrożeniowych w projektach zakończonych porażką w ujęciu procentowym

Wnioski z badania

• znaczący spadek liczby projektów zakończonych porażką na przestrzeni 8 lat. Jednak nadal zgrubnie jeden projekt IT na cztery rozpoczęte kończy się porażką, co powinno zmuszać menadżerów do refleksji i działania

• wzrost liczby projektów zakończonych sukcesem jest obserwowany w okresie wzmożonej niepewności tj. pandemii, wojny

• projekty zakończone porażką kończyły się w następujący sposób:

• system nie był uruchomiony,
• system był uruchomiony jedynie w bardzo ograniczony zakresie,
• konfliktem między dostawcą a odbiorcą, który prowadził do procesu sądowego,
• zmianą dostawcy usług wdrożeniowych,
• rozpoczęciem wdrożenia nowego, innego systemu,
• rozpoczęciem audytów po nie udanym wdrożeniu w celu zebrania materiałów dowodowych,
• rozpoczęciem reimplementacji

• na uwagę zasługuje fakt, iż w grupie projektów zakończonych sukcesem lub częściowym sukcesem obserwowane jest coraz większe wykorzystanie metodyki zwinnej na przestrzeni 8 lat

• na uwagę zasługuje fakt, iż w grupie projektów zakończonych sukcesem lub częściowym sukcesem obserwowane jest coraz większe wykorzystanie koncepcji budżetu zmiennego na przestrzeni 8 lat

• rezultaty badań skłaniają do wniosku, iż uelastycznienie podejścia do realizacji projektu poprzez wybór metodyki zwinnej oraz uzgodnienie elastycznego budżetu wdrożeniowego może być jednym z istotnych czynników wpływających na skuteczność zakończenia projektów IT dla wybranej grupy projektów w szczególności w uwarunkowaniach niepewności.