Jak efektywnie zrealizować projekt transformacji organizacji?

VWFS w Polsce stanowi część globalnego koncernu Volkswagena zajmującą się przede wszystkim zapewnieniem klientom usług finansowych związanych z samochodami (kredyt, leasing, ubezpieczenia), ale obejmuje również bank internetowy z ofertą depozytową. W 2016 roku, przed rozpoczęciem transformacji, VWFS w Polsce stanowiły cztery spółki: VW Bank Polska S.A., VW Leasing GmbH Sp. z o.o. oddział w Polsce, VW Serwis Ubezpieczeniowy oraz MAN Financial Services Sp. z o.o. Działalność całej grupy była mocno zintegrowana dla zapewnienia pełnej obsługi klienta i efektywności operacyjnej.

Oś wydarzeń

Na początku listopada 2016 roku centrala koncernu przedstawiła nową strategię, której elementem była decyzja o rozdzieleniu działalności bankowej i leasingowej. Program transformacji pod nazwą „Panda” był najważniejszym przedsięwzięciem w organizacji. Termin pierwszych, kluczowych zmian w Polsce wyznaczono na sierpień 2017 roku, czyli po niespełna 10 miesiącach. Dalsze prace były realizowane w drugiej fazie projektu – „Panda Day 2”.

Niespełna miesiąc po wdrożeniu tych zmian rozpoczęto prace nad drugim dużym projektem „Róża”, który polegał na połączeniu VW Bank Polska S.A. z VW Bank GmbH i przekształceniu w oddział w Polsce. Wniosek o połączeniu musiał być złożony do końca sierpnia 2018, a samo połączeniu musiało nastąpić najpóźniej miesiąc później. Czasu nie było więc wiele. Ze względu na liczne powiązania projekty „Panda Day 2” i „Róża” zostały w Polsce połączone.

Trudno wyobrazić sobie skalę takiego wyzwania, warto więc bliżej przyjrzeć się z czym się mierzyliśmy:

• Krótki czas na realizację obu etapów projektu i sztywny ostateczny termin
• Niesprecyzowany zakres zadań, połączony ze skomplikowanym procesem decyzyjnym i prawnym m.in. HQ, regulatorów, interpretacji podatkowych
• Ograniczona dostępność zespołu VWFS, który musiał realizować prace projektowe równolegle z bieżącą działalnością biznesową oraz innymi projektami, które zbiegły się w czasie m.in. wdrożenia IFRS9, RODO, split payments
• Zależność od decyzji regulatorów – zwłaszcza w przypadku „Róży” wymagane były zgody niemieckiego BaFin, polskiego KNF i Europejskiego Banku Centralnego

Szczegółowy opis wymogów regulacyjnych i specyfiki branżowej projektu mógłby być tematem odrębnego opracowania. W tym przypadku chcielibyśmy skupić się bardziej na uwarunkowaniach typowych dla projektów transformacyjnych, takich jak duża niepewność dotycząca wymagań i zakresu prac, istnienie wymogów regulacyjnych koniecznych do spełnienia oraz różnorodność zależności wewnętrznych i zewnętrznych.

Globalny zespół doradców

Zarządzanie całym międzynarodowym programem w centrali VWFS (HQ) powierzono Deloitte. Podobnie w poszczególnych krajach zaangażowano naszą firmę do zarządzania lokalnymi projektami „Panda”. Dużym ułatwieniem był fakt, że już wcześniej pracowaliśmy z VWFS. Dzięki temu było nam łatwiej szybko wejść do organizacji, którą znaliśmy. Stabilny zespół, wieloletnie relacje i zaufanie oparte na wcześniejszej współpracy były bardzo ważne dla efektywnej realizacji projektu.

Łącznie prace w projekcie wykonywało ok. 300 pracowników, zespół zarządzający projektem przekraczał 30 osób, a ponadto zaangażowani byli dostawcy IT, kancelarie prawne, agencja PR oraz inni doradcy. Całość była realizowana w bliskiej współpracy z HQ.

Metodyka zarządzania projektem

Ze względu na międzynarodowy charakter programu „Panda” metodyka zarządzania projektem została przygotowana centralnie i narzucona zespołom projektowym w poszczególnych krajach. Składała się z:

• kilkumiesięcznej fazy planowania,
• szczegółowego harmonogramu działań,
• rozbudowanych tabel opisujących nowy model operacyjny w podziale na elementarne procesy z opisem wymaganych zmian,
• rejestrów zagadnień i ryzyk
• oraz dwutygodniowego cyklu rozbudowanych raportów statusowych.

W sumie opracowano sporo dokumentacji. Z jednej strony wymóg HQ mobilizował do wykonania planowania, z drugiej wnioski z retrospektywy przeprowadzonej po zakończeniu pierwszej fazy projektu pokazywały, że nie jest to idealne podejście. W szczególności widać było, że zbyt dużo pracy wymagało opracowanie wszystkich dokumentów, faza planowania była długa, rozbudowany plan trudny do utrzymania, a wobec wielu niewiadomych, czy braku decyzji, wymagał dużo zmian.

Jednym elementem, w którym sprawdził się szczegółowy harmonogram, był plan przełączenia na Day 2 (tzw. cutover plan). Wdrożenie przekształcenia miało być zrealizowane w jeden weekend od godziny 20:00 w piątek do 8:00 rano w poniedziałek. W tym czasie mieliśmy:

• wgrać nowe wersje większości wykorzystywanych systemów,
• zamknąć księgi banku,
• wykonać złożone operacje związane ze zmianami standardów rachunkowości,
• przygotować raporty.

Cała procedura obejmowała ponad 200 zadań i została w całości trzykrotnie przećwiczona w trakcie testów z zespołem. Szacowaliśmy, że procedura potrwa nieco ponad 50 godzin, przy założeniu pracy w trybie całodobowym. To dawało niewielki margines na ewentualne opóźnienia. Proces został dokładnie opisany z przypisaniem zależności, odpowiedzialności, szczegółowymi komentarzami oraz punktami kontrolnymi. Zespół intensywnie pracował przez cały weekend, by go zrealizować. I tak się stało – wdrożenie przebiegło bez przeszkód i z sukcesem.

Innym, ważnym aspektem planowania, była koordynacja z pozostałymi projektami toczącymi się równolegle w VWFS. Była to nie tylko kwestia najefektywniejszego wykorzystania ograniczonego zespołu, środowisk testowych i innych zasobów, ale także planowanie wdrożeń zmian w systemach IT, gdzie jednocześnie wprowadzano powiązane zmiany w wielu systemach, przygotowane przez wiele projektów. Opóźnienie w którymś projekcie, który miałby być wdrażany w tej samej wersji mogło stanowić zagrożenie dla powodzenia całego przedsięwzięcia. Dlatego konieczne było monitorowanie postępów prac w całym portfelu projektów i podejmowanie trudnych decyzji, szczególnie tuż przed Day 2.

Zespół projektowy, czyli ludzie są najważniejszi

Gdyby wskazać jeden, najważniejszy czynnik sukcesu, to był nim zespół. Idealny, powinien być wewnętrznie zmotywowany i silne przekonany o celowości swojej pracy. Nie można go stworzyć z dnia na dzień na potrzeby projektu, takie zespoły kształtuje się przez lata wspólnej pracy. W VWFS trafiliśmy właśnie na taki zespół. Pracownicy, równolegle zajęci swoimi obowiązkami, odpowiedzialnie włączali się w zadania projektowe. To ich zaangażowanie, ciężka praca, zawodowe kompetencje oraz współpraca pozwoliły na zrealizowanie, w ograniczonym czasie, tak złożonej transformacji.

Wszystko co robimy wpływa na budowanie zespołu, jego rozwój, motywację i zaufanie. Wówczas, gdy staniemy przed dużymi wyzwaniami, możemy na niego liczyć.

Jasny komunikat od Zarządu i HQ o znaczeniu projektu pomagał ustalać priorytety. Jednak zdarzały się sytuacje, że w natłoku ważniejszych zadań prace projektowe schodziły na drugi plan i opóźniały się. By nie stracić tempa, trzeba było przypominać o zadaniach i terminach. Prostym narzędziem do tego było odliczanie – jeden slajd na spotkaniu statusowym pokazujący, ile dni minęło, a ile zostało, wraz z informacją o najważniejszych zbliżających się zadaniach.

W tak dużym projekcie, obejmującym wiele obszarów specjalistycznych, trzeba polegać na ludziach i ich wiedzy. Kierownik projektu nie ma szansy być ekspertem w każdej dziedzinie. Jednakże powinien starać się zrozumieć poszczególne zagadnienia. Poza merytoryką i terminami w harmonogramie – bardzo ważna jest też motywacja, emocje oraz wiara w sukces. Zarządzanie projektem, to nie tylko narzędzia i praktyki, ale przede wszystkim zarządzanie ludźmi i ich emocjami. Na co dzień pomaga pozytywna energia, życzliwość i uśmiech.

Ważne jest świętowanie sukcesów – nie tylko po zakończeniu projektu, ale także tzw. małych zwycięstw. Niekiedy trzeba zadbać, by projekt nie był tylko ciężką pracą, ale sprawiał też przyjemność. Na przykład – mieliśmy pluszową maskotkę projektu (oczywiście Pandę). Na jednym z warsztatów w trakcie przerwy układaliśmy puzzle (przerwa była za krótka, więc układankę pracownicy dokończyli w kuchni).

Projekt realizowany był w siedzibie VWFS w ramach tradycyjnej, funkcjonalnej struktury organizacyjnej, podzielonej na departamenty i działy, przy współpracy z HQ oraz pomocy kilkunastu dostawców. O ile silną stroną zespołu były kompetencje merytoryczne, o tyle doświadczenie w pracy projektowej i efektywnej współpracy pomiędzy działami było zróżnicowane.

Dlatego jednym z pierwszych wyzwań była nauka współpracy między poszczególnymi funkcjami. Pomogła w tym seria warsztatów. Kilkadziesiąt osób zgromadzonych w jednej dużej sali, pracujących razem, dyskutujących, co jest do zrobienia oraz kiedy to należy zrobić, jakie są ryzyka, zagadnienia, problemy, niewiadome, konieczne decyzje. To duże wyzwanie dla organizacji, by wyciągnąć tyle osób na cały dzień z bieżącej pracy, ale bez tego nie udałoby się stworzyć dobrych planów. Jednocześnie współpraca podczas warsztatów zacieśniła więzi między zespołami i wskazała im wspólny cel projektu.

W bieżącej pracy przy projekcie ustaliliśmy regularny cykl spotkań:

• co tydzień spotkanie statusowe całego zespołu zarządzającego,
• co tydzień (potem co dwa tygodnie) telekonferencje statusowe z zespołem zarządzającym projektem w HQ,
• w cyklu 1 lub 2 tygodniowym - telekonferencje z partnerami w HQ odpowiedzialnymi za poszczególne strumienie prac,
• oraz lokalne spotkania z poszczególnymi departamentami, by omówić stan realizacji prac, zagadnień i ryzyka.

Częstotliwość spotkań była uzależniona od krytyczności danego obszaru i intensywności toczących się prac. Była to także okazja do zgłaszania problemów i spraw adresowanych do innych departamentów. Zagadnienia rejestrowaliśmy w podsumowaniach statusów i przekazywaliśmy adresatom. Szybko okazało się, że kierownik projektu jako centralny punkt komunikacji jest mało efektywny, stopniowo więc coraz bardziej nawiązywała się bliższa, operacyjna współpraca pomiędzy departamentami, by na bieżąco rozwiązywać pojawiające się problemy.

Inne środki komunikacji wykorzystywane w projekcie obejmowały m.in.:

- Repozytorium dokumentacji projektowej w SharePoint – foldery sieciowe oraz komunikację wymagań, zmian i zgłoszeń błędów do dostawców IT przez Jira. Wszystkie rozwiązania zapewniały dostępność aktualnych wersji dokumentów i informacji dla uczestników projektu.

- Komunikację mailową, podstawowe narzędzie w bieżącej wymianie informacji oraz do podsumowania spotkań.

- Telefony – nieocenione w szybkiej komunikacji, (chociaż trzeba pamiętać o ich ograniczeniach, np. do omawiania złożonych zagadnień znacznie lepsze są spotkania).

- Video konferencje – przydatne w sytuacji, kiedy zespół znajduje się w różnych lokalizacjach.

- SMS-y – wykorzystywane przy komunikacji w trakcie samego wdrożenia.

- Skype – wykorzystywany do przesyłania wiadomości i telekonferencji, ale mógłby być używany w szerszym zakresie.

Przyglądając się efektywności komunikacji podczas projektu zauważyliśmy, że najskuteczniejsze są bezpośrednie spotkania, a komunikacja elektroniczna, chociaż w wielu sytuacjach pomocna, nie może ich zastąpić.

Praca w jednej lokalizacji zdecydowanie poprawiała komunikację – najlepszym przykładem są niezliczone sprawy załatwione w trakcie spotkań w kuchni, windzie lub na korytarzu, z osobami zbyt zajętymi, by znalazły w kalendarzu czas na spotkanie. Były to również okazje, by dowiedzieć się o sprawach w projekcie i jego otoczeniu, które być może nie pojawiłyby się na oficjalnych statusach.

Odrębnym zagadnieniem była współpraca z dostawcami IT. Na początku przeprowadziliśmy warsztaty, by zrozumieć wymagania i wypracować rozwiązania. W trakcie projektu organizowaliśmy też cotygodniowe spotkania i telekonferencje. W czasie testów i wdrożenia kluczowe okazało się wsparcie na miejscu w siedzibie VWFS. To umożliwiło diagnozę, rozwiazywanie problemów i poprawianie błędów od ręki.

Projekt dotyczył nie tylko zespołu projektowego, ale wpływał na wszystkich pracowników VWFS. Głęboka transformacja oznaczała zmianę struktur organizacyjnych, przeniesienie pracowników do innych spółek, zmianę przełożonych oraz zakresu obowiązków. Przez długi czas, gdy ten model był wypracowywany, pracownicy żyli w stanie dużej niepewności, co do swojej przyszłości w organizacji. By obniżyć poziom stresu i niepewności, równolegle z projektem prowadzona była wewnętrzna kampania informacyjna do wszystkich pracowników. Regularne spotkania komunikacyjne z całym zespołem, indywidualne spotkania z przełożonymi wspierane przez HR partnerów, komunikacja za pośrednictwem strony intranetowej z informacjami o projekcie i odpowiedziami na najczęściej pojawiąjące się pytania (FAQ). Dużym sukcesem projektu było to, że żaden pracownik nie odszedł z powodu wprowadzanych zmian.

Co przyczyniło się do sukcesu?

W trakcie realizacji projektu nieustannie doskonaliliśmy sposób realizacji prac i wykorzystywane szablony dokumentów. Po Day 1 zorganizowaliśmy też warsztat – retrospektywę, by zastanowić się wspólnie, co przyczyniło się do powodzenia projektu, a co utrudniało pracę, lub można zrobić lepiej w przyszłości.

W trakcie retrospektywy po Panda Day 1 zidentyfikowaliśmy kilka czynników sukcesu, m.in.:

• Jasne określenie priorytetu projektu („Do or Die”)
• Dobra, otwarta komunikacja, w tym wiele różnego typu spotkań
• Bezpośrednia, bieżąca współpraca pomiędzy pracownikami i departamentami
• Akceptacja częstych zmian
• Zaangażowanie liderów projektu i kierownictwa organizacji
• Akceptowanie „wystarczająco dobrych” rozwiązań, skupienie na tym co konieczne

Podobnie na powodzenie Panda Day 2 wpłynęły m.in.:

• Zaangażowanie całego zespołu, ciężka praca i determinacja by zrealizować projekt pomimo napotykanych wyzwań
• Wczesne definiowanie wymagań i wypracowanie rozwiązań z dostawcami, bliska współpraca i wsparcie dostawców na miejscu
• Codzienne spotkania („stand-up”)
• Intensywne testy, w tym procedury przełączenia
• Szczegółowa i przetestowana procedura przełączenia („cutover plan”)

Z drugiej strony dostrzeżono obszary możliwej poprawy:

• Zbyt wiele zmian koncepcji i decyzji
• Późno podejmowane kluczowe decyzje
• Dużo dokumentacji oraz raportów
• Długoterminowe, szczegółowe planowanie

Ewolucja roli kierownika projektu

Tradycyjnie można myśleć o roli kierownika projektu, jako odpowiedzialnego za zaplanowanie, zakomunikowanie zadań do wykonania, monitorowanie pracy i rozwiązywanie problemów. Jednak ograniczenie się jedynie do takiego podejścia, nie mogło zadziałać w tak złożonym projekcie.

Po pierwsze wiedzę o tym, co należy zrobić, posiadał zespół – każdy w swoim obszarze funkcjonalnym – a reszta była wypracowywana w trakcie projektu. Zadaniem kierownika projektu było efektywne pozyskanie tej wiedzy w trakcie spotkań i warsztatów, oraz pomoc w przekształceniu jej w plan działań. Musiał też wychwycić zależności i zapewnić spójność planów pomiędzy departamentami. To, co dodatkowo wniósł do projektu, to wiedza i doświadczenie w zakresie typowej pracy projektowej.

Po drugie, jako osoba z zewnątrz, musiał wypracować swoją pozycję w zespole. W zhierarchizowanej organizacji to trudne zadanie, dlatego najskuteczniejszymi metodami zarządzania okazało się przypominanie o celu, zadaniach i terminach, motywowanie, proszenie, docenianie i komunikowanie dotychczasowych osiągnięć, dawanie przykładu własnym zaangażowaniem, energią, wiarą w cel przedsięwzięcia i sukces, a tylko w wyjątkowych przypadkach eskalacja.

Po trzecie monitorowanie postępów – chociaż istotne było sprawdzanie statusu realizacji prac i raportowanie, to dla powodzenia projektu ważniejsze okazało się identyfikowanie problemów i pomoc w ich rozwiązaniu. Bardzo ważna była też komunikacja oraz organizacja i prowadzenie spotkań. Największą trudność stanowiło oparcie się pokusie kontrolowania przepływu informacji i zachęcanie do bezpośredniej komunikacji.

Podsumowując, rola efektywnego kierownika projektu w takim przedsięwzięciu, to nie tyle klasyczne zarządzanie, co służba na rzecz zespołu projektowego. Umożliwianie realizacji zadań, pomoc w rozwiązywaniu problemów, wsparcie wiedzą oraz coaching wspomagający rozwój kompetencji w zespole.

Podsumowanie - wspólnie odkrywamy zasady Agile

Każdy z etapów transformacji stanowił projekt o klasycznej strukturze – z fazą planowania, szczegółowym planem i obszerną dokumentacją oraz jednym dużym wdrożeniem na koniec.

Patrząc na to, co najlepiej zadziałało i jakie wyciągaliśmy wnioski po każdej fazie, można zauważyć, że wykorzystywaliśmy pewne praktyki Agile (np. timebox’y – zwłaszcza w spotkaniach, regularny dwutygodniowy cykl spotkań, planowania i realizacji prac, dużo bliskiej współpracy i warsztatów, retrospektywa), a co więcej, odkrywaliśmy wspólnie, że zasady Agile sprawdzają się w praktyce:

• Bliska współpraca i bezpośrednia komunikacja pomiędzy departamentami i zaangażowanie ludzi bezpośrednio odpowiedzialnych za realizację zadań
• Ograniczenie nadmiernej dokumentacji i szczegółowych, długoterminowych planów
• Praca w jednej lokalizacji, wsparcie dostawców na miejscu, wiele spotkań
• Akceptacja, że zawsze będą zmiany w projekcie
• Rozwiązywanie problemów ad-hoc i szybkie podejmowanie decyzji
• Skupienie na tym co najważniejsze, konieczne („Good enough”, zasada Pareto, priorytety zadań – MoSCoW)

Co więcej, dzięki temu, że zespół projektowy odkrywał to sam i doświadczał w trakcie pracy, mógł z większym przekonaniem przyjmować nowe podejście.

Sukces projektu to nie tylko udane wdrożenia i terminowe wprowadzenie transformacji, bez zakłócenia bieżącej działalności biznesowej. To także rozwój nowych kompetencji, silna wiara w możliwość wspólnego realizowania trudnych projektów, lepsza komunikacja i współpraca pomiędzy departamentami.

Dziękujemy całemu zespołowi VWFS za wspólną pracę i naukę. Nie sposób wymienić wszystkich, którzy przyczynili się do tego sukcesu. Poza pracownikami VWFS w Polsce, byli to również pracownicy dostawców oraz zespół w HQ, zwłaszcza liderzy projektów „Panda” i „Róża’, którzy zapewniali wsparcie w rozwiązywaniu problemów, uzyskiwaniu decyzji i realizacji zadań po stronie HQ. A także nasze koleżanki z Deloitte – Marta Komosa i Ania Matusik-Matys, które w różnych okresach zarządzały projektem w obszarze IT oraz koordynowały go z innymi projektami.