Wiele sporów w projektach technologicznych bierze się stąd, że na etapie projektowania strony nie potrafią dobrze przewidzieć zakresu wykonywanych prac i możliwych problemów. Niepowodzenia w realizacji projektu prowadzą wtedy często do eskalacji problemu i ciągnących się latami, kosztownych sporów sądowych. Dlatego już na etapie tworzenia umowy, należy zadbać o odpowiednie narzędzia, które pomogą rozwiązać kwestie sporne – i uniknąć procesu sądowego.
Kilka lat temu doradzałem klientowi w ramach realizacji projektu informatycznego. Przedmiotem tego projektu było wdrożenie systemu obiegu dokumentów, który miał pomóc pracownikom zamawiającego w ich codziennych czynnościach biurowych: przyspieszyć procesy archiwizacji dokumentów i ułatwić zarządzenie sprawami przedsiębiorstwa. Projekt zakończył się całkowitym niepowodzeniem. Zamawiający złożył oświadczenie o odstąpieniu od umowy i naliczył kary umowne, a wykonawca zażądał zapłaty pełnego wynagrodzenia, ponieważ uważał, że projekt zakończył się porażką z uwagi na brak współdziałania zamawiającego. Dotkliwym rezultatem porażki projektu była także narastająca frustracja pracowników zamawiającego – zainwestowali w ten projekt dużo czasu, który nie przerodził się w sukces projektu.
Zagłębienie się w źródła niepowodzenia projektu pokazało, że spór między stronami wynikł stąd, że strony nie były w stanie uzgodnić zakresu projektu na etapie analizy. Zamawiający twierdził, że funkcjonalności związane z automatyzacją migrowania dokumentów znajdują się w zakresie umowy, a wykonawca był odmiennego zdania. Problem został przekazany do Komitetu Sterującego, który składał się z osób zaangażowanych w projekt wdrożeniowy – i nie był w stanie rozwiązać patowej sytuacji.
Trzy miesiące po odstąpieniu, zamawiający postanowił podjąć drugą próbę wdrożenia systemu obiegu dokumentów. Jednocześnie, miał uzasadnione obawy, że ponownie rozminie się z wykonawcą w rozumieniu postanowień umowy oraz docelowego zakresu.
Czy ryzyko trudności na etapie analitycznym jest nieodłączną cechą projektów IT? Czy jeżeli dojdzie do powstania problemu konieczne jest jego eskalowanie do stanu, w którym konieczne jest odstąpienie od umowy i wejście „all in” w spór sądowy?
Praktyka pokazuje, że zjedzenie słonia po kawałku może być dobrą zasadą w ramach sporów związanych z realizacją sporów IT. W drugim podejściu do realizacji projektu wyposażyliśmy zamawiającego w narzędzie, które doprowadziło do zakończenia projektu IT powodzeniem w drugim podejściu. Co ważne – w drugim podejściu zamawiający również natknął się na spory dotyczące zakresu realizowanych działań. W projektach technologicznych o skomplikowane strukturze jest to jak najbardziej naturalne i jest to problem, którego bardzo trudno uniknąć. Jednakże wyposażenie stron umowy w narzędzia do rozstrzygania sporów, które pomogły sprawnie rozstrzygnąć spory na jego wstępnym etapie, pozwoliło na uniknięcie porażki całego projektu.
Takim narzędziem jest krok w ramach procedury eskalacji problemu, który polega na przekazaniu problemu do koncyliacji eksperckiej. W tym konkretnym przykładzie, uzgodniony między stronami ekspert, w oparciu o uzgodniony między stronami materiał dowodowy, wypowiadał się na temat zasadności stanowisk stron w obszarze zgodności analizy oraz docelowego systemu z zakresem umowy. Nic nie stoi również na przeszkodzie, aby koncyliację zastąpić wiążącym arbitrażem w zakresie konkretnych zagadnień, których nie da się rozstrzygnąć w procedurze eskalacji. Dla zapewnienia szybkości procedowania – tak ważnego w projektach IT – w zapisie na sąd polubowny można zawrzeć wytyczne dotyczące czasu postępowania oraz ograniczenia w zakresie kosztów zastępstwa procesowego.
Eskalowanie problemów i radykalne działania rzadko przynoszą satysfakcjonujący efekt. Spieranie się o wszystko, jest drogą do poniesienia znacznych kosztów oraz do niezadowolenia strony i docelowych użytkowników systemu IT, który nie został wykonany. Szybkie rozstrzygnięcie problemu, jeszcze w czasie projektu, może pozwolić na zakończenie projektu z sukcesem dla obu stron.
Autor: Wojciech Jarosiński