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 (SZP - https://www.jsproject.pl/blog/projekty/900-zarzadzanie-projektami-vuca-szp ) 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, 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 develoment). 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 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ć – jak to napisałem wcześniej – 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.
To tyle o roli kierownika projektu i zespołu. Kolejny tekst cyklu będzie dotyczył wzrostu znaczenia fazy realizacji i uczenia się oraz innej roli i charakteru planowania.
