Niepowodzenia projektów IT w kontekście analizy biznesowej

Przeglądając statystyki dotyczące projektów informatycznych (np. raport CHAOS – Standish Group) można zauważyć, że choć rok do roku liczby się zmieniają to wnioski pozostają te same: w przypadku zdecydowanej większości projektów IT, podsumowanie wdrożenia projektu pokazuje przekroczony budżet lub czas realizacji, wdrożenie z ograniczonym zakresem lub przerwanie prac przed ukończeniem projektu.

Artykułów o powodach takiego stanu rzeczy jest mnóstwo, jeszcze więcej jest poradników opisujących jak zakończyć projekt IT pełnym sukcesem.

Dziś chciałbym skupić się na trzech głównych powodach niepowodzeń fazy analizy, co ma duże przełożenie na wynik całego projektu. Są to wnioski wysnute w oparciu o moje doświadczenia oraz obserwacje.

Powód I: Brak czasu/zaangażowania interesariuszy.

Na brak czasu oraz zaangażowania interesariuszy możemy narzekać podczas realizacji projektów regulacyjnych, w przypadkach kiedy szeroko rozumiany biznes nie jest zainteresowany realizacją projektu. Jeżeli dodatkowo nie znajdziemy wsparcia kierownictwa w realizacji projektu, dostaniemy typowy przepis na niestrawny projekt. W takich przypadkach zmorą analityka jest brak uczestnictwa interesariuszy w spotkaniach projektowych, niedotrzymywanie wszelkich zadanych terminów i notoryczne bombardowanie spotkań przemyśleniami o bezsensowności wykonywanych prac. Problematyczne okazuje się także uzyskanie opinii na temat dokumentu analitycznego oraz jego akceptacji. Jak może potoczyć się projekt, jeśli w fazie analizy wystąpiły te zdarzenia które opisałem powyżej? Zainteresowanie projektem ze strony biznesu zaczyna narastać kiedy projekt wstępuję w fazę testów. Pojawiają się pierwsze wątpliwości co do spełnienia wszystkich nakazów regulacyjnych oraz wymagań projektu. Winni oczywiście szybko się znajdą są nimi: Analityk/PM/dostawca/całe IT (kolejność dowolna).

Na drugim biegunie znajduje się przypadek kiedy projekt jest dobrze umocowany w organizacji, posiada wsparcie kierownictwa, jednak z uwagi na specjalistyczny wymiar, konieczna wiedza znajduje się w rękach (czytaj umysłach), wąskiej grupy zapracowanych ekspertów. Ich kalendarze są zwykle zapełnione na wiele tygodni w przód, więc samo spotkanie z nimi okazuje się nie lada wyzwaniem. Jeżeli udało się nam przebrnąć przez tę fazę spotkań, to mission impossible jeszcze jest przed nami. Oczekiwanie na zaopiniowanie/akceptację analizy biznesowej przeciąga się w nieskończoność, nie pomogą tutaj prośby/groźby/eskalacje, czas danych osób nie jest z gumy, mając 8h spotkań dziennie trudno liczyć na wygospodarowanie czasu na wnikliwą analizę wielostronicowego dokumentu. Czas biegnie nieubłaganie, przechodzimy więc fazę analizy bez feedbacku ze strony biznesu, wszelkie nieporozumienia/nieścisłości/ błędy będziemy musieli niestety nadrabiać w testach.

Ostatnim przykładem jest projekt automatyzujący procesy i usprawniające pracę Operacji. Projekt taki należy do grupy „oszczędnościowych”, gdzie Business case budowany jest na redukcji FTE. Nie można się wiec dziwić, że Operacje nie mają żadnego interesu w realizacji danego projektu. Analiza w takim projekcie od początku idzie opornie, przedstawiciele Operacji dzielą się wiedzą niechętnie, „na siłę”. Spotkania wyglądają jak gra w ciuciubabkę „jak tu powiedzieć, aby nie powiedzieć”, ale nie narazić się na eskalacje o braku współpracy.

Powód II: Zmieniająca się wizja biznesu a co za tym idzie, ciągła zmiana zakresu projektu.

W większości przypadków projekt został powołany „na szybko”, nie było fazy twórczej w której budowana jest koncepcja biznesowa odpowiadająca na pytanie „czego potrzebujemy”, „co chcemy zrobić”, nie ma zbudowanej koncepcji rozwiązania, zamkniętego zakresu ani oszacowanego przedziału kosztów. Wszystko to powoduje, że budowa koncepcji biznesowej przeniesiona jest na fazę zbierania i analizy wymagań, powodując chroniczny ból głowy analityka, który nie może „wejść w buty” biznesu, zrozumieć jego potrzeb, ani odpowiedzieć sobie na pytanie o cel wędrówki. Jednym razem wydaje mu się że biznes potrzebuje „samochodu”, a drugim razem „samolotu”, a kiedy ostatecznie uda się uzgodnić że potrzebujemy „samochodu”, to zaczyna się uszczegóławianie, czy potrzebuje „Malucha” czy „Ferrari”. Biznes zwykle powie że „Ferrari” ale znając budżet projektu, analityk musi przygotować analizę pod „Fiata Pandę”. Najgorszą kombinacją dla ww. sytuacji jest brak decyzyjności w projekcie. Przypadek występuje szczególnie w dużych korporacjach, gdzie dobre decyzje są nagradzane uściskiem ręki, a błędne decyzje będą wypominane w korporacyjnych roszadach. Efektem ćwiczenia są liczne rekomendacje, ale brak decyzji. Do jej podjęcia musi zostać powołany komitet (klasyczne rozmycie odpowiedzialności), komitet musi się zebrać, podebatować i po pierwszej/kolejnej debacie, udaje się w końcu uzyskać wiążącą decyzję. Wszystko super tylko problemem jest czas – faza analizy się kończy a brak jest decyzji mającej wpływ na zakres.

Najgorszym wariantem omówionego przypadku jest jednak zmiana wizji/zakresu na etapie developmentu. Zwykle terminy gonią, nie można wiec wrócić na etap analizy. „Pociąg jedzie”, a zgłaszane są nowe CRy. Nikt nie panuje już nad logiczną,spójną wizją całości, co w efekcie prowadzi do tego, że pierwotnie biznes potrzebował „Fiata Pandy” ale ostatecznie jednak potrzebuje „spychacza”, a dostanie „Fiata Pandę” z doczepionym pługiem i zmodyfikowanym silnikiem, w dodatku za cenę dwóch „spychaczy”.

Powód III: Nieprecyzyjne / niekompletne wymagania.

Czas pochylić głowę i posypać ją popiołem. Trzecim powodem niepowodzenia fazy analizy jest błędnie przeprowadzona analiza, za którą odpowiadamy my – analitycy. Przyczyn jest wiele: zbyt krótki czas na analizę, powodujący niedostateczne zgłębienie tematu, brak specjalistycznej wiedzy z danej gałęzi, błędny dobór technik analitycznych, niezrozumienie intencji biznesu, w połączeniu z niezrozumieniem analizy przez biznes, słaba jakość analizy, lub niepełna analiza, czy ostatecznie, powierzenie wizji przygotowania analizy osobie bez koniecznego doświadczenia – coraz rzadziej ale jednak zdarzają się i takie przypadki, że analitykiem zostaje osoba bez doświadczenia/predyspozycji do danej pracy. Redukcje zatrudnienia i wolny wakat są wystarczającą zachętą do „awansu” na analityka. Jeżeli połączymy to z otrzymaniem na pierwszy ogień trudnego projektu, efekt końcowy nie jest trudny do przewidzenia, okazuje się, że zadanie nie jest takie łatwe i nie jest to tylko: „siądź i spisz to co biznes ci powie”.

Co więc zrobić, aby uniknąć takich sytuacji ? To inna historia … być może temat kolejnego wpisu, ewentualnie można przeczytać jeden z wielu dostępnych w sieci poradników 🙂