Na potrzeby rozważań prowadzonych w tej książce podzieliłem świat zarządzania projektami na cztery kategorie: kaskadowe, zwinne, optymalizacyjne i tytułowe eksploracyjne. Schematycznie ilustruje to poniższy diagram.
Rys. Rodzaje projektów.
W dalszej części tego rozdziału omówię wszystkie te kategorie, aby zarysować Ci, drogi czytelniku, szerszą perspektywę.
Artykuł jest fragmentem książki Bardziej niż Agile będącej w trakcie druku: https://onepress.pl/ksiazki/bardziej-niz-agile-marcin-zmigrodzki,baragi.htm#format/d
Ludzkość projekty realizuje od kilkunastu tysięcy lat. Od kiedy zaczęliśmy podejmować większe wyzwania wymagające koordynacji dużej grupy ludzi okazało się, że osiągamy lepsze efekty, gdy planujemy z góry nasze przedsięwzięcie. Dwanaście tysięcy lat temu Göbekli Tepe, którego wysokość sięga piętnastu metrów było konstruowane przez kilkaset lat. Stawiana osiem tysięcy lat później piramida Djosera o wysokości sześćdziesięciu dwóch metrów była budowana około trzydziestu lat. Rzymskie Koloseum zbudowane kolejne dwa i pół tysiąca lat później wznoszone było na wysokość 48 metrów przez dziewięć lat. Sześć lat zajęło zbudowanie niemal kilometrowej wysokości Burj Kalify. Pomijając oczywiste uproszczenia dotyczące złożoności tych projektów, postęp nastąpił. W dużej mierze zawdzięczamy go lepszym technologiom, ale również lepszej organizacji pracy olbrzymich zastępów specjalistów.
Taka filozofia współpracy zakładała szczegółowe planowanie, a potem rozliczanie ludzi z wykonywania planu. Zakładała też precyzyjne rozdzielanie zadań, aby ograniczyć chaos. Jej siłą była zdolność skalowania. Sprawdzała się zarówno w małych przedsięwzięciach, jak stawiania wieży wartowniczej, jak i w gigantycznych. Machu Picchu przez 30 lat wznosiły setki ludzi od inżynierów, który wytyczali przebieg murów, tarasów i kanałów wodnych po niewolników, którzy wciągali bloki granitu szczyt góry.
Przewijając sześćset lat wprzód po Machu Picchu docieramy do epoki tworzenia standardów zarządzania projektami, z których najpopularniejszym okazał się PMBOK Guide. Wyewoluował on najpierw na bazie potrzeby realizacji dużych inwestycji powojennych i zimnowojennych w USA, a potem w całym świecie zachodu i wreszcie globu. Z początkowego sektora konstrukcyjno-budowlanego rozpropagowany został na konsulting, IT, produkcję i inne obszaru gospodarki.
Równolegle wraz ze wzrostem skali produkcji masowej oraz presją na zadowolenie klientów i redukcję kosztów produkcji, magazynowania i transportu wyłoniły się dwa podejścia Lean i Six Sigma na dwóch krańcach naszej planety. Komponentem każdego z nich z osobna stało się prowadzenie projektów optymalizacyjnych. Six Sigma nawet zaproponowała wprowadzenie całego cyklu życia projektu składającego się z pięciu etapów o nazwie DMAIC (w sumie to zaproponowała trzy cykle życia projektów, bo jeszcze mniej znane DMADV i DFSS). Zatem pojawiło się drugie podejście do prowadzenia projektu, które mówiło “weź funkcjonujący proces i uruchom na nim projekt, którego celem będzie odkrycie i wdrożenie usprawnień.”
W duchu Lean optymalizacja miała przynieść skrócenie czasu przejścia procesu i w efekcie większą responsywność na zmiany popytu oraz oszczędności. W duchu Six Sigmy optymalizacja owocowała większą powtarzalnością procesu, mówiąc żargonowo jego stabilizacją, co też przyczyniało się do oszczędności.
Na początku XXI wieku dojrzała koncepcja mówiąca o tym, że nie cały projekt trzeba z góry planować. Wystarczy, że zespół w ponawianych cyklach będzie przybliżał się do ideału, jednocześnie odkrywając, czym ten ideał jest.
Jakie mamy korzyści takiego podejścia? Po pierwsze na początku nie w pełni rozumiemy, jakiego efekty finalnego się spodziewamy, a po drugie ciężko precyzyjnie oszacować ile to zajmie. Zatem zamiast popełniać błędy, bo po prostu zaakceptujmy naszą niepewność. Zaufajmy, że zespół zmotywowanych specjalistów da radę. Będzie starał się z całych sił i dostarczy najlepszy możliwy rezultat. Przy takich założenia powstały metodyki zwinne. Po kolejnych dwudziestu latach widzimy, że wyścig wśród metodyk zwinnych wygrały Scrum i Kanban. Tak narodziła się trzecia gałąź metodyk projektowych, ale również całej filozofii współpracy ludzi, nazwana zwinnością.
Jednak tempo przemian na świecie narasta. Modny stał się termin VUCA od ang. volatility, uncertainty, complexity and ambiguity, czyli zmienność, niepewność, złożoność i niejednoznaczność.
Jak się okazało po dwóch dekadach praktycznych doświadczeń, Scrum, czy Kanban dedykowane są do mniejszych zespołów, które z grubsza znają wizję końca, natomiast szczegóły wymagań oraz sposób ich realizacji może być doprecyzowywany w trakcie realizacji.
Rosnąca zmienność powoduje, że coraz częściej konieczne jest gwałtowne modyfikowanie kierunku projektu, albo oznacza wręcz, że nie wiadomo, gdzie zespół ma dotrzeć, tylko w trakcie to musi ujawnić.
I tu na wściekłym strusiu wpada czwarty jeździec, projekt eksploracyjny. Projekt, który zaczyna się w mgle chaosu (fuzzy frontend) i często w nim kończy, ale którego główną wartością jest nabranie kompetencji jak ujeżdżać ów chaos. W takich projektach porażka jest często powodem do dumy.
Argument za narastającą potrzebą wyjścia poza zwinność daje raport Gartnera o tytule Hype Cycle for Enterprise Architecture 2021 i 2022. Otóż pojawiają się tam takie zagadnienia, jak Agile poza IT, zwinne zarządzanie projektem, architektura zwinna i wszystkie one znajdują się na odcinku rosnącego rozczarowania. W innym raporcie Gartnera o tytule Agile and DevOps dotyczącym koncepcji zarządczych w IT w 2020 roku pojawiła się koncepcja Hypothesis Driven Development, ale 2022 została włączona do koncepcji Feature Management.
Projekt eksploracyjny definiowany jest w artykułach naukowych, jako projekt, w którym niejasny jest cel oraz sposób jego realizacji. Warto zauważyć, że sam termin eksploracyjnych projektów nie pojawia się w ogóle w raporcie.
Nazwa eksploracyjny została wybrana subiektywnie. W świecie projektów bardziej niepewnych niż zwinne i kaskadowe pojawia się wiele terminów. Inne znane terminy to badawczo-rozwojowe, resilience management (zarządzanie odpornością), ekstremalne, eksperymentalne, hypothesis driven development, model spiralny zarządzania projektami. Dla uniknięcia nieporozumień dalej będę używał tylko jednej nazwy – eksploracyjne na oznaczenie ich wszystkich. Projekt eksploracyjny charakteryzuje się tym, że ma nieprecyzyjne cele, niekompletny zakres oraz nie da się zidentyfikować wszystkich ryzyk. Generalnie w takim projekcie niewiele wiemy i musimy zabrać się za odkrywanie.
Tu warto nadmienić, że jedną z powracających cech takich projektów jest zarządzanie niepewnością a nie ryzykiem. Różnica polega na tym, że ryzyka da się zmierzyć, a niepewność z powodu braku wiedzy pozostaje niemierzalna. Jest to też jeden z pierwszych wniosków z wywiadów, które przeprowadziłem, przygotowując się do tej książki. Za wyjątkiem dwóch osób, które częściowo odpowiedziały twierdząco, ponad pięćdziesięciu moich rozmówców odparło, że nie stosuje ilościowych metod zarządzania ryzykiem w swoich projektach eksploracyjnych. Jeszcze raz powtórzę, bo to musi wybrzmieć. Ponad 90% praktyków skrajnie niepewnych projektów nie zarządza ryzykiem w sposób bardziej zaawansowany.
Przygotowując się do pierwszych wywiadów zakładałem, że moi rozmówcy potwierdzą mi, że zarządzanie ryzykiem jest ważne i stosują je na co dzień. Stało się dokładnie odwrotnie.
Zacząłem drążyć, jakie są powody takiego stanu rzeczy i głównym uzasadnieniem okazało się to, że po prostu w trakcie eksploracji nie posiadamy danych. Ryzykiem za pomocą narzędzi statystycznych można zarządzać tylko wtedy, gdy dysponujemy próbą z wcześniejszych podobnych sytuacji. W tym wypadku wkraczamy na nieznany ląd. Próba bardzo często składa się z jednego elementu i właśnie w tej chwili jest on badany. Jeden z końcowych rozdziałów książki poświęcam właśnie aspektom, których wciąż brakuje w praktykach prowadzenia projektów eksploracyjnych.
Kolejny rodzaj projektów, który warto wymienić to projekty optymalizacyjne. Są to przedsięwzięcia, które uruchamiane są w obszarze istniejącego już procesu i ich zadaniem jest jego poprawa. Przykładami takich projektów są Six Sigma i Lean. W takich projektach zakres w rozumieniu zbioru zadań jest na początku nieznany, bowiem trzeba odkryć, co wymaga naprawy w procesie. Natomiast znany jest zakres w rozumieniu miejsca, gdzie będzie dokonywana poprawa. Przykładowo może to być gniazdo produkcyjne, fragment procesu obiegu dokumentów, wybrany dział. Na wejściu znajduje się proces na wyjściu proces, który działa szybciej, taniej, mniej awaryjnie, bardziej powtarzalnie, dając większą satysfakcję klientom.
Na ogół efektem projektów optymalizacyjnych są nie rewolucyjne zmiany w istniejących procesach, raczej usprawnienia niż totalne przemodelowanie wybranych obszarów organizacji.
