... od dwunastu lat związany z sektorem bankowym: jako dostawca rozwiązań, konsultant i pracownik banku. Kierownik projektów, przez wiele lat wiceprezes warszawskiego oddziału Project Management Institute, obecnie członek zarządu banku DnB NORD Polska.

O połączeniach banków

Lista błędów, jakie popełniane są podczas procesów łączenia banków, ich struktur organizacyjnych i technologii, jest stała. Można ją spisać, a i tak zawsze popełniane są po raz kolejny. Przewaga jednego projektu połączenia nad innym polega wyłącznie na tym, na ile osoby zarządzające projektem potrafiły - już po fakcie - zminimalizować czy zniwelować skutki tych zdarzeń. Źródłem problemów są najczęściej niedocenianie osiągnięć drugiej strony i przecenianie własnych, brak szybkich decyzji i ograniczenie technologiczne.

To truizm, ale najważniejszym zasobem, który organizacja posiada, są ludzie. Połączenie powinno więc zmierzać do optymalnego wykorzystania dwóch zespołów ludzi. Na co dzień sprawa jest prosta, ludzie nowo zatrudnieni uczą się od tych, którzy pracują w firmie od lat. Uczą się nie tylko potrzebnych umiejętności, ale też kultury organizacyjnej. Jeśli zatrudniamy nie pojedynczego człowieka, lecz cały zespół, to musimy liczyć się z tym, że ów zespół przyniesie ze sobą własną kulturę. Czasem potrzeba lat, aby powstała nowa, spójna kultura. Jeśli nie mamy do czynienia z wyraźnym wchłonięciem jednej organizacji przez drugą, połączonym z redukcjami na wielką skalę - co tak naprawdę podważa sens połączenia - to nowa kultura musi zostać po prostu wypracowana i nie da się tego natychmiast osiągnąć.

O wieloletnich projektach

Dziś strategia IT banku jest pochodną strategii biznesowej. W praktyce mamy więc wyraźny plan projektów na kolejny rok i nieco bardziej ogólny na dwa kolejne lata. To nie oznacza końca dużych projektów, ale w przypadku planowania długoterminowego trzeba zachować ostrożność, bo istnieje spore ryzyko, że przy fazach projektu trwających dłużej niż rok efekt końcowy będzie rozbieżny z celami firmy. Ma to odbicie w projektach typu Greenfield, "budowanie banku w banku", a więc wdrożeniach systemów IT, które nie mają przejmować w pewnym momencie wszystkich obowiązków poprzednio stosowanych systemów, lecz płynnie włączyć się w działalność banku, pokrywając pewne spektrum nowych zazwyczaj produktów. Nie zakłada się, że w ramach jednorazowej konwersji wszyscy klienci i wszystkie dane muszą zostać przeniesione. Po prostu oba systemy będą działać równolegle, może wiele lat. Nie jest to bardziej kosztowne, bo prowadzi do znacznego skrócenia czasu trwania projektu.

O złej sławie sztywnych metodologii zarządzania projektami

Metodologia nie powinna wstrzymywać ludzi od myślenia, a czasem mam wrażenie, że tak właśnie się dzieje. Metodologia to tylko punkt odniesienia, który przydaje się, gdy doświadczenie nie podpowiada, jak postąpić. Trzeba też pamiętać, że różne organizacje na różnym etapie rozwoju wymagają różnych poziomów formalizacji. Inaczej uzyskujemy maksymalnie zbiurokratyzowany proces w organizacji, która z uporządkowanym podejściem spotyka się tak naprawdę pierwszy raz. Na początek do zarządzania portfelem projektów zupełnie wystarczy raport statusowy raz na miesiąc, którego wypełnienie zajmuje kierownikowi projektu pół godziny. I może jeszcze jedno krótkie spotkanie weryfikujące, raz w miesiącu. A potem, jak już mamy setki projektów - niewiele więcej.