zarządzanie projektami zarządzanie zmianą

Wyobraźmy sobie projekt informatyczny, który właśnie dobiegł końca. System działa, wszystkie zaplanowane funkcjonalności są na miejscu, wykonawca wywiązał się z umowy, dokumentacja jest podpisana. Być może udało się nawet zmieścić w budżecie i harmonogramie. Można ogłosić sukces.

Tylko czy organizacja rzeczywiście osiągnęła to, co zamierzała? Kilka miesięcy później może się okazać, że pracownicy nadal korzystają ze starych rozwiązań, wymyślają własne sposoby obchodzenia nowych procedur albo używają niewielkiej części możliwości systemu. Narzędzie działa, ale sposób pracy prawie się nie zmienił. Czy sukces projektu oznacza więc automatycznie sukces zmiany, którą miał przynieść?

Technologia to tylko część układanki

Ostatnio na kilku warsztatach z zarządzania projektami i zmianą wielokrotnie wracaliśmy do tego tematu. Uczestnicy podchodzili do niego bardzo różnie. Część doskonale wiedziała, że o powodzeniu projektu decyduje nie tylko technologia, harmonogram i budżet, ale też ludzie, którzy będą musieli pracować w nowych warunkach. Dla innych zaskoczeniem było to, jak wiele zależy od spraw, które często uchodzą za drugorzędne: komunikacji, zaangażowania pracowników, ich obaw i przyzwyczajeń oraz tego, jak menedżerowie przygotowują swoje zespoły.

Nie chodzi o brak kompetencji w zarządzaniu projektami. Po prostu łatwiej zarządzać tym, co da się zaplanować, zmierzyć i wpisać do harmonogramu, niż ludzkimi zachowaniami. Termin uruchomienia systemu, testy, szkolenia i odbiory zaplanujemy bez trudu. Dużo trudniej przewidzieć, kiedy ludzie zaczną korzystać z nowego rozwiązania tak, żeby przyniosło obiecane korzyści. A przecież po to zwykle realizujemy projekty.

Wdrożenie rozwiązania to nie wdrożenie zmiany

To rozróżnienie wydaje mi się szczególnie ważne. Wdrożenie systemu oznacza, że organizacja dostaje narzędzie. Wdrożenie zmiany oznacza, że ludzie zaczynają inaczej pracować, podejmować decyzje, współpracować i obsługiwać klientów. Pierwsze tworzy możliwości, drugie pozwala z nich skorzystać.

Weźmy firmę, która wprowadza nowy system do zarządzania dokumentami. Technicznie wszystko działa, a pracownicy dalej wysyłają pliki mailem, trzymają własne wersje dokumentów i uzgadniają decyzje po staremu. System jest wdrożony, ale zmiana sposobu pracy nie nastąpiła.

Nie zawsze wynika to z niechęci ludzi. Być może nie rozumieją, dlaczego stary sposób ma zniknąć. Być może nowe rozwiązanie nie odpowiada na ich rzeczywiste potrzeby. A może przełożeni nadal oczekują pracy według starych zasad, choć oficjalnie obowiązują nowe. Samo szkolenie z obsługi systemu też tego nie załatwi, bo umiejętność korzystania z narzędzia nie jest jeszcze gotowością do zmiany. Można wiedzieć, jak obsługiwać system, i nadal nie widzieć powodu, żeby to robić.

Zarządzanie zmianą nie może zaczynać się po projekcie

Częsty błąd polega na tym, że zarządzanie zmianą włączamy dopiero wtedy, gdy rozwiązanie jest gotowe. Najpierw projektujemy i wdrażamy system, a potem zastanawiamy się, jak przekonać ludzi, żeby z niego korzystali. Tymczasem powinno ono towarzyszyć projektowi dużo wcześniej. Już na etapie planowania warto wiedzieć, kogo zmiana dotknie, jak wpłynie na codzienną pracę zespołów, jakie kompetencje będą potrzebne i jakie przyzwyczajenia trzeba będzie zmienić.

Ogromne znaczenie mają też menedżerowie. To w dużej mierze od nich zależy, czy nowe rozwiązanie zostanie naprawdę wykorzystane. Jeśli po wdrożeniu sami działają po staremu, trudno oczekiwać czegoś innego od pracowników.

Nie każda zmiana spotka się z entuzjazmem i to normalne. Wątpliwości, pytania, a nawet opór są naturalnymi reakcjami. Ważne, czy organizacja potrafi je zrozumieć i sensownie na nie odpowiedzieć. Celem nie jest to, żeby wszyscy byli zadowoleni, tylko żeby stworzyć warunki, w których ludzie będą mogli skutecznie pracować w nowej rzeczywistości.

Kiedy naprawdę kończy się sukces projektu?

W tradycyjnym podejściu do projektów dużo uwagi poświęcamy zakresowi, terminom, budżetowi i jakości dostarczonego rozwiązania. To niezbędne, bez tego trudno mówić o skutecznym zarządzaniu. Ale spełnienie tych kryteriów nie gwarantuje jeszcze korzyści. Obok pytania „czy dostarczyliśmy to, co zaplanowaliśmy?“ powinno więc paść drugie: „czy dzięki temu organizacja naprawdę działa lepiej?“.

Czy ludzie korzystają z nowego rozwiązania? Czy zmieniły się procesy? Czy decyzje zapadają sprawniej, a klienci są lepiej obsługiwani? Czy osiągamy korzyści, dla których zaczęliśmy projekt? Odpowiedzi często pojawiają się dopiero po jakimś czasie od formalnego zakończenia.

Nie twierdzę, że projekt ma trwać w nieskończoność. Powinien mieć jasny początek i koniec. Ale odpowiedzialność za korzyści ze zmiany nie może znikać w chwili podpisania protokołu odbioru. Ktoś musi dalej obserwować, czy rozwiązanie przynosi efekty, wychwytywać trudności i korygować kurs. Zamknięcie projektu jest zdarzeniem formalnym, a utrwalanie zmiany to proces.

Dwa światy, które potrzebują siebie

Po tych warsztatach coraz mocniej wierzę, że zarządzania projektami i zarządzania zmianą nie powinno się traktować jak dwóch odrębnych światów, a tym bardziej jak konkurencji. Zarządzanie projektami pomaga zaplanować, zorganizować i dostarczyć rozwiązanie. Zarządzanie zmianą przygotowuje organizację i ludzi do tego, żeby to rozwiązanie zaczęło działać w codziennej praktyce. Jedno bez drugiego często nie wystarcza.

Dlatego przy kolejnym przedsięwzięciu, zwłaszcza związanym z cyfryzacją albo zmianą procesów, warto patrzeć nie tylko na to, co zamierzamy wdrożyć, ale też na to, co ma się dzięki temu zmienić. I może już na początku zadać sobie jedno pytanie: co ludzie będą robić inaczej, kiedy projekt się skończy?

Bo nie wdrażamy systemów po to, żeby mieć nowe systemy, tylko żeby coś w organizacji działało lepiej. A to nie dzieje się samo w dniu uruchomienia oprogramowania.