„Podział kompetencji był na tyle klarowny, że bardzo dobrze się uzupełnialiśmy, w ogóle nie wchodząc sobie w drogę. Reszta zespołu również nie miała wątpliwości, do kogo się zwracać z poszczególnymi problemami” – dodaje Tomasz Świderek. Istotne było zapewnienie projektowi wsparcia w takich dziedzinach, jak kontroling finansowy, zarządzanie dokumentacją, czy też wsparcia prawnego. Za podziałem obowiązków poszedł również podział uprawnień. Istotnym krokiem do sukcesu było skrócenie ścieżki decyzyjnej w organizacji umożliwiającej sprawne podejmowanie ważnych decyzji, na przykład dotyczących dokonywania wielomilionowych zakupów czy poniesienia nieprzewidzianych wydatków.

Akceptacja ryzyka

Plan projektu ARUZ to wynik pracy zespołowej. To suma doświadczeń kilkunastu osób spisana podczas licznych spotkań warsztatowych. Kluczowym czynnikiem wpływającym zarówno na harmonogram, jak i na ryzyko opóźnienia projektu były zakupy elementów elektronicznych do produkowanych układów. Ericpol potrzebował ich w liczbach często przekraczających istniejący zapas na rynku międzynarodowym i trzeba było uwzględnić oczekiwanie na wyprodukowanie elementów.

Podjęcie się realizacji projektu związane było z akceptacją dość wysokiego poziomu ryzyka. Jego głównym źródłem było zagrożenie, że urządzenie poprawnie zmontowane według projektu technicznego ostatecznie nie zadziała. Ponadto duże zapotrzebowanie na specjalistyczne elementy elektroniczne czy unikalna, skupiona w małym zespole wiedza potrzebna do zbudowania urządzenia były również charakterystycznymi dla tego projektu źródłami ryzyka. „W projekcie ARUZ ryzykiem zarządzamy na co dzień. Na każdym spotkaniu projektowym ten temat jest obecny. W przypadku zidentyfikowania istotnych zagrożeń lub szans są one dokumentowane w rejestrze ryzyk, a działania w związku z nimi planowane są uwzględniane w harmonogramie projektu i nadzorowane tak jak pozostałe zadania. Najważniejsze zagrożenia są raportowane i dyskutowane na forum Komitetu Sterującego” – mówi Tomasz Świderek.

Prototyp

W przypadku ARUZa, w którego skład wchodzą 3 tys. skomplikowanych układów elektronicznych, 100 km kabli, 1200 zasilaczy, a w razie awarii na dostawę niektórych potrzebnych elementów trzeba czekać 22 tygodnie, najmniejsza pomyłka mogła kosztować duże opóźnienie w projekcie. Aby zminimalizować to zagrożenie, Ericpol zbudował prototyp w małej skali – µARUZa. „Na budowę prototypu przeznaczyliśmy łącznie 5 miesięcy. Była to doskonała inwestycja” – ocenia Adam Włodarczyk. Choć składał się z zaledwie 2 paneli i 24 płyt, prototyp umożliwił weryfikację poprawności działania poszczególnych funkcjonalności, które docelowo ma posiadać ARUZ. Przygotowanie µARUZa pozwoliło również udoskonalić kilka zastosowanych rozwiązań oraz skontrolować jakość zamawianych elementów.

Zaangażowanie

W budowie analizatora uczestniczyło w sumie kilkanaście różnych zespołów pracujących w bardzo napiętym harmonogramie. W projekcie o charakterze badawczym naturalnym zjawiskiem było zderzanie się różnych wizji działania. Istotne więc było, aby to potencjalne źródło nieporozumień i sytuacji konfliktowych wykorzystać konstruktywnie do wypracowania najbardziej efektywnej formuły realizacji projektu. Udało się to dzięki licznym dyskusjom na organizowanych w projekcie warsztatach tematycznych. „Pomimo różnic zdań nas wszystkich łączyło jedno: nastawienie na współpracę i osiągnięcie sukcesu. Zespół był silnie zmotywowany i zaangażowany przez cały projekt. Dzięki tej wewnętrznej motywacji możliwy był dialog i szukanie kompromisów” – podkreśla Wojciech Dubiel, kierownik ds. działań operacyjnych w Ericpolu.

Bieg z przeszkodami

Jak zwykle przy realizacji przedsięwzięcia o dużej skali natrafialiśmy na różne problemy, które trzeba było rozwiązać. Do głównych z nich należał czas. 12 miesięcy na wykonanie projektu, zakup potrzebnych elementów, wykonanie podzespołów, montaż, oprogramowanie i uruchomienie urządzenia już na etapie decyzji o starcie w tym przedsięwzięciu to niewiele.

Mieliśmy dużo wątpliwości, czy jest to możliwe do wykonania. Kolejnym wyzwaniem był montaż urządzenia w miejscu, w którym w dalszym ciągu były prowadzone prace budowlane. Wszechobecny kurz, ekipy budowlane, pracujący ciężki sprzęt nie sprzyjały realizacji tak czułego urządzenia elektronicznego, jakim jest ARUZ. Konieczne okazało się zgranie obszaru zupełnie nam jako firmie informatycznej nieznanego, jakim jest plac budowy z dobrze nam znanym obszarem software’owym. Prozaiczne sprawy związane z transportem znacznych rozmiarów elementów konstrukcji nośnej, czy chociażby systemu podtrzymania zasilania (UPS) o wadze sumarycznej blisko 6 ton na poziomy II i III budynku musiały być z wyprzedzeniem skoordynowane z pracami budowalnymi. Wielkogabarytowe elementy musiały się znaleźć w miejscu docelowym kilka tygodni, a czasem miesięcy (!) wcześniej, zanim tak naprawdę były potrzebne. W tym przypadku przewidywanie i zgranie terminów było kluczowe. Do ciekawych wyzwań należało zapobieganie skutkom zdarzeń losowych, takich jak nagła przerwa w dostawie prądu spowodowana przerwaniem kabla zasilającego podczas prac budowlanych. Pamiętajmy, że w pełni uruchomione urządzenie może wymagać zasilania rzędu 0,5 MW. Dziś cieszymy się, że nastawienie na sukces zespołu, zmiany w sposobie zarządzania (w niektórych przypadkach wymagało to odejścia od sformalizowanych procedur opisanych w książkach) tego projektu oraz w ścieżkach decyzyjnych, elastyczność w podejściu do nieznanych nam obszarów przyczyniły się do sukcesu.