Okiem prawnika: o błędach w projektach IT i umowach na każde czasy
Jakie błędy popełniamy najczęściej w projektach IT? Czy brak exit planu może spowodować eskalację potencjalnego sporu? Jak przygotować umowę na każde czasy, aby zminimalizować ryzyko wystąpienia sporu lub przynajmniej stawiać w lepszym położeniu stronę?
Te kwestie wyjaśnia nasz ekspert Piotr Kaniewski w rozmowie z CRN.
Jeżeli rzeczywiście realizacja blisko połowy wdrożeń IT napotyka poważne kłopoty, a około 25 proc. z nich kończy się fiaskiem, należałoby się za-stanowić, czy wysokie prawdo-podobieństwo niepowodzenia nie jest dla takich projektów immanentne. Z drugiej strony można zauważyć, że to wynika z konkretnych problemów. A problemy można przecież wyeliminować.
Wdrożenia systemów informatycznych są skomplikowany-mi przedsięwzięciami, które nierzadko trwają kilkanaście miesięcy albo nawet kilka lat. W trakcie ich realizacji zmieniają się oczekiwania, trendy i standardy technologiczne, a także wskaźniki gospodarcze, prawo i same organizacje uczestniczące w projekcie lub ich przedstawiciele. Niestety, procesowi pozyskiwania i sprzedawania technologii zazwyczaj towarzyszy pośpiech. W połączeniu z częstą dysproporcją wiedzy i doświadczenia na korzyść dostawcy IT oraz brakiem zaufania ze strony zamawiającego, daje to mieszankę powodują-cą problemy. Co ważne, da się zauważyć, że większość tych problemów wykazu-je istotne podobieństwa. Są one wręcz powtarzalne i przeważnie skutkują dale-ko idącymi konsekwencjami.Przy czym często przyczyna niepowodzenia wdrożenia leży u jego samego początku – w procesie sprzedażowym. Nadal typowe jest przeprowadzanie go w dość formalistyczny sposób, nieróżniący się od procedur zakupów dla innych dóbr czy usług. Tymczasem obszar IT wymaga dedykowanego podejścia ze względu na swoją specyfikę. Szczególnie rekomendowane jest uzyskanie w trakcie procesu zakupowego „próbek” pracy uczestniczących w nim dostawców. Dodatkowo, zdarza się, że dział zakupów danej organizacji pozostaje osamotniony w obliczu zakupu i w kluczowym momencie wyboru dostawcy nie uczestniczą członkowie pionów IT, biznesu, bezpieczeństwa czy działu prawnego. Tymczasem rekomendowanym podejściem jest komponowanie cross-funkcjonalnych zespołów zakupowych, do których należą „zakupowcy”, biznes, IT, „bezpiecznicy” i prawnicy. Następnie, takie zespoły po-winny kontynuować proces negocjacyjny z dostawcą IT.
Umowa z głową
Nawet najlepsza umowa nie uchroni w 100 proc. przed sporem. Może ona natomiast zminimalizować ryzyko jego wystąpienia lub przynajmniej stawiać w lepszym położeniu stronę, która faktycznie jest w danym sporze pokrzywdzona. Niemniej nie oznacza to, że umowa powinna być instrumentarium sankcji na wypadek każdego możliwego niepowodzenia. Popularne jest powiedzenie, że „umowę pisze się na złe czasy”. Perspektywa prawnika kontraktowego każe przeciwstawić się temu twierdzeniu. Takie podejście będzie swoistą samospełniającą się przepowiednią. Jeśli strony będą pisać umowę na złe czasy, niechybnie takie złe czasy wygenerują. Kontrakt wdrożeniowy powinien być pisany na każde czasy – tak, aby w przypadku napotkania problemów służyć opcją odnalezienia rozwiązania. Powinien stanowić swoistą instrukcję działania w różnych sytuacjach, nie quasi-kodeks kar. Powinien ponadto motywować strony do wypełniania swoich zobowiązań, zarówno bodźcami negatywnymi, jak i pozytywnymi. Jeśli finalnie spór okazał się nieunikniony, umowa powinna dostarczać narzędzi dochodzenia swoich praw przez stronę, która została pokrzywdzona działaniem lub zaniechaniem kontrahenta.
Przeszacowane oczekiwania
Często się zdarza, że zamawiający przeszacowują oczekiwania względem narzędzia IT, które chcą pozyskać. Nieco upraszczając, chcą, żeby robiło ono „wszystko”. Jako że nie ufają swoim dostawcom, oczekują dostarczenia na wstępie bardzo szczegółowej specyfikacji takiego narzędzia, a następ-nie „odhaczania” jej kolejnych elementów. Powoduje to, że dostawca, zamiast skupić się na dostarczeniu najistotniejszych funkcjonalności, poświęca czas i zasoby na elementy systemu, które tak naprawdę nie są kluczowe. Z kolei zbyt szczegółowa specyfikacja rozwiązania IT pozostawia mało miejsca na jego interpretację przez dostaw-cę. W ten sposób odcinana jest możliwość zaaplikowania przez niego jego najlepszych praktyk a jednocześnie powstaje ryzyko dezaktualizacji wymagań. Może się bo-wiem okazać, że po kilku lub kilkunastu miesiącach pierwotne oczekiwania za-mawiającego okazały się nietrafne, przestarzałe technologiczne lub po prostu nie odpowiadają nowym realiom prawnym.Wiemy, czego chcemy dopiero, kiedy to zobaczymy. Dlatego umowa powinna zakładać możliwie częste wydania produkcyjne i procedury korygowania zakresu umowy – tak, aby dostosować rozwiązanie do realnych potrzeb klienta.
Metodyka projektowania innych światów
Popularnym przepisem na niepowodzenie projektu jest pozostawienie umowy i metodyki wdrożenia w dwóch różnych rzeczywistościach. Odbiera to stronom roszczenia prawo żądania wzajemnego wypełniania obowiązków wynikających z przyjętej metodyki. Jeśli zatem istnieją rozbieżności w interpretacji jej zasad albo po prostu strona się jej nie trzyma, to w konsekwencji brakuje narzędzia, które zapewniłoby egzekucję założonego planu działania. We wdrożeniach istotne jest bowiem nie tylko co ma zostać dostarczone, ale także to, jak ma się to odbyć. Kontrakt powinien zatem definiować nie tylko to, co dostawca ma wdrożyć, ale także w jaki sposób.
Model wynagrodzenia bez szans powodzenia
„Dostawca robi to, za co mu się płaci”. To truizm, ale bardzo mądry w kontekście projektów IT. Model wynagrodzenia niezagregowany z modelem dostarczania niesie za sobą znaczne ryzyko niepowodzenia projektu. Tymczasem zamawiający często nie-chętnie na bieżąco rozliczają się z dostawcą. Prowadzi to do sytuacji, w której w naturalny sposób priorytet danego klienta spada. Pokrywanie przynajmniej bieżących kosztów dostawcy zwiększa jego motywację do pracy dla swojego klienta. Z drugiej strony, naturalne dążenie dostawcy do jak najwcześniejszego „spieniężenia” projektu również generuje spory, stawiając w niekorzystnym położeniu zamawiającego. Płatność pewnej części wynagrodzenia należnego dostawcy musi być zależna od jakości jego pracy, a ta realnie jest weryfikowana przy testach regresji i wydaniach produkcyjnych. Co nie mniej ważne, model wynagradzania powinien odpowiadać modelowi dostarczania. Jeśli dostawca ma dostarczyć pracę (tj. ludzi dyspozycyjnych w danym czasie), model Time&Material faktycznie sprawdzi się znakomicie. Jeśli jednak dostawca ma dostarczyć swojemu klientowi konkretną wartość biznesową (np. funkcję XYZ systemu) – wówczas płatność wynagrodzenia powinna odpowiadać pro-gresowi w dostarczaniu wartości, a nie przepracowanemu czasowi.
Brak współdziałania Klienta
Niestety, rzadkością jest sytuacja, w której wdrożenie polega na prostej instalacji tzw. „pudełkowego” systemu bez angażowania zamawiającego. Przeważnie konieczne jest dość intensywne współdziałanie pomiędzy stronami. Jego brak jest najczęstszą bezpośrednią przyczyną niepowodzeń wdrożeń leżącą po stronie zamawiających.Skąd to się bierze? Można sądzić, że z braku przygotowania do współdziałania. A ono może wynikać albo z braku odpowiednich kompetencji ludzkich lub zasobów w organizacji, braku odpowiedniego planu działania, albo braku… odpowiednich umów z innymi dostawcami. Projekt IT może wymagać współpracy z dostawcami innych systemów (które mają być zintegrowane lub zastąpione). A jeśli kontrakt z nimi nie zapewnia roszczeń o taką współpracę, może się okazać, że tej zabraknie.Należy też wspomnieć, że zarzuty braku współdziałania bywają przez dostawców IT wykorzystywane jako oręż zaczepny – w przypadku, jeśli to dostawca napotyka jakieś problemy po swojej stronie i chce się uchylić od ich konsekwencji (wówczas zdarza się „zasypywanie” klienta mniej lub bardziej racjonalnymi żądaniami współdziałania w oczekiwaniu na jego potknięcie). Dobra umowa wdrożeniowa powinna precyzyjnie opisywać zakres współdziałania, tak aby strony miały możliwie ten sam obraz sytuacji oraz ustalone oczekiwania względem siebie.
Odpływ ludzi po stronie dostawcy
Grzechem, który obciąża niejednego dostawcę IT, jest zastępowanie w trakcie realizacji projektu najlepszych specjalistów (których obietnica wykorzystania nierzadko przesądza o powodzeniu sprzedaży usług przez tego dostaw-cę) mniej doświadczonym personelem. Może się to wiązać ze spadkiem jakości lub tempa prac, a także nierzadko po prostu z rozczarowaniem klienta samą postawą kontrahenta. Zalecaną praktyką jest wprowadzenie procedury dającej zamawiającemu pewną kontrolę nad zmianami kluczowej części personelu. W końcu to ludzie realizują każ-dy projekt i to od nich zależy powodzenie przedsięwzięcia.
Niejasne procedury weryfikacyjne i testowe
Nie powinno dziwić, że najczęściej spory eskalują w chwili, gdy przychodzi do weryfikacji rezultatów prac wdrożeniowych. Mogą one wynikać z wielu kwestii, w tym opisanych wcześniej problemów. Zdarza się też tak, że nieporozumienia generuje sam brak jasnej definicji powodzenia, gdy z umowy nie wynika, kiedy można uznać wdrożenie za należycie zrealizowane.Aby temu zaradzić, umowa powinna określać jak najbardziej klarowne kryteria akceptacji i definicję ukończenia. Poza tym bardzo skrupulatnie powinny zostać opisane procedury weryfikacyjne, w tym testy: jakie, kiedy, kto oraz w jaki sposób je przeprowadza.
Brak planu E(exit)
Może to zaskakiwać, ale jasny plan na wypadek konieczności rozstania sprzyja trwałości relacji zamawiający-dostawca IT. Zawarcie w kontrakcie jasnego exit pla-nu daje stronom pewien komfort: gdy coś nie idzie po ich myśli, nie muszą zaczynać zastanawiać się, co będzie, jak się nie uda. Mogą skupić się na swojej pracy, bo umowa jasno przewiduje, co się stanie w przypadku niepowodzenia. Warto mieć na uwadze, że taka sytuacja może się wydarzyć nawet przy najlepszej współpracy stron (bo np. dojdzie do całkowitej zmiany strategii biznesowej klienta albo nadejdzie zdarzenie w typie pandemii COVID-19) .Brak exit planu może spowodować eskalację potencjalnego sporu. „Dogadamy się, co zrobić, jeśli się pokłócimy w trakcie kłótni” zazwyczaj nie działa. Za to konkretny plan rozwiązania relacji, opisujący co strony po-winny sobie przekazać, redukuje ryzyko chaosu charakterystycznego dla kryzysów relacji biznesowych. Oczywiście nawet najlepsza umowa nie za-pobiegnie sytuacji, w której dana strona odmówi jej wykonania (tak jak żadne metody projektowe czy nawet największe pieniądze), ale może ułatwić jej egzekwowanie. Już sama możliwość dochodzenia wykonania konkretnej czynności może zostać uznana za jakiś sukces w razie wystąpienia konfliktu.