Przy tworzeniu projektów informatycznych potrzebna jest konsekwencja aktualizacji dokumentów uwzględniających niekorzystne wydarzenia, a także zmysł obserwacji środowiska projektu i dużo wyobraźni osób zarządzających całym przedsięwzięciem.

O tym, że 90% projektów informatycznych kończy się po wyznaczonych terminach i z przekroczonym budżetem lub nie kończy się w ogóle, nie trzeba nikomu przypominać. To, że niepowodzenia informatycznych projektów odbijają się negatywnie na całym przedsiębiorstwie, powodują utratę motywacji pracowników, dezorganizują podstawową działalność, podkopują zaufanie do kadry zarządzającej i mogą spowodować spadek konkurencyjności firmy, również wydaje się jasne i nie wymagające komentarza. A jednak wciąż wiele projektów jest prowadzonych w całkowitej sprzeczności z zasadami sztuki: kolejne fazy projektu planowane są z tygodniowym wyprzedzeniem, brak zdefiniowanych struktur organizacyjnych i odpowiedzialności poszczególnych członków zespołu projektowego, kadra zarządzająca dowiaduje się o postępach realizacji projektu z branżowej prasy lub od konkurencji, a końcowy użytkownik nigdy nie wypowiedział się co do swoich potrzeb. "Polaków charakteryzuje duch partyzancki - sądzą oni, że poradzą sobie w każdych warunkach. Często idzie to w parze z brakiem umiejętności przewidywania i planowania" - mówi Kazimierz Leśniak, kierownik Działu Informatyki w Pilkington Sandoglass z Sandomierza. Również cechują się oni brakiem umiejętności przewidywania ryzyka.

Nadmiar optymizmu

Wiele projektów informatycznych przebiega przy optymistycznym założeniu, że wszystko pójdzie zgodnie z planem. Podejście hurra-optymistyczne nie wynika wyłącznie z braku wyobraźni. Opracowanie karty ryzyka i jej ciągła aktualizacja wymaga czasu pracowników firmy doradczej i użytkowników, poświęcanego na rozmowy, dyskusje i intensywną pracę koncepcyjną. A projekty informatyczne zazwyczaj są realizowane pod presją czasu, najchętniej poświęcanego na wykonanie prac w widoczny sposób posuwających projekt do przodu. Jednocześnie żadnej ze stron nie zależy na wyciąganiu na światło dzienne kłopotliwych kwestii. Dostawca rozwiązania nie chciałby stwarzać wrażenia, że nie radzi sobie z projektem, klient wolałby całą odpowiedzialność za losy projektu przenieść na dostawcę. "W jednym z dużych projektów, starannie przygotowaliśmy Kartę Projektu. Wyspecyfikowaliśmy zakres, cele, plany wdrożenia, punkty kontrolne, nazwaliśmy zidentyfikowane czynniki ryzyka, oszacowaliśmy prawdopodobieństwo ich wystąpienia, zaproponowaliśmy środki zapobiegawcze i plany awaryjne. Nasz klient wręcz się przestraszył, tym bardziej że miał już wcześniej niekorzystne doświadczenia z wdrażaniem projektu informatycznego" - opowiada Bogumił Dałkowski, prezes firmy doradczej GET Manager we Wrocławiu. W większości metodologii wdrażania systemów zintegrowanych zarządzanie ryzykiem jest wymieniane jako element konieczny wdrożenia, jednak w praktyce jest on jednym z najbardziej zaniedbywanych. W dużym projekcie z całą pewnością pojawią się problemy, sytuacje kryzysowe i przejściowe załamania. Sztuką jest ich wcześniejsze przewidzenie, zauważenie symptomów kryzysu, poinformowanie o tym fakcie wszystkich zainteresowanych i podjęcie rozsądnych działań. Sprawne zarządzanie ryzykiem w projekcie zwraca się z nawiązką. "Moment, w którym potwierdza się efektywność wcześniej przygotowanych procedur awaryjnych oraz ścieżek postępowania w sytuacjach zagrożenia i kryzysu, jest najczęściej momentem, w którym znacznie wzrasta zaufanie kadry zarządzającej do prowadzących projekt" - wyjaśnia Marcin Kamiński, kierownik projektu wdrożenia SAP R/3 w Intercell z Sieradza.

Ryzyko w projekcie informatycznym to prawdopodobieństwo wystąpienia zdarzenia, które niekorzystnie wpłynie na przebieg projektu. Najczęstsze syndromy pojawienia się problemów to przesuwanie terminów zakończenia kolejnych etapów projektu i potrzeba zainwestowania dodatkowych środków finansowych. Przyczyny ich powstawania są zróżnicowane, począwszy od braku czytelnego zdefiniowania celów projektu i poparcia zarządu, poprzez mało kompetentny i słabo umotywowany zespół projektowy, częste zmiany specyfikacji wymagań i brak efektywnych struktur decyzyjnych, skończywszy na zmianie zarządu lub właściciela w trakcie wdrożenia.

Zdaniem analityków Gartner Group, ponad 60% źródeł ryzyka wiąże się z dostępnością zasobów, wymaganiami użytkowników, charakterystyką organizacji klienta i procesem zarządzania. Relatywnie niewielkie znaczenie ma technologia, błędy programistyczne czy zmiany legislacyjne. "Zarządzanie ryzykiem w projektach informatycznych jest trudne i złożone, ponieważ najważniejsze czynniki ryzyka związane są z ludźmi" - stwierdza Andrzej Sieradz, dyrektor centrum przetwarzania danych w Coca-Cola Beverages w Radzyminie.