Śmiertelny błąd Black Belta: Nigdy nie ignoruj dysfunkcji zespołu Six Sigma

🎯 Widziałem projekty DMAIC, które technicznie były bez zarzutu. Solidna karta projektu, właściwa metodologia, zaangażowany sponsor. A mimo to lądowały w szufladzie. Nie dlatego, że analizy były złe. Dlatego, że dwie osoby w zespole nie rozmawiały ze sobą od marca, Champion i Black Belt ciągnęli w przeciwnych kierunkach, a ekspert dziedzinowy od tygodnia odpowiadał jednosylabowo. Konflikty w projektach Lean i Six Sigma są równie kosztowne co defekty. A w przeciwieństwie do defektów prawie nikt ich nie mierzy.

📕 Zainteresowany/a tematem – czytaj dalej… ⬇️

Władza nieformalna blokuje dane

Każdy projekt DMAIC ma formalną strukturę: Champion definiuje zakres, Black Belt prowadzi, Green Belt wspiera, eksperci dziedzinowi dostarczają wiedzy procesowej. Na papierze wygląda to przejrzyście. W praktyce struktura formalna bardzo często jest fasadą, za którą ukrywa się zupełnie inna mapa wpływów. [^1]

Dynamika władzy w zespole projektowym rzadko kiedy pokrywa się z hierarchią opisaną w karcie projektu. Technolog z 20-letnim stażem, który zna każdy niuans procesu, ma realny wpływ na to, czy dane będą zbierane rzetelnie – niezależnie od tego, czy figuruje w dokumencie jako „członek zespołu”. Jeśli poczuje się pominięty lub zagrożony, dane zaczną być „przypadkowo” niepełne, pomiary „nieco” opóźnione, a spotkania informacji zwrotnej coraz rzadziej produktywne.

Badania nad dynamiką władzy w projektach wskazują, że nieformalni liderzy opinii mogą skutecznie zablokować projekt nawet bez jawnego sprzeciwu. Ich narzędzia są subtelne: selektywna dostępność, opóźnienia w odpowiedziach, „zapominanie” o przekazaniu kluczowych informacji. W fazie Measure taki mechanizm może kosztować tygodnie i nikt tego nie zidentyfikuje jako „problem z zespołem”. Na raporcie statusowym pojawi się: „opóźnienia w zbieraniu danych”. [^2]

Kto naprawdę decyduje?

Identyfikacja rzeczywistej mapy wpływów powinna być częścią spotkania inaugurującego każdy projekt, a nie opcjonalnym ćwiczeniem team-buildingowym, lecz elementem analizy ryzyka. Narzędzia do tego są proste: analiza sieci społecznych (do której wystarczy flipchart i 20 minut), krótkie wywiady indywidualne z każdym członkiem zespołu przed pierwszym spotkaniem, obserwacja tego, kto do kogo się zwraca z pytaniami.

Warto zadać sobie jedno pytanie: gdyby projekt miał się nie udać, kto miałby na tym skorzystać? Odpowiedź często wskazuje na miejsce, gdzie napięcie jest największe i gdzie interwencja jest najpilniejsza.

Kiedy Black Belt rozumie, że technolog jest de facto strażnikiem procesu, może zamiast go omijać – włączyć go w projekt jako eksperta wiodącego dla konkretnej sekcji analizy. To nie jest kompromis. To strategia zarządzania zasobem, który bez zaangażowania stanie się największym ryzykiem projektu. [^3]

Champion kontra Black Belt – kto ma rację?

To jeden z najczęstszych i najbardziej destrukcyjnych konfliktów w projektach Lean Six Sigma. Champion chce wyników na koniec kwartału. Black Belt wie, że solidna analiza przyczynowo-skutkowa wymaga trzech miesięcy i pełnego zestawu danych. Obaj mają rację. I właśnie dlatego ten konflikt jest tak trudny do rozwiązania. [^4]

Napięcie między Championem a Black Beltem wynika zazwyczaj z różnicy perspektyw czasowych i priorytetów organizacyjnych. Champion odpowiada za wyniki biznesowe – widzi projekt przez pryzmat wskaźników, terminów i prezentacji dla zarządu. Black Belt odpowiada za jakość metodologiczną. Wie, że skrócenie fazy Analyze to prosta droga do wdrożenia rozwiązania, które nie usuwa pierwotnej przyczyny problemu. Efekt: projekt kończy się sukcesem na papierze i klęską w praktyce po kilku miesiącach. [^5]

Protokół mediacji, zanim będzie za późno

Problem narasta najczęściej w przejściu z fazy Measure do Analyze, gdy Champion oczekuje już rekomendacji, a Black Belt dopiero buduje pełny obraz. Jeśli nie ma ustalonego protokołu eskalacji, każda strona zaczyna działać na własną rękę: Champion wywiera presję przez menedżerów liniowych, Black Belt broni metodologii kosztem relacji.

Skutecznym rozwiązaniem jest zdefiniowanie w karcie projektu tzw. punktów decyzyjnych z jawnie opisanymi kryteriami. Zamiast ogólnego „projekt trwa 4 miesiące”, karta projektu powinna zawierać: „po 6 tygodniach fazy Measure, na przeglądzie bramkowym etapu, Champion i Black Belt wspólnie oceniają kompletność danych wg kryteriów X, Y, Z i podejmują decyzję o przejściu do Analyze”. Taka struktura eliminuje szarą strefę, w której rodzi się konflikt. [^2]

Warto też wprost omówić na spotkaniu inaugurującym: co Black Belt robi, gdy Champion wywiera presję na skrócenie analizy? Jaki jest tryb eskalacji? Kto jest ostatecznym arbitrem? Brak odpowiedzi na te pytania w fazie planowania gwarantuje trudną rozmowę w fazie wdrożenia w najgorszym możliwym momencie.

„Ty mi powiesz, jak mam pracować?”

Opór ekspertów dziedzinowych to temat, o którym w literaturze Lean mówi się mało, bo jest niewygodny. Zakłada, że wprowadzamy zmiany w obszarze, który ktoś zna lepiej od nas. I że ta osoba może mieć rację, a mimo to stać na przeszkodzie projektowi. [^6]

Ekspert dziedzinowy – technolog, mistrz, doświadczony operator – często postrzega projekt Lean jako zagrożenie. Nie dlatego, że jest „trudny” lub „nieelastyczny”. Dlatego, że jego wiedza i doświadczenie przez 20 lat były wartością samą w sobie. Projekt, który metodologicznie kwestionuje jego intuicję, podważa fundament jego pozycji w organizacji. Opór jest więc racjonalny – tyle że destrukcyjny dla projektu. [^7]

Jak zamienić opór w sojusz

Najczęstszy błąd Black Belta to traktowanie eksperta dziedzinowego jako źródła danych, a nie jako partnera analizy. Ekspert czuje się przesłuchiwany, nie pytany o zdanie. Efekt: dostarcza minimum informacji wymaganych do zamknięcia rozmowy – i nic więcej.

Odwrócenie tej dynamiki wymaga zmiany podejścia już na etapie planowania. Zamiast wywiadu z ekspertem, warto zaproponować mu współprowadzenie warsztatów procesowych. Zamiast prezentować mu wyniki analizy do „zatwierdzenia”, zaprosić go do budowania diagramu przyczynowo-skutkowego. Taka zmiana roli – z obiektu analizy do współtwórcy – radykalnie zmienia poziom zaangażowania. [^8]

Model zarządzania zmianą ADKAR (Hiatt, 2006) wskazuje, że kluczowym warunkiem skutecznego wdrożenia jest etap „Desire” – gotowość pracownika do aktywnego wspierania zmiany. Gotowość ta rośnie dramatycznie, gdy pracownik był współtwórcą rozwiązania, a nie jedynie jego odbiorcą. W kontekście Lean Six Sigma oznacza to, że ekspert dziedzinowy zaproszony do współbudowania diagramu przyczynowo-skutkowego staje się naturalnym ambasadorem wdrożenia. To nie jest kwestia miękkich kompetencji. To twarda arytmetyka ryzyka projektowego. [^9]

Strach, który blokuje dane

Jest jeden problem z fazami Measure i Analyze, o którym podręczniki Lean Six Sigma nie piszą wprost: ludzie zniekształcają dane, jeśli się boją. Nie zawsze świadomie. Ale zniekształcają. [^4] Gdy operator wie, że dane z jego stanowiska posłużą do oceny jego wydajności, zaczyna nieświadomie „poprawiać” pomiary. Gdy mistrz rozumie, że analiza Pareto wskaże jego obszar jako główne źródło defektów, nagle pojawiają się „wyjątki” i „specyficzne okoliczności” wyjaśniające statystyki. To nie jest złośliwość. To mechanizm obronny, który aktywuje się w każdej organizacji, gdzie kultura oceny dominuje nad kulturą uczenia się. [^3]

Jak zbudować bezpieczną przestrzeń pomiarową

Pierwszym krokiem jest jawne zadeklarowanie na spotkaniu inaugurującym, że dane zbierane w projekcie nie będą używane do oceny indywidualnych pracowników ani jako podstawa do działań dyscyplinarnych. Brzmi to prosto, ale wymaga wiarygodności. Jeśli organizacja ma historię projektów kończących się redukcją zatrudnienia lub zmianami zakresu obowiązków, samo deklarowanie nie wystarczy.

Skutecznym narzędziem jest anonimizacja danych na poziomie stanowisk w fazach wstępnych projektu oraz włączenie pracowników w interpretację wyników przed ich zaprezentowaniem zarządowi. Gdy operator słyszy: „zebraliśmy dane, pomóż nam je zrozumieć” zamiast „oto co znaleźliśmy w twoim obszarze” – poziom otwartości diametralnie rośnie.

Patrick Lencioni w swojej przełomowej książce z 2002 roku wskazuje brak zaufania jako fundament wszystkich pozostałych dysfunkcji zespołu – od unikania konfliktów, przez brak zaangażowania, po lekceważenie wyników. W kontekście Lean Six Sigma brak zaufania nie objawia się kłótnią na spotkaniu – objawia się niekompletnymi arkuszami pomiarowymi i danymi, które „dziwnie” wyglądają w MSA (analizie systemu pomiarowego). Zanim Black Belt wdroży narzędzie Gage R&R, warto sprawdzić, czy zespół mu ufa. Jeśli nie – nawet najlepsza metodologia pomiarowa nie da rzetelnych wyników. [^7]

Facylitator czy lider projektu?

W klasycznym modelu Lean Six Sigma Black Belt jest jednocześnie liderem merytorycznym projektu i facylitatorem pracy zespołowej. To połączenie ról, które w teorii jest efektywne – a w praktyce generuje nieuchronny konflikt priorytetów. [^1]

Lider projektu dąży do wyniku: analizy, rekomendacje, wdrożenie, zamknięcie. Facylitator dba o proces grupowy: zaangażowanie, równowagę głosów, konstruktywne napięcie i decyzje podejmowane przez cały zespół. Gdy projekt jest pod presją czasu, Black Belt niemal zawsze wybiera rolę lidera – co oznacza, że przestaje słyszeć to, co dzieje się między ludźmi. [^5]

Kiedy potrzebny jest zewnętrzny facylitator

Sygnały, że Black Belt nie jest w stanie jednocześnie prowadzić projektu i zarządzać dynamiką grupową, są zazwyczaj subtelne: spotkania kończą się formalnie sprawnie, ale bez prawdziwego zaangażowania; decyzje są podejmowane jednomyślnie, bo nikt nie chce przedłużać dyskusji; jeden lub dwóch członków zespołu systematycznie milczy.

W takich sytuacjach warto rozważyć włączenie zewnętrznego facylitatora – kogoś, kto nie jest odpowiedzialny za wyniki projektu, a jedynie za jakość procesu grupowego. Nie musi to być konsultant zewnętrzny – może to być inny Black Belt z organizacji, Champion innego projektu, lub doświadczony HR Business Partner. Kluczowe jest oddzielenie roli merytorycznej od procesowej. [^2]

Koszt dwóch dodatkowych godzin facylitacji na kluczowych warsztatach jest nieporównywalnie niższy niż koszt miesiąca opóźnienia projektu spowodowanego narastającym napięciem w zespole, którego nikt nie zaadresował na czas.

Diagnoza dysfunkcji przed katastrofą

Większość projektów Lean Six Sigma ma rozbudowane narzędzia do diagnozy procesu – mapy strumienia wartości, diagramy spaghetti, wykresy kontrolne. Prawie żaden nie ma narzędzi do diagnozy zespołu, który ten proces analizuje. [^3]

To luka strukturalna. Inwestujemy w narzędzia do mierzenia zmienności procesu, ale nie mierzymy zmienności zaangażowania, zaufania i otwartości w zespole – czynników, które bezpośrednio wpływają na jakość danych i decyzji projektowych. [^4]

Narzędzia wczesnej diagnozy

Diagnoza dysfunkcji zespołu nie musi być skomplikowana. Na spotkaniu inaugurującym warto przeprowadzić krótką anonimową ankietę (5-7 pytań) badającą poziom psychologicznego bezpieczeństwa, klarowność ról i zaufanie do procesu decyzyjnego. Narzędzie Team Health Check, opracowane przez Henriego Kniberga w ramach Spotify Engineering Culture (2012), lub uproszczona wersja kwestionariusza Lencioniego pozwalają zebrać użyteczne wyniki w ciągu 30 minut i wskazują obszary ryzyka zanim projekt ruszy pełną parą. [^10][^7]

Kontrakt zespołowy – często traktowany jako formalność przy pisaniu karty projektu – może być faktycznym narzędziem zarządzania napięciem, jeśli zawiera nie tylko role i obowiązki, ale też jawne ustalenia dotyczące sposobu podejmowania decyzji, trybu eskalacji konfliktów i zasad komunikacji między fazami. Zespół, który na początku projektu otwarcie rozmawia o tym, co zrobi, gdy pojawi się konflikt, znacznie rzadziej daje się konfliktowi zaskoczyć. [^8]

Globalne badanie Antony, Sony (2020), przeprowadzone na 201 ekspertach Lean Six Sigma z sektora produkcji i usług, wskazuje, że dominujące przyczyny niepowodzeń projektów mają charakter ludzki i organizacyjny: brak zaangażowania zarządu, opór wobec zmian, niewystarczające mechanizmy motywacyjne oraz słaba komunikacja – daleko przed błędami metodologicznymi. A mimo to harmonogramy projektów wciąż nie zawierają czasu na zarządzanie dynamiką zespołu. [^3]

Mierz to, czego nie mierzysz

Przez ostatnie lata nauczyłem się, że defekty w danych najczęściej mają źródło w defektach relacji. Że opóźnienia w harmonogramie zaczynają się od jednej nieodebranej rozmowy. Że cofnięcie efektów wdrożenia rzadko kiedy jest skutkiem złego rozwiązania – częściej jest skutkiem tego, że nikt, kto miał je wdrożyć, nie czuł się jego współtwórcą.

Proponuję od dziś każdy projekt zaczynać od tego samego pytania: czy ten zespół jest gotowy pracować razem? Nie „czy ma kompetencje” – to warto sprawdzić osobno. Zapytaj też koniecznie o gotowość do otwartości, do kwestionowania założeń, do powiedzenia głośno, że coś nie działa.

Badania Beer i Nohria (2000) opublikowane w Harvard Business Review dokumentują, że około 70% wszystkich inicjatyw zmian organizacyjnych nie osiąga zakładanych celów. W sektorze doskonalenia procesów skala problemu jest analogiczna – a literatura dotycząca Lean Six Sigma wskazuje jako kluczowy czynnik niepowodzeń właśnie element ludzki: opór wobec zmian i niewystarczające zaangażowanie kierownictwa. [^4][^3]

Praktyczne kroki, które rekomenduje każdemu Black Beltowi i Championowi:

  • Wbuduj diagnozę zespołu w spotkanie inaugurujące – krótka ankieta bezpieczeństwa psychologicznego, anonimowa, przed pierwszym spotkaniem
  • Zdefiniuj protokół eskalacji konfliktu w karcie projektu – kto jest arbitrem, co jest trybem eskalacji, kiedy angażuje się zewnętrzny facylitator
  • Oddziel rolę lidera projektu od facylitatora – przynajmniej na kluczowych warsztatach analitycznych
  • Rozmawiaj z ekspertami dziedzinowymi przed projektem, nie w projekcie – zrozum ich obawy, zanim staną się oporem
  • Mierz zaangażowanie zespołu co dwa tygodnie – szybkie badanie nastrojów: 3 pytania, w 5 minut wyniki widoczne dla wszystkich

Jeśli którykolwiek z tych elementów wywołuje u Ciebie reakcję „u nas to nie przejdzie” – właśnie znalazłeś/aś pierwsze dysfunkcje swojego zespołu. I to jest dobry punkt startowy.

🤔 Jakie konflikty w projektach najtrudniej Ci było rozwiązać? Chętnie wymienię doświadczenia.  Napisz proszę w komentarzu. ✍️

źródła:

[^1] „Why do Great Six Sigma Project Teams Still Fail?”, 6sigma.us, 2017. https://www.6sigma.us/small-business/six-sigma-teams-fail/

[^2] Krysiński M., Miller P., „Rola konfliktu w zarządzaniu projektami realizowanymi w metodyce PMBOK”, Katedra Informatyki, Wydział Zarządzania, Uniwersytet Łódzki, 2016. https://dspace.uni.lodz.pl/handle/11089/19736

[^3] Antony J., Sony M., Lizarelli F.L., Fernandes M.M., „A Global Study Into the Reasons for Lean Six Sigma Project Failures: Key Findings and Directions for Further Research”, IEEE Transactions on Engineering Management, 2020. https://ieeexplore.ieee.org/document/9186804

[^4] Beer M., Nohria N., „Cracking the Code of Change”, Harvard Business Review, May-June 2000, s. 133-141. https://hbr.org/2000/05/cracking-the-code-of-change

[^5] Iyer R., „3 Lessons from Failed Six Sigma Projects: A Leadership Perspective”, LinkedIn Pulse, 2024. https://www.linkedin.com/pulse/3-lessons-from-failed-six-sigma-projects-leadership-perspective-iyer-kchbf

[^6] „Zarządzanie konfliktem w zespołach projektowych w świetle wyników badań”, Academia.edu. https://www.academia.edu/5808140

[^7] Lencioni P.M., The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass, San Francisco, 2002.

[^8] „Strategie rozwiązywania konfliktów w zespole projektowym”, DoktorBiznes.pl, 2024. https://doktorbiznes.pl/strategie-rozwiazywania-konfliktow-w-zespole-projektowym/

[^9] Hiatt J.M., ADKAR: A Model for Change in Business, Government and our Community, Prosci Learning Center Publications, 2006. https://www.prosci.com/adkar

[^10] Kniberg H., Ivarsson A., Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Crisp, 2012. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

[^11] Thomas J., Mengel T., „Preparing project managers to deal with complexity – Advanced project management education”, International Journal of Project Management, 26(3), 2008, s. 304-315. https://doi.org/10.1016/j.ijproman.2008.01.001


📕 Zajrzyj do doskonałej książki Stowarzyszenia SLMP – Historie Leanem Pisane – i poznaj moją – Od Zera do Lean Six Sigma Managera 👊

Podziel się swoją opinią