W zarządzaniu projektami kluczowe jest planowanie. Podejście kaskadowe charakteryzuje się wyraźnym oddzieleniem etapów planistycznych od realizacyjnych. Wynika to 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ń, podporządkowana w istotnej części procesom technologicznym. Nie można budować ścian jeśli nie mamy wybudowanego fundamentu. Kolejność działań jest zobrazowana przez diagram sieciowy. Bufory mogą być zawarte w zadaniach leżących poza ścieżką krytyczną – jeżeli planujemy z wykorzystaniem ścieżki krytycznej, lub po wszystkich zdaniach – jeśli planujemy z wykorzystaniem łańcucha krytycznego. Po zdefiniowaniu uzasadnienia i celów projektu, podstawą w planowaniu jest zakres, który tworzony jest  na podstawie wymagań. Zgromadzanie wymagań i przełożenie ich na zakres projektu jest często czaso- i praco-chłonnym etapem projektu. Kluczowa rolą zbiorową dla projektu jest grupa sterująca – Komitet Sterujący, a indywidualną – Project Manager.

Najbardziej rozpowszechnione podejście zwinne – czyli 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óra obejmuje pozyskanie i zarządzanie wymaganiami. SCRUM nie precyzuje w jaki sposób Product Owner to robi. Stąd etap przygotowawczy prac rozwojowych w SCRUM nie jest tak „wyraźny” jak ma to miejsce w podejściu kaskadowym. Ma to również związek z charakterem produktu, jakim są rozwiązania informatyczne, których kształt wyłania się w trakcie prac, do kolejnych etapów włączane są uwagi ze strony użytkowników a design przeplata z wytwarzaniem. Jest to proces bardzo eksploracyjny, odkrywczy, którego ostateczny rezultat nie jest znany w punkcie startowym. Obok Product Ownera pracuje Scrum Master, którego rola w odróżnieniu od roli Project Managera, jest mniej kontrolująca 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 kaskadowego 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 ścisłe zestawienie różnych technik kaskadowych z technikami zwinnymi. I tak, podejścia kaskadowe takie jak 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ą odpowiedzialność za sukces projektu oraz lider zespołu wytwórczego, który wspiera zespół.

Taka hybryda może wyniknąć z połączenia kaskady i zwinności. Warto też zwrócić uwagę na inne spójne, przetestowane metody zarządzania projektami, które łączą dobrą planistykę i zwinność. Jedną  z takich metod jest Agile Project Management, oparty o Dynamic System Developement 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 priorytetyzcji 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 w momencie 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 facylitowanego mają swoją historię w kontekście projektowym, zarówno kaskadowym jak i zwinnym. 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 Design (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 interfejs. 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 współpracy różnych interesariuszy. Filozofia agile podkreśla to zaangażowanie, ale nie można się zgodzić, że było ono nieobecne w projektach kaskadowych. Kluczowe jest odpowiednie dobranie skali i sposobu planowania. W Altkom Akademii jesteśmy przekonani, że o takim wyborze powinno decydować racjonalne spojrzenie na projekt i produkt bardziej niż miejscami dogmatyczne przekonania o wyższości jednej metody nad drugą.