Jak dowieźć sukces do mety?

Materiał promocyjny Garść dobrych praktyk w zakresie prowadzenia skomplikowanego projektu w obszarze badawczo-rozwojowym zdobytych podczas budowy Analizatora Rzeczywistych Układów Złożonych (ARUZ).

Ma zrewolucjonizować badania chemiczne, umożliwiając poznanie natury zjawisk złożonych i skracając czas oczekiwania na wyniki. ARUZ to największy na świecie symulator przebiegu reakcji chemicznych, który wchodzi w skład Laboratorium Symulacji Molekularnych w Łódzkim Technoparku. Urządzenie zaprojektowane przez naukowców z Politechniki Łódzkiej na zlecenie Technoparku Łódź zbudował Ericpol, polska firma inżynierska o dużym, międzynarodowym doświadczeniu w realizacji projektów. Ericpol odpowiedzialny był za zaprojektowanie urządzenia we wszystkich obszarach, zaczynając od konstrukcji mechanicznej, układów chłodzenia oraz instalacji elektrycznej i zasilającej, poprzez układy elektroniczne odpowiedzialne za jego moc obliczeniową, kończąc na oprogramowaniu, dzięki któremu urządzenie może wykonywać postawione mu zadania. Kolejnymi etapami były: wykonanie poszczególnych elementów, ich montaż w specjalnie do tego celu wybudowanym przez Technopark budynku, uruchomienie urządzenia, wykonanie testów oraz przygotowanie go do pracy.

Testowany obecnie ARUZ dzięki swojej mocy obliczeniowej będzie w stanie zanalizować zjawiska zachodzące z jednoczesnym udziałem ponad miliona molekuł, a wynik przedstawić w ciągu kilku dni. Umożliwi to 27 tys. równolegle pracujących układów FPGA (Field Programmable Gate Array), rozmieszczonych na 20 panelach symulatora. To pierwsze wykorzystanie technologii FPGA na tak dużą skalę. Budynek, w którym mieści się maszyna, wyposażony jest w tzw. klatkę Faradaya o średnicy 16 m oraz 5,5 m wysokości. Jest to jedna z największych kabin ekranujących na świecie, której zadaniem jest tłumienie zakłóceń elektromagnetycznych.

Budowa pierwszego na świecie symulatora reakcji chemicznych o takiej skali była ogromnym przedsięwzięciem zarówno pod względem technicznym, jak i projektowym. Wymagała bowiem prowadzenia projektu w obszarze bardzo złożonej integracji naukowo-technicznej. Głównym wyzwaniem było zarządzanie pracą kilkunastu zespołów, m.in. naukowców, informatyków, mechaników, elektryków, hydraulików i elektroników, oraz skoordynowanie ich działań z projektem budowlanym. Czas również odgrywał w projekcie istotną rolę. Ericpol miał zbudować symulator w 12 miesięcy. Fakt, że na świecie jeszcze nikt nie zbudował niczego podobnego, również nie ułatwiał zadania. Jak zatem skutecznie zarządzać skomplikowanym projektem w warunkach niepewności?

Zespół projektowy

W projekcie budowy ARUZa brało udział ok. 70 osób o różnorodnych kompetencjach. „Mieliśmy wielką przyjemność pracować z prawdziwymi fachowcami, którzy na każdym etapie służyli pomocą w realizacji tego niecodziennego przedsięwzięcia” – podkreśla Tomasz Świderek, koordynator projektu. Projekt wymagał integracji wielu różnych dyscyplin związanych zarówno z produkcją specjalistycznego oprogramowania, jak i zaprojektowaniem i budową przeznaczonych do tego celu urządzeń elektronicznych oraz infrastruktury. „W realizacji pomogło nam doświadczenie z wcześniejszych dużych projektów, które prowadziliśmy w roli integratora i wykonawcy. Szczególnym wyzwaniem była skala projektu, jak również jego unikalny charakter” – tłumaczy Tomasz Świderek.

Decyzyjność

Zarządzanie przedsięwzięciem o takim stopniu skomplikowania wymagało współpracy dwóch kierowników projektu. Jeden odpowiadał całościowo za wynik, kontakt z klientem oraz koordynację ogółu prac i część zespołów podwykonawców, a drugi za monitoring części konsultantów i ich zespołu, zarządzanie ryzykiem, a także raportowanie statusu projektu. Jedyna możliwość, która dawała szansę do prowadzenia projektu do pomyślnego finału, to podział obowiązków i idący za tym podział odpowiedzialności związanej z poszczególnymi zakresami. Równocześnie odpowiedzialność za powodzenie całego projektu została w rękach jednej osoby. „Podzielenie się obowiązkami było bardzo dobrym posunięciem, ponieważ koordynacja wszystkich wątków (tworzenie oprogramowania, budowa konstrukcji mechanicznej, zakupy podzespołów, montaż urządzenia, testowanie itd.) i ich synchronizacja z równolegle toczącym się projektem budowlanym przez jedną osobę mogłyby być zbyt ryzykowne” – przyznaje Adam Włodarczyk, odpowiadający całościowo za projekt.

„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.

Podzielenie się obowiązkami było bardzo dobrym posunięciem, ponieważ koordynacja wszystkich wątków (tworzenie oprogramowania, budowa konstrukcji mechanicznej, zakupy podzespołów, montaż urządzenia, testowanie itd.) i ich synchronizacja z równolegle toczącym się projektem budowlanym przez jedną osobę mogłyby być zbyt ryzykowne.

Adam Włodarczyk

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.

Tomasz Świderek

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.

Wojciech Dubiel

Materiał powstał przy współpracy z firmą Ericpol.