Zabierz opał spod kociołka

Praktycy transformacji wiedzą jedno, bez względu na to, jakby się nie starali, zawsze wdrażając zmiany naruszą czyjeś wygodne status quo, a najpewniej wywołają również poczucie zagrożenia. Nie da się przeprowadzić głębokich zmian i jednocześnie i pozostać powszechnie lubianym managerem. Dlatego transformacja przypomina batalię i wymaga przemyślanej i wyważonej strategii. I z tego powodu, oprócz podstawowego frameworku transformacyjnego, np. COBIT lub MSP, warto się wyposażyć w zestaw technik, które pozwoliłem sobie tutaj nazwać fortelami[1].

W tekście Fundamenty cyfrowej transformacji powołałem się na publikację Johna Kottera, w której zaleca on: „Form a powerful guiding coalition”. Należy jednak zdawać sobie sprawę, że nie każdy będzie chciał się do tak tworzonej koalicji przyłączyć. Część niezdecydowanych zachowa neutralność, obserwując dokąd ta transformacja zmierza, pojawią się również osoby które zmianę będą po prostu sabotowały.

Opis fortelu

I tutaj pojawia się pytanie, jak się zachować wobec mniej lub bardziej jawnych przeciwników. Oczywiście… przekonywać, pozyskiwać, starać się zdobyć ich zaufanie…  itd. itp. ale co z tymi, którzy mimo wszelkich starań werbalnie deklarują pełne poparcie dla wdrażanych zmian, lecz stosują strategię biernego oporu i przy każdej możliwości sypią piasek w przekładnie. Cierpliwie czekają aż zmiany ugrzęzną, ukochane status quo powróci, a ten interim od transformacji sobie wreszcie pojedzie do innego projektu.

Gdy już rozpoznamy takie osoby, to z pomocą przychodzi nam jeden ze starych chińskich forteli, tj. „zabierz opał spod kociołka”. W największym skrócie, pozbaw swojego oponenta źródła siły, na której buduje swoją pozycję. Nie należy wchodzić w otwarty konflikt. Po pierwsze zawsze należy dać szansę na zmianę postrzegania zmiany – nasza koalicja powinna być zawsze otwarta. Po drugie walki zawsze wykrwawiają obie strony i odciągają od głównego celu, jakim jest usprawnienie firmy, która nas wynajęła. Fortel ten zasadza się na tym, aby uniemożliwić szkodzenie. Uczynić wroga zmian na tyle słabym aby nie był w stanie wyrządzić szkody.

Należy w pierwszej kolejności określić źródło siły naszego oponenta. Może to być oparcie we współpracownikach, osobiste relacje z kimś z wyższego kierownictwa, kompetencje (prawdziwe lub pozorne – ważne że osoba taka uchodzi za kompetentną, wcale nią być nie musi). Bez zidentyfikowania źródła siły tego fortelu nie da się zastosować. A zidentyfikować można wyłącznie przez baczną obserwację i rozmowy, jak najwięcej rozmów.

Przykłady

Odpowiadałem za transformację firmy wytwarzającej oprogramowanie. Firma miała ogromne problemy z zakończeniem dwóch bardzo dużych projektów i zleciła mi i mojemu zespołowi zaprojektowanie i wdrożenie dedykowanej metodyki wytwarzania oprogramowania. Proces zarządczy oparliśmy na metodyce #PRINCE2, a wytwórczy na #Scrum (połączenie metodyki klasycznej z #Agile). Jeden z programistów nie akceptował nowego podejścia. Oczywiście nie decydował się na jawną konfrontację, ale ignorował wszelki prośby o stosowanie się do wdrażanego governance oraz używania technik projektowych. Zawsze uzasadniał to ogromną ilością obowiązków i napiętymi terminami. To akurat była prawda, kary umowne w opóźnionych już ponad rok projektach były gigantyczne, a tym samym argument – „Mam skończyć na czas integrację, czy wypełniać te tabelki?” był niezwykle skuteczny (te tabelki – to był np. rejestr jakości używany do potwierdzenie czy wszystkie scenariusze testowe zostały zrealizowane).

Ponadto ten programista uchodził za najlepszego w firmie specjalistę od integracji. Każdy zespół prosił o jego czas, a on ciągle przełączał się pomiędzy pracami – wszyscy go potrzebowali. Jego siłę stanowiła kompetencja (jak się okazało później raczej wyobrażenie o kompetencji). Pierwszą moją decyzją było wybranie zespołu z najtrudniejszą integracją i przydzielenie tam tego programisty w pełnym wymiarze czasu – żadnych innych prac aż do zakończenia integracji w tym zespole. Na codzienne przeglądy postępów zapraszałem również programistów z innych zespołów aby mogli uczyć od tej skarbnicy wiedzy. Efektem końcowym było obnażenie niewielkich kompetencji. Okazało się, że to nie jest wybitny mistrz integracji, jak wszyscy sądzili lecz zupełnie przeciętny programista. Cała siła jaką dysponował przy blokowaniu zmiany rozwiała się w ciągu miesiąca.

Inna transformacja dotyczyła firmy produkcyjnej. Tutaj odpowiadałem za reorganizację działu IT. Dyrektor IT najdelikatniej mówiąc nie był moim przyjacielem i zwolennikiem wprowadzanych zmian. W końcu w każdym IT wszystko zawsze działa doskonale. Ale skoro Zarząd przysłał kogoś takiego jak ja, to nie pozostawało nic innego jak udawać, że o takich zmianach sam marzył od dawna i tylko czekał na właściwą okazję aby wdrożyć procesy #ITIL. Tutaj źródłem siły był zespół, składający się kolegów znających się od lat i utrzymujących bliskie relacje również prywatnie. Najoględniej, koledzy uwili sobie ciepłe gniazdko i skupiali głownie na tym aby się nie przepracować. Jak się łatwo domyślić takie rozwiązania jak system ticketowy, SLA na usługach czy wdrożone procesy ITIL zakłócały ten słodki stan. W tym przypadku zacząłem pokazywać całemu zespołowi możliwe ścieżki rozwoju, ciekawe konferencje, szkolenia, opowiadałem o możliwościach, projektach i wyzwaniach czekając aż znajdą się wśród nich osoby z ambicjami większymi niż ich aktualne status quo i zaczną się rozwijać. W bardzo krótkim okresie pojawiło się dwóch naturalnych liderów, których zacząłem promować i finalnie wdrożyłem strukturę organizacyjną zapewniającą im stanowiska kierownicze. Rozbiłem apatyczny zespół, który bronił się przed zmianami dając szansę na rozwój tym, którzy chcieli z niej skorzystać, a dalsze zmiany mogłem opierać na tych dwóch nowych kierownikach. Bierny opór Dyrektora IT przestał mieć znaczenie.

Podsumowanie

We wspomnianej książce Piotra Plebaniaka, która stanowi moją inspiracje dla tego artykułu, można znaleźć przykłady historyczne odnoszące się do walk Lawrencea z Arabii z Turkami, ofensywy Tet Północnego Wietnamu przeciwko Stanom Zjednoczonym czy Wojny Zimowej (Finlandia contra Sowieci). Ale dla poznania w jaki sposób one „zabierały opał spod kociołka” odsyłam Państwa do oryginału, który jeszcze raz serdecznie polecam.

[1] Bazą jest doskonała książka Piotra Plebaniaka pt. „36 forteli, chińska sztuka podstępu, układania planów i skutecznego działania”

Poprzedni artykuł Transformacja cyfrowa przedsiębiorstw produkcyjnych
Następny artykuł Zagarnij każdą kozę

Inne artykuły

ASAP goni FUCKUP

Seven Step Continuous Improvement Process

Łatwo powiedzieć, żeby do monitorowania transformacji wybrać właściwe mierniki, natomiast znacznie trudniej to wykonać. W szczególności intuicyjnie, bez znajomości odpowiednich technik zarządczych. Dlatego w tym wpisie przedstawię jedną (ale nie jedyną

ASAP goni FUCKUP

Definicja potrzeb biznesowych

Aby prawidłowo zdefiniować zakres projektu bądź programu należy poznać rzeczywistą motywacje kluczowych interesariuszy. Często czują oni intuicyjnie, że potrzebna jest zmiana stanu aktualnego ale nie potrafią bądź nie chcą czytelnie

ASAP goni FUCKUP

Definicja zakresu – Technika planowania opartego na produktach

Technika planowania opartego na produktach jest jedną z technik specjalistycznych dostarczanych przez metodykę PRINCE2. Technika ta koncentruje się na fizycznych produktach wytwarzanych w ramach projektu (czyli zakresie). Dopiero na podstawie