Wypatrywanie potencjalnych skał i mielizn oraz obmyślanie sposobów ich omijania to powinność wszystkich stron projektu: sponsorów, kierownika i członków zespołu. Jeżeli jednak wachta w porę nie zauważy, że przedsięwzięcie dryfuje w niepożądanym kierunku, trzeba będzie wezwać pomoc.

Zagrożony projekt, również informatyczny, przypomina statek, który zboczył z kursu i osiadł na mieliźnie. Ponieważ nie może wrócić na właściwy kurs o własnych siłach, wezwani przez załogę właściciel statku, armator, a także właściciel przewożonego ładunku muszą wspólnie zastanowić się, co zrobić, aby ponieść jak najmniejsze straty. W przeciwieństwie do unieruchomionego statku ratowanie zagrożonego projektu informatycznego rzadko odbywa się na wniosek załogi. To udziałowcy projektu informatycznego - zazwyczaj sponsor lub klient - nie mogąc uzyskać od załogi informacji o pozycji lub też nie wytrzymując napięcia związanego z oczekiwaniem na przybycie statku do docelowego portu, biorą sprawy w swoje ręce.

Opcji jest kilka. Holowanie statku na głębszą wodę w celu uratowania zarówno jego, jak i ładunku nie zawsze jest możliwe. Jeżeli kadłub został uszkodzony, istnieje spore niebezpieczeństwo, że statek zatonie, a wtedy nic nie da się uratować. Alternatywą jest odciążenie statku przez usunięcie części ładunku - dzięki temu statek podniesie się z dna i powrót na kurs będzie możliwy. Być może jednak statek jest unieruchomiony na dobre. W tym przypadku można by podjąć próbę przeładowania choćby częś- ci ładunku na inny statek. Pytanie tylko, czy są na to czas i środki? Jeżeli poszycie statku jest dziurawe, a część ładunku zalana, najmniej kosztownym i ryzykownym wyjściem może się okazać jedynie zabezpieczenie wraku...

Właściwej decyzji nie da się podjąć bez rzetelnego ustalenia faktów: stanu statku, ładunku i załogi. Trzeba też rozważyć wszystkie czynniki zewnętrzne - odległość do najbliższego portu, pogodę, możliwości czasowe wynikające z zobowiązań itp. W przypadku każdego scenariusza ratunkowego należy także ustalić listę związanego z nim ryzyka, zagrożeń oraz sposobów radzenia sobie z nimi. Z reguły czasu jest mało, a stawka spora, dlatego w sytuacji kryzysowej najlepiej posługiwać się sprawdzonymi praktykami. Taki właśnie był wydźwięk spotkania - wykładu na temat sposobów ratowania zagrożonych projektów informatycznych, zorganizowanego niedawno przez Management Training & Development Center. Wykład poprowadził George Sifri, wieloletni kierownik projektów, instruktor firmy szkoleniowej ESI International.

Kilka wstępnych zastrzeżeń

Mówiąc o ratowaniu zagrożonych projektów, George Sifri czyni kilka ważnych zastrzeżeń. Po pierwsze, nie każdy projekt, w którym występują problemy, jest projektem zagrożonym. Według przedstawionej przez niego "roboczej definicji", projekt zagrożony to m.in. taki, którego uczestnicy nie są w stanie powiedzieć, kiedy on się zakończy lub na jakim etapie obecnie się znajduje. W takiej sytuacji projekt bezdyskusyjnie wymaga interwencji z zewnątrz.

Jeżeli żadna z tych sytuacji nie ma miejsca, a jedynie zostały przekroczone ustalone wcześniej wartości progowe (czas, budżet itp.) - oczywiście w rozsądnym stopniu - mają zastosowanie zwykłe techniki zarządzania projektami będące w gestii kierownika projektu. Gdy jednak odchylenia od założonych wartości są zbyt duże, operacja ratunkowa staje się bardzo zasadna. Podstawowym wyznacznikiem celowości ratowania projektu powinno być przekonanie, że jego kontynuowanie stwarza realną szansę na poprawę biznesu i wnosi wartość. Gdy projekt traci wsparcie wśród decydentów, zmieniają się potrzeby biznesowe leżące u jego podstaw, projekt traci sponsora lub gdy klient podjął już działania prawne, by wyciągnąć konsekwencje wynikające z zapisów umowy, ratowanie projektu zazwyczaj jest niecelowe.