Czy nadchodzi zmierzch projektów IT i PMów?

Uwaga! To nie będzie kolejny artykuł o mniej lub bardziej standardowych elementach umów wdrożeniowych. To nie będzie choćby artykuł o najczęściej spotykanych problemach i nieszablonowych sposobach na ich rozwiązanie (choć i na takie treści – mamy nadzieję, niebanalne i interesujące – zapraszamy już niedługo).

W nadchodzących miesiącach podzielimy się z Państwem naszą wiedzą i doświadczeniami dotyczącymi różnych rodzajów umów IT. Będzie praktycznie, przystępnie i życiowo. Ale zanim przejdziemy do rozkładania umów IT na części pierwsze, nasz cykl wpisów rozpoczynamy spojrzeniem na projekty IT z lotu ptaka i nieco prowokacyjnymi wnioskami*.

* Project managerów i fanów metodyki waterfall z góry przepraszamy za stres spowodowany poniższym materiałem

Około 30% projektów IT skazanych jest na porażkę

Wdrożenia IT nie bez powodu owiane są sławą trudnych i związanych z niestandardowo wysokim ryzykiem niepowodzenia. Sztampowo już przytacza się statystykę – ok. 30% projektów IT skazanych jest na porażkę. Skąd te liczby?

Faktycznie statystyka od lat jest nieubłagana. The Standish Group, niezależna międzynarodowa firma badawcza, od 1994 r. cyklicznie – co ok. 2 lata – publikuje raporty prezentujące dane dotyczące sukcesów i porażek projektów informatycznych. Dane gromadzone sa już przez 25 lat (!) i obejmują ponad 50 000 projektów.

Badanie niezmiennie pokazuje, że:

• ok. 50% projektów jest doprowadzanych do końca, jednak wiążą się z przekroczeniem czasu, budżetu lub niedowiezieniem kompletu funkcjonalności;
• ok 20% projektów kończy się porażką – zostaną anulowane lub porzucone;
• ok 30% projektów kończy się sukcesem – zostają ukończone w terminie, założonym budżecie i z kompletem funkcjonalności

Odchylenia od tego trendu na przestrzeni ostatnich dwóch dekad nie są znaczące. Mogłoby się wydawać, iż rozwój technologii czy choćby wykorzystywanie doświadczeń z ciągle rosnącej liczby realizowanych wdrożeń istotnie zwiększy szanse na powodzenie projektów. Jednak nie widać takiego przełożenia.

Pewien wpływ na statystyki ma sposób zdefiniowania “sukcesu”. Tradycyjną miarą sukcesu w statystykach The Standish Group była Żelazna Triada: realizacja na czas, w budżecie i w zakresie (założonych funkcjonalnościach). W ostatnim dziesięcioleciu przewagę uzyskało podejście, zgodnie z którym o sukcesie projektu powinna świadczyć poziom satysfakcji z efektów oraz wartość, którą te efekty przynoszą organizacji. Statystyka dla Żelaznej Triady i współczesnego podejścia przygotowana w oparciu o dane oparte na bazie 50.000 projektów prezentuje się następująco:

Podejście “tradycyjne” może być o tyle złudne, iż prezentuje ocenę powodzenia projektu od strony “biurokratycznej” – czy dostarczono to, na co się umówiono. Nie uwzględnia natomiast żywego problemu – czy to, co zamawiający otrzymał odpowiada jego realnym, aktualnym potrzebom i niesie za sobą wartość. o ile te dwa warunki są spełnione, często przekroczenie czasu, budżetu czy zmiany założonych funkcjonalności przestają mieć przesądzające znaczenie dla oceny tego, czy projekt to faktyczny sukces. Z kolei spełnienie wszystkich elementów Żelaznej Triady nie musi oznaczać, iż zamawiający oceni projekt jako udany. przez cały czas może on rozmijać się z aktualnymi potrzebami i nie wnosić do organizacji wartości dodanej, w rezultacie skłaniając do przemyśleń, czy była to inwestycja warta zaangażowanego czasu i zasobów?

Jakie projekty IT są najbardziej narażone na porażkę?

Analiza szczegółowych danych i wniosków płynących z raportu daje pewien obraz tego, jakie projekty wiążą się z większym ryzykiem fiaska. najważniejsze znaczenie z perspektywy ryzyk wydają się mieć dwa czynniki:

• metodyka prowadzenia projektu,

• rozmiar przedsięwzięcia.

Niezależnie od rozmiaru projektu, te prowadzone w metodykach zwinnych cieszą się wyższym odsetkiem sukcesu. Dane z raportu z 2020 r. zestawiają 42% udanych projektów zwinnych z zaledwie 13% udanych projektów kaskadowych.

Porównanie projektów prowadzonych w obu metodykach z uwzględnieniem podziału na małe, średnie i duże przedsięwzięcia pokazuje, iż tylko w przypadku małych projektów różnica pomiędzy obiema metodykami nie jest diametralna: w przypadku zastosowania metodyk zwinnych 59% projektów zakończono sukcesem, przy odsetku 45% udanych projektów prowadzonych w Waterfall.

Im większy projekt, tym rośnie przepaść pomiędzy obiema metodykami, o ile chodzi o szanse na udane zakończenie. Projekty w metodyce Waterfall w przypadku dużych i średnich przedsięwzięć wiążą się z 2-3 krotnie mniejszym prawdopodobieństwem zakończenia sukcesem niż te prowadzone zwinnie. I tak 19% dużych projektów agilowych powinno zakończyć się powodzeniem. o ile wybierzemy metodykę Waterfall – będzie to już zaledwie 8%

Statystyka pokazuje zatem zabójczą kombinacje – o ile lubisz ryzyko i życie na krawędzi, realizuj duże projekty w podejściu kaskadowym. Komplikacje wydają się niemal gwarantowane. Ale…

Czy Agile zapewnia większą szansę sukcesu?

Dane mówią same za siebie. Nie ryzykowałabym jednak tak prostego wnioskowania w przypadku każdego przedsięwzięcia. Doświadczenie pokazuje, iż ostatecznie na wdrożenia w zwinnej metodologii częściej decydują się zamawiający o większej dojrzałości w obszarze IT, co może mieć pewien wpływ na korzystniejszą statystykę.

Zaskakujący i dający wiele do myślenia jest inny wniosek płynący z najnowszego raportu The Standish Group. Aż do edycji z 2020 r. autorzy rekomendowali wykorzystanie we wdrożeniach IT podejścia projektowego, udziału Project Managera i narzędzi do zarządzania projektami, wskazując, iż są to najważniejsze elementy przekładające się na sukces przedsięwzięcia. Najnowsze badania prowadzą do całkowicie odmiennych wniosków.

Szokujące dane dotyczą wpływu poziomu kompetencji lub choćby samej obecności PMa na sukces projektu. W przypadku projektów zwinnych, udział wysoko wykwalifikowanego PMa zapewniał powodzenie zaledwie 18% projektów. W projektach, w których PMa nie było w ogóle lub cieszył się niewielkimi kompetencjami, odsetek sukcesu projektu wzrastał do oszałamiających 91%, przy jedynie 1% projektów zakończonych całkowitą porażką. W przypadku nie-zwinnych metodyk, wysoko wykwalifikowany PM dawał 23% pozytywnie zakończonych projektów, a brak PMa lub PM o niskich kwalifikacjach – aż 53% udanych przedsięwzięć. Kwalifikacje PMa okazały się dużo mniej istotne niż zdolności interpersonalne osoby zarządzającej projektem, szybkość podejmowania decyzji i unikanie biurokracji w zarządzaniu projektem.

The Standish Group publikuje też twarde dane pokazujące, że:

• podejście do wytwarzania systemu jako z góry zdefiniowanego projektu, a nie ciągłego, cyklicznego procesu, drastycznie obniża szanse osiągnięcia sukcesu – w tym zwłaszcza dojścia do rezultatu skutkującego satysfakcją klienta i wartością dodaną dla organizacji;
• wykorzystanie narzędzi do zarządzania projektami zwiększa ryzyko porażki przedsięwzięcia i około dwukrotnie zwiększa jego koszty (!).

Czy nadszedł czas na zmianę myślenia o realizacji wdrożeń i ostateczny zmierzch klasycznej kaskadowej metodyki?

Dane jasno pokazują, iż trzymanie się dotychczasowych utartych schematów w żaden sposób nie jest gwarancją bezpieczniejszej realizacji wdrożenia IT. Wręcz przeciwnie – są one czynnikiem istotnie zwiększającym ryzyko porażki, nieprzewidzianych kosztów i opóźnień.

Wniosek postawiony przez The Standish Group mówi o tym, iż od początku byliśmy w błędzie usiłując wcisnąć wytwarzanie systemu w ramy projektu. Oprogramowanie to nie budynek, a próby podobnego zdefiniowania programu komputerowego prowadziły i niezmiennie prowadzą do tego, iż znakomita większość takich projektów nie zakończy się pełnym sukcesem – chyba, iż mówimy o małych i prostych wdrożeniach.

Jeżeli nie projekt, to co?

Alternatywą jest podejście procesowe – praca nad oprogramowaniem jako jeden z ciągłych procesów wpisanych w funkcjonowanie organizacji, obejmujący cykl planowania, realizacji, weryfikacji i ustanowienia standardów na przyszłość. Nasuwa to oczywiście pytania o kontrolę nad kosztami, czasem, dowiezionymi funkcjonalnościami. Bez wątpienia są to wyzwania, które muszą być zaadresowane i na które odpowiedź może przynieść dobrze skonstruowana umowa . Nie zmienia to jednak wniosku, iż dotychczasowe projektowe podejście, jak pokazują dane z kolejnych CHAOS Reports, wcale nie stanowiło remedium na te bolączki.