Możesz mieć genialny, ważny, innowacyjny i rewolucyjny pomysł. Sęk w tym, że jest on niewiele wart, póki inni za tobą nie pójdą i nie zechcą go wdrożyć. Znakomitym przykładem jest historia Ignaza Semmelweisa – lekarza, który w XIX wieku LATAMI usiłował namówić swoich kolegów po fachu do… mycia rąk. To, co różni pioniera antyseptyki od liderów i menedżerów współczesnych firm, to fakt, że nie miał formalnej władzy nad swoimi kolegami. Ale czy to faktycznie tak wiele zmienia?

Dlaczego pracownicy nie chcą zmian?

Prawie każdy lider (oraz rodzic) zna z autopsji przykłady biernego oporu innych. Prosimy, żądamy, grozimy, druga strona niby się zgadza, ale wdrożenia w życie naszych oczekiwań jakoś nie widać.

Model ADKAR: czego ludzie potrzebują do zmiany?

W zgrabny sposób model ten uświadamia nam, że aby zmiana się udała, jej uczestnicy muszą przejść przez kilka etapów.

Wprowadzacie nowy system do zarządzania projektami, ale ludzie nadal pracują w Excelu i przesyłają sobie pliki mailem? Zanim zamówisz kolejne szkolenie, sprawdź, gdzie utknęli. Model ADKAR pomaga rozdzielić pięć różnych problemów:

• Świadomość. Czy ludzie rozumieją, jaki problem ma rozwiązać nowy system? „Bo centrala tak zdecydowała” wyjaśnia, skąd przyszedł nakaz, ale nie po co.
• Chęć. Czy widzą sens przesiadki? Jeśli mają prowadzić projekty w nowym systemie, ale szef nadal żąda raportów w Excelu, trudno się dziwić, że nie palą się do podwójnej roboty.
• Wiedza. Czy wiedzą, jak wykonać swoje codzienne zadania? Prezentacja wszystkich funkcji systemu niekoniecznie nauczy ich, jak zgłosić opóźnienie albo znaleźć aktualny plan.
• Umiejętność. Czy potrafią zrobić to samodzielnie na prawdziwym projekcie? Podążanie za trenerem podczas ćwiczenia to jedno. Poradzenie sobie bez niego, kiedy goni termin — drugie.
• Utrwalenie. Co dzieje się po szkoleniu? Czy przełożeni sami korzystają z systemu i pomagają usuwać przeszkody, czy po tygodniu wszyscy wracają do starych plików?

Objaw jest ten sam: ludzie nie korzystają z systemu. Przyczyny są różne, więc kolejny kolorowy samouczek wideo nie załatwi każdej z nich.

Nie warto przechodzić dalej, póki nie upewnimy się, że wcześniejszy etap został “zaliczony”. Powszechna dobra praktyka mówi wręcz, że nie da się skutecznie przepchnąć kogoś dalej niż o dwa kroki na raz. Czytaj: nie planuj na weekendowy zjazd firmowy, że w piątek uświadomisz ludzi, w sobotę zdobędziesz ich chęci, w niedzielę nauczysz, co i jak, tak żeby w poniedziałek byli już cali zwarci i gotowi. Maks to awareness i desire albo desire i knowledge na raz.

Krzywa adopcji — nie wszyscy ruszą jednocześnie

Choć to moja własna interpretacja – lubię patrzeć na krzywą adopcji, jako na drugi, prostopadły wymiar przestrzeni, której pierwszym wymiarem jest ADKAR. Pokazuje ona, że nie wszyscy równie szybko przejdą przez jego kolejne etapy.

Krzywą adopcji opisał Everett Rogers, badając, jak rozprzestrzeniają się nowe pomysły i technologie. Są tacy, którzy stali nocą w kolejce do sklepów Apple przed premierą pierwszego iPada. Wtedy, kiedy jeszcze nie bardzo było wiadomo, co to właściwie jest i do czego może służyć. Są też ci, co nabyli tablety później. Oraz ci, którzy ani myślą.

Dokładnie tak samo jest w pracy – jedni są ciekawi i chcą testować nowy system, zanim dostaną do niego dostęp. Inni wolą poczekać, aż koledzy sprawdzą, czy w ogóle da się na nim pracować. Wniosek dla osoby wdrażającej zmianę: nie wszystkich przekonasz tym samym argumentem ani w tym samym momencie.

Zacznij od ludzi, którzy chcą spróbować (innowatorzy)

Nie staraj się, aby najpierw wszyscy przeszli fazę A i D modelu ADKAR – zniszczą cię krytycy i sceptycy. Znajdź innowatorów — ludzi gotowych przetestować pomysł, nawet jeśli nie wszystko jeszcze działa. Daj im czas i wsparcie, zbierz uwagi i popraw rozwiązanie. Wesprą cię psychicznie (co nie jest bez znaczenia), a wyniki pokażą, czy jest z czym wychodzić do reszty firmy.

Znajdź ludzi, których inni słuchają (wcześni naśladowcy)

Entuzjasta każdej nowej aplikacji niekoniecznie przekona kolegów. Potrzebujesz też osób, które są otwarte na zmiany, a jednocześnie takich, do których inni przychodzą po radę i których opinię traktują poważnie. W modelu Rogersa taką rolę często pełnią wcześni naśladowcy — early adopters. Zaproś ich do sprawdzenia rozwiązania na własnej pracy. Ich uczciwe „sprawdziłem, pomaga” może znaczyć więcej niż prezentacja dyrektora. O ile rzeczywiście pomaga.

Większości pokaż, że to działa (wczesna i późna większość)

Entuzjastę przekonałeś możliwościami nowego systemu. Wczesna większość zapyta raczej: „Kto już na tym pracuje i jak mu idzie?”. Daj im porozmawiać z kolegami, którzy przetestowali rozwiązanie. Niech pokażą, co robią szybciej, czego nie muszą już poprawiać i na czym sami się wyłożyli. Taka rozmowa daje więcej niż kolejny pokaz funkcji.

Późna większość będzie czekać dłużej. Zanim się przestawi, chce mieć pewność, że rozwiązanie jest dopracowane, a pomoc dostępna. W podjęciu decyzji podejmuje także widmo nieuchronności. Jeśli wiedzą, że stary system zostanie za sześć tygodni wygaszony – motywacja do wdrożenia nowego wymiernie wzrasta.

Ach, no i sprawdź czy firma nie wysyła sprzecznych sygnałów: trudno wymagać pracy w nowym systemie, jeśli dyrektor podczas cotygodniowych statusów nadal pokazuje starego dobrego Excela.

Nie poświęcaj następnych dwóch lat na przekonywanie Maruderów

Maruderzy, czyli guzdrały, sceptycy i inni. Ich istnienie jest całkiem normalne. Pisząc te słowa, uśmiecham się na wspomnienie miny pewnej stażystki, która w 2013 roku była w firmowej kuchni świadkiem mojej rozmowy z szefem. Chciał mnie on koniecznie przekonać, abym wziął jako telefon służbowy najnowszy model iPhone’a. Ja jednak twardo się operałem:

Wolę swoją starą Nokię. Intuicyjna, działa na deszczu, ekran nie pęka, jak mi gdzieś spadnie. A nawet jak pęknie, to kosztuje tylko kilka stów, a nie ciężkie tysiące. A ten iPhone to wiesz – może leżeć u nas w szufladzie, będzie do testowania dla zespołu.

Część spośród Maruderów z czasem dojdzie do wniosku, że „to wszystko ma jednak sens”. Z pozostałymi warto porozmawiać indywidualnie. Jeśli tylko dyskusja ta będzie oparta na merytorycznych podstawach – mogą pomóc ci poprawić i usprawnić to, co wdrożyliście.

Jeśli jednak ktoś mimo dostępnego wsparcia odmawia przejścia na uzgodniony sposób pracy, trzeba postawić sprawę jasno. Albo się dostosujesz, albo adiós.

Pętla PDCA: wdrażaj, sprawdzaj, poprawiaj

Jakiekolwiek zmiany wdrażasz – nie ma szans, aby wszystko przewidzieć i zaplanować idealnie. Lepiej podejść do tego iteracyjnie, na bieżąco poprawiając i wyciągając wnioski. Nietypowe wprowadzenie do PDCA przedstawiam na swoim prywatnym blogu. Ale dla tych, którzy nie chcą otwierać 70-tej zakładki w przeglądarce: PDCA to Plan — Do — Check — Act, czyli zaplanuj, wykonaj, sprawdź i działaj na podstawie wyników.

Załóżmy, że chcecie wprowadzić w organizacji prosty szablon briefu projektu, bo ludzie notorycznie zaczynają pracę, zanim ustalą co właściwie mają dowieźć.

• Plan — zaplanuj. Przygotujcie prosty brief i ustalcie, po czym poznacie, że pomaga. Mniej nieporozumień po starcie? Mniej pracy do wyrzucenia, bo ktoś inaczej zrozumiał cel?
• Do — wypróbuj. Przetestujcie go w dwóch projektach. Nie musicie od razu ogłaszać nowej procedury dla całej firmy.
• Check — sprawdź. Czy brief pomógł uniknąć tych problemów? Które pytania coś wyjaśniły, a które ludzie wypełniali na odczepnego?
• Act — zdecyduj, co dalej. Jeśli działa — włączcie go do stałego sposobu pracy. Jeśli nie — poprawcie i sprawdźcie ponownie albo zrezygnujcie z rozwiązania, które tylko dokłada roboty.

Najłatwiej zatrzymać się na „wykonaj”. Szablon opublikowany, komunikat wysłany, zadanie odhaczone. Tylko czy od tego pracuje się lepiej? Bez sprawdzenia efektów równie dobrze możecie właśnie produkować kolejną warstwę biurokracji.

Wdrażanie zmian w firmie – rady z linii frontu

Ustal swoją rolę oraz odpowiedzialność

Masz “pomóc we wdrożeniu zmiany”? Brzmi dobrze. Pamiętaj jednak, żeby zacząć od doprecyzowania, co to właściwie znaczy.

Masz wypracować nowy model, być liderem zmian, być doradcą lidera? Kogo będziesz miał do pomocy? Czy Klient/Szef oczekuje, że będziesz poruszał się i optymalizował w ramach istniejącego procesu i składu osobowego, czy oczekuje rewolucji? Do jakiego stopnia sobie te rewolucje wyobraża? Dlaczego tak, a nie inaczej? Jakie ma dotychczasowe doświadczenia z rewolucjami?

Jeśli ma to być nowy sposób pracy, to nim zaczniesz rozmawiać o problemach – poznaj bieżący proces. Może sytuacja wcale nie jest taka, jak ci się przedstawia? Najlepiej poznać go, rysując istniejące przepływy. Przyda się tutaj mapowanie procesów w BPMN 2.0.

Wysłuchaj ludzi, ale nie próbuj naprawiać wszystkiego

Podczas wprowadzania zmian ludzie bywają sfrustrowani i jedną z ich naturalnych tendencji jest przychodzenie do ciebie ze stosem narzekań. Od samego początku powinieneś jak mantrę powtarzać dwie rzeczy:

• Konstruktywnie! Co możemy zrobić w tej sprawie i jak ty możesz w tym pomóc. Nie ma sensu omawiać obszaru, w którym nie da się nic zrobić. Z kolei jeśli zrobienie czegoś jest realne, ale ta osoba nie kiwnie w tej sprawie palcem – to znaczy, że aż tak bardzo jej to nie boli.
• Zanim zacznie zmieniać i krytykować zachowania innych, niech zastanowi się, jakie zmiany mogą zostać wprowadzone na jej własnym poletku.

Wysłuchując uwag i pomysłów, zawsze zwracaj uwagę na ile związane są one z celem projektu. Nie jesteśmy w stanie zrobić wszystkiego za jednym zamachem. To przykre, że ludzie mają stare komputery, ale na ile ma to związek z naszym celem?

Konfrontuj też i uzgadniaj opinie i dane z różnymi grupami, nie wierz w jeden komunikat. Genialna zmiana dla działu sprzedaży może sparaliżować magazyn. A czasem… magazyn wszystko wyolbrzymia i trzeba to jeszcze skonfrontować z logistyką. Na pewno nie wierz jednak w pierwszą wersję, jaką usłyszysz.

Projekt rośnie? Znajdź więcej ludzi do pchania!

Naturalne jest to, że w ramach dużego projektu (np. reorganizacja PMO i całościowego podejścia do zarządzania projektami) powstanie kilka projektów pobocznych – np. nowe szablony dla fazy analizy, wdrożenie JIRa itd. Powinieneś znaleźć stosowne osoby w organizacji, które to faktycznie pociągną.

I klasycznie – one muszą widzieć tę potrzebę, tego chcieć i faktycznie się tym zajmować. Inaczej to po prostu dołożenie kolejnego bezpańskiego projektu, który jedynie skomplikuje sytuację. Jeśli wszystko pociągniesz sam, ryzykujesz nie tylko brak czasu. Po twoim odejściu wszystko może wrócić do poprzedniego stanu.

Centrala ogłasza zmianę. A co mówią kierownicy?

Komunikujcie zmianę i “zdobywajcie serca” kaskadowo w dół organizacji. Prezes do dyrektorów, dyrektorzy do kierowników, kierownicy do swoich ludzi. Każdy przełożony powinien umieć wyjaśnić swojemu zespołowi, po co ta zmiana i co konkretnie oznacza w jego pracy.

Niestety częsty jest model typu: prezes z grupą zaufanych przygotowuje zmianę, a potem zbiera wszystkich razem i ją komunikuje. Zmiana zaskakuje jednocześnie kierowników i ich zespoły. Zamiast ją wdrażać, mogą więc wspólnie psioczyć na „durne pomysły z góry” i zająć się jej radosnym sabotowaniem.

Nie wprowadzaj pięciu rewolucji naraz

Pragmatyzm, a nie idealizm. Lepiej zmienić coś w dobrym kierunku, niż nie zmienić w ogóle. Być może nawet masz w głowie system, który wydaje się idealny dla danej organizacji, ale czy ludzie, którzy mieliby z nim pracować są na niego gotowi?

⁠⁠Nie wprowadzaj kilku rewolucji naraz. Jeśli narzucisz zespołowi równolegle nowe procedury, nowy system i zmianę zasad pracy, doprowadzisz ludzi do przeciążenia. Zamiast brać na warsztat dziesięć poprawek naraz, wybierz 2–3 najważniejsze usprawnienia, wdróż je do końca i daj ludziom czas na złapanie nowego rytmu.