Pisanie umów dla projektów IT realizowanych w Agile

Prawie 20% projektów IT kończy się niepowodzeniem, a niektóre z nich kilkakrotnie przekraczają założony budżet. Rekord z Wlk. Brytanii to ponad 64 mld zł na nieudany projekt! Jaka jest więc rola prawnika w projektach wdrożeniowych w obliczu związanych z nimi ryzyk?

Wdrożenia systemów IT to zdecydowanie jedne z najbardziej skomplikowanych przedsięwzięć w branży IT. Znajduje to potwierdzenie chociażby w kosztach związanych z realizacją wdrożeń oraz skalą ryzyka wynikającą z ewentualnego niepowodzenia projektów wdrożeniowych. Dla każdego, kto choć raz brał udział w tego rodzaju przedsięwzięciu, nie stanowi zaskoczenia długość prowadzonych w ramach wdrożeń negocjacji czy grubość dokumentacji towarzyszącej projektowi wdrożeniowemu. Z tych samych względów wdrożenia informatyczne stosunkowo rzadko kończą się pełnym sukcesem. Jak wynika z publikowanego przez The Standish Group raportu za rok 2013 („CHAOS Manifesto 2013: Think Big, Act Small”), tylko 39% wdrożeń IT zostało pomyślnie zrealizowanych,  18% zakończyło się klęską, a 43% wykonano z tzw. problemami (przekroczony budżet, harmonogram lub rezultat nieodpowiadający wymaganiom).

Koszty związane z nieudanymi projektami

Skutki takich nieudanych lub problematycznych wdrożeń najlepiej pokazać na konkretnych przykładach oraz towarzyszących im liczbach, które najbardziej dosadnie – aby nie powiedzieć drastycznie – przemawiają do naszej wyobraźni. Pierwszy przykład to absolutny światowy rekord w skali kosztów poniesionych w związku z nieudanym wdrożeniem IT. Rzecz dotyczy rozwiązania o nazwie Lorenzo, wdrażanego na zamówienie National Health Service (NHS) – związku systemów służby zdrowia Wielkiej Brytanii. Projekt finansowany był ze środków publicznych. Realizowany przez niemal 10 lat, którego celem było polepszenie warunków świadczenia usług medycznych dla pacjentów, poprzez m.in. usprawnienie obiegu dokumentacji medycznej pomiędzy placówkami, zakończył się fiaskiem. Zanim to się jednak stało, zdążył wydrenować kieszeń angielskiego podatnika na kwotę 12 mld funtów (odpowiednio: 19,4 mld USD, 64,4 mld zł)! Wystarczy dodać, że koszty poniesione w związku z nieudanym wdrożeniem pozwoliłyby na wypłatę wynagrodzenia dla 60 tysięcy angielskich pielęgniarek przez 10 lat, albo pokrycie, i to podwójnie, kosztów interwencji i stacjonowania wojsk angielskich w Iraku i Afganistanie.

Kolejne przykłady związane są z jednym z najbardziej magicznych miejsc na Ziemi, a mianowicie z Nowym Jorkiem. Pierwszy z nich to New York City Automated Payroll System, nad którym prace wystartowały jeszcze w 1999 r., a planowana data startu produkcyjnego została wyznaczona na rok 2011. Systemu nie uruchomiono do dzisiaj, a planowany pierwotnie budżet w wysokości 66 mln USD zdążył osiągnąć pułap 360 mln USD, ponad 5,5-krotnie przewyższając początkowe założenia. Drugi  przykład dotyczy systemu CityTime, kolejnej klęski wdrożeniowej, która przed ostatecznym fiaskiem, zdążyła pochłonąć 10 lat pracy oraz ponad 10-krotnie przewyższyć pierwotnie planowany budżet, sięgając ostatecznie kwoty w wysokości 700 mln USD, wobec planowanych 63 mln USD. W efekcie tych porażek władze Nowego Jorku wydały uchwałę, zgodnie z którą w każdym przypadku, w którym realizacja projektu IT przekroczy o 10% zakładany pierwotnie budżet, kierownictwo projektu ma obowiązek natychmiastowego poinformowania o tym fakcie Radę Miasta Nowego Jorku.

Ostatni przypadek jest – o ironio – związany z wymiarem sprawiedliwości i właśnie dlatego, zważywszy na kontekst tego artykułu, nie mógł nie pojawić się w tym zestawieniu. Tym razem rzecz dotyczy kalifornijskiego systemu sądowniczego, którego kierownictwo zamówiło wdrożenie systemu IT, mającego na celu poprawę jakości działań administracyjnych ułatwiających zwykłemu Johnowi Smithowi niełatwe co do zasady zetknięcie się z trybami wymiaru sprawiedliwości. Pomimo szlachetnych pobudek oraz wysokiej rangi zamawiającego, projekt zakończył się klęską. Nim to się jednak stało, zdążył wyciągnąć z kieszeni kalifornijskiego podatnika kwotę w wysokości 643 mln USD, o 50% większą wobec początkowo planowanej w budżecie.

W obliczu tych ryzyk rola prawnika w projektach wdrożeniowych często sprowadza się do pytania, co mogę zrobić, aby klienta przed tymi ryzykami uchronić. Odpowiedź na to pytanie zależy jednak w dużej mierze od wybranego modelu (metodologii), w jakim dane wdrożenie będzie realizowane, bo te właśnie modele w sposób zasadniczy wpływają na rodzaj, zakres oraz prawdopodobieństwo wystąpienia ryzyk związanych z realizacją projektów wdrożeniowych. Zanim więc o roli prawnika, przyjrzyjmy się dwóm konkurującym ze sobą modelom realizacji projektów IT.

Podejście waterfall do projektów

Generalnie rzecz biorąc, metodologia realizacji projektów wdrożeniowych w modelu Waterfall sprowadza się do założenia, że spodziewany końcowy rezultat wdrożenia jest precyzyjnie opisany już na jego początku. Przyjmujemy za pewnik, że w przygotowanej analizie przedwdrożeniowej przewidziane zostały m.in. wszystkie wymagania, funkcjonalności oraz parametry techniczne niezbędne do powodzenia projektu. Innymi słowy, już na starcie wiemy dokładnie co będzie na mecie. Umawiamy się również, że to, co chcemy uzyskać, będzie realizowane w wyraźnie odrębnych, kaskadowo (stąd Wodospad) po sobie następujących etapach (planowanie → analiza → wytworzenie kodu → testy → wdrożenie/start produkcyjny). Warto dodać, że poza tym, że wiemy „co” i „kiedy”, najczęściej wiemy też „za ile”. W zasadzie więc wiemy wszystko co prawnikowi do szczęścia potrzeba. A zatem w czym problem … W kolejności!

Miał rację Steve Jobs – który pojawi się jeszcze na łamach tego cyklu – kiedy twierdził, że ludzie nie wiedzą czego chcą, dopóki tego nie zobaczą. Wyobraźmy sobie naszą reakcję, gdyby jakiś czas temu ktoś nam powiedział, że wszystko, czego potrzebujemy do szczęścia, to coś, co jest trochę większe od naszego telefonu i trochę mniejsze od naszego laptopa, a dodatkowo nie można z tego do nikogo zadzwonić. Cóż, wyniki sprzedaży iPada zdają się mówić same za siebie. Kiedy już go zobaczyliśmy, część z nas zaczęła zadawać sobie pytanie natury czysto egzystencjalnej – czym było moje życie bez tabletu Apple’a? Inni zaczęli traktować jego zakup jako wyraźną cezurę na życie przed i po zakupie iPada. Podobny przykład związany jest z legendarnym Henrym Fordem, który z właściwym sobie poczuciem humoru stwierdził, że gdyby na początku swojej kariery zapytał klientów, czego chcą, wszyscy byliby zgodni: chcemy szybszych koni. Więc ich nie pytałem – dodał. Te dwa przykłady wydają się dobrą ilustracją tezy, że „to”, czego naprawdę chcemy, wiemy dopiero wtedy, kiedy „to” zobaczymy.

Coraz szybciej dezaktualizująca się analiza założeń

Pierwsze kontrakty dla wdrożeń realizowanych w modelu Waterfall powstały na początku lat 80. XX wieku. Jednocześnie sama metodologia sekwencyjnej, kaskadowej realizacji projektów informatycznych czerpie założenia jeszcze z czasów Rewolucji Przemysłowej i właściwych tym czasom metodom produkcji, których piewcami byli wspominany wcześniej Henry Ford czy Frederick Taylor. To jasne, że 30 lat, jakie dzielą nas od tamtych czasów, to lata świetlne w kontekście rozwoju rynku IT i rozwiązań informatycznych. Co więcej, dynamika i szybkość, z jaką te zmiany następują, są obecnie o niebo większe, niż chociażby w latach 90. ubiegłego stulecia.

Nie zanosi się na to, aby ten trend miał się zmienić. Czym to  jest spowodowane? Mianowicie tym, że to, co sobie na początku projektu ustaliliśmy w zakresie wymagań lub funkcjonalności projektowanego rozwiązania, może się, ze względu na średni czas realizacji wdrożenia, kompletnie rozmijać z realnymi potrzebami biznesowymi zamawiającego. Zgodnie z ostatnimi badaniami przeprowadzonymi przez Uniwersytet Missouri pod kierownictwem prof. Ala Goernera, coraz szybsze tempo rozwoju technologicznego skutkuje coraz wyższym współczynnikiem erozji wymagań zawartych w analizie przedwdrożeniowej pomiędzy etapem ich ustalenia a faktyczną implementacją. Badacze z Uniwersytetu Missouri, analizując stopień erozji (dezaktualizacji) analizy przedwdrożeniowej, wykorzystali pojęcie tzw. czasu połowicznego zaniku (half-life), jakie odnosi się do średniego czasu, po jakim aktywność izotopu promieniotwórczego spada do połowy swojej początkowej wartości (S. Atkinson, G. Benefield, “Software Development: Why the Traditional Contract Model Is Not Fit for Purpose”, HICSS, 2013, 2013 46th Hawaii International Conference on System Sciences). Innymi słowy, pozwala to zmierzyć, po jakim czasie 50% zawartych w analizie przedwdrożeniowej ustaleń przestanie być aktualne.

O ile w latach 80. XX wieku half-life analizy przedwdrożeniowej wynosił 10-12 lat, o tyle w roku 2000 wynosił już tylko 2-3 lata, aby obecnie spaść do 6 miesięcy. Tym samym połowa wymagań objętych analizą dezaktualizuje się już po 6 miesiącach, połowa z pozostałej połowy (25%) stanie się nieaktualna jeszcze przed upływem 12 miesięcy, połowa z pozostałej ćwiartki (12,5%) będzie nic nie warta, zanim skończy się 18 miesiąc od startu projektu itd. Wygląda zatem na to, że nim przekroczymy 18 miesiąc od daty sporządzenia analizy przedwdrożeniowej, tylko 12,5% jej zawartości pozostanie aktualne.

Ryzyko kurczowego trzymania się metody kaskadowej

Podsumowując, w obecnych realiach rynkowych (ultraszybka dynamika rozwoju technologicznego) oraz właściwych dla gatunku homo sapiens cechach poznawczych (wiem co chcę dopiero jak to zobaczę) kurczowe trzymanie się metody kaskadowej we wdrożeniach informatycznych może w optymistycznym scenariuszu pozwolić nam na uzyskanie tego co (teoretycznie) chcemy, co oczywiście wcale nie musi być tym, czego akurat właśnie potrzebujemy, w najgorszym zaś scenariuszu doprowadzi do fiaska projektu, gigantycznych kosztów, procesów sądowych i masy nerwów. A co mówią statystyki? Ponad połowa (51,8%) przypadków, w których wdrożenie nie zostało zrealizowane albo zostało zrealizowane z problemami, to niewłaściwa lokalizacja wymagań zawarta w analizie przedwdrożeniowej lub zmiana potrzeb zamawiającego w trakcie realizacji wdrożenia (The Standish Group Report 2013).

Na koniec warto podać przykład, który z matematyczną precyzją ilustruje i obnaża wady metodologii sekwencyjnej. Przypadek dotyczy Departamentu Obrony USA, który tylko w 1995 r. wydał na zakup IT kwotę rzędu 35,7 mld USD. Jak jednak wykazał przeprowadzony audyt, jedynie 2% zakupionych rozwiązań IT nadawało się do wykorzystania. 75% zakupionej technologii – w konsekwencji źle przeprowadzonej analizy lub zmieniających się w toku wdrożenia potrzeb zamawiającego – okazało się całkowicie bezużyteczne. Pozostałe 23% zakupionych rozwiązań poddano gruntownym modyfikacjom przed ich produkcyjnym zastosowaniem. Odwołując się zatem do żargonu wojskowego, zaledwie 750 mln USD stanowiło trafiony wydatek, w pozostałej zaś części (niemal 35 mld USD) Departament Obrony istotnie przestrzelił.

Zatem wydaje się, że leżąca u podstaw modelu Waterfall zasada, zgodnie z którą przed rozpoczęciem procesu produkcyjnego powinniśmy precyzyjnie określić jego końcowy rezultat, jest zakodowanym w proces wdrożeniowy wirusem generującym realne ryzyka, o trudnych do przecenienia konsekwencjach.  O tym, jak Agile odpowiedział na sygnalizowane powyżej problemy i jak to przełożyło się na konstrukcję umów wdrożeniowych oraz rolę prawnika w projektach informatycznych, już w następnym artykule (w numerze ITwiz 8/2014).

Autorami tekstu są: Marcin Maruta – specjalista w zakresie projektów IT. Doradzał największym krajowym i międzynarodowym dostawcom usług IT oraz odbiorcom tych usług. Koordynuje obsługę prawną międzynarodowych sporów sądowych i arbitrażowych oraz Łukasz Węgrzyn – prawnik w Kancelarii Radców Prawnych Maruta i Wspólnicy. Specjalista z zakresu prawa nowych technologii, własności intelektualnej i mediów. Wcześniej pracował między innymi jako prawnik wewnętrzny dla Agora, MTV Networks oraz członek zespołu TMT kancelarii prawnej „Bird & Bird”.