Dlaczego 80% wdrożeń systemów zarządzania się nie udaje

Jeśli Twoja firma miała już „projekt wdrożenia systemu zarządzania" i skończyło się na segregatorze w szafie, ten tekst wyjaśni dlaczego.

Osiem. Tyle razy firma, do której dołączyłem, próbowała wdrożyć „system zarządzania". Osiem różnych podejść, osiem firm konsultingowych, osiem zestawów pięknej dokumentacji. Efekt za każdym razem ten sam: segregator na półce, PowerPoint w archiwum i ludzie, którzy na dźwięk słowa „metodyka" robili się nerwowi.

Równolegle odkryłem coś jeszcze ciekawszego. W firmie toczyło się ponad sto projektów. Ponad sto. Nikt nie miał pełnego obrazu, nikt nie zarządzał portfelem, nikt nie wiedział które z nich się pokrywają, a które są ze sobą sprzeczne. Połowa z nich nie miała nawet sponsora, który umiałby wyjaśnić po co istnieją.

Pytanie, które sobie wtedy zadałem, nie brzmiało „jaka metodyka jest najlepsza?". Brzmiało: „dlaczego żadna z ośmiu nie zadziałała?".

Po czym poznać, że Twoje wdrożenie zmierza do szuflady

Zanim opowiem co zadziałało, sprawdź u siebie. Jeśli rozpoznajesz dwie lub więcej z tych sytuacji, prawdopodobnie jesteś na tej samej ścieżce co tamte osiem prób:

System zarządzania zaprojektował zespół konsultantów lub zarząd, a ludzie na dole dowiedzieli się o nim na szkoleniu. Dokumentacja jest piękna, ale nikt jej nie otwiera w codziennej pracy. Ludzie traktują nowe procesy jako „dodatkową robotę" obok normalnej pracy. Po wyjeździe konsultantów nikt nie pilnuje wdrożenia. Na pytanie „po co nam ten system?" ludzie wzruszają ramionami.

To nie jest kwestia złej metodyki. To jest kwestia złego podejścia do wdrożenia.

Konsultanci wyjechali, segregatory zostały

Odpowiedź okazała się banalnie prosta. Za każdym razem scenariusz wyglądał identycznie: przyjeżdża firma doradcza, robi warsztaty z zarządem, projektuje piękny system, pisze dokumentację, szkoli ludzi i wyjeżdża. Zarząd ogłasza „od teraz pracujemy tak". Ludzie kiwają głowami, wracają do biurek i pracują po staremu.

Nikt nie zapytał ludzi, którzy mieli w tym pracować, czy widzą w tym sens. Nikt nie sprawdził, czy ta piękna metodyka ma jakikolwiek związek z ich codzienną robotą. System zarządzania był czymś „z góry", obcym ciałem w organizmie firmy. A organizm, jak to organizm, odrzucał przeszczep.

60% metodyki, 99% potrzeb

Problem wielu wdrożeń jest taki, że kupujesz metodykę jak gotowy garnitur i próbujesz go naciągnąć na firmę, która ma zupełnie inną budowę ciała. Postanowiłem zrobić coś kompletnie innego. Zamiast wdrażać kolejną gotową metodykę, rozłożyłem ją na czynniki pierwsze. Wzięliśmy każdy element z osobna i zadaliśmy sobie uczciwe pytanie: czy to jest nam potrzebne? Nie czy „powinno być", nie czy „tak mówi standard". Czy ludzie, którzy mają tego używać, widzą w tym sens.

Okazało się, że mniej więcej 60% dowolnej standardowej metodyki zarządzania pokrywa 99% tego, czego potrzebujesz w codziennej pracy. Reszta to egzotyczne przypadki, które zdarzają się raz na kwartał albo nigdy. Po co komuś 200 stron procedur, jeżeli 120 z nich dotyczy sytuacji, które nie nastąpią?

Wyciągnęliśmy to co istotne. Uprościliśmy. I zaczęliśmy wdrażać od dołu, nie od góry.

PMO w dwanaście miesięcy

Budowa szła stopniowo. Zaczęliśmy od uporządkowania portfela projektów, bo tam był największy chaos. Sto niezarządzanych inicjatyw trzeba było najpierw zinwentaryzować, potem ocenić, a potem bezlitośnie wyciąć te bez uzasadnienia. Połowa odpadła już na etapie inwentaryzacji, bo nikt nie umiał wyjaśnić po co w ogóle istnieją.

Cały obszar zarządzania zmianą postawiliśmy na poziomie B-1 w strukturze, czyli bezpośrednio pod zarządem. Nie przy IT, nie w dziale wsparcia, nie w bocznym korytarzu. Tam, gdzie podejmowane są decyzje. Bez tego nie miałoby to szans, bo każdy dyrektor mógłby olać „sugestie" z bocznego działu.

W ciągu dwunastu miesięcy od firmy bez jakiegokolwiek zarządzania portfelem doszliśmy do działającego PMO z pełnym pipeline'em projektów, priorytetyzacją i raportowaniem.

A potem ludzie zaczęli domagać się więcej

Wprowadziliśmy ownership procesowy. Każdy kluczowy proces dostał swojego właściciela, jasne cele i sposób pomiaru. Ludzie zaczęli traktować swoje procesy jak własne. Zaczęli je ulepszać z własnej inicjatywy.

I tu wydarzyło się coś, czego się nie spodziewałem. Kiedy daliśmy ludziom uproszczoną wersję i powiedzieliśmy „to jest wasze, róbcie z tym co uważacie za sensowne", stało się coś paradoksalnego. Zaczęli domagać się więcej. Przychodzili i pytali: „a nie powinniśmy jeszcze mierzyć tego?", „a może dodajmy raportowanie tamtego?". Ludzie, którzy rok wcześniej mieli alergię na słowo „proces", teraz sami rozbudowywali system, bo czuli że jest ich.

Pamiętam galę, na której nagradzaliśmy najlepszych właścicieli procesów. Ludzie przychodzili po certyfikaty z dumą. W firmie, która osiem razy odrzuciła wdrożenie systemu zarządzania.

Od czego zacząć, żeby nie wylądować w szufladzie

Więc dlaczego osiem poprzednich prób się nie udało, a ta jedna tak? Nie dlatego, że miałem lepszą metodykę. Nie dlatego, że byłem mądrzejszy od konsultantów, którzy byli przede mną. Udało się dlatego, że to było pierwsze podejście, które nie próbowało być idealne.

Jeśli planujesz wdrożenie systemu zarządzania, trzy rzeczy zrób inaczej niż zwykle:

Zacznij od ludzi, nie od dokumentacji. Zanim napiszesz jedną stronę procedury, zapytaj ludzi, którzy mają w tym pracować, czego im brakuje. Co im przeszkadza. Gdzie tracą czas. To jest Twoja prawdziwa specyfikacja wymagań.

Wyrzuć 40% metodyki. Weź dowolny framework i odrzuć wszystko, co nie dotyczy codziennej pracy. 60% pokryje 99% Twoich potrzeb. Resztę zawsze możesz dodać później.

Daj ludziom ownership. Jeden proces, jeden właściciel, jasne cele. Nie wdrażaj „systemu". Daj ludziom narzędzie, które jest ich, nie zarządu.

System zarządzania zaczyna działać dopiero wtedy, gdy przestaje być projektem konsultingowym, a zaczyna być narzędziem ludzi, którzy w nim pracują.

A jeśli Twoje wdrożenie zaczyna się od trzydniowych warsztatów strategicznych z zarządem... to prawdopodobnie skończy się dokładnie tam, gdzie siedem poprzednich. W szufladzie.

Rafał Myrta - buduje działy rozwoju i systemy zarządzania zmianą w dużych i małych organizacjach.

Why 80% of Management System Implementations Fail

If your company has already had a "management system implementation project" and it ended up in a filing cabinet, this article will explain why.

Eight. That's how many times the company I joined tried to implement a "management system". Eight different approaches, eight consulting firms, eight sets of beautiful documentation. The result was always the same: a filing cabinet on the shelf, PowerPoint in the archive, and people who got nervous at the word "methodology".

At the same time, I discovered something even more interesting. The company was running over a hundred projects. Over a hundred. Nobody had the full picture, nobody was managing the portfolio, nobody knew which ones overlapped and which ones contradicted each other. Half of them didn't even have a sponsor who could explain why they existed.

The question I asked myself then wasn't "what methodology is best?". It was: "why didn't any of those eight work?".

How to tell your implementation is heading for the drawer

Before I explain what worked, take a look at your own situation. If you recognize two or more of these scenarios, you're probably on the same path as those eight failed attempts:

A management system designed by consultants or the executive team, with people on the ground finding out about it at a training session. The documentation is beautiful, but nobody opens it in their daily work. People treat new processes as "extra work" on top of their normal job. After consultants leave, nobody enforces the implementation. When you ask "why do we need this system?" people just shrug.

It's not a question of bad methodology. It's a question of bad approach to implementation.

The consultants left, the filing cabinets stayed

The answer turned out to be strikingly simple. Every single time it played out the same way: a consulting firm shows up, runs workshops with the executive team, designs a beautiful system, writes documentation, trains people, and leaves. Management announces "from now on we work this way". People nod, go back to their desks, and work the same as before.

Nobody asked the people who had to actually work with it if they saw the point. Nobody checked if this beautiful methodology had anything to do with their daily work. The management system was something imposed from above, a foreign object in the company organism. And organisms, as they do, reject the transplant.

60% of methodology, 99% of needs

The problem with many implementations is that you buy a ready-made methodology like an off-the-rack suit and try to squeeze it onto a company with a completely different body shape. I decided to do something completely different. Instead of implementing another packaged methodology, I broke it down into components. We took each element separately and asked ourselves an honest question: do we actually need this? Not "should we have it", not "that's what the standard says". Do the people who will actually use it see the point.

It turned out that roughly 60% of any standard management methodology covers 99% of what you need in daily work. The rest is exotic edge cases that happen once a quarter or never. Why would someone need 200 pages of procedures if 120 of them cover situations that will never happen?

We extracted what was essential. Simplified. And started implementing from the bottom up, not from the top down.

PMO in twelve months

The build-out was gradual. We started by organizing the project portfolio, because that's where the biggest chaos was. A hundred unmanaged initiatives needed first to be inventoried, then evaluated, then ruthlessly cut if they had no justification. Half of them dropped out during the inventory stage because nobody could explain why they existed in the first place.

We placed the entire change management function at the B-1 level in the structure, which means directly reporting to management. Not in IT, not in a support department, not in some side hallway. Where decisions get made. Without that, it wouldn't have stood a chance, because any director could just ignore suggestions from a sidelined department.

Within twelve months, we went from a company with no portfolio management whatsoever to having a working PMO with a full pipeline of projects, prioritization, and reporting.

Then people started demanding more

We introduced process ownership. Every key process got its own owner, clear goals, and a way to measure them. People started treating their processes like their own. They started improving them on their own initiative.

And then something happened that I didn't expect. When we gave people a simplified version and said "this is yours, do what you think makes sense", something paradoxical happened. They started asking for more. They'd come by and ask: "shouldn't we also be measuring this?", "maybe we should add reporting on that?". People who a year earlier had an allergy to the word "process" were now building out the system themselves because they felt ownership of it.

I remember a ceremony where we recognized the best process owners. People came to collect their certificates with pride. In a company that had rejected a management system implementation eight times.

Where to start so you don't end up in a drawer

So why did the eight previous attempts fail while this one succeeded? Not because I had a better methodology. Not because I was smarter than the consultants who came before me. It worked because this was the first approach that didn't try to be perfect.

If you're planning a management system implementation, do three things differently than usual:

Start with people, not documentation. Before you write a single page of procedure, ask the people who will actually work with it what they're missing. What's getting in their way. Where they're wasting time. That's your real requirements specification.

Throw out 40% of the methodology. Take any framework and discard everything that doesn't apply to daily work. 60% will cover 99% of your needs. You can always add the rest later.

Give people ownership. One process, one owner, clear goals. Don't implement a "system". Give people a tool that belongs to them, not to management.

A management system only starts working when it stops being a consulting project and becomes a tool for the people who work with it.

And if your implementation starts with three-day strategic workshops with the executive team... it will probably end up exactly where the seven before it did. In a drawer.

Rafał Myrta - builds growth departments and change management systems in organizations large and small.