Bariera językowa to oczywiście nie jedyne ryzyko w tym projekcie...

T.G.: Oczywiście, z perspektywy czasu i odniesionego sukcesu widzę, że kolejnym ryzykiem była skala przedsięwzięcia, która niesie dużo więcej problemów. Do tej pory zarządzałem dziesięcioosobowym zespołem, w tym projekcie było to już sto osób. A przecież 100 to jest 10 razy 10. Także 10 razy więcej poszczególnych problemów.

Jak ludzie reagowali na te piętrzące się zadaniado wykonania?

T.G.: Tempo pracy było naprawdę duże. Nie wszyscy dotrzymywali kroku. Ale bardzo miło, że w sytuacjach takich jak ta, gdy pewnego razu siedzieliśmy wieczorem, ciężko było już cokolwiek zrobić z jakimś problemem, atmosfera gęstniała z chwili na chwilę, jedna z osób powiedziała: "No tak, ale to trzeba zrobić. Albo jesteśmy zespołem, albo nie". Miło jest przewodzić zespołowi, ale jeszcze milej, gdy tego typu zdanie wychodzi od członka zespołu. To znaczy, że oni czują się razem. Od tej osoby usłyszałem też kiedyś bardzo wymagające zdanie: "Tomek, ale ty jesteś kierownikiem projektu, od ciebie oczekujemy, że ty teraz z tą sytuacją coś zrobisz". Dziś wszystko to się miło wspomina, ale ciężar szefa projektu był ogromny. Ta odpowiedzialność jest bardzo dużym obciążeniem pod względem emocjonalnym i bardzo wypala. Projekt uruchamialiśmy sekwencyjnie, rozkładając jego ciężar na 4 etapy. Każdy z nich bardzo przeżywałem.

Zobacz również:

• 9 cech wielkich liderów IT
• CIO "bumerangi": liderzy IT awansują, powracając
• 6 znaków ostrzegawczych, na które CIO powinni zwrócić uwagę w 2024 roku

A inne ryzyko?

T.G.: Największym ryzykiem zawsze jednak pozostanie człowiek. Startując z projektem Kaleidoscope, nie mieliśmy ludzi, o których moglibyśmy powiedzieć, że mają doświadczenie i pełne przygotowanie projektowe. Oni mieli potencjał, a potencjał jest trudno oszacować i łatwo się przy tym pomylić. Choć trzeba przyznać, że czasem byliśmy mile zaskoczeni, gdy okazywało się, że ludzie niejako wyrastali ponad szacunki, jakie im przypisywaliśmy. Jeszcze inne ryzyko to skala projektu. Byliśmy na granicy, za którą trzeba by już powiedzieć, że projekt jest zbyt duży. Cztery kraje, nowość systemu, interfejsy - to wszystko składało się na zwiększone ryzyko. Dziś, post factum, życzyłbym sobie jednej dodatkowej osoby - architekta projektu. Teraz dopiero widzę, że kimś innym jest kierownik budowy, a kimś innym ktoś, kto tę budowę projektuje. Przy projekcie o tej skali osoba architekta bardzo by się przydała. Skala projektu związana jest ściśle z czasem trwania przedsięwzięcia i ten czas był kolejnym ryzykiem. Projekt trwał 18 miesięcy, ludzie byli już zmęczeni i to powodowało kryzysy. Przeżyliśmy dwa takie trudne momenty: pierwszy, latem minionego roku, spowodował konieczność przebudowania harmonogramu, i drugi, pod koniec, gdy trzeba było wszystko podomykać. Tak długi czas trwania projektu trudno przetrwać, ta praca jest ciężka zarówno fizycznie, jak i psychicznie.

A Pani Prezes, ze swojego punktu widzenia, jakie wnioski po zakończonym projekcie chciałaby podkreślić?

J.S.: Bardzo mocno dotarło do mnie, że najbardziej niedoceniane w projektach jest zarządzanie zmianą. Zanim jeszcze nasz projekt się rozpoczął, wagę tej kwestii podkreślali ludzie z centrali, zachęcili nas do tego, by dobrze rozważyć związane z tym zagadnienia. Razem z Tomkiem pojechaliśmy w tej sprawie do Belgii, gdzie o tym rozmawialiśmy. To także dzięki świadomości wagi, jaką należy przywiązywać do zarządzania zmianą, wielu rodzajów ryzyka udało nam się uniknąć. W każdym kraju biorącym udział w projekcie były osoby dedykowane do zarządzania zmianą. Te osoby, jak wszystkie inne, były rozliczane z konkretnych rzeczy, dlatego dbały o skuteczność w swoim obszarze. Informowali pracowników o pojawiających się zmianach i nowych narzędziach, przygotowując wszystkich ludzi do pozytywnego przyjęcia. Jeśli z zapisu tej rozmowy ktoś ma naprawdę skorzystać, to podkreślę to bardzo wyraźnie: zadbajcie w swoich projektach o zarządzanie zmianą; co więcej, zadbajcie o to, zanim wasz projekt się rozpocznie. Na samym początku zapewne jeszcze nie do końca wiadomo, czego zmiany będą dotyczyły, ale i tak nie należy tego obszaru pozostawiać na później.

T.G.: Do pewnych rzeczy rzeczywiście dochodziliśmy etapami, trudno było wszystko przewidzieć od początku. W projekcie pomimo istniejącego harmonogramu trzeba przez cały czas trzymać rękę na pulsie. Jeden z menedżerów na Słowacji powiedział w pewnym momencie: "Robi się ciężko i chcę wiedzieć, co w tej chwili jest ważniejsze - biznes czy projekt". Odpowiedź, jaką usłyszał wtedy od swojego przełożonego, brzmiała: "Na tę chwilę - projekt". Nie da się wdrożyć systemu ERP, równocześnie nie godząc się z tym, że ludzie będą musieli poświęcić się mu bardziej niż bieżącym kwestiom biznesowym. Ta sytuacja pokazuje, że dla sukcesu projektu ustawienie priorytetów na daną chwilę jest kluczowe. Równie istotne jest podejmowanie zdecydowanych akcji korekcyjnych. Jeśli widać, że coś idzie nie tak - wtedy jest czas na zdecydowany ruch sterem. Trzeba się z tym pogodzić i wykonać zwrot, a nie tylko (patrząc z punktu widzenia żeglarza) lekko ustawić się z wiatrem. W pewnych wypadkach trzeba się podjąć nawet odmiany strategii wdrożenia projektu. Mieliśmy w tym projekcie momenty, w których to właśnie robiliśmy.

Które decyzje należały do najtrudniejszych?

T.G.: Na pewno te z kategorii "go/no go". W naszym projekcie były one, na szczęście, bardzo sformalizowane. W pewnym momencie trzeba podjąć tę decyzję, a ona wcale nie jest prosta, bo wcale wszystko nie jest przygotowane, a opóźnienie nie daje gwarancji, że będzie lepiej, bo zespół jest zmęczony. Decyzje te, podejmowane w czasie spotkań i telekonferencji, nie były pozbawione emocji. Były to gorąco dyskutowane kwestie, ale ostateczne postanowienia podejmowano bardzo profesjonalnie. Jeszcze raz podkreślę dużą pozytywną rolę sformalizowania procesów decyzyjnych.

Ostatnie słowo należy w tej rozmowie do szefa projektu.

T.G.: Mówi się, że dobry los nie jest sprzymierzeńcem bezczynnych. Myślę, że to prawda, dlatego zawsze starałem się odrabiać zadane lekcje. Ale jednocześnie wierzę, że także szczęście jest ważnym czynnikiem sukcesu - przecież ten element niejeden raz okazał się istotny w czasie tych 18 miesięcy. Dlatego powiedzenie - Bogu dzięki! - jest dzisiaj z mojej strony jak najbardziej na miejscu. Tak naprawdę ostatnim słowem powinno być słowo "ludzie". Każdy szef projektu wie, że w takim miejscu powinny paść konkretne imiona i nazwiska poszczególnych osób, które tworzyły zespół, oraz podziękowanie dla nich.

<hr />Team spirit

Maciej Mazuruk, dyrektor ds.konsultingu BCC,członek Komitetu Sterującego projektu Antalis.

W tego typu przedsięwzięciach normą jest występowanie trzech stron projektu: centrali firmy, jej oddziału (oddziałów) oraz firmy wdrożeniowej. W przypadku Antalisa było jeszcze więcej stron projektu, uwzględniając dostawców aplikacji innych niż SAP, a wchodzących w skład rozwiązania korporacyjnego Aries (systemy: magazynowy, transportowy, do raportowania, zewnętrzny CRM itp). Niełatwo było nad tym organizacyjnie zapanować. Z tego samego względu projekt generował dodatkowe wyzwania w obszarze integracji różnych systemów IT.

Kolejnym wyzwaniem była sama natura projektu - jego międzynarodowość. Sto dwadzieścia zaangażowanych w projekt osób pochodziło z różnych krajów, o różnej kulturze i organizacji pracy, a język projektowy - angielski - nie był ojczystym dla żadnego uczestnika. Wdrożenie było prowadzone w czterech krajach jednocześnie. Były momenty, że start produktywny w jednym kraju nakładał się z migracją danych i przygotowaniem do startu w innych - a więc krytyczne fazy projektu nachodziły na siebie. Sztuką była odpowiednia alokacja zasobów i koordynacja prac, w tym także konsultantów spoza Polski. Nie było to łatwe. Zdarzało się, że konsultanci pracowali w soboty, niedziele i święta (1 listopada) po kilkanaście godzin na dobę. Czasami trzeba było z dnia na dzień podjąć niełatwą decyzję - na przykład o wyjeździe kierownika projektu Andrzeja Jańczuka do Pragi na pełne dwa tygodnie. Nietypowym elementem w organizacji projektu były też częste (co 2 tygodnie) spotkania Komitetu Sterującego - zazwyczaj takie zebrania odbywają się tylko na koniec każdej fazy projektów SAP.

Elastyczność i zaangażowanie opłaciły się, a w trakcie prac przedstawiciele Antalisa i konsultanci BCC zbudowali wyjątkowy "team spirit". Efektem jest rozwiązanie, miejscami wykraczające poza standard systemu korporacyjnego - w odpowiedzi na wysokie wymagania, jakie stawiał Antalis w tym projekcie.

<hr />