W poprzednim, 26 numerze Strefy PMI, mogliście przeczytać pierwszą część tekstu dotyczącego zmian w zarządzaniu projektem i projektami w świecie VUCA, tj. w czasach nam współczesnych.
Obecnie zajmiemy się zmianami dotyczącymi roli kierownika projektu i wzrostu samoorganizacji zespołu projektowego, wzrostu znaczenia fazy realizacji oraz uczenia się i eksperymentowania, z równoczesnym zmniejszeniem oraz zmianą roli i charakteru planowania oraz coraz większego zakresu stosowania wizualizacji informacji i zarządzania produktem.
Przypomnijmy, że akronim VUCA opisuje współczesne środowisko biznesowe następującymi charakterystykami:
- Zmienność (ang. Volatility)
- Niepewność (ang. Uncertainty)
- Złożoność (ang. Complexity)
- Niejednoznaczność (ang. Ambiguity).
Jakie są więc te inne zmiany w zarządzaniu projektami w środowisku VUCA?
Zmiana roli kierownika projektu i zespołu projektowego
W środowisku VUCA zmienia się rola i zadania kierownika projektu, a także rola zespołu projektowego. Zmiana ta zwłaszcza związana jest z digitalizacją produktów oraz zastosowaniem technologii cyfrowych i IT – w praktyce bowiem wszystkie projekty w tym obszarze są projektami biznesowo-informatycznymi, a także ze złożonością i niepewnością.
W czasach VUCA nie jest już możliwe by kierownik projektu posiadał wystarczającą wiedzę oraz kompetencje biznesowe, produktowe i technologiczne (IT) wymagane przy większości obecnych projektów. Obok kompetencji z zarządzania systemem projektowym coraz większe znaczenie mają kompetencje przywódcze oraz rola lidera. Obecny kierownik projektu to nie tradycyjny menedżer w stylu „command and control”, rozdający zadania projektowe oraz kontrolujący uzyskane wyniki. Dla uzyskania efektów biznesowych, a także dla uzyskania zadowolenia członków zespołu projektowego, musi to być obecnie lider z dużymi kompetencjami „miękkimi”.
Obok tradycyjnych zadań w tym obszarze, jak np. budowanie zespołu, komunikacja w zespole i z innymi interesariuszami czy rozwijanie zespołu, do zadań kierownika projektu należą obecnie:
- budowanie systemu wspólnych wartości zespołu i spowodowanie, by te wartości były „motorem” działań i zachowań członków zespołu,
- identyfikowanie wewnętrznych motywacji członków zespołu i dopasowania projektów i zadań do tych motywacji,
- upełnomocnianie osób w zespole i stworzenie środowiska umożliwiającego „wyłanianie” się z zespołu liderów dla poszczególnych tematów i/lub problemów.
Zarządzanie projektem, rozumiane dotychczas jako zarządzanie ludźmi i realizowanymi przez nich zadaniami, staje się obecnie zarządzaniem całym środowiskiem (systemem) projektowym, rozumianym jako stworzenie i utrzymanie takiego systemu pracy w projekcie, który umożliwia zarówno osiągnięcie celów biznesowych projektu, zgodnych z celami strategicznymi firmy, jak i celów rozwojowych oraz satysfakcji pracowników.
Dla nauki zarządzania projektami oznacza to w praktyce z jednej strony konieczność znacznie szerszego spojrzenia na rolę i kompetencje kierownika projektu – lidera. Z drugiej strony – co chyba jeszcze ważniejsze – konieczność wypracowania odpowiedzi i wskazówek dotyczących pytania: jaka jest droga i metoda „tworzenia” takiego profilu kierownika-lidera projektu oraz jego urzeczywistnienia w praktyce.
Lider, w roli zarządzającego systemem pracy, będący także coachem i wsparciem dla zespołu to jedna strona medalu. Drugą jest oczywiście sam zespół projektowy. W czasach VUCA zaczęliśmy mówić o samoorganizującym się zespole. Samoorganizujący się, lub też samozarządzający się zespół projektowy to swego rodzaju „ideał”, będący podejściem do pracy w zespole – nie tylko projektowym – wskazywanym jako kierunek rozwoju przez takie podejścia w zarządzaniu, jak „Management 3.0”, Agile, turkus. Taki kierunek myślenia wynika z kilku przyczyn. Po pierwsze, w środowisku VUCA mamy do czynienia z wysokiej klasy profesjonalistami, nazywanymi często „pracownikami wiedzy” (ang. knowledge worker). Jednak dla sukcesu projektu konieczna jest współpraca wielu takich specjalistów, gdyż żaden z nich, a także kierownik projektu, nie „ogarnia” samodzielnie całości tematu projektu. Po drugie zaś, stworzenie takiego zespołu specjalistów i danie im swobody – w określonych ramach – czyli granicach – sprzyja ich kreatywności i pomysłowości, a także efektywnej pracy, a tym samym osiągnięciu biznesowych celów projektu.
Jednak to nie tylko „ideał”, lecz także coraz częstsza praktyka, zwłaszcza w zespołach i projektach w obszarze IT (software development, product development). W podejściu Scrum nie występuje rola kierownika projektu; są natomiast role: właściciela produktu, Scrum Mastera oraz członka zespołu wytwórczego; w podejściu Kanban występuje rola Service Delivery Managera oraz Service Request Managera oraz zespół realizacyjny. O ile jednak w tych podejściach mowa jest o tym jak taki zespół ma funkcjonować, to stosunkowo mało mówi się o tym, jak stworzyć taki samoorganizujący się zespół. Najważniejszy chyba problem praktyczny – jaki obserwuje autor – to spowodowanie, by osoby w zespole chciały i potrafiły przejmować coraz więcej odpowiedzialności za realizowane prace, za ich terminowość i zgodność z wymaganiami. Problem niechęci do brania odpowiedzialności bardzo często wiąże się z całym systemem pracy i z kulturą organizacji, np. z karaniem za popełnione błędy, z brakiem mechanizmów dostarczania wiedzy i rozwoju kompetencji, czy też z tradycyjną hierarchiczną strukturą. Wszystko to są elementy zarządzania systemem pracy, które powinny być zadaniem kierownika projektu – lidera zarządzającego całym systemem projektowym. Stosunkowo częstsze i chyba łatwiejsze w praktyce jest natomiast wyłanianie się w zespole pojedynczych liderów, zajmujących się konkretnymi tematami, lub obszarami projektu.
Lider i samoorganizujący się zespół to w praktyce dwa elementy, które muszą funkcjonować w symbiozie. Jak lider może tworzyć takie zespoły? Co jest niezbędne po stronie zespołu? Gdzie są najważniejsze wyzwania dla tej symbiozy? To kolejne pytania istotne zarówno dla praktyki, jak i dla nauki zarządzania projektami.
Wzrost znaczenia fazy realizacji i uczenia się oraz inna rola i charakter planowania
Tradycyjne zarządzanie projektami bardzo dużą uwagę kładzie na fazę inicjowania i planowania projektu. Przykładem tego jest np. PMBOK® Guide 6th Edition, w którym na ogólną liczbę 48 procesów, aż 26 to procesy inicjowania i planowania. Planowanie z określeniem precyzyjnej struktury podziału pracy (zakresu projektu) oraz przypisaniem konkretnych dat startu i zakończenia do poszczególnych zadań projektowych jest odpowiednie dla środowiska o dużej pewności i przewidywalności, jak produkcja, czy konstrukcja.
W środowisku VUCA, charakteryzującym się zmiennością i złożonością, takie podejście nie prowadzi do zakładanych efektów biznesowych. Praktyki – zwłaszcza w środowisku projektów digitalnych, informatyczno-biznesowych – czyli środowisku zwinnym (Agile-owym) – są zupełnie inne. Zmiana podejścia do planowania dotyczy w szczególności następujących jego aspektów:
- „Filozofii planowania”,
- Planowania zakresu,
- Szacowania,
- Harmonogramowania.
Na poziomie „filozofii” planowania myślenie probabilistyczne zastępuje tradycyjne myślenie deterministyczne. Zgodnie z myśleniem probabilistycznym odpowiedź na pytanie o termin dostarczenia produktu projektu powinna brzmieć: mamy 85% szans, że produkt dostarczymy najpóźniej do dnia <data>. W środowisku VUCA po prostu nie wiemy, bez względu na to, czy jesteśmy programistą, inżynierem IT, projektantem, czy marketingowcem, ile dokładnie czasu zajmie wykonanie konkretnego zadania. Problem pogłębia dodatkowo częsta realizacja wielu zadań, zarówno projektowych, jak i zadań operacyjnych.
W świecie zmienności inaczej także wygląda praktyka planowania zakresu. Ze względu na zmienność wymagań i potrzeb klientów, zarówno bezpośrednich klientów projektu, jak i klientów firm dla których realizowane są projekty, szybkie zmiany technologii, pojawianie się nowych produktów i pomysłów biznesowych, nie jest możliwe zdefiniowanie zakresu „up front” i jego późniejsze utrzymanie. Konieczne są więc inne, bardziej zwinne techniki planowania, jak i monitorowania zakresu prac.
Największe zmiany w stosunku do tradycyjnego zarządzania projektami zachodzą w obszarze szacowania i harmonogramowania. Szacowanie zgrubne nadal jest przydatne, jednak szacowanie indywidualnych zadań jest marnotrawstwem. Takie szacowanie nie powinno być wykonywane, gdyż jak pokazuje doświadczenie:
- Nigdy nie wiemy, ile czasu zajmie wykonanie indywidualnego zadania
- Szacując prace często tworzymy nierealistyczne oczekiwania
- Do oszacowania dodajemy spory bufor, by być po „bezpiecznej stronie”.
Podobnym marnotrawstwem w środowisku VUCA jest szczegółowe harmonogramowanie poszczególnych zadań i określanie dat początkowych i końcowych ich wykonania. Szacunki czasu trwania są bowiem nieprecyzyjne, a rzeczywistość projektowa i tak ulegnie zmianie w stosunku do zbudowanego harmonogramu.
Świat VUCA wymusza inne podejście do planowania projektu oraz do jego realizacji i monitorowania. Już nie precyzyjne planowanie jest najważniejsze dla sukcesu projektu, lecz jak najszybsze uczenie się, zdobywanie nowej wiedzy i wyciąganie wniosków, zarówno z sukcesów, jak i z porażek. Monitorowanie projektu i uczenie się musi odbywać się na podstawie twardych danych, zebranych w trakcie tego konkretnego, jak i wcześniejszych projektów. Stąd coraz większe znaczenie zaczynają mieć i będą miały w przyszłości te metody zarządzania projektem, które wykorzystują konkretne mierniki do monitorowania oraz prognozowania stanu projektu. Są to zarówno mierniki wynikowe (ang. lagging indicators), jak i wyprzedzające (ang. leading indicators). Coraz większe zastosowanie będą mieć takie techniki i związane z nimi wykresy jak: diagram skumulowanego przepływu, wykres przebiegu cyklu realizacji, diagram starzenia (ang. WIP Aging); natomiast prognozowanie będzie w coraz większym stopniu wykorzystywać symulację Monte Carlo.
Zarządzanie wiedzą i zarządzanie wizualne
Odrębnym zagadnieniem, do tej pory stosunkowo rzadko uwzględnianym w świecie zarządzania projektami, jest zarządzanie wiedzą a przede wszystkim metody uczenia się, jakie mogą być zastosowane w dynamicznym środowisku przez kreatywnych pracowników wiedzy. Są to na przykład metody dotyczące analizy i doskonalenia, wykorzystywane w podejściu Lean.
Wielość i złożoność informacji, charakterystyczna dla środowiska VUCA wymaga także nieco innego podejścia do zarządzania tymi informacjami. Badania funkcjonowania mózgu wskazują, że wizualizacja informacji, ich prezentacja w sposób umożliwiający ich widoczność i niejako „stała obecność” w środowisku projektu, różnego typu wykresy, schematy, czy kolory ułatwiają zrozumienie informacji. Coraz popularniejsze, zwłaszcza w projektach realizowanych metodami zwinnymi, stają się tablice zadań, skumulowanego przepływu, wykres przebiegu cyklu realizacji, różnego typu histogramy. Wizualizacja – w spójny, zintegrowany sposób – informacji dotyczących różnych poziomów zarządzania projektem i zbiorem projektów, dotyczących:
- Szczegółowych zadań, realizowanych w poszczególnych zespołach (strumieniach) projektu,
- Integracji zadań realizowanych w kilku zespołach (strumieniach) projektowych,
- Pakietów roboczych wytwarzanych w projekcie – poziom kierownika projektu,
- Projektów składających się na program – poziom kierownika programu,
- Projektów i programów – poziom zarządzania portfelem projektów,
- Strategii celów strategicznych w powiązaniu z portfelem / portfelami, programami oraz projektami strategicznymi
ułatwia zarządzanie i podejmowanie decyzji, ogranicza, lub wręcz eliminuje raportowanie, a także stanowi czynnik angażujący ludzi w prace i zwiększa ich motywacje.
Dlatego też zarówno praktyka projektów realizowanych w środowisku VUCA, jak i nauka zarządzania projektami powinny w coraz większym stopniu wypracować, promować i stosować różne techniki wizualizacji danych i informacji. Już obecnie niektóre oferowane na rynku rozwiązania informatyczne wspierające zarządzanie projektami i portfelem projektów, takie jak np. Targetprocess, Kanbanize oparte są właśnie o wizualizację informacji. Prowadzonych jest także wiele prac badawczych dotyczących wizualizacji informacji.
Zarządzanie projektami we współczesnym środowisku VUCA znacznie różni się i będzie coraz bardziej różnić się – co do swojej praktyki, jak i „filozofii” podejścia – od tradycyjnego zarządzania projektami. Zmiany te – moim zdaniem – nie mają charakteru rewolucyjnego, lecz bardziej ewolucyjny, gdyż w gruncie rzeczy dotyczą tej samej materii i tych samych celów biznesowych. Zmiany dotyczą jednak ważnych elementów „filozofii” myślenia o projekcie oraz wielu stosowanych technik i narzędzi.
Miał więc rację Marek Aureliusz pisząc, że „Życie to zmiana, a świat to wyobrażenie”.
Część I artykułu została opublikowana w 26. wydaniu Strefy PMI: https://strefapmi.pl/strefa-wiedzy/czy-to-juz-przewrot-kopernikanski-zarzadzanie-projektami-w-swiecie-vuca-cz-i/
Konsultant i trener zarządzania i zarządzania projektami posiadający wieloletnie doświadczenie w doskonaleniu pracy firm, zespołów, menedżerów i liderów. Ekspert z ponad 25-letnim doświadczeniem w obszarze zwinnego i klasycznego zarządzania projektami, programami i portfelem projektów, zwinnego przywództwa oraz zwinnych transformacji i budowania organizacji projektowych. Wielki fan podejścia Flow Management, wykorzystującego Lean, Kanban oraz TOC, a także gier symulacyjnych. Mówi o sobie: „pomagam menedżerom, project managerom, zespołom i firmom pracować i zarządzać efektywniej, mądrzej oraz mieć z pracy i zarządzania więcej zadowolenia i satysfakcji”.