Nic nigdy nie idzie zgodnie z planem. Naiwnością byłoby sądzić, że będzie inaczej. Tymczasem wiele publikacji i szkoleń z zarządzania projektami koncentruje się na idealnych scenariuszach, podczas gdy niewiele z nich oferuje praktyczne rozwiązania na momenty, kiedy projekt zaczyna się mierzyć z niepowodzeniem. Nie wystarczy zapisanie w Issue Log czy eskalowanie. Pierwsze to biurokratyczna i nieefektywna metoda. Drugie to reakcja, gdy mleko się już rozlało. Jak zatem metodycznie i skutecznie rozgrywać trudności i przeszkody w projekcie, zamiast być przez nie rozegranym? Zapraszam do skorzystania z mojej autorskiej praktyki Baseball Game.
Praktyka zrodziła się w ogniu zmagań projektowych. Początek miał miejsce w 2017 roku, gdy mój zespół, złożony z menedżerów projektów w dużej globalnej firmie, mierzył się ogromem projektów różnego typu. Te projekty łączyło jedno: MWB (Must-Win-Battle) – czyli projekty, które nie mogą się nie udać. Łatwo się domyślić, że były to projekty z gatunku najtrudniejszych czy nawet mission impossible. Wówczas z tego bitewnego doświadczenia wykuła się i obroniła w boju koncepcja Baseball Game.
Cztery rodzaje odchyleń w projekcie
Zaczęło się od tego, że uświadomiliśmy sobie, że istnieją cztery i tylko cztery rodzaje odchyleń w projektach i, że wzorem starożytnych Rzymian, dobrze jest sobie te odchylenia, przeciwności, podzielić (łac. divide et impera – dziel i rządź). Podzielone, skategoryzowane, od razu stają się łatwiejsze w zarządzaniu. Dwa dotyczą aspektu czasowego, pozostałe dwa aspektu jakościowego. Oto pierwsze dwa w kontekście czasowym:
– Jeszcze nierozpoczęte (Not Started Yet) – zadanie projektowe miało rozpocząć się w poprzednim tygodniu. Mija tydzień, a zadanie jest ciągle nierozpoczęte.
– Ciągle niezakończone (Not Completed Yet) – zadanie projektowe miało być zakończone dwa tygodnie temu, ale nadal jest realizowane i niezakończone.
Kolejne dwa odchylenia charakteryzują problemy z jakością w projekcie:
– Dotknięte ryzykiem (At Risk) – co prawda od strony czasowej nie ma zagrożeń, ale przy głębszej analizie przebiegu zadania już teraz widać, że nie dostarczy zamierzonego rezultatu.
– Poniżej oczekiwań (Below Expectations) – zadanie zrealizowane, dowiezione, ale rezultat jest niepełny lub bez rezultatu.
Mamy zatem pierwszy krok w praktyce Baseball Game. W żargonie zespołów projektowych, których nauczyłem tego podejścia, lubimy mawiać: „Teraz wiadomo, jaką piłką gramy”. Pora przejść do samej gry.
Zasady gry w baseball
Zaintrygowały mnie zasady gry w baseball, w szczególności reguły, które musi spełnić drużyna atakująca. Pałkarz, jeśli legalnie odbije piłkę, wyrusza już jako biegacz na zdobycie czterech baz. Bazy muszą być zdobyte w ustalonej kolejności i muszą być zdobyte wszystkie. Wtedy drużyna zyskuje punkt. Wówczas w 2017 roku pomyślałem, że przeciwności, problemy i odchylenia w projekcie są właśnie taką odbitą piłką baseballową i trzeba teraz rozegrać te odchylenia oraz problemy, zdobywając, jak w grze baseballowej, cztery bazy. Jak to przełożyliśmy na zarządzanie odchyleniami w projekcie?
– Zbierz fakty (grab the facts) – ustalmy fakty i tylko fakty. Żadnych ocen czy przypuszczeń. Żadnych pomysłów na tym etapie. Z jakim rodzajem problemu, odchylenia projektowego mamy do czynienia? Jaka jest skala, rozmiar tego odchylenia? Jakie konsekwencje nastąpiły już, a jakie nastąpią za moment?
– Opracuj scenariusze (develop scenarios) – teraz czas na listę opcji. Co możemy zrobić? Jaka jest opcja pierwsza, jaka druga, jaka trzecia? Nie oceniamy opcji i alternatyw. Po prostu tworzymy listę.
– Wybierz opcję (select the option) – ta baza jest najtrudniejsza do zdobycia. Nie przeskakujemy do decyzji czy wyboru. Nie wybieramy alternatywy przez aklamację, przez
głosowanie, “na czuja”. To byłoby wysoce nieprofesjonalne. Ustalamy kryteria decyzyjne. Jak mamy kryteria wyboru dobrej decyzji, wybór właściwej opcji z listy stworzonej w drugiej bazie jest czystą formalnością. Nie musimy się przepychać z własnym zdaniem, prowadzić niekończących się dysput. Mamy sensowne kryteria, mamy sensowny wybór.
– Działaj (act) – żadna decyzja nic nie zmieni, jeśli nie wprowadzi się jej w życie. W tej bazie „zaprzęgamy trzy konie pociągowe”, czyli nasze 3xW (What – Co? Who – Kto? By When – Do kiedy?). Esencję praktyki Baseball Game ilustruje Rys. 1.
Rys. 1. Praktyka Baseball Game w zarządzaniu odchyleniami w przebiegu projektu.
Źródło: opracowanie własne.
Może rzeczywisty przykład Baseball Game?
Michał prowadzi projekt w banku, który ma poprawić jakość danych wejściowych, używanych w różnych aplikacjach bankowych. Przed nim etap testowania nowych rozwiązań softwarowych. I tu napotyka odchylenie typu: Ciągle niezakończone. Michał ze swoim zespołem projektowym postanowił rozegrać to odchylenie metodą Baseball Game.
Baza 1: Zbierz fakty. Zadanie ma już dwa tygodnie opóźnienia. Główny tester wylądował na długotrwałym zwolnieniu lekarskim.
Baza 2: Co można z tym zrobić? Możemy wydłużyć czas trwania projektu o trzy tygodnie, zwrócić się do działu IT o dodatkowe zasoby do testowania lub zlecić wsparcie testowe na zewnątrz, co zwiększy budżet projektu.
Baza 3: Michał i zespół przyjęli dwa kryteria dobrego wyboru. Pierwsze – utrzymać budżet w limicie pierwotnym. Drugie – utrzymać czas realizacji projektu. Stąd oczywisty wybór padł na opcję drugą.
Baza 4: Co? Do IT wpłynie oficjalny wniosek o dostarczenie zasobów do testowania. Kto? Wniosek złoży sponsor projektu. Do kiedy? W ciągu 3 dni od teraz.
Czy to zadziałało? Tak. Owszem, dział IT się „burzył”, ale sponsor projektu szybko im wytłumaczył, że skoro zobowiązali się do testowania, zakontraktowali to zadanie, to powinni się z tego wywiązać. A chorobowe jednego z testerów nie może być wymówką. Profesjonalny wykonawca jest przygotowany na takie sytuacje i ma plan awaryjny. Sponsor zaproponował, że skorzysta z outsourcingu, ale zafakturuje ten koszt na dział IT. Skłonili się do pierwotnej propozycji i skierowali nowe zasoby testerów do projektu Michała. Sam sponsor „zakupił” u Michała i spółki patent na Baseball Game, gdy sprawy idą nie tak.
Co zmieniła praktyka Baseball Game?
Zmieniła wiele. Przede wszystkim nauczyła nas dwóch bezcennych umiejętności: dyscypliny myślenia oraz dyscypliny działania. Przestaliśmy debatować i narzekać w nieskończoność. Debatowanie i narzekanie jest bezproduktywne i nieprofesjonalne. Przestaliśmy oskarżać innych i okoliczności. Oskarżanie i szukanie winnych jest bezproduktywne i nieprofesjonalne. Praktyka Baseball Game zmieniła nas i zmieniła nasze zarządzanie projektami. Z czasem zaczęliśmy z dużym wyprzedzeniem rozpoznawać oznaki, że coś pójdzie nie tak. I dzięki temu mogliśmy uruchomić działania prewencyjne, żebyśmy nie musieli grać w baseball. Dyscyplina myślenia połączona z dyscypliną działania, wypracowana za pomocą Baseball Game sprawiła, że po latach praktyki, rozgrywamy ten projektowy baseball mimochodem. Wpadamy na siebie przy kawie albo wbijamy się na krótkie spotkanie i w ciągu paru minut omawiamy wszystkie cztery bazy.
Dwight D. Eisenhower mawiał: „plan jest niczym, planowanie jest wszystkim”. Starożytni Rzymianie mawiali: „serva ordinem et ordo servabit te” (łac. zachowaj porządek, a porządek zachowa ciebie). My nie planujemy projektów, gdzie wszystko idzie zgodnie z planem. My wiemy, że zawsze coś pójdzie nie tak. I jesteśmy na to przygotowani, jak Rzymianie, z naszym baseballem.
Praktyk w dziedzinie zarządzania projektami od ponad 30 lat z użyciem wielu metod (PRINCE2, PMBOK, LeanSixSigma, Design Thinking, Agile i Scrum). Zarządzał zespołami projektowymi w wielu globalnych organizacjach. Wspierał dziesiątki osób w certyfikacji LeanSixSigma i Professional Scrum Master. Prowadzi z innymi praktykami własną firmę doradczo-szkoleniowo-coachingową. Prywatnie od kilkunastu lat pasjonuje się praktykowaniem szermierki samurajskiej, „kenjutsu” i systemu samoobrony, krav maga. Od kilkudziesięciu lat lubi zasiąść do fortepianu i wyczarować jakąś „muzę” dla siebie lub innych.