Czy projekt IT może skończyć się sukcesem?

Czy projekt IT może skończyć się sukcesem? Żeby odpowiedzieć na to pytanie, trzeba zacząć od zdefiniowania czynników sukcesu. Najprościej założyć, że projekty zakończone sukcesem, to wszystkie te, które nie zakończyły się niepowodzeniem. A czym jest „niepowodzenie w projekcie IT”? O tym w dalszej części naszego wpisu.

Statystyki i raporty

Według danych Chaos i PMP projekty IT oscylują wokół podobnych, pokazanych powyżej wartości od lat. Uśredniając dane z ostatnich 8 lat i przyjmując 2% jako błąd, otrzymujmy powyższe uśrednione wyniki. A te uśrednione wartości mówią, że około 30% projektów IT kończy się sukcesem. Prawie 20% projektów jest zamykana przedwcześnie. Połowa projektów IT jest ostatecznie doprowadzana do końca, ale budżet i terminy znacząco odbiegają od założeń początkowych, niestety brak danych na temat tego, co w liczbach lub procentach znaczą owe przekroczenia.

Zatem połowa projektów IT jest kończona, ale nie według początkowych szacunków, co zwykle oznacza przekroczony budżet, czas i zmienione produkty końcowe. Oczywiście wskaźnik ten nie mówi nic na temat tego, jak wiele z tych projektów zostało dokończonych, choć ich uzasadnienie biznesowe dawno już utraciło ważność. Dzieje się tak, ponieważ domyślnie przyjmuje się, że jeśli projekt trwa, to nadal jest zasadny biznesowo (innymi słowy: przyjmuje się etyczne działanie wszystkich akcjonariuszy projektu), ale o tym, że bywa z tym różnie, przy innej okazji.

Statystki dają nam odpowiedź na tytułowe pytanie, lecz jest jednak pewne „ale”. Doświadczenie pokazuje wyraźnie, że statystyki w biznesie dyktują zwycięzcy i cele marketingowe, co nie zawsze przekłada się na rzeczywisty obraz otaczającego nas świata.

Takie raportowanie odbywa się zwykle na potrzeby statystyk w następujący sposób: najpierw sprawdza się, jak wygląda średnia na rynku, a następnie tak manipuluje się założeniami, by wynik wszystkich projektów w korporacji nie odbiegał zbyt znacząco od przyjętych, średnich założeń. Zazwyczaj powinien być trochę od nich lepszy (2-6 %, żeby zrealizować założone KPI), bo inaczej szef działu odpowiedzialnego za zarządzanie projektami będzie miał problemy. Osoby z doświadczeniem w podobnych firmach, wiedzą, że owe dopasowywanie wyników, to bardzo często złożony i nie do końca świadomy dla wszystkich proces, który opiera się na kilku wskaźnikach, wielu raportach i przyjętych założeniach metodologicznych, które bywają zmienne w czasie, ale to obszerny temat na zupełnie inną okazję.

Jeszcze jeden akapit z wyjaśnieniem dla tych, którzy odnieśli wrażenie, że przesadnie krytykujemy duże organizacje – nie to jest naszym celem. Czasem tak wiele czynników wewnątrz organizacji ma wpływ na raporty, że jeśli chcemy rzetelnie podejść do jakiegoś zagadnienia, trzeba zdać sobie z nich (tych wpływów) sprawę, żeby zrozumieć, że nie wszystkie dane z korporacji (a to one są głównym źródłem danych statystycznych, bo mają najwięcej pieniędzy i czasu na produkcję różnych danych i ich raportowanie) są jednakowo wiarygodne i czasem nawet trudno oszacować błąd pomiarowy, który może wynosić nawet do kilkudziesięciu procent, zależnie od obecnych trendów i pozycji rynkowej. Tyle tylko, że nikomu nie zależy na dostarczaniu danych pozwalających oszacować granice błędu.

Definicja projektu kończącego się niepowodzeniem

Wracając od danych raportowanych do danych rzeczywistych: znacząca część projektów kończy się niepowodzeniem (całkowitym lub częściowym).

Co zatem oznacza niepowodzenie projektu IT, o którym pisaliśmy na początku? Metodyki mówią, że właściwym zachowaniem jest zamknięcie projektu przed jego ukończeniem, czyli zanim wszystkie zdefiniowane produkty zostaną dostarczone i odebrane, jeśli projekt traci uzasadnienie biznesowe. Jak sami widzicie, metodyki nie lubią wskazywać winnych i przegranych. Zostały napisane tak, żeby ewentualną czyjąś porażkę przekształcić w lekcję, z której mogą czerpać kolejne zespoły projektowe i ratować, co się tylko da. Żartobliwie reasumując: w końcu metodyki tworzyli i tworzą głównie Kierownicy Projektów i nie przyznają się, że coś im się nie udało. Tak naprawdę to bardzo racjonale podejście, które pozwala minimalizować straty i mówi firmom jak efektywnie uczyć się na błędach. Dlatego zamiast pisać i mówić i nieudanych projektach, używa się stwierdzenia „projekty zakończone przedwcześnie”. I teraz już prawie wszystko jest jasne.
Niestety, „prawie robi różnicę”. Z doświadczenia wiemy, że nie można oprzeć się tylko na metodykach i statystykach, chyba że zależy nam wyłącznie na tym, żeby nasze raporty były zgodne z wcześniej założonymi wytycznymi, a my musimy pokazać, że „u nas jest na zielono”. Jeśli chcemy pochylić się nad rzeczywistym problemem i skupić na efektywnym jego rozwiązaniu, trzeba przyjąć, że projekty czasem się nie udają i jakoś sobie te założenia porażki zdefiniować. Jako porażkę projektu proponujemy przyjąć takie warunki, w których marnowane są zasoby (czyli włożona praca i inne koszty są niewspółmierne do rzeczywistych i potencjalnych korzyści) lub nie jesteśmy w stanie w ogóle nic wartościowego zaraportować.

Czy projekt IT może skończyć się sukcesem? Podsumowanie

Przy takich założeniach, można zdefiniować następujące powody niepowodzeń projektów IT:
a. źle zdefiniowany lub niedoszacowany projekt,
b. brak uzasadnienia biznesowego lub źle przygotowane i nieaktualizowane,
c. brak analityka biznesowego,
d. zbyt duży projekt,
e. źle dobrany zespół projektowy i niewłaściwe priorytety,
f. słabe umocowanie PM-a, brak motywacji w zespole,
g. źle dobrana metodyka,
h. zmienność organizacji,
i. zmienność środowiska zewnętrznego,
j. problemy komunikacyjne,
k. źle zdefiniowane ryzyka lub brak zarządzania nimi.

Wiele z powyżej zdefiniowanych punktów przelata się ze sobą i są bardziej lub mniej powiązane, ale postaramy się je jakoś sensownie odseparować i opisać źródła problemów, wynikające z niech komplikacje oraz ryzyka, oraz podać podstawowe techniki radzenia sobie z nimi wraz z przykładami ich wykorzystania w praktyce. Ale o tym już niebawem.

Przemek Jarocki

Project Manager w HOSTERSI

Pytania? Skontaktuj się z nami

Zobacz również:

Wsparcie DevOps – dlaczego jest mi potrzebne?

Techniczne aspekty RODO

Chmura obliczeniowa nie taka straszna. Wprowadzenie do Amazon Web Services

Przeniesienie sklepu internetowego do chmury

Czy warto zatrudniać własnego administratora?