Technologie: Dlaczego projekty IT nie udają się?

Bartosz Illukiewicz
Paweł Grzelak

Wiele porażek wdrożeń projektów informatycznych wynika z nieporozumień pomiędzy różnymi stronami zaangażowanymi w projekt, a także z asymetrii informacji między odbiorcą (bankiem) a dostawcą określonych usług. Stopień skomplikowania bankowych projektów IT sprawia, że zleceniodawca już po zawarciu umowy z zewnętrznym dostawcą usług, często de facto nie wie, za co płaci.

Wysokie ryzyko projektów IT potwierdzają wyniki serii sondaży przeprowadzanych przez Standish Group, znanych pod nazwą Chaos Report. Badanie, obejmujące obecnie 50 tys. projektów software development na całym świecie, po raz pierwszy przeprowadzono w 1994 r. Ocenia ono projekty w trzech kategoriach: przekroczenie budżetu, przekroczenie zakładanego kosztu i stopień zrealizowanych funkcjonalności.

W pierwszym sondażu odsetek projektów zwieńczonych sukcesem wynosił jedynie 16 proc., zrealizowanych z częściowym niepowodzeniem(tzn. opóźnionych, z przekroczonym budżetem lub bez dostarczenia pełnej zakładanej funkcjonalności) – 53 proc., a zakończonych niepowodzeniem (tj. takich, które nie zostały doprowadzone do końca) – aż 31 proc.

Choć z upływem lat nastąpiła poprawa i w najnowszym sondażu proporcje te wyniosły odpowiednio 32/44/24 proc., to wyniki nie dają specjalnych powodów do zadowolenia – wciąż pełnym powodzeniem kończy się wdrożenie jedynie jednego na trzy projekty. Raport Chaos swoim zasięgiem obejmował przede wszystkim duże firmy (45 proc. z tych, które wzięły udział w sondażu, znajdowało się też na liście „Fortune 1000”) i projekty ze Stanów Zjednoczonych – kraju, gdzie działa wiele stowarzyszeń zrzeszających certyfikowanych specjalistów od zarządzania projektami. Nadal w mocy pozostaje więc paradoks Cobba: „Wiemy, dlaczego projekty upadają. Wiemy, jak uchronić je przed porażką. Zatem dlaczego ciągle upadają?”

Ramy współpracy z dostawcami

Naszym zdaniem, kluczowe jest zrozumienie różnic w podejściu do negocjacji warunków współpracy między dostawcą a bankiem. Ten drugi z reguły dąży do maksymalnego obniżenia ceny podstawowej. Problem pojawia się, jeśli dostawcy nie tłumaczą w rzetelny sposób bankowi, jaki zakres usług otrzyma za obniżoną cenę. Wielu, aby pozyskać projekt, przystaje na dużo niższą cenę, równocześnie dyskretnie wprowadzając trudne do zauważenia ograniczenia zakresu i poziomu usług. W rezultacie już po rozpoczęciu projektu okazuje się, że do zrealizowania zakładanych funkcjonalności konieczny jest dwu-, trzykrotnie większy budżet od spodziewanego. Wtedy bank często nie ma już wyboru – na zmianę dostawcy nie pozwala deadline projektu albo po prostu się to nie opłaca. Takie działania dostawcy możliwe są wtedy, gdy zawarta z bankiem umowa gwarantuje mu względną bezkarność.

Dostawca usług oczywiście również ponosi określone ryzyko – inwestuje w projekt i zrozumiała jest potrzeba zabezpieczenia przez niego swoich interesów. Bank musi jednak mieć świadomość kilku spraw, które mogą wpłynąć na zbytnią nierównowagę relacji i sprawić, że po podpisaniu umowy dostawca stanie się absolutnym monopolistą, a koszt usług wykraczających poza podstawowy zakres drastycznie wzrośnie. Typowe zagrożenia dotyczące umów z dostawcami to:

• brak możliwości bezpiecznego zakończenia współpracy,
• brak jasnego zrozumienia (jednakowego przez obie strony) zakresu i spodziewanego poziomu usług,
• brak odniesienia do aspektów biznesowych,

Dla bezpieczeństwa banku kluczowy jest sposób, w jaki kontrakt określa możliwości odstąpienia przez strony od umowy. Zapisy ...