W poprzednim numerze Strefy PMI miałem okazję przedstawić założenia hybrydowego zarządzania projektami. Tym razem chciałbym się skupić na powodach, dla których firmy będą wybierać to podejście, a w praktyce już dawno wybierają, jedynie nie nazywają go w ten sposób.


Przykładem projektu, który skorzystał z hybrydowego zarządzania projektami, jest wprowadzenie nowego systemu planowania produkcji w pewnej firmie. Celem projektu było usprawnienie procesów zamówień materiałów, planowania produkcji oraz planowania dystrybucji towarów. Przedsięwzięcie rozpoczęło się nietypowo ponieważ stwierdzono, że skoro w firmie działają już różne systemy planowania produkcji, dlatego należy je po prostu połączyć i zintegrować w jedno rozwiązanie. Zdecydowano, że odpowiedzialni za aktualnie działające rozwiązania programiści będę liderami przygotowania poszczególnych nowych modułów, a integracja między obszarami zostanie zapewniona poprzez wspólne struktury danych. Na poziomie całego projektu mieli ich wspierać analitycy oraz główny architekt rozwiązania. Ponieważ było to „tylko przepisanie” istniejących systemów do planowania produkcji, stwierdzono, że „rozpoznanie bojem”, a tym samym rozpoczęcie prac nad nowymi modułami będzie najlepszym rozwiązaniem dla projektu. Założono, że użytkownicy systemu nie będą musieli od razu przygotować całościowych wymagań, a jedynie na każde spotkanie z liderem obszaru będą zgłaszać kolejne priorytety do realizacji. Takie podejście wydawało się optymalne: szybki start realizacji projektu, zastosowanie prototypowania oraz ciągła współpraca z odbiorcami pokaże od razu pierwsze efekty dla organizacji.

Wyzwania

Kolejne tygodnie pokazały jednak pewne wyzwania związane z taką organizacją pracy: brak synchronizacji prac pomiędzy zespołami/modułami oraz brak zastosowania optymalnych rozwiązań do projektu. W pierwszym przypadku głównym wyzwaniem okazała się praca nad strukturą danych, gdzie różne zespoły nadpisywały sobie efekty swoich prac oraz czasami dublowały struktury zakładając oddzielnie elementy dedykowane do siebie (w tym czasie były one już przygotowane przez inny zespół). Z kolei prace główne nad potrzebami właściciela biznesowego nie umożliwiały dłuższego planowania optymalnych rozwiązań dla projektu. Można to porównać do wyboru kierunku jazdy: wspólna podróż samochodem – wyznaczanie kolejnych miast w kierunku docelowej lokalizacji jest świetną formą współpracy i zaangażowania obu stron, ale gdybyście znali docelową lokalizację, to mogłoby się okazać, że następnym razem lepiej wybrać pociąg jako środek transportu.

Powyższe wyzwania na pewno zostałyby z czasem usprawnione w projekcie i nie trzeba byłoby zmieniać podejścia do realizacji, gdyby nie dwa kolejne elementy. Pierwszym okazał się Komitet Sterujący projektu, który widząc kolejne „przepalane” na projekt tygodnie zaczął pytać na kiedy będzie gotowy i dlaczego to tak długo trwa? I tutaj zaczął się problem. Jak mamy ocenić status projektu i w ogóle przygotować i zweryfikować prognozy na jego terminy zakończenia, w momencie kiedy my nawet nie wiemy, co będziemy realizować w kolejnym sprincie? Kolejny aspekt to ocena skali przedsięwzięcia. Okazało się, że skala prac do realizacji rośnie, a analiza zakresu projektu (zrobiona w jego trakcie) pokazała, że oprócz modułów jest jeszcze wiele innych obszarów do realizacji (na przykład interfejsy do innych systemów produkcyjnych oraz do systemów finansowych przedsiębiorstwa). Dodatkowo okazało się, że niektórych z w/w elementów nie ma sensu robić zwinnie, ponieważ jest to zakres do realizacji w tradycyjnym podejściu.

Fot. Daniel Krasoń – stock.adobe.com

Rozwiązanie – w kierunku hybrydy

Co w takiej sytuacji powinniśmy zrobić? Oczywiście wrócić do początku projektu, doprecyzować cele przedsięwzięcia, zebrać wymagania, określić plan projektu. Ale pojawiło się pytanie, czy będzie to efektywne, jeżeli projekt ma już 4 miesiące realizacji i nie za bardzo jest miejsce na jego wstrzymanie lub powracanie do podstaw.

Gdybym ja prowadził ten projekt od początku, na pewno pierwszym krokiem byłoby zdefiniowanie celów projektu oraz stworzenie tradycyjnego planu projektu. Określone (nawet zgrubnie) wymagania pozwoliłyby nie tylko zwymiarować projekt, ale również wybrać najlepszy model realizacji przedsięwzięcia.

Tutaj jednak nie było czasu na powrót do startu projektu, dlatego zdecydowano się na zastosowanie hybrydowego podejścia do realizacji projektu. Po pierwsze został doprecyzowany na głównym poziomie zakres projektu oraz zdecydowano, które elementy zakresu projektu powinny być realizowane tradycyjnie, a które zwinnie.

Zdecydowano, że budżet i pracochłonność projektu oraz harmonogram będę pilnowane całościowo z prognozowaniem ostatecznych parametrów. Na poziomie zespołu zastosowano elementy agile, takie jak sprinty, wykresy spalania w celu pilnowania backlogu i pozostałej pracochłonności danego modułu. Na podstawie specyfiki zakresu technicznego ustalono, że miesięczne sprinty będą najbardziej optymalnym rozwiązaniem – nastąpi odpowiedni podział czasu poświęconego na pracę, planowanie i prezentowanie rozwiązań. Ciągła praca nad najważniejszymi funkcjonalnościami modułów pozwoliła na koncentrację zespołu na kluczowych aspektach projektu. Codzienne spotkania z omówieniem statusu prac i problemów dawały również kluczowe informacje dla kierownika projektu do pilnowania „tradycyjnej” części projektu.

Korzyści z łączenia podejść

Efekty integracji dwóch światów można było zobaczyć w ciekawej sytuacji, która miała miejsce w projekcie. Komitet Sterujący zadał w krótkim odstępie czasu dwa pytania: „Kiedy będziecie gotowi z wejściem produkcyjnym?” oraz „Kiedy zakończycie projekt?”. Dla niektórych osób z organizacji było to to samo pytanie, ale przy zastosowaniu hybrydowego podejścia zespół był w stanie odpowiedzieć zarówno na pierwsze pytanie, czyli jakie są jeszcze kluczowe funkcjonalności z backlogu, bez których uruchomienie nie będzie możliwe lub nie będzie stanowiło wartości dla firmy oraz na drugie pytanie, kiedy projekt się zakończy zakładając realizację aktualnych wymagań z backlogu. Odpowiedź na pierwsze pytania wynosiła 3 miesiące, odpowiedź na drugie 9 miesięcy i… długo trzeba było wyjaśniać niektórym interesariuszom skąd ta różnica.

Przedstawiony przykład nie ma oczywiście świadczyć, że hybrydowego zarządzania projektami mamy używać tylko do ratowania problematycznych zwinnych lub tradycyjnych projektów. Wnioski z tego przykładu wskazują na korzyści płynące z hybrydowego zarządzania projektami: połączenie elementów tradycyjnego zarządzania projektami z elastycznymi metodykami agile pozwala na dostosowanie się do zmieniających się oczekiwań odbiorców, zwiększenie efektywności działań i lepszą kontrolę nad projektem. Jednocześnie zaangażowanie interesariuszy, takich jak klienci czy członkowie zespołu, jest kluczowe dla osiągnięcia sukcesu przedsięwzięcia. Celem naszym w tym podejściu jest ustawienie projektu od początku optymalnie ze względu na jego specyfikę i oczekiwania odbiorców. I właśnie te oczekiwania powodują, że hybrydowe podejście będzie stosowane w organizacjach. Z jednej strony zespół projektowy bardzo często chce i nawet oczekuje zwinnego podejścia do realizacji przedsięwzięcia, a z drugiej strony Zarządy, Dyrekcja, Komitety Sterujące cały czas potrzebują danych do podejmowania decyzji o uruchomieniu, wstrzymaniu czy wręcz reagowaniu na status projektu. Hybrydowe podejście pozwoli nam połączyć te oczekiwania w jednym przedsięwzięciu.