Od dłuższego czasu intryguje mnie następująca kwestia zarządzania projektem: definiujemy projekt, jako unikalne doświadczenie, przedsięwzięcie, ale jednocześnie w odniesieniu do tych unikalnych doświadczeń stosujemy jednolite podejście do zarządzania tymi różnymi projektami. Standard PMBOK®Guide, a także IPMA Competence Baseline, czy metodyka PRINCE2®, wszystkie te źródła w zasadzie mówią o jednolitym podejściu do zarządzania jakże różnymi projektami. A przecież logika i zdrowy rozsądek podpowiadają, że do unikalnych doświadczeń, warto by zastosować zróżnicowane podejścia.
W parze z tym zdrowym rozsądkiem idą także moje praktyczne doświadczenia z tymi różnymi projektami. W swojej karierze doświadczyłem bowiem i takich projektów, gdzie podejście standardu PMBOK®Guide, czy metodyki PRINCE2 sprawdza się doskonale. Mamy zdefiniowane cele, wiemy co powinno powstać w projekcie (jakie produkty o jakich parametrach) i … jedziemy.
Moje doświadczenia z branży IT oraz branży inżynierskiej (np. projektowanie różnych wyrobów, ich części i modułów, lub całych rozwiązań) wskazują, że to w/w tradycyjne podejście nie do końca się sprawdza i nie w pełni pasuje z punktu widzenia zarządzania projektem z tych branż. O ile bowiem cel w tego typu projektach można stosunkowo łatwo zdefiniować, to już z produktami, czyli rozwiązaniem jakie winno być dostarczone wcale nie jest tak prosto. Weźmy choćby taki produkt, jakim jest system wspomagający zarządzanie przedsiębiorstwem (zarówno powstający wg standardu, jak SAP, jak i ten pisany „na miarę”): przecież tak naprawdę szczegółowe rozwiązanie nie jest znane, ani na początku projektu, ani w trakcie planowania. W praktyce powstaje ono często metodą "prób i błędów", metodą wielu iteracji.
I jeszcze inny przykład, z jakim miałem do czynienia (prowadząc szkolenia, konsultacje, a także uczestnicząc jako wykładowca w Studiach podyplomowych "Zarządzanie projektem badawczym") w ciągu ostatnich 2 lat: - projekty naukowo-badawcze. Tu sytuacja często jest jeszcze bardziej skomplikowana: często bowiem na początku projektu nie można precyzyjnie określić ani jego celu, ani też produktu, czy inaczej mówiąc powstającego rozwiązania. Dopiero zdobyte w trakcie projektu doświadczenia oraz dokonane odkrycia dotyczące rozwiązania mogą doprowadzić do powstania produktu, czasem zupełnie innego, niż pierwotnie zakładany.
Jak widać z powyższego krótkiego opisu mamy w praktyce trzy różne typy projektów, a jeśli będziemy się trzymać standardów i podejść istniejących w świecie zarządzania projektami, to będziemy stosowali takie samo, lub bardzo zbliżone podejście. Przecież to chyba droga na manowce – czy zgodzilibyście się z tym stwierdzeniem?
Jakże więc ucieszyłem się, gdy w książce Roberta K.Wysockiego "Effective Project Management – Traditional, Agile, Extreme", fifth Edition (Wiley Publishing, Inc. 2009) natrafiłem w jej drugiej części na analogiczne, choć nieco bardziej pogłębione rozważania na ten właśnie temat. Opierając się na swoich ponad 30-letnich doświadczeniach, w tym na ocenie częstości występowania różnych typów projektów R.Wysocki buduje własną typologię projektów i związane z nią różne podejścia do zarządzania projektem (nazywane przez niego krajobrazem – ang. landscape). Podstawą jego typologii projektów i podejść do zarządzania projektami są dwa następujące parametry:
• Cel projektu, a w zasadzie możliwość jego precyzyjnego zdefiniowania
• Rozwiązanie (jakie ma powstać w projekcie), a w zasadzie stopień jego precyzyjnego zdefiniowania na początku projektu (na etapie planowania).
W wyniku połączenia obu tych parametrów powstaje następująca macierz i następujące podejścia do zarządzania projektami:
1. TPM: Tradycyjne zarządzanie projektem
2. APM: Agile project management (podejście „zwinne”)
3. xPM: Extreme project management – ekstremalne zarządzanie projektem
4. MPx: Emertxe project management – odwrotność XPM (dosłownie extreme pisane wspak).
Ta typologia zarządzania projektami odpowiada moim przemyśleniom, przestawionym na początku niniejszego tekstu, rozszerzonym o typ czwarty!
Dodatkowo R.Wysocki wyróżnia jeszcze pod-typy zarządzania projektem:
• W ramach TPM: podejście liniowe i przyrostowe (ang. lineal i incremental)
• W ramach APM: podejście iteracyjne i adaptacyjne.
Główne różnice pomiędzy tymi podejściami związane są z odmiennym modelem cyklu życia zarządzania projektem, obejmującym poszczególne fazy zarządzania projektem, w szczególności odmiennym zakresem tych faz oraz ich iteracyjnością.
Coś w tym jest? Zainteresowaliście się przedstawionymi podejściami?
O szczegółach: w tym o różnicach między tymi podejściami, konsekwencjami dla ZP opowiem jednak już w kolejnym tekście.