W tym odcinku opowiadam dlaczego projekty informatyczne nie kończą się sukcesem i co zrobić, aby Twój projekt IT uniknął takiego losu.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 4, pięć typowych przyczyn porażek projektów informatycznych i jak ich unikać? Jest to odcinek dosyć wyjątkowy, ponieważ jest to pierwszy odcinek, który nagrywam już po premierze, także mam nadzieję, że uda mi się uwzględnić różne sugestie, które otrzymałem od was, słuchaczy, w ramach różnych kanałów społecznościowych, czy po prostu w bezpośrednich rozmowach. Ten odcinek jest niezwykle pojemny, szeroki, bardzo specyficzny ponieważ można wymienić bardzo różne przyczyny porażek projektów informatycznych. Jest to w zasadzie kwestia mocno uznaniowa i ja opieram się głównie na swoich doświadczeniach, a także na doświadczeniach, o których słyszałem od innych zaprzyjaźnionych osób z firm informatycznych. Nie oznacza to jednak, że nie zastanowiłem i nie zagłębiłem się w ogólnodostępne raporty i widzę pewne pokrewieństwa, podobieństwa. Mimo wszystko dla mnie priorytet stanowią własne doświadczenia, bo to właśnie o nich mogę opowiedzieć z dość dużą dokładnością.

Zacznę chyba tradycyjnie od zdefiniowania problemu, czyli co rozumiem przez pojęcie „projekt informatyczny”? Będziemy się głównie skupiać na projektach związanych z realizacją oprogramowania dedykowanego, bo na tym znam się najlepiej. Natomiast warto pamiętać, że podobne problemy mogą dotyczyć również projektów, w których istotną rolę gra wdrożenie infrastruktury technicznej, choć mogą występować pewne różnice. Przez projekt mam też na myśli przedsięwzięcie o pewnym skończonym czasie, o konkretnym zakresie realizacji celu, choć trzeba pamiętać, że efekty i konsekwencje takiego wdrożenia projekt informatycznego z reguły wykraczają poza okres jego realizacji. Szykując się do realizacji tego odcinka postanowiłem skorzystać z własnych doświadczeń, spisywałem różnego rodzaju negatywne doświadczenia, które miałem i mieliśmy jako firma w naszej historii; jak również te, które zasłyszałem od innych osób i tak się złożyło, że tych przyczyn wyszło pięć. Oczywiście jakby poszukać głębiej pewnie można by było dopisać kilka interesujących zagadnień, może będzie to temat na drugą część tego odcinka. Natomiast to co te pięć przyczyn wiąże ze sobą, to to, że dotyczą one różnych etapów realizacji projektu informatycznego.

Zaczynamy od razu z grubej rury, przyczyna numer jeden to brak biznesowego uzasadnienia projektu. Nie zliczę sytuacji, w których nasi klienci na zadanie przez nas pytanie, dlaczego właściwie chcecie państwo zrealizować ten projekt odpowiadali na przykład: bo jest to teraz modne, zrobienie apki webowej czy mobilnej; bo ma ją konkurencja; bo jeżeli takiej aplikacji nie zrobimy, to klienci mogą uznać, że jesteśmy w tyle za konkurencją. Każdy z tych powodów jest w porządku, ale po to, aby w ogóle zacząć dyskusję na temat sensu istnienia aplikacji. Oczywiście, że fakt istnienia jakiejś apki u naszej największej konkurencji jest dobrym powodem do dyskusji, ale zdecydowanie jest to zbyt mały powód, aby od razu przejść do jej realizacji. Trzeba określić na początku cel, jaki problem rozwiązuje dany projekt? Jakie jest kryterium czy metryka sukcesu? Tutaj oczywiście można takie kryteria w najprostszy sposób podzielić na dwie części; albo firma zwiększy przychód na przykład przez dotarcie do nowych klientów, albo ograniczy koszty, co też wpłynie na końcowy dochód. Mogą być też korzyści niekoniecznie stricte finansowe, można powiedzieć pośrednie korzyści marketingowe, na przykład myśmy współpracowali z klientem, który dostarczał pewne fizyczne towary, natomiast za pomocą naszego oprogramowania budował niejako wizerunek marki nowoczesnej, zwiększał przywiązanie do swojej marki, co może nie dawało mu bardzo bezpośrednich korzyści, ale zdecydowanie wzmacniało jego markę, brand. Jeżeli jest to jednak możliwe, warto na początku projektu zdefiniować możliwie obiektywną metrykę, miarę, do której później, na koniec projektu, będzie można wrócić i stwierdzić czy projekt faktycznie się udał. Bo sam fakt, że dany projekt zostaje dostarczony w terminie, to trochę za mało, aby mówić o pełnym sukcesie, można powiedzieć, że jest to warunek konieczny, ale zdecydowanie nie wystarczający. Co ciekawe, takie kryterium sukcesu wpływa pozytywnie również na zespół deweloperski, my mieliśmy taki projekt, w którym wiedzieliśmy dość dobrze na jakim kryterium sukcesu zależy klientowi, ono nawet nie było tak wprost oczekiwane od nas, ale zespół wiedząc, że musi dane rozwiązanie opracowywane przez nas osiągnąć pewien procent konwersji, bodajże 50-60% konwersji w pewnym procesie biznesowym, to członkowie tego zespołu angażowali się nie tylko w dostarczenie działającego oprogramowania, ale również w sugerowanie rozwiązań, które pomogłyby w zwiększeniu konwersji. Można by powiedzieć, że programiści zahaczali o obszar stricte biznesowy, dbając o to, aby skuteczność była jak najwyższa.

Przyczyna numer dwa, to brak dostatecznej komunikacji ze wszystkimi interesariuszami projektu, a zwłaszcza z jego użytkownikami. W realizacji każdego projektu bardzo ważnym pojęciem jest wspomniany interesariusz, również zwany udziałowcem, z angielskiego stakeholder, czyli osoba, na którą dany projekt ma wpływ, lub mająca inny, istotny związek z danym projektem. Do oczywistych udziałowców projektu realizowanego na przykład dla jakiejś dużej firmy mogą należeć chociażby dyrektor finansowy, który musi zaakceptować wydatek na takie rozwiązanie, kierownik działu IT związany z wdrożeniem systemu, a także oczywiście pracownicy, użytkownicy takiego systemu. Już choćby to proste wyliczenie pokazuje, że są to bardzo różne osoby, o różnych kompetencjach i z różnych obszarów działania firmy. Może zdarzyć się, że przy ustalaniu zakresu projektu będzie brakować niektórych interesariuszy w projekcie i zadziała to w obie strony. To znaczy jeżeli realizujemy projekt na przykład z menadżerem odpowiedzialnym za operacyjne działania w jakimś dziale, ale potem, kiedy już dostarczymy projekt okaże się, że nie uzgodniliśmy pewnych istotnych szczegółów chociażby ze wspomnianym kierownikiem działu IT, na przykład nie respektując ich możliwości związanych z serwerami dostępnymi w firmie, to mamy pewien problem. W druga stronę potrafi działać to tak samo, pracowaliśmy kiedyś z klientem, gdzie rozmawialiśmy bezpośrednio z dyrekcją i mieliśmy wrażenie, że dyrekcja jest świetnie zorientowana w operacyjnym działaniu firmy, praktycznie w realizacji każdej najdrobniejszej czynności. Ale kiedy dostarczyliśmy oprogramowanie okazało się, że faktyczni użytkownicy, czyli pracownicy liniowi w tej firmie mieli nieco inne wyobrażenia na temat tego oprogramowania. Na szczęście skończyło się na kilku drobnych, z punktu widzenia tworzenia oprogramowania, zmianach, które znacząco usprawniły pracę użytkowników. Aby uniknąć tego problemu zadbajmy o to, aby na pierwszych spotkaniach definiujących zasadniczy zakres projektu byli obecni wszyscy, może nie wszyscy użytkownicy, czy wszystkie osoby, które będą korzystać z systemu, ale chociaż przedstawiciele wszystkich grup zainteresowanych wdrożeniem danego rozwiązania.

Przyczyna numer trzy to niedostateczne oszacowanie wysiłku potrzebnego po stronie pracowników klienta. Wydawało by się, że nie ma gorszego projektu niż taki, który trzeba robić na przysłowiowym ASAP-ie, ponieważ wszyscy po stronie klienta chcą, aby ten projekt był gotowy. Problem pojawia się także w skrajnie innej sytuacji, czyli wtedy, kiedy klient nie ma czasu na bieżące konsultowanie projektu i nie zależy mu na sprawnej jego realizacji. Owszem, na początku praktycznie każdy klient wie, że trzeba odbyć jedno, czy kilka spotkań, może nawet dłuższy warsztat, ale do sukcesu przedsięwzięcia informatycznego potrzeba znacznie więcej czasu po stronie klienta. Dostępność na pytania członków zespołu deweloperskiego, udział w pracach projektowych i bieżące konsultacje, weryfikowanie efektów prac, nie mówię o trywialnym testowaniu aplikacji, bo to zadanie jest po stronie zespołu deweloperskiego, ale także o sprawdzaniu czy faktycznie to, co zespół wytworzy ma sens i jest przydatne w organizacji. My również mieliśmy taki projekt, w którym pracowaliśmy z klientem niezwykle niedostępnym, ten klient potrafił znikać na całe tygodnie i w pewnym momencie doszło do sytuacji, w której po paru miesiącach otrzymaliśmy informację zwrotną o tym, że w projekcie nie ma postępów, podczas kiedy tak naprawdę te postępy były ograniczone przez brak kontaktu ze strony klienta. Projekt zakończył się połowicznym sukcesem, bo choć część, która nie wymagała dużej interakcji powstała, to ta druga część związana ze znacznie bardziej intensywnym udziałem klienta została zakończona niepowodzeniem. W takim przypadku zdecydowanie warto na samym początku projektu oszacować tak, jak szacuje się czas potrzebny na wytworzenie oprogramowania, czy dostarczenie rozwiązania, trzeba oszacować koszt czasowy po stronie klienta.

W miarę omawiania kolejnych przyczyn zmierzamy do przodu w procesie realizacji projektu informatycznego i przyczyna numer cztery, to jest taki odnośnik do poprzednich odcinków, odcinka 1 i 2, w których dyskutowałem na temat wyboru rozwiązań gotowych i dedykowanych, a także różnych rodzajów rozwiązań mobilnych, czy to stron czy aplikacji mobilnych. I to jest właśnie jedna z kluczowych przyczyn porażek, czyli zły wybór rodzaju rozwiązania informatycznego. Sami uczestniczyliśmy kiedyś w projekcie, w którym dość duża firma dysponowała naprawdę fajną, sprawnie działającą stroną mobilną, ale niejako uparła się, aby stworzyć aplikację mobilną właśnie z przytoczonego wcześniej powodu, bo konkurencja taką ma i choć były drobne różnice pomiędzy aplikacją, a stroną mobilną, to jednak cały ten projekt był niestety mocno niepotrzebny i to też przełożyło się na jego realizację. Jest to jeden z gorzej przez nas wspominanych projektów, który przeciągnął się budżetowo, bo cały czas trzeba było dorównywać z zakresem aplikacji mobilnej, do tworzonej wewnętrznie strony mobilnej. Ale żeby nie było cały czas tak negatywnie, bo w tym odcinku o porażkach wspominam o różnych problematycznych sytuacjach, rozmawialiśmy kiedyś z dużą siecią handlową, która miała bardzo wiele życzeń odnośnie pomysłu aplikacji mobilnej, ale w momencie gdy przedstawiliśmy im wyszacowanie na poziomie kilkunastu tysięcy roboczo godzin, kulturalnie podziękowali i stwierdzili, ze jednak to nie był po ich stronie zbyt dobry pomysł. O ile pamiętam, postanowili skupić się na rozwoju swojej strony mobilnej. Środkiem zaradczym dla tej przyczyny porażek projektów informatycznych jest po prostu staranna analiza danej sytuacji, najlepiej konsultacja  z jakimś dostawcą usług informatycznych, aby porównać wszystkie za i przeciw poszczególnych rozwiązań technologicznych i przede wszystkim analiza celu realizacji danego projektu.

Przyczyna numer pięć, czyli brak rozsądnych planów na rozwój rozwiązania. Wbrew pozorom zdarza się czasem, że projekt jako projekt o zamkniętym zakresie udaje się zrealizować skutecznie, on nawet osiąga pewne ustalone wcześniej metryki, ale brakuje rozsądnej perspektywy na rozwój danego projektu. O ile pewne długofalowe konsekwencje wdrożenia projektu takie jak koszty utrzymanie infrastruktury czy usługa wsparcia, czyli tak zwany support powinny być przedstawione przez rzetelnego dostawcę, o tyle zaangażowanie sił po stronie klienta w używanie produktu może okazać się ponad miarę. Niestety bardzo mocną jest pokusa ciągłego rozszerzania produktu o jedną, dwie, trzy nowe funkcje, co zwłaszcza przy rozwiązaniach mocno niestandardowych, w przypadku start-upów potrafi prowadzić do porażki. Rozwiązaniem w takiej sytuacji jest nie myśleć o projekcie jako zamkniętej całości, tylko realizować projekt maksymalnie procesowo, iteracyjnie po to, aby dążyć do stworzenia najpierw jak najmniejszego pod względem zakresu, tak zwanego MVP, czyli minimum viable product, dzięki czemu bardzo szybko jako klient otrzymacie produkt, który można już testować, którego można używać, który wnosi pewną wartość do organizacji, co pozwala na to, abyście byli w stanie wyrazić opinię i zmodyfikować kierunek,  w którym aplikacja jest rozwijana.

Tak docieramy do końca tego zestawienia, w sumie poszło całkiem sprawnie, może krótko podsumujmy w takich parach, czyli przyczyna porażki i rozwiązanie problemu. Przyczyna numer jeden, brak biznesowego uzasadnienia projektu i tutaj możemy zastosować precyzyjne określenie celu i wprowadzenie obiektywnych metryk skuteczności jego realizacji. Przyczyna numer dwa, brak uwzględnienia ważnych udziałowców, interesariuszy w projekcie, oczywiście na początku realizacji projektu trzeba się upewnić, że wszystkie osoby są obecne w komunikacji, czy też na spotkaniach. Przyczyna numer trzy, klienci nie zakładają po swojej stronie odpowiedniego wysiłku, czasu, potrzebnego na realizacje projektu po swojej stronie. Rozwiązaniem jest tutaj precyzyjne przedstawienie zadań, jakie będą leżały po stronie klienta w zakresie realizacji projektu. Przyczyna numer cztery czyli zły wybór rodzaju rozwiązania informatycznego, tutaj pół żartem mogę powiedzieć, że rozwiązaniem jest słuchanie tego podcastu, gdzie takie tematy już się pojawiały i na pewno będą się pojawiać, natomiast warto mocno rozważyć zalety i wady poszczególnych rodzajów rozwiązań informatycznych i skorzystać z pomocy konsultanta w celu doboru optymalnej formy. Przyczyna numer pięć, czyli brak odpowiednich perspektyw na rozwój projektu, tutaj warto traktować przedsięwzięcia nie tylko w przypadku start-upów, ale nawet w przypadku realizacji projektów dla dużych, uznanych firm, warto tratować takie projekty procesowo, iteracyjnie, zaczynać od stworzenia jak najmniejszych, ale już funkcjonalnych rozwiązań, czyli MVP i stale rozwijać te rozwiązania, czyli odejść od stricte projektowego myślenia.

I to by było na tyle, nie są to jedyne przyczyny, myślę, że nie odważyłbym się powiedzieć, że są to zdecydowanie najważniejsze przyczyny, ale z pewnością są to przyczyny, które nam w przeszłości przysporzyły różnych problemów i jeżeli uda się ich wam uniknąć, to macie znacznie większą szansę na skuteczną realizację projektu informatycznego. Warto też zauważyć, że tak naprawdę wszystkie te pięć dość różnych przyczyn łączy jedno; główną rolę odgrywają nie kwestie czysto techniczne, ale komunikacyjne, ludzkie. Można tutaj powrócić do znanych słów Kevina Mitnicka, słynnego niegdyś hakera, a dokładnie tytuły jego książki „Łamałem ludzi, nie hasła”, tak samo jak możliwość włamania się do systemów informatycznych wynikała nie tyle ze słabości zabezpieczeń, co ze słabości ludzi, takie problemy w realizacji projektów informatycznych najczęściej biorą się właśnie z problemów ludzkich.

Na tym kończymy dzisiejszy odcinek, zachęcam do subskrybowania, ale przede wszystkim do zgłaszania wszelkich opinii czy to za pomocą Facebooka, LinkedIn, maila, czy numeru telefonu. Choć nie daję gwarancji czasu odpowiedzi, to nie umowa SLA, to postaram się odpowiedzieć na każdą wiadomość. Kłaniam się i do usłyszenia.