Kiedy projekt zawodzi

Przedsiębiorstwa zbyt rzadko i zbyt późno rezygnują z realizacji projektów, które nie mają prawa zakończyć się powodzeniem - przekonuje Eric Guldentops, twórca COBIT-u. Biznes musi więc dopracować metody oceny zyskowności projektu jeszcze w fazie ich realizacji.

Przedsiębiorstwa zbyt rzadko i zbyt późno rezygnują z realizacji projektów, które nie mają prawa zakończyć się powodzeniem - przekonuje Eric Guldentops, twórca COBIT-u. Biznes musi więc dopracować metody oceny zyskowności projektu jeszcze w fazie ich realizacji.

Nawet na 600 mld USD rocznie szacuje Gartner straty ponoszone na świecie z powodu źle prowadzonych bądź niezrealizowanych projektów IT. Dane te potwierdzają badania Standish Group, które mówią, że o sukcesie można mówić jedynie w przypadku 30% projektów IT, a 20% kończy się niepowodzeniem. Pozostałe 50% to przedsięwzięcia określone mianem "challenged", a więc takie, które trudno uznać jednoznacznie za sukces lub porażkę, choć przyniosły wynik poważnie odbiegający od początkowych zamierzeń.

Jakby tego było mało badania IT Governance Institute z 2005 r. wyraźnie wskazują, że niski zwrot z kosztownych inwestycji w IT oraz słaba przejrzystość danych dotyczących produktywności IT to podstawowe wyzwania, z którymi borykają się dzisiejsze przedsiębiorstwa. Ponad 30% ankietowanych negatywnie ocenia zwrot z inwestycji w IT. 40% nie widzi bliskiego związku pomiędzy planami IT a strategią biznesową firmy. Nic zatem dziwnego, że zainteresowanie problematyką stopy zwrotu z inwestycji w IT w latach 2003-2005 w zarządach wzrosła ponad dwukrotnie (z 28% do 58%).

IT jak każda inwestycja

Z czego wynikają niepowodzenia? Zdaniem Erica Guldentopsa, doradcy zarządów ISACA i IT Governance Institute, twórcy standardu COBIT, jest to splot kilku czynników. Z jednej strony z niewiedzy i traktowania projektów IT jako specyficznych inwestycji, które rządzą się odrębnymi prawami, podczas gdy są one w istocie po prostu inwestycjami w zmianę biznesową, takimi jak każda inna. Z drugiej - z braku obiektywnych metod oceny końcowych rezultatów projektów. Z trzeciej zaś z nieumiejętności wyciągania wniosków z przeszłości oraz szacowania zwrotu z inwestycji w IT bez uwzględniania rzeczywistych strat powodowanych opóźnieniami. Przy szacowaniu całkowitych kosztów realizacji projektów i korzyści biznesowych z nich wynikających zbyt rzadko bierzemy pod uwagę obciążenia wynikające z opóźnienia projektów. W rezultacie żyjemy w błogim przeświadczeniu, że stopa zwrotu z inwestycji jest zaledwie dwucyfrowa, podczas gdy na skutek opóźnień nie można mówić o żadnym zwrocie z inwestycji.

Wreszcie jest to także skutek niechęci i lęk przed odpowiedzialnością za końcowy rezultat oraz ewentualne zaniechanie kontynuacji projektu. Projekty są przerywane dopiero w momencie przekroczenia budżetu o 20%, a nawet 40%. "Tak naprawdę rezygnacja z realizacji projektu jeszcze zanim przekroczy on założony budżet, a zwłaszcza na relatywnie niskim poziomie zaawansowania, nie może być traktowana jak klęska. To sukces, który pozwolił uniknąć większych strat finansowych" - przekonuje Eric Guldentops. Z perspektywy biznesu wszystkie te symptomy świadczą o jednym - kryzysie przywództwa i nieprzystawaniu metod zarządzania do praktyki współczesnych organizacji.

Brak jasnych kryteriów selekcji projektów, a także mechanizmów okresowego przeglądu realizowanych przedsięwzięć, krótkowzroczność lub brak strategii, ufność w najbardziej podstawowe wskaźniki finansowe, a także "sprzedawanie" projektów przy użyciu argumentów emocjonalnych prowadzą do nadmiernego wzrostu ich liczby i rozdźwięku pomiędzy projektami a strategią, wreszcie zaś do notorycznych opóźnień i przekraczania budżetów, niezadowolenia biznesu i utraty zaufania do IT ze strony reszty organizacji.

Zaniechania projektów

Dlaczego w ogóle przedsiębiorstwa wycofują się z już rozpoczętych projektów? Jak wnika z badań przeprowadzonych przez ITGI, projekty były odwoływane przede wszystkim z powodu zmian zachodzących wewnątrz organizacji. Drugą pod względem częstości występowania przyczyną są słabe wyniki osiągane w trakcie realizacji projektu. Trzecią zmia-ny zachodzące w otoczeniu biznesowym, a czwartą zmiany technologiczne.

Co ciekawe, projekty są zamykane znacznie szybciej (w okolicach 18% wydanych nakładów) gdy dotyczą kwestii związanych bezpośrednio ze sferą transakcyjną lub strategiczną (32%), niźli w przypadku sfery informacyjnej lub infrastrukturalnej (55%). Zatem im bardziej biznes jest zaangażowany w projekt, tym większe prawdopodobieństwo rezygnacji z niego w obliczu niepowodzeń. Inna sprawa, czy decyzja ta jest zawsze słuszna. Wniosek jest jednak jeden, im większa odpowiedzialność spoczywa na działach technologicznych, tym większe prawdopodobieństwo zlekceważenia pierwszych problemów.

Niestety, jak wynika z badań przeprowadzonych przez Cranfield School of Management, proces oceny inwestycji IT jest wciąż mocno skażony osobistymi bądź politycznymi aspiracjami użytkowników (potwierdza to 85% ankietowanych). Umiejętności oceny charakteru biznesowej zmiany następującej dzięki realizacji projektu są niewielkie (65%), podobnie zresztą jak umiejętności oceny korzyści biznesowych płynących z projektu (47%) i jakość komórek odpowiedzialnych za zatwierdzanie projektów (37%). Proces oceny inwestycji IT jest zbyt biurokratyczny (43%), a prawdziwe zaangażowanie menedżerów biznesowych jest niskie (40%).

Ważna ocena biznesu

Nadziei na poprawę należy upatrywać w tym, że aż 88% organizacji podejmuje wysiłki mające na celu zmianę tej sytuacji. Rozwiązanie problemu jest banalne, choć może być trudne w realizacji. Inwestycję w IT należy traktować jak każdą inną inwestycję i oceniać szanse jej powodzenia dokładnie w ten sam sposób. Niewątpliwie oznacza to konieczność większego zaangażowania biznesu w proces oceny i zarządzania projektem. Trzeba wreszcie oswoić organizacje z myślą, że projekty mogą się nie udać i co więcej stworzyć mechanizmy, które pozwolą na ich wycenę i ewentualne usunięcie na możliwie wczesnym etapie. ITGI zebrał te wszystkie rekomendacje w zbiorze praktyk "Val IT'series Enterprise Value: Governance of IT Investments", dostępnym na stroniehttp://www.itgi.org . Autorzy zbioru rekomendują wprowadzenie w organizacjach zarządzania portfelem projektów oraz zarządzania cyklem życia projektów na przestrzeni ich funkcjonowania.

<hr>

Z czego biorą się nasze kłopoty przy prowadzeniu projektów IT? Z tego, że nie patrzymy wstecz, nie patrzymy w przyszłość, a najważniejsze decyzje podejmujemy patrząc na to, kto w danej chwili jest najsilniejszy w organizacji. Za rzadko próbujemy też wrócić do punktu wyjścia, zmienić zakres projektu, tak aby bardziej dopasować go do strategii.
Kiedy projekt zawodzi

Eric Guldentops, doradca zarządu ISACA i IT Governance Institute, twórca standardu Cobit Trans European Research and Education Networking Association

<hr>

Dla Computerworld komentują

dr Jerzy Stawicki, niezależny konsultant, właściciel firmy JS Project

Złe lub źle prowadzone projekty są stanowczo zbyt późno "zabijane". Jednak praktycznego rozwiązania problemów z nimi związanych należy szukać wcześniej, jeszcze przed samym rozpoczęciem projektu. Po pierwsze konieczne jest określenie zasad definiowania projektów, obejmujących m.in. cele biznesowe oraz analizę kosztów i korzyści. Po drugie potrzebne jest opracowanie modelu oceny projektów zgłoszonych do portfela projektów firmy i zasad ich priorytetyzacji, uwzględniających m.in. zgodność z celami strategicznymi, korzyści biznesowe oraz możliwości realizacyjne. W praktyce oznacza to jedno — budowę systemu zarządzania portfelem projektów.

Warto również uświadomić kadrę kierowniczą, że nie istniał, nie istnieje i nigdy nie będzie istniał żaden algorytm wybierający najlepsze dla firmy projekty i gwarantujący ich powodzenie. Zawsze trzeba będzie zarządzać zarówno portfelem projektów, jak i poszczególnymi projektami, i robić to w profesjonalny sposób. A jeśli jeszcze do tego profesjonalizmu dodamy zarówno niekonwencjonalne myślenie, oparte np. na metodach zarządzania portfelem i projektem, takich jak Zarządzanie Ograniczeniami TOC (Theory of Constraints), to kto wie, być może przyjdzie moment, kiedy nie trzeba będzie rezygnować z realizacji projektów.

Andrzej Tarasiewicz, dyrektor ds. rozwoju rynku rozwiązań ITSM w HP Polska

Kiedy projekt zawodzi

Andrzej Tarasiewicz, dyrektor ds. rozwoju rynku rozwiązań ITSM w HP Polska

Praktyka niektórych przedsiębiorstw w zakresie zarządzania portfelem projektów IT przypomina strzelanie z wielkokalibrowej broni do pojawiających się nagle i przemieszczających się szybko celów. Liczba tych celów jest przy tym wprost proporcjonalna do dynamiki zmian w otoczeniu biznesowym danego przedsiębiorstwa. Organizacje projektowe w tego typu przedsiębiorstwach są pozbawione mechanizmów monitorujących położenie oraz prędkość przemieszczania się celu biznesowego. Dużym problemem jest także wciąż brak dobrej komunikacji pomiędzy biznesem i IT oraz zdolności do szybkiego wprowadzania nowych rozwiązań dostosowanych do dynamiki zmian w otoczeniu.

Z tego właśnie powodu bardzo rzadko podejmuje się decyzje o zmianie "sił i środków" użytych do osiągnięcia celu. Co gorsza, projekty prowadzone są dalej nawet wtedy, gdy ich cel już dawno wykroczył poza granice na wielo-wymiarowej mapie określającej sens jego realizacji. Jasny podział ról i odpowiedzialności oraz przypisanie ich do funkcji w poszczególnych działach firmy pozwala na narysowanie i aktualizację odpowiednio szcze-gółowej mapy oraz monitorowanie poruszających się po niej potencjalnych i rzeczywistych celów. Zarządzanie tak dużą ilością informacji, proporcjonalną do dynamiki zmian w biznesie, wymaga jasnych zasad, a często także zmiany w sposobie zarządzania.

Piotr Pachocki, starszy konsultant, ekspert ds. zarządzania projektami w Infovide-Matrix

Wdrożenie systemu oceny projektów pod kątem ich ewentualnego zamknięcia wymaga pewnej dojrzałości organizacyjnej. Decyzja o tym rzadko jest podejmowana przez osoby bezpośrednio zaangażowane w prowadzenie projektu. Dla wykonawców przedterminowa rezygnacja oznacza porażkę zawodową, a dla sponsorów zmarnowane środki. Dlatego też decyzja o rezygnacji z projektu powinna zostać podjęta przez struktury zewnętrzne, np. wyspecjalizowaną jednostkę kontrolingową, czy - co jest lepszym rozwiązaniem - centralne Biuro Projektów, mające zazwyczaj szerszy zakres działania. Oczywiście, aby taka kontrola miała sens konieczna jest standaryzacja i przejrzystość działań projektowych. Pragmatyczna droga do zwiększania efektywności powinna zaczynać się od standaryzacji procesu prowadzenia pojedynczego projektu, przez wdrożenie centralnych mechanizmów kontroli, po optymalizację portfela projektów.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200