Czy chcielibyście mieć kryształową kulę, która pokazywałaby czy projekt stworzenia i wdrożenia oprogramowania, który właśnie wystartowaliście okaże się sukcesem czy porażką? Oczywiście, że tak. Niestety nie mam takich kul na stanie, ale poniżej dostaniecie ode mnie całkiem niezły zastępnik - listę najważniejszych powodów klęsk projektów software'owych (ładne polskie słowo). Lista oczywiście nie wyczerpuje całkowicie tematu, ale bazując na moich doświadczeniach wymieniam tutaj najczęstsze sytuacje, które podpowiadają, że na projekcie nie będzie "różowo".

Dla kogo jest ten artykuł?

Poniższy artykuł jest skierowany do różnych grup ludzi, które mają swój udział w późniejszej porażce danego przedsięwzięcia. Będą to m.in.:

• pracownicy działów zakupów - odpowiedzialni za np. wybór dostawcy tworzącego oprogramowanie
• właściciele produktu (product owners) - odpowiedzialni w ramach biznesu za realizację i wdrożenie oprogramowania
• kierownicy projektów - zarówno po stronie odbiorcy / klienta, jak i po stronie dostawcy tworzonego oprogramowania
• sponsorzy projektów - osoby odpowiedzialne za strategiczne umocowanie projektu
• architekci oprogramowania - osoby odpowiedzialne za tłumaczenie języka biznesu na konkretne elementy / moduły / usługi (te małe i te duże) w dostarczonym rozwiązaniu

Jeśli w chwili obecnej nie jesteś w żadnej z tych funkcji to oczywiście nic nie stoi na przeszkodzie, żeby zapoznać się z artykułem, bo nie znasz dnia ani godziny, kiedy przyjdzie zlecenie z góry, że teraz Twoja kolej, żeby poprowadzić jakiś projekt.

Jak zdefiniować porażkę projektową?

Kiedy byłem jeszcze młodym Padawanem wierzyłem, że każdy projekt można doprowadzić do szczęśliwego zakończenia (w ten czy inny sposób). Myślałem sobie: "Wgryzę się w każdy problem, który stanie na drodze i pokonam go z aleksandryjską mądrością - jeśli nie uda mi się rozwiązać węzła gordyjskiego, to go przetnę" (piękna mieszanka młodzieńczej naiwności i wybujałego ego 😉 ). Na początku podejście to przynosiło nawet sukcesy. Niestety jak pokazała historia, było to szczęście początkującego. W miarę zdobywania doświadczenia i podejmowania się kolejnych projektów, osiągnięcie sukcesu stawało się znacznie trudniejsze, a wielokrotnie nie byłem zadowolony z tego, jak sprawy się kończyły.

Więc jak stwierdzić, że odnieśniliśmy spektakularny "antysuckes"? Można to stwierdzić jedynie poprzez porównanie oczekiwań i tego jak te oczekiwania zostały spełnione. Dlaczego mówię oczekiwania, a nie cele / założenia projektu? Wiele projektów może być uznawanych przez jedną stronę za porażkę, a przez drugą za sukces. Miałem możliwość w trakcie swojej dotychczasowej podróży przez meandry świata IT uczestniczyć w projektach zarówno jako klient dostawców oprogramowania jak i dostawca i wytwórca rozwiązań software'owych, więc spróbuję spojrzeć na zagadnienie przez pryzmat tych róznych perspektyw.

Czsami klient będzie widział sukces tam, gdzie z perspektywy dostawcy jest porażka. Przykład - tworzone oprogramowanie zostaje wdrożone, zaczyna być używane produkcyjnie i służy swojemu celowi, ale budżet został przekroczony po stronie dostawcy (bez dopłat ze strony klienta). Zespół dostawcy wypracował mnóstwo nadgodzin, żeby zmieścić się z zakresem i zmianami, a większość jego członków jest na granicy "rzucenia papierami".

Na drugim krańcu spektrum porażkowych projektów znajdziemy sukces finansowy z perspektywy dostawcy, ale za to bez produkcyjnego wdrożenia (lub wdrożenie jest tylko po to, żeby podpisać protokół odbioru). Pieniądze zostały (z perspektywy klienta) przepalone na mnóstwo przeróbek w podejściu "agile" (cudzysłów zamierzony) i rozliczeniu Time & Material, budżet został wyczerpany, a finał finałów jest taki, że nie ma nic, z czego dałoby się sensownie korzystać.

Jakie zatem są najczęstsze powody dołączenia do mało elitarnego grona >70% projektów związanych z wytwarzaniem i wdrażaniem oprogramowania, które zakończyły się porażką? Poniżej kilka wybranych, dużych przyczyn, które często się powtarzają.

Przyczyna porażki projektowej nr 1 - brak jakiegokolwiek planowania, brak / słaba analiza wewnętrzna

Jak ktoś mądry kiedyś powiedział (jakiś tam Churchil czy inny Franklin): "Failing to plan is planning to fail" (w moim wolnym tłumaczeniu: "Jeśli zapominasz o planowaniu, to planujesz porażkę"). I nie chodzi oczywiście o to, żeby raz wymyślonego super-ekstra planu trzymać się mocno niczym kleszcz swojego żywiciela. Okoliczności się zmieniają i czasami trzeba rozważyć dostosowanie planu do sytuacji, ale sam proces przygotowania planu pozwala:

• przemyśleć przynajmniej część możliwych scenariuszy,
• przygotować się na szanse i ryzyka, które mogą wystąpić,
• wiedzieć (przynajmniej na pewnym poziomie ogólności) do czego się dąży / jaki jest cel
• czy to co sobie wymyślił inicjator / inicjatorzy ma jakąkolwiek szansę na realizację

Po co? jak? dlaczego (najlepiej 5 razy 'dlaczego?')? - to tylko kilka podstawowych pytań, które warto sobie zadać zanim jako klient wyruszymy na łowy, żeby wyłonić dostawcę najnowszego rozwiązania, które sprawi, że Twój biznes będzie działał sprawniej niż wcześniej.

Jeśli organizacja nie jest wystarczająco dobrze przygotowana przed rozpoczęciem współpracy z zespołem wytwarzającym oprogramowanie, to projekt będzie błądził w losowych kierunkach, co oczywiście sprawi, że nie spełni jakichkolwiek założeń.

Nie bądź jak król Julian (z animacji "Pingwiny z Madagaskaru"), który lubi podejście: "Teraz prędko, zanim dotrze do nas, że to bez sensu".

Przyczyna porażki projektowej nr 2 - błędy w procesie zakupowym

Jeśli oprogramowanie nie będzie wytwarzane wewnątrz organizacji i trzeba posiłkować się dostawcami zewnętrznymi do gry wchodzą przedstawiciele działu zakupów. Rozpisywane są procedury przetargowe, zapraszane są już znane i czasami mniej znane firmy zajmujące się wytwarzaniem i wdrażaniem oprogramowania. Ale jeśli zgodnie z najgorszymi praktykami dział zakupów dostał polecenie kupienia w jak najlepszym stosunkku ceny do "wartości" (znaczy się najtaniej i na jutro), bez przekazania i zrozumienia prawdziwych celów procesu, to już u zarania projektu jesteśmy w słabej sytuacji, bo dom będziemy budować z pominięciem fundamentów.

"Ale jak to?" - ktoś mógłby zapytać. "A tak to" - odpowiedziałbym ja. Dział zakupów (zwany często gęsto rdzennie polskim "procurement'em"), bez sensownych wytyczynych zadziała odruchowo i zrobi z procesu zakupowego "Igrzyska śmierci" - przeżyją tylko ci najbardziej zdeterminowani (tudzież zdesperowani). "Zakupy" zarportują super wynik, bo obniżą cenę zakupu o 50%, a później na projekcie dochodzi do "mimowolnych" optymalizacji - tu właśnie znikają fundamenty. Oczywiście dostawca nie powinien się zgadzać na takie warunki, żeby być w stanie zapewnić odpowiedni poziom jakości dostarczonego produktu, ale uwierzcie mi, że zastanawianie się skąd weźmiesz pieniądze na pensje dla zespołu potrafi mocno zmienić perspektywę.

Przyczyna porażki projektowej nr 3 - niezgodność zapisów kontrakowych odnośnie metody rozliczeń projektu z rzeczywistością projektową

Duże, średnie i małe firmy chcą z góry wiedzieć - "ile to będzie kosztowało?" (duże chcą jeszcze, żeby im calkowity koszt w trakcie 5 lat od wdrożenia policzyć, ale to już opowieść na osobną notkę). No i wszystko fajnie. Jako dostawca rozwiązania z entuzjazmem odpowiedziałbym, że jeśli tylko będziemy wiedzieli co dokładnie jest do zrobienia, to powiemy (w miarę) dokładnie ile to będzie kosztowało (szacowanie samo w sobie jest przybliżeniem, a ile dokładnie wyjdzie wiemy po realizacji). I tu znowu wracamy do początku - jeśli nie został przygotowany wewnętrzny plan odnośnie celów projektu, jego zakresu, to prowadzimy w zasadzie rozpoznanie bojem w trakcie realizacji. Jeśli jakiś dostawca zgadza się w takich warunkach na rozliczenia typu "fixed price" to albo wygrał wspomniane w poprzednim punkcie "Igrzyska śmierci", albo właśnie ostro (jako organizacja) przepłacacie za realizację (dostawca musi uwzględnić duże ryzyko zmian w wycenie). Jeśli wygrał "igrzyska", to mamy kurs na katastrofę i problemy we współpracy na projekcie. Dla takich projektów sensowniejsze byłoby podejście rozliczenie "Time & Material", które ma również swoje wady i wymaga bieżącej kontroli przez klienta, czy wszystko zmierza w dobrym kierunku.

Przyczyna porażki projektowej nr 4 - ignorowanie podstaw zarządzania projektami

Czasy i metody się zmieniają, ale u podstaw projektów, które mają większe szanse powodzenia zawsze leżą te same zasady działania. Niestety często zasady te są ignorowane - czasami przez brak wiedzy, czasami świadomie. Niezmiennie jedank pomijanie / ignorowanie tych zasad przybliża projekt do porażki.

Brak zasady jednoosobowej odpowiedzialności

Jeśli nie ma jednej, wyznaczonej osoby w organizacji odpowiedzialnej za sukces projektu, to sukces tenma duże szanse się nie pojawić. Zasada jednoosobowej odpowiedzialności jest podstawią w zarządzaniu projektami, ale z jakiegoś powodu często jest pomijana przy uruchamianiu projektu. W sytuacji, gdy sukces projektu jest (potencjalnie) sukcesem wszystkich, a matek i ojców w razie wystąpienia będzie wielu, to porażka tradycyjnie będzie sierotą. W tak przygotowanym projekcie trudno o zaangażowanie w działania stricte z nim związane. Zadania te znajdą się na dole listy priorytetów, zwłaszcza, gdy ludzie masę codziennej "bieżączki" do wykonania. W tym miejscu kluczowa jest rola sponsora projektu, aby odpowiednio umocował osobę, która ramach organizacji będzie odpowiadała za realizację.

Ignorowanie trójkąta ograniczeń w zarządzaniu projektami

"Święta trójca" zarządzania projektami stanowi, że jesteśmy w realizacji ograniczeni następującymi parametrami:

• czas
• zakres
• budżet Zasada ta mówi również, że jeśli ruszymy jeden z parametrów (np. zwiększymy zakres), to nie pozostanie to bez wpływu na pozostałe dwa. I jak bardzo byśmy nie próbowali zaklinać rzeczywistości, to prawa matematyki są dosyć bezwzględne. Jeśli spróbujemy je złamać, możemy odkryć, że nasz projektowy świat zwalił nam się z hukiem na głowę.

Brak (lub słabe) zarządzanie ryzykiem

Jeśli tak jak świeżo upieczony absolwent zakładasz, że wszystko na projekcie pójdzie dobrze, to mam dla Ciebie złe wiadomości. Realizując projekt w takim podejściu okazuje się, że nie ma miejsca na pomyłkę, na chorobę jednego z członków zespołu, wszystko robione jest "na styk" i jedno małe ziarenko piasku w trybach tak ustawionej maszyny sprawia, że wszystko się sypie. Jeśli nie prowadzisz rejestru ryzyk projektowych (tych sensownych oczywiście, bo to, że nikt w ryzykach nie miał wpisanego COVIDa, czy wojny na Ukrainie jest w zupełności usprawiedliwione) i nie masz przygotowanych choćby pomysłów (niekoniecznie pełnych scenariuszy) jak działać w razie ich wystąpienia, to prosisz się o kłopoty.

Jak mówi stare anglojęzyczne przysłowie "Hope for the best, prepare for the worst", czyli "miej nadzieję na najlepsze, ale przygotuj się na najgorsze" - to powinno być motto każdej kartki z rejestrem ryzyk.

Brak procesu zarządzania zmianą

Z perspektywy zarówno dostawcy jak i klienta zarządzanie zmianą jest jednym z kluczowych elementów rogrywki, żeby ta rozgrywka zakończyła się pozytywnie dla obydwu stron. Jeśli zmiany "wślizgują" się do projektu na każdym spotkaniu projektowym klienta z dostawcą, to w ten sposób obdywie strony "wyślizgują" się ze skończenia kiedykolwiek danego projektu. Nieważne, czy realizujemy projekt w metodyce agile, czy liniowej / waterfall, czy dowolnej hybrydzie (czyli tak jak to najczęściej wychodzi w rzeczywistości) niezbędny jest wcześniej uzgodniony sposób obsługi nowych pomysłów odnośnie projektu, które z dużym prawdopodobieństem pojawią się w trakcie jego realizacji. A im dłuższy projekt, to prawdopodobieństwo będzie dążyło do 100%.

Przyczyna porażki projektowej nr 5 - brak zaangażowania interesariuszy z odpowiednim przełożeniem na organizację

Jeśli z jednej strony zostaje uruchomiony projekt zbudowanie i wdrożenia oprogramowania, które ma zmienić sposób pracy 80% załogi, ale jednocześnie nikt z najwyższych szczebli zarządzania nie czuje, że powinien aktywnie działać na rzecz projektu, to mamy doskonały przepis na katastrofę. Projekt nie będzie odpowiednio umocowany, będzie miał problemy z pozyskaniem ludzi wewnątrz organizacji do poświęcenia mu swojego czasu, przez co realizacja będzie albo przeciągać się w nieskończoność, albo pewne elementy zostaną pominięte ze względu na brak zaangażowania wymaganych osób.

Przyczyna porażki projektowej nr 6 - brak osób w organizacji oddelegowanych do zapewnienia jakości

Jeśli współpracujesz ze zewnętrznym dostawcą oprogramowania konieczne jest wyznaczenie wewnątrz organizacji osoby odpowiedzialnej (ale też kompetentnej w tej kwestii) za jakość zrealizowanego i wdrożonego oprogramowania. Im bardziej skomplikowane oprogramowanie budujesz, tym więcej czasu należy poświęcić na weryfikację, czy działa ono zgodnie z założeniami i czy robi to bez błędów (przynajmniej w kluczowych dla biznesu procesach). Potrzebny jest do tego zespół / specjalista QA, który będzie wspierał kierownika projektu. Często w praktyce widzę, że spada to na kierownika, ale nie jest to najlepsza praktyka (choć rozumiem, że często ograniczenia budżetowe, czy osobwe uniemożliwiają inne podejście).

Przyczyna porażki projektowej nr 7 - niska asertywność kierownika projektu

Zarządzanie projektami bez mówienia "nie" wielu żądaniom jest po prostu niemożliwe. Im większa organizacja, im więcej zaangażowanych osób, tym łatwiej stracić z oczu cele projektu pod stosem zgłaszanych zmian. Jeśli zgadzasz się na prawie wszystko, nigdy niczego nie dostarczysz. Kierownik projektu pozbawiony asertywności w połączeniu z projektem angażującym wielu interesariuszy (z których niektórzy mogliby byź zadowoleni, gdyby projek się nie powiódł) to pewna droga do porażki.

Przyczyna porażki projektowej nr 8 - łączenie lub nieprawidłowe przydzielenie odpowiedzialności

Przykładem takiego mocno ryzykownego łączenie odpowiedzialności będzie sytuacja, gdy kierownik projektu wykonuje mnóstwo pracy poza organizacją projektu, komunikacją i aktywnym nadzorem, np. zadania z obszarów: analiza, rozwój, zapewnienie jakośći, itp. Im większy projekt, tym większa możliwość porażki z powodu braku rozdziału obowiązków, gdyż kierownnik stanie się wąskim gardłem. Zamiast być facylitatorem i kimś, kto usuwa przeszkody na drodze zespołu, stanie się przeszkodą.

Przyczyna porażki projektowej nr 9 - Nieprawidłowy dobór technologii, niedopasowana architektura rozwiązania

Zespół dostarczający oprogramowanie naciska na używanie najnowocześniejszych technologii. Na początku wygląda to fajnie, ale w trakcie prac okazuje się, że zespół nie jest gotowy na wyzwania / ograniczenia, które wybrana technologia przed nimi stawia (i kiedy będzie już za późno na zmiany). To samo dotyczy architektury - złe wybory dokonane na początku będą się odbijać czkawką przez resztę trwania projektu, a nawet długo po jego zakończeniu w okresie utrzymania i rozwoju. W momencie, gdy zespół uświadamia sobie w jakkim położeniu się znalazł i dodatkowo zaczyna zbliżać się termin dostarczenia produkty włącza się tryb paniki i finalnie otrzymujemy produkt, który w jakimś zakresie jest zgodny z dobrymi praktykami, a reszta działa powiązana szurkami i klejona na gumę do żucia.

Przyczyna porażki projektowej nr 10 - Niedoświadczony zespół wykonawcy

Nie zrozumcie mnie źle - wiem ile można dostarczyć zaangażowanymi i łebskimi "studentami". A wiem to stąd, że sam to niejednokrotnie zrobiłem. Nie zmienia to faktu, że jeśli cały zespół będzie składał się tylko z osób, które mają zerowe lub niewielkie doświadczenie w projektach komercyjnych, to czasami po prostu nie będą w stanie podjąć sensownej decyzji.

Przyczyna porażki projektowej nr 11 - Problemy w komunikacji

Mamy coraz więcej narzędzi do komunikowania się. Możemy być w stałym kontakcie przez telefon, mail, slacka, zooma czy inne technologie (np. dla bardziej starświeckich jak ja - spotkania na żywo). Jednak jeśli ta komunikacja nie ma ustalonych na początku zasad, ustalenia nie są wiążące i często się zmieniają miotając projektem we wszystkie strony, to taka "komunikacja" jest tylko i wyłącznie szumem informacyjnym, który nie pomaga realizować projektu. Wręcz przeciwnie - jest gwoździem do trumny danego przedsięwzięcia. Niezależnie od tego jaka forma / kanały komunikacji zostanie ustalona przez strony projektu muszą być jasne kryteria jak i dlaczego dana informacja wpływa na projekt.

Podsumowanie

W większośći przypadków porażki projektowe (z perspektywy organizacji je inicjujących) biorą się z błędów już u zarania projektu. Od idei do realizacji droga w takich projektach jest bardzo krótka i nie ma czasu na choćby odrobinę refleksji na temat celów, ram czasowych, czy jakiejkolwiek sensowności takiego przedsięwzięcia. Z perspektywy dostawców oprogramowania porażka zazwyczaj bierze się ze zbytniej desperacji jeśli chodzi o chęć zrealizowania danego projektu i godzenie się na dowolne warunki stawiane przez zamawiającego, czy oddelegowanie do projektu osób ze zbyt małym doświadczeniem. Wszystko na końcu spina komunikacja - jeśli będą w niej zatory (za mało), albo wodospady (za dużo, nie do przetworzenia), to ciężko finalnie uzyskać efekt zadowalający dla wszystkich zaangażowanych.