Jak uratować zagrożony projekt IT

W jaki sposób kontynuować projekt, który już przyniósł straty dla spółki? Jakie to będzie miało konsekwencje księgowe, prawne, podatkowe? Jak podchodzić do dalszego prowadzenia projektu IT? Jak się ratuje projekty prowadzone w agile? Rozmowa z Aleksandrem Poniewierskim, partnerem EY, kierującym działem IT Advisory w Europie Środkowej i Południowej.

Kiedyś opisywałem projekt wdrożenia nowego systemu transakcyjnego w Banku Ochrony Środowiska. Podjęto wówczas decyzję o porzuceniu wdrożenia systemu greckiej firmy Temenos i zdecydowano o wyborze nowego rozwiązania. Podstawowym błędem, który popełniono w pierwszym projekcie było nie zamrożenie fazy określania wymagań, co do funkcjonalności nowego systemu. Dochodziły kolejne propozycje i ostatecznie ich lista urosła ponad miarę, paraliżując projekt i doprowadzając do wzrostu kosztów do poziomu nieakceptowanego przez zarząd. Czy jest jakaś dobra droga wyjścia z takiej sytuacji?

Nawiasem mówiąc doradzaliśmy w tym projekcie w BOŚ… Najtrudniejsza jest odpowiedź na pytanie, co się stało, że dotąd na projekt wydaliśmy 100-150 mln zł i nie osiągnęliśmy założonych celów? I co teraz zrobić – zakończyć, czy ratować projekt? Jeśli zakończyć, to pojawia się pytanie o ewentualne konsekwencje, które wiele osób „mrozi”. Firmy doradcze, które nie są w stanie odpowiedzieć na to pytanie, nie są również w stanie pomóc przedsiębiorstwu stojącemu przed takim problemem.

Do tego typu projektów oddelegowujemy doradców o różnych specjalizacjach. W pierwszej kolejności potrzebne są kompetencje księgowe. Trzeba ocenić, które z poniesionych kosztów można odzyskać, które spisać na straty, a na które zrobić odpis księgowy. Potrzebni są też prawnicy, który z punktu widzenia obowiązujących przepisów prawa patrzą na problem zakończenia lub rewitalizacji projektu. Zwykle w takich przypadkach zmienia się zarząd firmy. W spółkach Skarbu Państwa nowy zarząd zobowiązany jest – gdy jest to zasadne – przekazać do Prokuratury wniosek o niegospodarność. W przypadku firm prywatnych następuje rozliczenie historii projektu i konsekwencje z tym związane.

Trzeci typ osób zaangażowanych po naszej stronie w projekt, to doradcy podatkowi. Projekty wdrożenia nowego systemu trwają zwykle 2-3 lata, w tym czasie przedsiębiorstwo dokonuje wielu odpisów podatkowych, korzysta z ulgi technologicznej, środków z Unii Europejskiej. Rozwiązanie tego problemu to nie lada wyzwanie. Na koniec dopiero pojawiają się Project Managerowie, którzy opracowują nową strategię.

Niekiedy zdarza się też, że w czasie trwanie projektu kompletnie zmienia się technologia. Bywa, że RFP – Request For Proposal – wysłano 5 lat przed rozpoczęciem projektu, a kolejne 5 lat wdrażano, bez powodzenia nowy system IT. Kontynuowanie takiego projektu nie ma sensu. Takie projekty poddaje się rewitalizacji.

Co następuje po tym, gdy firma otrzyma opinię doradców w zakresie księgowości, prawa i podatków?

Aby móc podjąć kolejne działania, prowadzony przez nas projekt musi mieć silnego sponsora w zarządzie. Nie podejmujemy się poprowadzenia go, jeśli zarząd nie zdaje sobie sprawy, że do końca musi trzymać rękę na pulsie i do końca wspierać realizację projektu.

Następnym krokiem jest przeprowadzenie złożonego procesu, w którym odpowiadamy na pytanie, co można zrobić. Jednym z jego elementów jest analiza biznesowa i podjęcie decyzji, czy danego systemu przedsiębiorstwo wciąż potrzebuje. Sprawdzamy, co zostało kupione i co powstało w efekcie projektu. Przyglądamy się też zespołowi projektowemu. Często okazuje się wówczas, że to nie problem tego, pojedynczego projektu, ale całego podejścia do IT w przedsiębiorstwie.

Ostatecznie mamy trzy drogi postępowania: sądzić się z dostawcą, rewitalizować dotychczasowy projekt lub zacząć wszystko od nowa.

Ile projektów się „zabija”, a ile udaje uratować – rewitalizuje lub redefiniuje na nowo?

Z naszej praktyki wynika, że jedynie 10% projektów jest „zabijanych”. To ostateczność, a konsekwencje podjęcia takiej decyzji są bardzo duże zarówno dla dostawcy, jaki i zamawiającego oraz konsultanta pracującego przy projekcie. Zasugerowałem takie postępowanie zaledwie w kilku przypadkach. W pozostałych 90% przypadków rewitalizacji podlega 80%, a redefinicji 20% projektów.

Rewitalizacja i redefinicja projektów polegają na ponownym określeniu wymagań, co do funkcjonalności systemu w oparciu o aktualne potrzeby biznesowe. Następnie określeniu, co jest realne, a co nierealne do wykonania. W efekcie ogranicza się kastomizację systemu. Zazwyczaj oznacza to także zwiększenie budżetu i skrócenie czasu trwania projektu w stosunku do pierwotnego harmonogramu. Dzięki ograniczeniu funkcjonalności nowego rozwiązania sprawiamy, że skupiamy się na najważniejszych zadaniach.

Wspominał Pan, że przyglądają się Państwo także zespołowi projektowemu…

W ratowaniu projektów bardzo ważny jest tzw. czynnik ludzki. To ludzie, którzy byli związani z projektem przez ostatnie lata. Od ich dalszej pracy w 90% zależy sukces naszych działań. Przy dużych projektach to dziesiątki ludzi, którzy mogą przyjąć strategię oblężonej armii broniąc się przed jakąkolwiek ingerencją, zmianą. Niekiedy konieczna jest zmiana lidera, czy wprowadzenie czynników, o których zapomniano np. sposobie motywowania ludzi. Zmiana musi być jednak bardzo konsekwentna, jeśli wprowadzamy premie to za bardzo konkretne efekty.

Inny sposób to zmiana „ducha projektu”. Bardzo często zdarza się, że nawet najlepszy dostawca na świecie nic nie może zrobić, bo został złapany w pułapkę zmieniających się warunków. Za przykład może służyć projekt budowy Kompleksowego Systemu Informatycznego w Zakładzie Ubezpieczeń Społecznych. To instytucja stojąca na zapisach prawnych, które się cały czas zmieniają. Tak było w początkach wdrożenia KSI ZUS. Zakład definiuje potrzeby, dostawca projektuje pod to system, tymczasem z dnia na dzień zmieniają się warunki, bo Sejm zmienia prawo. Dostawca mówi zamroźcie wymagania. ZUS odpowiada, ale obiecywaliście, że będziecie zgodni z polskim prawem. Sytuacja patowa. W takim przypadku trzeba zmienić „ducha projektu”, np. zamrozić wymagania na pewnym etapie i doprowadzić do osiągnięcia określonych celów. Dopiero później można wprowadzać kolejne zmiany. Często okazuje się, że „złe” projekty po zmianie „ducha projektu” zaczynają iść dobrze.

Są jeszcze przyszli użytkownicy…

I to jest najważniejszy element w projekcie. Zwykle okazuje się, że dostawca we wstępnej fazie przeszkolił już użytkowników z nowego rozwiązania. Na szkoleniu pokazano im, że jest ono mercedesem w swojej klasie. Użytkownicy są do tego przekonani, w dodatku nie znają nic innego. W takiej sytuacji trudno ich przekonać do szczerej odpowiedzi, czego tak naprawdę oczekują. Tym bardziej, że system nie realizuje tego, co zostało obiecane. Jednocześnie zaś trzeba skupić się na wdrożeniu najważniejszych funkcji, aby uratować projekt.

Przekonanie użytkowników do zmian to najbardziej emocjonalny element. Pamiętam projekt, w którym na szkoleniu pokazano funkcje, który wdrażany system nie ma. Tymczasem użytkownicy z działów biznesowych nie chcieli odebrać projektu, ponieważ w ostatecznej wersji ich nie było. To był przykład ratowania projektu, którego nie trzeba było ratować. Przekonanie użytkowników zajęło nam jednak 6 miesięcy. Tłumaczyliśmy, że to, co otrzymali jest kompromisem między ceną, czasem i potrzebami firmy. Zwykle największe roszczenia użytkowników dotyczą obszaru raportowania.

Prowadziliśmy też inny, duży projekt za kilkadziesiąt milionów złotych. Niestety został zabity. Tam jednak została wygenerowana fałszywa opowieść, że nowy system wprowadzi nowe procesy biznesowe, które spowodują, że instytucja się zmieni, zacznie działać w nowej jakości, będzie ponownie zyskowna. Zaczęliśmy od komunikacji, że firma rezygnuje z wdrożenia nowego systemu. Reakcją były głosy, ale my go potrzebujemy. Odpowiadaliśmy, że przecież nie byli zadowoleni z wdrażanego rozwiązania. Użytkownicy na to: „no tak, ale z tamtego, które zostało źle wdrożone, ale samego systemu bardzo potrzebujemy”.

Próby przekonywania użytkowników nazywamy „rekultywacją” projektu.

W jaki sposób podchodzi się do tego procesu?

Często wynajmujemy profesjonalne agencje PR do komunikacji. Niekiedy z nowego systemu korzystać mają setki, tysiące użytkowników. Nie da się z każdym porozmawiać osobiście. Trzeba to robić podczas spotkań, w wewnętrznych gazetkach firmowych. To duża kampania reklamowa. Rekultywacja to budowa nowej wizji projektu.

Czy są różnice w ratowaniu projektów prowadzonych tradycyjną metodą i w agile?

Niekiedy ratując projekt decydujemy o zmianie podejścia do niego – z waterfall na agile lub odwrotnie. Zmiana podejścia spowodowana jest tym, że niektóre organizacje nie są przygotowane do danej metodologii. Jednak ograniczenie funkcjonalności nowego rozwiązania i skupienie się na najważniejszych zadaniach dotyczy zarówno projektów prowadzonych tradycyjną metodą waterfall, jak i w metodologii agile. Różnica polega na tym, że w drugim przypadku nasze działania określiłbym, jako „łowienie planktonu”. Trudno jest bowiem określić, co się ma.

Na czym dokładnie polega problem z projektami prowadzonymi w metodologii agile?

To nowe podejście i często jest bardzo źle rozumiane. Uważa się, że jeśli nie potrafimy zdefiniować wymagań dotyczących przyszłego rozwiązania, to poprowadzimy projekt w metodologii agile i w trakcie jego realizacji ustalimy ostateczne cele. Tymczasem koszt naprawy takiego projektu jest bardzo, bardzo duży. Związany jest z tym, że de facto projekt trzeba rozpocząć od nowa. Oznacza to zmianę metodyki i ponowne określenie listy wymagań, rollback sprintów, sprawdzenie, co zrobiono, określenie gdzie się jest, przejście na etapowy sposób prowadzenia projektuje, a to trwa…

W projektach typu waterfall jest dokumentacja, analiza luk – określenie, co system może, a co klient chce, konieczny zakres kastomizacji, zaplanowany odbiór. Mając to wiemy, jaki procent wymagań został zrobiony, co trzeba jeszcze zrobić, z czego można zrezygnować, co będzie trudne do zrealizowania. Informacje te można nałożyć na mapę ważne/mniej ważne, zrobione/niezrobione.

Tymczasem w agile, w krótkich spritnach definiuje, testuje i dogrywa się kolejne elementy przyszłego rozwiązania. Przy wielkim rygorze projektowym dopuszczalne jest przesuwanie poszczególnych etapów. Czasami jednak dużym problemem jest odróżnienie tego, co jest uzasadnionym przesunięciem. Jeśli ktoś stosuje agile musi mieć bardzo mocny i dobrze umocowany dział testowania. Bez tego projekt agile jest właściwie nie do opanowania.

Podchodząc do ratowania projektu musimy rozumieć, czy projekt był celowo robiony w agile, czy też było to jedynie wymówką związaną z tym, że firma nie wiedziała, co chce zrobić, nie określono warunków brzegowych. W projektach agile często pokazuje się drobne, szybkie sukcesy, tzw. quick win. Trzeba wówczas uważać, aby się nie „znieczulić”, nie uznać, że – skoro osiągamy kolejne cele – wszystko jest w porządku. Są organizacje, które z quick win zrobiły sukces całego projektu.

Jaki był największy projekt, którym się Państwo zajmowali?

Pomagaliśmy przy projekcie, który pochłonął już 150 mln zł.

• 10% projektów jest zabijanych
• 72% projektów jest rewitalizowanych
• 18% projektów jest redefiniowanych