Słuchałem niedawno najnowszego nagrania Rafała Zaorskiego na Kanale Zero (dość znany inwestor giełdowy, ostatnio zasłynął planami wykonania „epickiego flipa” w swoim apartamencie na Złotej 44 w Warszawie). Mówiąc o inwestycjach na rynku kapitałowym stwierdził, że „historia może się nie powtarza, ale się rymuje”. Bardzo mi to zdanie zapadło w pamięć – całkiem eleganckie i pobudzające wyobraźnię. Niestety w dziedzinie, z którą zawodowo mam najwięcej do czynienia, czyli wdrażaniu zmian w organizacji, wciąż sprawdza się wersja podstawowa tego powiedzenia: historia lubi się powtarzać i powtarza się dość często. Jest to historia zmian udanych częściowo albo po prostu nieudanych. A ponieważ głównym zadaniem Project Managera jest budowanie historii sukcesów projektowych, warto się zastanowić, jakie lekcje i z jakich doświadczeń możemy w tym zakresie czerpać. Z tego artykułu dowiesz się, jak Project Manager może taką pozytywną historię budować.


30 lat temu Jeffrey Hiatt, amerykański inżynier oprogramowania z Dell Laboratories zaczął bliżej interesować się tym, na ile użytkownicy oprogramowania, które tworzył faktycznie z niego korzystają. Doszedł do wniosku, że nie decyduje o tym jedynie jakość software’u i to, czy odpowiada on na potrzeby biznesowe. Równie ważne – a czasami nawet ważniejsze – okazało się to, czy użytkownicy chcą i (lub) potrafią z tego oprogramowania korzystać. Okazało się, że nie wystarczy stworzyć dobre rozwiązanie i dostarczyć je w budżecie oraz na czas – trzeba jeszcze zadbać o tzw. czynnik ludzki: o tych, których zmiana dotyka (wszyscy, którzy na skutek jej wdrożenia muszą zmienić swój sposób pracy), a nie tylko o tych, którzy pracują nad nowymi rozwiązaniami (zespół projektowy). Dzisiaj już nas to szczególnie nie dziwi, ale ciągle wiele projektów cierpi na tym, że na skutek niższego poziomu przyswojenia i stosowania wdrażanych rozwiązań przez ich użytkowników projekty te nie osiągają zakładanych rezultatów biznesowych. Jest to spory ból głowy dla kierowników projektów, którzy są z tych rezultatów rozliczani.

Boleśnie przekonał się o tym jeden z moich znajomych, który prowadzi kancelarię prawną, zatrudniającą około 20 osób, w tym 10 samodzielnych prawników, aktywnie pracujących z klientami kancelarii. Zainwestował on całkiem spore środki, jak na skalę swojej działalności, we wdrożenie systemu CRM. Z założenia system miał sprawić, że cała wiedza o klientach, która dotychczas była „w głowach” prawników będzie zgromadzona w firmie i będzie dostępna w jednym miejscu. Dzięki temu można byłoby lepiej tych klientów obsługiwać – czasem kilku jego ekspertów pracowało dla tego samego klienta nad różnymi sprawami nie wiedząc o tym nawzajem i nie koordynując wystarczająco swoich działań. Poza tym dzięki zgromadzeniu w jednym miejscu informacji o wszystkim, co kancelaria robiła dla danego klienta można było oferować tym klientom dodatkowe usługi i szybko zwiększać przychody bez istotnych dodatkowych nakładów na marketing i sprzedaż. Kolega wziął na siebie koordynację wdrożenia (nota bene będąc jednocześnie Sponsorem tej zmiany, jako właściciel kancelarii). Z „jakichś” powodów jednak zakupiony software nie był zbyt intensywnie wykorzystywany przez prawników, którzy mieli być jego głównymi użytkownikami. I to pomimo solidnych szkoleń na temat działania narzędzia, które wszyscy przeszli. Ponad rok po wdrożeniu CRM był wykorzystywany incydentalnie i – jak to powiedział mój kolega – jego wdrożenia mogłoby właściwie nie być. Te „jakieś” powody związane były z niechęcią do stosowania CRM wśród jego kluczowych użytkowników i z niewystarczająco skutecznym radzeniem sobie z tym oporem. Z punktu widzenia podejścia do zarządzania projektem nie można było tutaj nic zarzucić. Poprawnie wybrany i wdrożony CRM nie przyniósł korzyści z powodu „czynnika ludzkiego”.

To był przykład z małej kancelarii – ale w większych organizacjach także pojawiają się podobne wyzwania i ryzyka „ludzkie” mocno rzutują na biznesowe rezultaty projektów. Jakiś czas temu pracując z kadrą kierowniczą dużej polskiej firmy analizowaliśmy sukcesy i „sukcesy porażkopodobne” wśród największych projektów wdrażanych na przestrzeni ponad 10 lat. Znalazło się oczywiście wiele wdrożeń zakończonych sukcesem – bo firma zacna i w tym czasie przeżywała okres szybkiego rozwoju. Ale także po tej mniej chwalebnej stronie uzbierało się kilkanaście projektów: związanych z wejściem na nowe rynki, wdrażaniem nowych produktów, optymalizacją procesów, reorganizacją, digitalizacją (w tym wdrożenie ERP). Niektóre z nich miały dla firmy znaczenie strategiczne, więc nie można było przejść nad nimi do porządku dziennego. Przyglądając się losom tych projektów można było je podzielić na następujące kategorie:

  • te, które „utknęły” i zostały porzucone, nie przynosząc żadnej wartości dla biznesu – o których wszyscy starali się zapomnieć,
  • projekty porzucone, ale takie, na których organizacja czegoś się nauczyła,
  • projekty, które przyniosły biznesowe korzyści, ale znacząco mniejsze od zakładanych,
  • projekty, które ostatecznie przyniosły korzyści, ale wiązało się to albo ze znaczącym przekroczeniem budżetu, albo czasu; w przypadku jednego z największych analizowanych projektów został on ukończony po ponad 5 latach, zamiast w ciągu roku, przy czym analiza post-projektowa pokazała, że ten rok był całkiem realistyczny przy innym podejściu do wdrożenia,
  • projekty, które zakończyły się sukcesem, ale ich rezultaty okazały się nietrwałe – czyli jakiś czas po wdrożeniu pracownicy powrócili do poprzednich sposobów pracy, pomimo że w okresie go-live i chwilę po nim większość z nich pracowała zgodnie z nowymi wymaganiami.

Z perspektywy prywatnego właściciela takie projekty były całkiem kosztownymi zabawkami. Czasem oznaczały inwestycje, które nie przyniosły zwrotu lub przynosiły, ale niższy od zakładanego. Dodatkowe negatywne skutki takich projektów to przeciążenie bezproduktywną pracą członków zespołów projektowych, zazwyczaj najlepszych pracowników – gdy nikt z nich raczej nie cierpiał na nadmiar wolego czasu. Powodowały one również poważne zaburzenia dla realizacji Business as Usual, gdyż zazwyczaj miały wpływ na dużą część załogi, a niekiedy wręcz na całą organizację. Potęgowały także zjawisko przeciążenia zmianami, które obecnie obserwowane jest w ponad 70% organizacji badanych przez Prosci, a także tych, z którymi mam okazję pracować na co dzień. Ta „saturacja” – bo tak się często ten efekt nazywa – nie tylko obniża morale i zaangażowanie pracowników. Przede wszystkim zmniejsza również produktywność w realizacji codziennych zadań i negatywnie wpływa na tempo oraz na stopień przyswojenia zmian. W czasach, gdy szybkość reakcji na zmiany w otoczeniu wprost przekłada się na pozycję konkurencyjną firmy, nie można takich negatywnych zjawisk pominąć.

Wśród przyczyn takiego obrotu spraw pojawiły się – można by powiedzieć – same „klasyki”, w tym:

  • nieskuteczne działanie Sponsora i koalicji Sponsorów w obszarze zarządzania „ludzką” stroną zmiany,
  • niewystarczająca zgodność wśród decydentów co do celów projektu lub sposobów wdrażania zmian,
  • opór pracowników,
  • niewystarczające zaangażowanie i przygotowanie kadry kierowniczej niższych szczebli, także opór w tej grupie,
  • nieskuteczna komunikacja z pracownikami i menedżerami, których zmiany dotyczyły,
  • skupienie gros uwagi na stronie merytorycznej (technicznej) projektu, pominięcie ryzyk „ludzkich”,
  • sprowadzanie zarządzania zmianą do szkoleń, technicznego wsparcia użytkowników i komunikacji – najczęściej jednostronnej, dotyczącej meritum projektów, a nie tego, co interesowało użytkowników,
  • brak pomiaru postępów zmiany na równi z monitorowaniem postępów projektu w czasie, monitorowaniem realizacji budżetu i analizą biznesowych wskaźników sukcesu,
  • brak zasobów na zarządzanie zmianą,
  • niewystarczające działania w zakresie utrzymania rezultatów zmian w dłuższym okresie.

Podkreślę raz jeszcze, że firma naprawdę zacna, działająca poza Polską na kilku dużych rynkach zagranicznych, zatrudniająca kilka tysięcy pracowników. Z doskonałą kadrą, dobrymi produktami, ugruntowaną pozycją na rynku i solidnymi wynikami finansowymi. Stosująca nowoczesne metody i narzędzia do zarządzania procesami i projektami. Wdrażająca od jakiegoś czasu zarządzanie zmianą. A jednak nawet w takiej firmie zdarzają się ewidentne „błędy w sztuce” – osoby, z którymi miałem okazję analizować te projekty zgodnie twierdziły, że prawie wszystkich problemów, związanych z „ludzką” stroną zmiany można było uniknąć (swoją drogą aż strach pomyśleć, co może się dziać w organizacjach mniej „zacnych”…). Nie wymagało to wielkich nakładów finansowych i czasowych. Wymagało natomiast robienia właściwych rzeczy, przez właściwych interesariuszy tych projektów, w odpowiednim momencie cyklu życia każdego z tych projektów. Kto mógł do tego doprowadzić, zaplanować odpowiednie działania, podnieść alert, gdy zmiana nie szła zgodnie z oczekiwaniami?

W idealnym świecie powinien być to kierownik projektu. Albo osoba odpowiedzialna za wdrożenie lub za „temat”, jeśli wdrożenie nie jest realizowane w trybie sformalizowanego projektu.

Fot. thinglass – stock.adobe.com

Co więc może zrobić Project Manager, aby nie powtarzać historii nieudanych zmian i skutecznie zarządzić „ludzką” stroną swojego projektu? Aby mieć tę kompetencję nie tylko z nazwy i nie tylko w certyfikacji – dla przypomnienia: zarówno PMI, jak i IPMA uwzględniają zarządzanie zmianą w swoich wymaganiach metodycznych i kompetencyjnych. Aby wreszcie zapewnić, że każdy projekt, który zależy od przyswojenia i stosowania nowych rozwiązań przez ludzi będzie odpowiednio zaopiekowany w zakresie „ludzkich” ryzyk.

Poniżej pięć obszarów, które zależą głównie od PM-a – pochodzą one zarówno z badań dobrych praktyk biznesowych w zakresie zarządzania zmianą, badań naukowych, jak i z moich doświadczeń zawodowych.

1. Zacznij od początku: czy i ile zarządzania zmianą potrzebujesz

Ostatnio na warsztacie dla Sponsorów zmiany usłyszałem pytanie: po czym poznać, że w moim projekcie potrzebuję zarządzania zmianą? Skąd mam się o tym dowiedzieć? Idealnie byłoby, gdyby odpowiedzi na te pytania dostarczył Project Manager. W jednej ze znanych mi firm Zarząd ustalił, że każdy projekt powyżej określonych parametrów budżetu i zakresu musi mieć analizę pod kątem potrzeb zarządzania zmianą przed decyzją go-no go. Nie zawsze trzeba być aż tak restrykcyjnym (chociaż akurat ta firma dobrze na tym wychodzi), ale przynajmniej warto na wstępie, oprócz ryzyk biznesowych przeanalizować ryzyka ludzkie i odpowiedzieć sobie na pytania takie, jak:

  • Jakie korzyści projekt ma przynieść organizacji i jaki ma w związku z tym zakres – bo od tego zależy skala zmian, które projekt niesie dla organizacji i pracowników.
  • Kogo zmiana dotyczy i w jakim stopniu.
  • Na ile użytkownicy zmiany są do niej gotowi, skąd może pochodzić opór i jak nim zarządzić.
  • Jaki jest poziom ryzyk ludzkich, związanych z projektem.
  • Jaki jest poziom gotowości organizacyjnej do wdrożenia i przyswojenia zmiany.
  • Kto powinien pełnić kluczowe role w zmianie.
  • Jakie zasoby są potrzebne, aby skutecznie zarządzić określoną skalą i kompleksowością zmiany, w szczególności czy potrzebna jest osoba w roli Change Managera, czy PM może się tym zająć sam.
  • Jakie podejście przyjąć do zarządzania tymi ryzykami w określonych uwarunkowaniach projektu i organizacji.

Istnieją ustrukturyzowane metody i narzędzia, które pomogą na te pytania odpowiedzieć w sposób uporządkowany, w miarę kompletny i dość szybki. Z moich własnych doświadczeń wynika, że czasami znalezienie takich odpowiedzi zajmuje kilka godzin, a czasami kilka dni roboczych – zależnie od projektu i od tego, ile mamy czasu i zasobów na takie analizy. Nawet samo uświadomienie sobie, że tych odpowiedzi nie mamy jest pomocne – świadoma niekompetencja to i tak jest krok do przodu. Gdyby PM zastanawiał się, kto mu te analizy wykona, to pierwszym odruchem powinno jednak być skorzystanie z maksymy Adama Słodowego. Czyli „zrób to sam” lub „J.D.I.”, jak mówi się w niektórych organizacjach. Nie raz słyszałem: nie mam na to czasu, nie wiem, jak to zrobić, za wcześnie na zarządzanie zmianą – i tak jeszcze nie wiadomo, co się zmieni. Dokładnie te zdania przychodzą mi na myśl za każdym razem, gdy w projektach „porażkopodobnych” analizuję „co poszło nie tak”. Tak więc nie powtarzaj historii nieudanych zmian – „J.D.I.”

2. Jeśli potrzebujesz zarządzania zmianą, to zintegruj je z projektem

W sytuacji, gdy już wiadomo, że projekt wymaga zarządzania zmianą trzeba zadbać o to, aby nie było dwóch osobnych planów wdrożenia: projektu i zmiany. Warto dokonać integracji w następujących obszarach:

  • Harmonogramu: na kiedy – w cyklu życia projektu – którzy pracownicy, co powinni wiedzieć i potrafić, aby mogli skutecznie pracować po zmianie; Change Management nie generuje osobnego harmonogramu tylko wspiera plan projektu, w terminach w nim przewidzianych.
  • Narzędzi i podejścia oraz wspólnego języka: zespół projektowy i inni interesariusze zmiany tak samo rozumieją, co i w jaki sposób robią, zarówno w obszarze PM jak i zarządzania zmianą.
  • Ról i zasobów: każdy wie, jaką rolę pełni w projekcie, a jaką w zmianie – koniecznie trzeba pamiętać, że to nie są te same role! Pomaga tutaj rozpisanie matrycy RACI. No i pozyskaj osoby do pełnienia tych ról, zapewnij, aby mogły znaleźć czas na niezbędne działania. W szczególności zdecyduj, czy jesteś w stanie sam pełnić rolę Change Managera, czy potrzebujesz w tym zakresie wsparcia wewnątrz lub na zewnątrz organizacji. Czasem taką usługę może zaoferować dostawca rozwiązania, jeśli zdążysz o to zadbać w umowie – jeśli nie zdążysz tego zrobić na początku projektu, to w praktyce trudno jest to później wyegzekwować.
  • Pomiaru postępów: postępy zmiany powinno się – i można! – mierzyć tak samo, jak postępy projektu i osiągania jego biznesowych celów. Z pomocą przychodzi tutaj na przykład ADKAR®, który jest znany choćby z PMBOK® Guide, opracowany przez wspominanego na wstępie Jeffreya Hiatta.

3. Zadbaj o kierowników średniego szczebla

Aż trudno uwierzyć, ale według światowych badań tylko 1/3 menedżerów jest odpowiednio przygotowywana do swojej roli w zmianie. Nawet w dobrych firmach czasami zapomina się o tej grupie zakładając, że skoro są częścią struktury firmy i płacimy im pensje, to dostosują się do zmian. Nic bardziej mylnego, menedżerowie nie będą sprzedawać swoim pracownikom zmiany, której sami nie kupili. Jednak podejmując odpowiednie działania, przy stosunkowo niewielkim nakładzie czasu i wysiłku możesz mieć sojuszników, zamiast oporników.

4. Działaj zgodnie z zasadą „will przed skill

Jeśli zastanawiasz się, jak poradzić sobie z oporem w projekcie, to zastosowanie tej zasady załatwia sprawę – z pomocą przychodzi tutaj wspomniany wcześniej ADKAR®. Jeśli doprowadzisz do tego, że do pracowników dotrze odpowiednia komunikacja na temat zmian, będzie ona z odpowiednim wyprzedzeniem i będzie pochodziła od właściwych nadawców (Sponsorzy, bezpośredni przełożeni pracowników), to możesz założyć, że ludzie w całej organizacji, od których zależy sukces Twojego projektu będą mieli świadomość, że jest on ważny i potrzebny. A jeśli poznają dostosowany do swoich realiów przekaz „WIIFM” („what’s in it for me” – jaki zmiana ma wpływ na mnie), jeśli zostaną zaangażowani do tworzenia docelowych rozwiązań oraz będą konfrontowani z potrzebą wdrożenia zmiany – wówczas sami będą chętniej korzystać z podsuwanych przez projekt sposobów, jak się do tych zmian mogą przygotować. Będą szukać sposobów, zamiast szukania wymówek. Nie zawsze dlatego, że polubią zmiany ale dlatego, że często są one naprawdę najlepszą możliwą opcją. Nawet jeśli obecnie lub w niedalekiej przyszłości wiążą się z niedogodnościami i osobistym ryzykiem. Podejście „jeśli nie chcesz tego zrobić, to zrób to niechętnie” jest na początek naprawdę wystarczające.

Fot. WavebreakMediaMicro – stock.adob

5. Rób to wszystko w uzgodnieniu ze Sponsorem i spraw, żeby to był prawdziwy Sponsor zmiany

Ktoś mi kiedyś powiedział: „jeśli zależy ci bardziej, niż Sponsorowi – to jesteś na prostej drodze do porażki”. I kilka razy się o tym przekonałem. Pracując z Project Managerami od ponad 20 lat słyszałem niejedną historię, gdy Sponsor wspierał projekt ale od strony zasobów i decyzji. Nie czuł, że potrzebuje być także „twarzą zmiany” do organizacji, zostawiając tę rolę innym (czasami przyjmują ją na siebie rzetelni PM-owie). Praktyka, w tym liczne badania, pokazują, że roli Sponsora nie można delegować. To właśnie Sponsor nadaje zmianie wagę, priorytet i uwiarygadnia ją w organizacji. To od niego zaczynają się wszystkie dobre rzeczy w zmianie, chociażby to on może wyrazić zgodę na wstępną diagnozę projektu pod kątem ryzyk ludzkich (lub może zablokować takie działania). To Sponsor powinien wspierać PM-a w skutecznym zaopiekowaniu czterech wymienionych powyżej obszarów. PM może z kolei pomóc Sponsorowi w pełnieniu jego (jej) roli, będąc sparingpartnerem i dostarczając wiedzy/ informacji niezbędnych do odpowiedniego przygotowaniu projektu i doprowadzenia go z sukcesem do końca. Na przykład monitorując postępy zmiany, przygotowując Sponsorowi plan jego działania i wskazując mu priorytety w zakresie budowania koalicji na rzecz zmiany z innymi kluczowymi liderami w organizacji. Pomimo wielokrotnego powtarzania ciągle warto przypomnieć, że 50% Sponsorów nie rozumie swojej roli w zmianie, a Sponsor to czynnik sukcesu #1 (i porażki też…). Od relacji ze Sponsorem zależy więc najwięcej i PM powinien sprawić, żeby był to Sponsor na miarę potrzeb zmiany.

Firma, której przykład podałem na wstępie, jako jedna z wielu, wdraża powyższe 5 zasad – z niezłymi efektami. Dzięki temu w tej organizacji historia nieudanych zmian ani się nie powtarza, ani „nie rymuje”. No, może precyzyjniej będzie powiedzieć, że porażki w zmianie stają się incydentalne – bo jednak nie wszystko jest idealnie. Tą droga podąża wiele znanych mi organizacji. Wielu PM-ów dzięki temu śpi spokojniej. A jeśli już powtarzają jakąś historię albo ją „rymują”, to jest to historia zmian pozytywnych, na lepsze, robionych z sensem i z sukcesami. Nie bez problemów i turbulencji – ale przy kontrolowalnym poziomie ryzyka. I przy mniejszym poziomie heroizmu. Po prostu nuda. I tak właśnie może i powinno być dzięki skutecznemu zarządzaniu „ludzką” stroną zmiany.