Zazwyczaj, gdy myślimy o dużych projektach infrastrukturalnych, wyobrażamy sobie drogi, mosty, tunele, czy trakcje kolejowe. W tradycyjnym podejściu, modernizacja infrastruktury wiążę się z inżynierią budowlaną, i zdecydowana większość uwagi zespołu projektowego, związana jest z tym właśnie aspektem. Jednak w dzisiejszym cyfrowym świecie, charakterystyka projektów infrastrukturalnych zmienia się diametralnie. Cyfrowe technologie stały się integralnym elementem sprawnie funkcjonujących obiektów budowlanych. Co więcej, często są one tak samo ważne, jak stal, beton, czy asfalt. Mimo to, w branży budowlanej, powszechne zrozumienie tych technologii, ich potencjału, ale także ograniczeń pozostaje daleko w tyle.
Sondaż przeprowadzony w 2021 przed GlobalData1 pokazał, że prawie połowa ankietowanych pracujących w branży budowlanej uważa, że inwestowanie w nowe technologie jest nieopłacalne. Wyniki badania wskazały na brak funduszy, wyszkolenia oraz zrozumienia nowych technologii jako źródła oporu i powściągliwości z jaką branża budowlana traktuje innowacje.
My, ludzie, mamy wrodzoną umiejętność szacowania ryzyka naszych przedsięwzięć „na oko”, lub „na wyczucie”. Jednak nie zawsze ta ocena musi być poprawna. Często, w swoich szacunkach, mamy tendencję do kierowania się w stronę tego, co znamy, i ignorujemy to, co jest nam obce. To uprzedzenie wynikające z nieznajomości (familiarity bias) może doprowadzić do pominięcia istotnych czynników wpływających na poprawne ocenienie ryzyka. Duże projekty infrastrukturalne są zazwyczaj zarządzane przez profesjonalistów związanych z budownictwem, którzy na betonie zjedli zęby. Jednak ta właśnie wiedza i doświadczenie (familiarity), mogą okazać się ograniczające. Bo jeśli do dyspozycji ma się tylko młotek, wszystko zaczyna wyglądać jak gwóźdź. Podobnie, jeśli nasza wiedza ogranicza się do betonu i stali, to nasz projekt infrastrukturalny skupi się tylko na tym. Tymczasem, jednym z często niedocenianych (przez nieznajomość) elementów projektów budowlanych, jest budowa oprogramowania do sprawnego i bezpiecznego funkcjonowanie infrastruktury.
Zarządzanie projektem – na styku sprzecznych filozofii
Wykładnicze tempo rozwoju informatyki sprowokowało potrzebę przemyślenia filozofii zarządzania projektami. Zwinne i bardziej odporne na zmiany podejście (Agile Project Management) jest wszechobecne w domenie tworzenia oprogramowania. Niestety, zwinne metody stoją w sprzeczności z tradycyjnym, sztywnym modelem zarządzania projektami budowlanymi, gdzie jakiekolwiek zmiany są często postrzegane jako źródło wszelkich nieszczęść.
W przeciwieństwie do tradycyjnego, liniowego planowania zakresu obiektów budowlanych, proces tworzenia oprogramowania jest z natury cykliczny i nieliniowy. Wszystkie funkcjonalności przechodzą przez ten sam proces tworzenia, testowania, usuwania błędów, ponownego testowania. Proces ten powtarzany jest na poziomach podsystemu i systemu, tak długo, jak to konieczne, by oprogramowanie było stabilne i funkcjonalne.
Na projektach infrastrukturalnych, integracja software’u w całość systemu, zazwyczaj, następuje pod koniec projektu. Natomiast, wczesne etapy projektu zdominowane są przez ciężkie roboty inżynieryjne, a rozwój oprogramowania odbywa się równolegle, niejako w tle. W rezultacie do uprzedzeń wynikających z nieznajomości domeny software’u przez zarządzających projektem, dochodzi problem związany z błędem bliskości (proximity bias) tak często wpływającym na poprawną ocenę ryzyka. Bardzo trudno jest skupić się na rozwoju oprogramowania, którego będziemy potrzebować za dwa lata, jeśli dzisiaj, tu i teraz, mamy poślizg, bo podwykonawca przywiózł za krótkie belki stalowe. Naszą naturalną tendencją jest przeszacowanie wagi problemów, które stoją tuż za rogiem, i niedowartościowanie ryzyka czekającego w dalszej przyszłości. Niestety, ten błąd prowadzi do stopniowo pogłębiającej się rozbieżności priorytetów projektu, a co za tym idzie, opóźnień, wysokich kosztów, i potencjalnych roszczeń.
Crossrail – opóźniony (między innymi) przez oprogramowanie
Crossrail, londyński projekt budowy nowej nitki metra, był reklamowany jako największy projekt infrastrukturalny w Europie w 2008 roku. Początkowo, uwagę wszystkich zainteresowanych pochłaniały bardzo skomplikowane prace związane z drążeniem tuneli w centrum Londynu. Pomimo wielu inżynierskich problemów i ryzyka związanego z pracami tunelowymi, Krajowe Biuro Audytu (National Audit Office – NAO) w 2014 roku wydało pozytywną opinię o postępie prac: „Crossrail osiągnął większośc lub wszystkie kamienie milowe wyznaczone na każde kolejne półrocze”2.
Pięć lat później, opinie NAO już nie były tak pozytywne. Pomimo pewnych komplikacji, roboty tunelowe okazały się nie być największym problemem na Crossrail. Niespodziewanie, projekt zaczął doświadczać znaczących opóźnień w 2015 roku, gdy tunele były już wydrążone.
Aby mitygować opóźnienia, zespół projektowy postanowił przeprowadzić równolegle część robót konstrukcyjnych i testy dynamiczne. Niestety, efektywne wykonanie testów okazało się problematyczne, gdyż „oprogramowanie składów i sygnalizacji nie osiągnęły odpowiedniego poziomu kompletności”3. Problemy z softwarem spowodowały, że „niewiele testów zostało przeprowadzonych z sukcesem”, i co więcej, ten nieskuteczny program testowania „pochłonął wiele dodatkowego czasu i wysiłku pracowników”, powodując coraz większe opóźnienia i wzrost kosztów prac konstrukcyjnych.
Problemy z softwarem nie był jedyną przyczyną opóźnień na Crossrail, ale z pewnością odegrały one znaczącą rolę. Mark Wild, dyrektor generalny Crossrail, w wywiadzie udzielonym w 2021 roku stwierdził: „Crossrail to ogromny, bardzo skomplikowany, cyfrowy zasób (…) bardziej zbliżony do wielkich przedsięwzięć z branży IT, niż z sektora infrastrukturalnego”4. Ta opinia nie była zbyt powszechna, ani popularna na wczesnych etapach projektu.
Positive Train Control – tworzenie software’u w tle
W 2008 roku, Kongres Stanów Zjednoczonych Ameryki, uchwalił ustawę5, wymagającą, aby wszystkie najważniejsze linie kolejowe (Class 1 Railroads) wprowadziły systemy Positive Train Control (PTC), których celem jest zapobieganie wypadkom i wykolejeniom poprzez automatyczną kontrolę prędkości i zachowania pociągów. Termin zakończenia projektów PTC początkowo wyznaczony był na na rok 2015. W związku z licznymi opóźnieniami, Kongres dwukrotnie opóźniał ostateczną datę, do końca 2018 i później 2020 roku6.
W raporcie z 2018 roku, Rządowe Biuro Audytu (Government Accountability Office – GAO) wspomniało o problemach z oprogramowaniem na projektach PTC, ale nie były one określane jako kluczowe. W tamtym czasie, większość projektów dopiero rozpoczynała fazę testowania, i problemy związane z softwarem dopiero zaczynały pojawiać się na powierzchni.
Rok później, nowy raport GAO7, już zdecydowanie podkreślał powagę kłopotów z oprogramowaniem: „31 na 37 spółek kolejowych wskazywało na poważny lub średni wpływ problemów z softwarem”. Z postępującą fazą testowania, coraz więcej projektów odkrywało, że oprogramowanie do PTC nie było gotowe do przeprowadzanie testów, a naprawianie błędów zajmowało dużo więcej czasu, niż wstępnie zakładano. Raport z 2019 stwierdza: „Problemy z softwarem są dużo bardziej uciążliwe teraz, gdy termin zakończenia prac w 2020 się zbliża, i pozostaje mniej czasu by zminimalizować opóźnienia spowodowane przez nie”.
Jak na Crossrailu, projekty PTC także ucierpiały przez familiarity bias, a brak efektywnego zarządzania procesem tworzenia oprogramowania spowodował opóźnienia. Zarówno na Crossrailu, jak i przy PTC, poważne problemy z softwarem zostały dostrzeżone na późnych etapach projektów, przy fazie testowania systemów i podsystemów (lub krótko przed). A na tak późnym stadium, drużyna projektowa ma ograniczone możliwości zminimalizowania opóźnień.
Budowa infrastruktury – myśl systemowo
Istnieją różne sposoby pozwalające na ograniczenia negatywnego wpływu problemów z softwarem na końcowy sukces projektu.
- Spójne, interdyscyplinarne planowanie i harmonogramowanie. Tworzenie oprogramowania musi być uwzględnione w ogólnym harmonogramie projektu. Harmonogram powinien również odzwierciedlać cykliczne, nieliniowe podejście do rozwoju oprogramowania, ze starannie zaplanowanym i uwzględniającym ryzyko czasem trwania zadań.
- Wczesne raportowanie i staranne archiwizowanie. W momencie integracji software’u z resztą infrastruktury, zazwyczaj jest zbyt późno, by mitygować opóźnienia. Dlatego dokładne raportowanie postępów w tworzeniu oprogramowania jest konieczne już na wczesnych etapach projektu. Dodatkowo, dokładna dokumentacja może mieć kluczowe znaczenia przy rozstrzyganiu potencjalnych roszczeń.
- Efektywne zarządzania ryzykiem. Na wczesnych etapach projektu, software często nie zajmuje wysokiego miejsca na liście zainteresowań osób odpowiedzialnych całościowo za sukces projektu. Niestety, gdy problemy z softwarem wypływają na powierzchnię, zazwyczaj jest już za późno na mitygowanie ryzyka. Dlatego, drużyny projektowe powinny poważnie brać pod uwagę ryzyko związane z tworzeniem i integracją oprogramowania już na wczesnych etapach projektu.
W dzisiejszych czasach cyfrowe, zintegrowane funkcjonalności często są dużo istotniejsze dla użytkowników infrastruktury, niż sam obiekt budowlany. Aby sprostać związanym z tym ryzykiem i wymaganiom, zarządzanie projektem budowlanym musi przekształcić się z tradycyjnych metod stosowanych budownictwie, na bardziej nowoczesne, wszechstronne metody skupione na dostarczaniu funkcjonujących systemów. Stal i beton już niekoniecznie są najważniejszym budulcem dobrze funkcjonującej infrastruktury. Przeciwnie, dzisiejsze infrastruktura zbudowana jest z wielu podsystemów, a software jest jednym z najistotniejszych z nich.
Niniejszy artykuł przedstawia wyłącznie poglądy, przemyślenia lub opinie autora, a nie jakiegokolwiek podmiotu HKA. W momencie publikacji dokładamy wszelkich starań, aby potwierdzić dokładność prezentowanych informacji, jednak treść nie ma na celu omówienia wszystkich aspektów omawianego tematu, nie powinna stanowić podstawy do podejmowania decyzji biznesowych i nie stanowi profesjonalnej porady jakiegokolwiek rodzaju. Niniejszy artykuł jest chroniony prawem autorskim © 2023 HKA Global, LLC.
1 https://www.designbuild-network.com/comment/tech-adoption-in-construction/
2 NAO 2014 – Crossrail – 24 stycznia 2014
3 NAO 2019 – Completing Crossrail – 3 maja 2019
4 Are rail projects a nightmare to deliver? Lessons for successful delivery – Video – 14 września 2021
5 The Rail Safety Improvement Act of 2008
6 GAO-19-135T – 3 października 2018
7 GAO-19-693T – 31 lipca 2019
Director HKA. Magister inżynier budownictwa, absolwent Politechniki Krakowskiej. Specjalista do spraw zarządzania ryzykiem oraz rozwiązywania roszczeń na projektach budowlanych na całym świecie. W swojej karierze zajmował się wieloma aspektami kontroli projektu, od statystycznego szacowania ryzyka związanego z budżetem i czasem projektu, do analizy opóźnień i wzrostu kosztów. Jego doświadczenie zawodowe obejmuje projekty w Polsce, Stanach Zjednoczonych, Wielkiej Brytanii, Kanadzie, Meksyku, i RPA. Jest posiadaczem certyfikatu PMP oraz PSP (Planning & Scheduling Professional).