Vive la différence! Niech żyje różnorodność. To powiedzenie można swobodnie zastosować do zarządzania projektami, które w ostatnich dziesięcioleciach mocno się wzbogaciło, zarówno od strony filozofii, jak i od strony metod, technik i narzędzi. Generalnie, zarządzanie projektami uległo poważnemu odchudzeniu i przesunięciu w kierunku zwinności. Warto się jednak zastanowić co dokładnie oznacza to przesunięcie.
Różne podejścia do planowania
Dla zarządzania projektami kluczowe jest planowanie. Podejście kaskadowe charakteryzuje się wyraźnym oddzieleniem etapów planistycznych od realizacyjnych. To wynika z charakteru wytwarzanego produktu. Niektóre produkty wymagają ścisłego zaprojektowania, wraz ze wszystkimi parametrami, a następnie ścisłego wytworzenia (wybudowania) zgodnie z tymi parametrami. Projekt to pewna sekwencja działań, narzucona w istotnej części przez procesy technologiczne. Nie można budować ścian jeśli nie mamy wybudowanego fundamentu. Kolejność działań jest zobrazowana przez diagram sieciowy. Bufory są zawarte, zależnie od podejścia, w zadaniach leżących poza ścieżką krytyczną – jeżeli planujemy z wykorzystaniem ścieżki krytycznej, lub po wszystkich zadaniach – jeśli planujemy z wykorzystaniem łańcucha krytycznego. Podstawą dla planowania, po zdefiniowaniu uzasadnienia i celów projektu, jest zakres, tworzony na podstawie wymagań. Gromadzenie wymagań i przełożenie ich na zakres projektu jest często czaso- i pracochłonnym etapem projektu. Kluczowa rolą zbiorową dla projektu jest grupa sterująca (Komitet Sterujący), a indywidualną kierownik projektu.
Najbardziej rozpowszechnione podejście agile, SCRUM, zupełnie inaczej podchodzi do planowania. Redukuje w dużym stopniu planowanie przed właściwym rozwojem i skupia się na planowaniu poszczególnych iteracji (sprintów). Kluczowa jest tu rola Product Ownera, której odpowiedzialności obejmują pozyskanie i zarządzanie wymaganiami. SCRUM nie precyzuje w jaki sposób Product Owner gromadzi wymagania. Stąd etap przygotowawczy prac rozwojowych jest wyraźnie słabszy w kontekście SCRUM niż ma to miejsce w projektach kaskadowych. Wynika to w dużej mierze z charakteru produktu. Rozwiązania informatyczne wyłaniają się w trakcie, design przeplata się z wytwarzaniem, do kolejnych prac włączane są uwagi ze strony użytkowników. Jest to proces bardzo eksploracyjny, odkrywczy, którego ostateczny rezultat nie jest znany w punkcie wyjścia. Obok Product Ownera pracuje Scrum Master, którego rola jest mocno odmienna od roli Project Managera, mniej kontrolna a bardziej wspierająca i służebna. W większym stopniu usuwa on przeszkody stojące na drodze zespołu niż nadzoruje jego pracę.
Hybryda
Coraz szerszą uwagę zyskują podejścia hybrydowe. Samo słowo jest używane w szóstej wersji PMBOK® Guide. Hybrydowe zarządzanie projektem łączy elementy podejścia tradycyjnego z podejściem zwinnym, szczególnie w obszarze planowania. Projekt hybrydowy łączy bardziej kompletne planowanie, poprzedzające działania rozwojowe z iteracyjnością i przyrostowością wytwarzania produktu.
Możliwe jest zestawienie różnych podejść. PMBOK® Guide lub PRINCE2 stawiają duży nacisk na uzasadnienie projektu, cele, korzyści, zakres ściśle wypływający z wymagań, przełożony na kompletną strukturę podziału prac. Podejście hybrydowe przejmuje te składniki projektowe i łączy je z iteracyjnym wytwarzaniem. W projekcie hybrydowym obecny jest zarówno Project Manager, który obejmuje całościową oddzielność za sukces projektu, jak i lider zespołu wytwórczego, który wspomaga zespół.
Taka hybryda może wyniknąć z połączenia podejścia przewidywalnego i zwinności. Ale warto też zauważyć spójne, przetestowane metody zarządzania projektami, które łączą dobrą planistykę i zwinność. Jedną z takich metod jest Agile Project Management, oparta o Dynamic System Development Method. W tym podejściu iteracyjne i przyrostowe wytwarzanie produktu jest centralne i nie różni się właściwie od tego, co proponuje SCRUM. Natomiast wytwarzanie jest poprzedzone pracami planistycznymi i architekturalnymi, które dają bardziej kompletny ale nie ostateczny obraz produktu.
DSDM także pracuje w oparciu o inne rozumienie „trójkąta projektowego”. Podczas gdy w projekcie kaskadowym celem jest wytworzenie produktu o ściśle określonym zakresie i przyjmuje się, że czas i koszt mogą ulec zmianie, tak DSDM blokuje czas i koszt i przyjmuje, że elastyczność dotyczy zakresu. Kluczowa dla podejścia DSDM jest technika priorytetyzacji MoSCoW, która dotyczy zarówno zakresu, jak i planowania pracy w poszczególnych iteracjach. DSDM zaleca rozplanować prace w rozkładzie 60% nakładów na komponenty (cechy, funkcjonalności systemu), które muszą być (poziom Must-Have), 20% na cechy które mogłyby być (Could-Have), i pozostałe 20% na cechy, które powinny być (Should-Have). W ten sposób bufor zostaje przeniesiony z czasu na zakres projektu. W momencie gdy komponenty, które muszą być, zajmują więcej czasu niż planowano to rezygnujemy z cech, które mogłyby być. W momencie gdy nadal prace nad poziomem Must-Have trwają więcej niż planowano, to rezygnujemy z cech, które powinny być. Czas i koszt zaplanowany jest chroniony i dopiero gdy prace nad poziomem Must-Have przekroczą planowany czas, zmieni się cały trójkąt i konieczne będzie przeplanowanie całego projektu, w tym dodanie jednej lub kilku iteracji.
Priorytetyzacja MoSCoW jest wykorzystywana także do planowania każdej iteracji, z tym, że podczas gdy zastosowanie tej techniki do definiowania zakresu całego projektu wymaga zaangażowania szerszego grona interesariuszy, planowanie iteracji pozostaje na poziomie zespołu deweloperskiego. Tenże podejmuje decyzje, które cechy muszą powstać w danej iteracji, które powinny powstać, a które mogłyby powstać.
W tym miejscu pojawia się kluczowy element podejścia DSDM. Zgodnie z filozofią zwinności, konieczne jest głębokie zaangażowanie szerokiego grona interesariuszy. DSDM jest bardzo precyzyjny co do sposobów, w jakie to zaangażowanie może być zapewnione. Kluczową techniką w DSDM są warsztaty facylitowane, a kluczową rolą procesową jest facylitator. Warsztaty facylitowane mogą być zaplanowane na różnych etapach projektu, są one szczególnie przydatne na etapie tworzenia architektury systemu, a następnie priorytetyzacji jego funkcjonalności i cech. Inne miejsca to ocena wykonalności projektu, analiza ryzyka, estymacje, przeglądy i retrospektywy.
Warsztaty facylitowane mają swoją historię w kontekście projektowym. PMBOK® Guide w każdej kolejnej wersji coraz szerzej wskazuje ich zastosowania. Jedną z wczesnych formuł warsztatowych były wypracowane przez IBM w latach dziewięćdziesiątych sesje Joint Application Development (JAD). Były to ustrukturyzowane spotkania interesariuszy, użytkowników, projektantów, deweloperów, którzy razem projektowali architekturę rozwiązania, konfigurację funkcjonalności oraz interface. Warsztaty facylitowane, proponowane przez DSDM/Agile PM, są zakorzenione w tej dobrej tradycji współpracy, która nie jest hasłem a przybiera bardzo konkretny format i strukturę.
Wybór skrzynki z narzędziami
Niezależnie od podejścia, z których kilka zostało zarysowanych powyżej, planowanie projektu nie jest pracą przy papierze lub przy komputerze, a jest bardzo angażującym etapem projektu, który wymaga zaangażowania różnych interesariuszy. Filozofia agile podkreśla to zaangażowanie, ale nie można się zgodzić, że było ono nieobecne w projektach zarządzanych tradycyjnie. Kluczowe jest odpowiednie dobranie skali i sposobu planowania. W Altkom Akademii jesteśmy przekonani, że o tym wyborze powinno decydować racjonalne spojrzenie na projekt i produkt bardziej niż miejscami dogmatyczne przekonania o wyższości jednej metody nad drugą.
Group facilitator, consultant, project manager, project management trainer. Holder of Green Project Management (b) certificate, accredited Green Project Management Consultant and Assessor. Designs and conducts workshops, including those related to strategy, portfolio, programs and projects, including project impact analysis and sustainability. Doctor of Social Sciences, university lecturer in Project Management. Graduate of the University of Leuven in Belgium. Owner at wefacilitate.eu