Jak dowieźć nierealny projekt IT do końca

Na rynku dostępnych jest wiele książek poświęconych zarzadzaniu projektami IT. Niestety, pomimo ogromnej ilości merytorycznej wiedzy, rzadko kiedy przygotowują one kierownika projektu do pracy w rzeczywistym środowisku biznesowym. Bariery te udało się pokonać z sukcesem Marcinowi Dąbrowskiemu, autorowi książki „10 zasad dowożenia projektów nierealnych”

Tylko niewielka liczba projektów IT idzie lekko, a pokonywanie większości napotykanych problemów nie wymaga wysiłku. Tylko czasami zdarza się, że projekty, które prowadzone są wzorowo i dostarczają określone efekty, z różnych przyczyn trzeba zatrzymać. I przeciwnie, są też takie, które się przeciągają, generują problemy, stres, dostarczają tylko część zakresu, a jednak okazuje się, że klienci postrzegają je jako sukces. Najwięcej jest jednak takich, które mimo aplikowania przeróżnych metodyk zarządzania idą jak po grudzie, a wiele z nich kończy się porażką. I to są właśnie te projekty nierealne, które zgodnie ze zdrowym rozsądkiem nie mogą się udać, więc być może w ogóle nie powinno się ich rozpoczynać.

Lista problemów, z którymi można się zderzyć, prowadząc projekt nierealny, jest długa. Zdaniem autora książki, najczęściej spotykane i najbardziej brzemienne w skutkach to: powtarzające się chronicznie opóźnienia, puchnący zakres prac, straty finansowe na projekcie, brak zasobów, brak kompetencji dziedzinowych, nieokreślony cel projektu, nieprzychylne nastawienie, ciągła presja na „więcej i lepiej”, unikanie podejmowania decyzji, zaskakujące zachowania, naliczanie kar, groźba zatrzymania projektu czy nawet zerwania kontraktu.

Realizując projekt nierealny, trzeba zwykle pracować na bazie harmonogramu, którego obiektywnie nie da się dotrzymać. Bardzo często trzeba się też mierzyć z problemem rozrastającego się zakresu. Gdy krok po kroku rozpakowuje się kolejne funkcjonalności systemu i za każdym razem okazuje się, że rozumienie zakresu było zbyt uproszczone, że dostarczyć trzeba o wiele więcej, i że prace będą kosztować znacznie więcej, a nikt tego nie przewidział. W oczywisty sposób irytuje to kierownictwo firmy, które postanawia zredukować zespół i ograniczyć środki finansowe. To z kolei prowadzi do sprzężenia zwrotnego, jeszcze większych opóźnień, eskalacji klienta i w konsekwencji dalszego pogorszenia warunków pracy zespołu. Jakby tego było mało, cel takiego projektu często fluktuuje, bo klient zmienia priorytety, w wyniku czego praca staje się nieefektywna. Do tego wszystkiego klient, pomimo złej sytuacji projektowej, jeszcze naciska, aby dostarczać więcej za mniej i dodawać nowe funkcjonalności, których nie było w umowie. A gdy chce się to poddać dyskusji, okazuje się, że po drugiej stronie nie ma partnera. W takim projekcie bardzo często sytuacja eskaluje do takiego stopnia, że klient posuwa się do gróźb naliczania kar, czasem nawet je aplikując, a nawet taki projekt zatrzymuje i ostatecznie zrywa kontrakt.

Cechy projektu nierealnego

Jakie cechy projektu nierealnego powodują powstawanie wymienionych wcześniej problemów? Lista jest obszerna, ale autor książki za najważniejsze z nich uważa te przedstawione poniżej.

• Nierealny harmonogram

Nie jest on skutkiem błędów zespołu projektowego czy też obiektywnych problemów, jakie mogły się pojawić w projekcie w trakcie prac. Taki harmonogram jest niejako „dziedziczony” z umową. Po prostu ktoś w firmie zdecydował, że zgadza się na takie, a nie inne warunki komercyjne, a następnie podpisał kontrakt na owych warunkach. To zaś w konsekwencji nie pozwala na realizację projektu na czas.

• Źle zdefiniowany zakres projektu

Kończy się to zwykle koniecznością wykonania większej pracy, niż początkowo zaplanowano. Skala tego zjawiska zależna jest od wielu czynników, m.in. od nastawienia klienta oraz tego, jak bardzo w danym momencie rezultaty projektu odbiegają od jego oczekiwań.

Jednakowoż dostawcy również czynią pewne założenia odnośnie do zakresu i kosztu prac. Bardzo często okazuje się, że ich wyceny nie są trafione. Powody tego są również różnorakie, np. braki funkcjonalne produktu, który sprzedają, brak wystarczającej wiedzy dziedzinowej, źle przeprowadzona analiza przedsprzedażowa itd.

• Źle finansowo sprzedany projekt

Projekt dobrze sprzedany ma szansę zakończyć się powodzeniem. Projekt źle sprzedany na pewno zakończy się stratami finansowymi. A dzieje się to wtedy, gdy kosztuje on dużo więcej, niż się spodziewano; więcej, niż obiektywnie powinien kosztować dobrze zwymiarowany projekt tej klasy. Skutki tego są zwykle opłakane. Brak zasobów, kompetencji, niski priorytet w organizacji, zabieranie ludzi do innych projektów, opóźnienia, eskalacje klienta itd.

• Źle sprecyzowany cel biznesowy projektu

Pomimo podpisanej umowy, klient nie do końca przemyślał to, co właściwie chce osiągnąć. Konsekwencje tego bywają tragiczne. Nawet poprawnie realizowany projekt, w którym dostarczane są oczekiwane rezultaty, może być kompletnie przeorganizowany czy wręcz zatrzymany. Przychodzi dzień, kiedy klient informuje, że zmieniły mu się priorytety i zakres, o harmonogramie nie wspomniawszy. Co więcej, takie sytuacje mogą powtarzać się w ramach jednego projektu wielokrotnie.

• Brak dobrych relacji biznesowych z klientem

Mało kto o tym wspomina, ale zdarzają się projekty sprzedane wbrew pewnym ważnym osobom lub grupom osób po stronie klienta. To jedna z najgorszych sytuacji, w której może się znaleźć zespół i kierownik projektu. Skutkuje to niejako „wrogimi” działaniami czy nawet swego rodzaju strajkiem włoskim po stronie klienta. Rozbijanie dyskusji, podważanie ustaleń, przekładanie spotkań, ciągła krytyka, wyszukiwanie problemów. A na koniec fiasko niezależnie od wybranej metodyki zarządczej.

• Źle skonstruowana umowa

Prowadzenie projektu w oparciu o źle przygotowany kontrakt jest bardzo trudne. Zwłaszcza kiedy zaniedbane zostały zapisy dotyczące kontroli zakresu, a także procedur postępowania w przypadku opóźnień oraz naliczania kar. W takiej sytuacji klient może na bieżąco dodawać sobie nowe wymagania oraz zmieniać kryteria odbioru, a druga strona nie ma możliwości jakiegokolwiek manewru.

Źle skonstruowana umowa od początku ustawia dostawcę oraz kierownika projektu w defensywie. W skrajnych przypadkach dostawcy są zmuszani do realizacji nierentownych projektów, których nie są w stanie formalnie wypowiedzieć.

• Niedopasowanie dostawcy i klienta

Różnice w organizacji pracy, mentalności, procesach zarządczych, sposobie podejmowania decyzji, podejściu do rozwiązywania problemów — wszystko to prowadzi do napięć, eskalacji, opóźnień w realizacji prac. Jeśli dostawca wszystkie swoje projekty realizuje w metodykach zwinnych, to trudno mu będzie współpracować z klientem, który ma bardzo formalne podejście do podejmowania decyzji oraz przeprowadzania jakichkolwiek zmian. Który wszystko musi planować z wyprzedzeniem, a znaczące decyzje procesuje hierarchicznie miesiącami.

• Nieprzygotowanie klienta do realizacji projektu

Często klient nie jest gotowy do prowadzenia projektu. Brakuje mu specjalistów dziedzinowych, liderów czy osób odpowiedzialnych za poszczególne obszary. Nie jest w stanie dostarczyć artefaktów, których wymaga dostawca. Nie ma wystarczającej wiedzy na temat swoich własnych systemów wewnętrznych, które trzeba zastąpić lub z którymi trzeba się integrować. Nie przewidział, jak jego struktura organizacyjna wpłynie na możliwość podejmowania koniecznych decyzji. A w takim środowisku pracy prowadzić projekt jest bardzo trudno.

• Niestabilne środowisko biznesowe

Prowadzenie projektu ma wtedy zwykle niedeterministyczny przebieg, w dużej mierze niezależny od tego, czy realizuje się go poprawnie i wywiązuje dokładnie z zapisów umowy. Jeśli przykładowo klient dokona przejęcia firmy, która już posiada nowoczesny system IT pokrywający się funkcjonalnie z wdrażanym, to z dużym prawdopodobieństwem skutkiem będzie zatrzymanie projektu. To samo może się zdarzyć w przypadku przygotowań do sprzedaży firmy.

Podsumowanie

Praca przy projekcie nierealnym jest bardzo wymagająca, a często toksyczna dla obu stron. To ekstremalnie trudny układ, który generuje problemy nietrywialne, na które nie ma prostych odpowiedzi. Żeby jednak dowiedzieć się, jak sobie z nimi radzić, trzeba sięgnąć po książkę. Polecam!

Wojciech Gryciuk

10 zasad… to lektura obowiązkowa dla osób odpowiedzialnych za rezultaty złożonych i skomplikowanych projektów. Z kolei dla osób decyzyjnych wskazane zostały mechanizmy wpływające na efektywność realizacji zmian w organizacjach. (…) Na rodzimym rynku próżno szukać książki o złożonych projektach IT, która stawia na pragmatyzm, dyscyplinę wykonawczą oraz przypomina, iż najważniejszym celem jest rozwiązywanie problemów i „dowiezienie projektu” dla klienta

Sławomir Soszyński, Wiceprezes Zarządu,

CIO, ING Bank Śląski