Hybridní řízení projektů – budoucnost nebo chiméra?

| Jan Doležal

hybridní projektové řízení

Co je to hybridní řízení projektů? Jedná se v podstatě o jeden z výsledků diskuze, zdali řídit projekty a vývoj konvenčně (vodopádově) nebo některým z agilních přístupů. Někteří jsou přesvědčeni, že je optimální oba přístupy kombinovat a používat současně. Velkým propagátorem tohoto smíšeného přístupu je David R. Robins, který o tom publikuje články a dal dohromady dokonce i Hybrid project management manifesto a také sw nástroj na podporu tohoto způsobu řízení.

Existuje už jen málo fanatických pravověrců, kteří by tvrdili že prediktivní nebo agilní přístup je ten jediný vhodný vždy, všude a za všech okolností. Většina lidí s praktickými zkušenostmi dobře ví, že prediktivní způsob řízení projektů má své místo a je v určitém kontextu nejlepší řešení. A na druhé straně, je jasné, že jsou kontexty a zadání, kdy je nejlepší postupovat agilně. Hybridní přístup se snaží využít výhody obou přínosů, nicméně vtírá se pochybnost, aby při tomto řešení ala „chytrá horákyně“ nedošlo k „vylití vaničky i s dítětem“.

Hybridní řízení projektů – definice podle D. R. Robinse

Jakožto pojem není hybridní PM zatím definován v žádném z hlavních PM standardů (pokud je mi známo). Nicméně, pokud budeme vycházet ze zřejmě nejcitovanějších pramenů od D. R. Robinse, tak hybridní projektový management kombinuje formální a agilní metody. Využívá důkladnost WBS s rychlostí a štíhlostí agilu.

Klíčové principy

  1. Hybridní projekt je řízen projektovým manažerem s použitím WBS. PM má celkovou odpovědnost za projekt.
  2. Scrum Masteři podporují projektového manažera během realizace každého sprintu.
  3. Pro průběžné reportování, analýzu a kontrolu managementu je nutná nepřetržitá týmová spolupráce.

Role a zodpovědnosti

  • Hybridní projekt je nezávislý na struktuře řízení a nepotřebuje nějaký další řídící prvek, jako např. Project management office. PMO přidává další vrstvu byrokracie, způsobuje zpoždění a výdaje a není kompatibilní s Agilem.
  • Projektový manažer přebírá roli produktového manažera. V metodě hybridního řízení projektů je pouze projektový manažer nebo produktový manažer. Je považován za vlastníka projektu. Pozn.: A plní tedy zřejmě i roli sponzora.
  • Manažer projektu a Scrum masteři sdílejí přímou odpovědnost za různé segmenty projektu.
  • Projektový manažer nese celkovou odpovědnost za projekt.
  • Projektový manažer se primárně zabývá front-endem toku projektu (požadavky na produkt, zpětná vazba od zákazníka, definice komponent a WBS).
  • Scrum Masteři jsou zodpovědní za backend toku projektu (nevyřízené položky, sprinty a vydání).
  • Projektový manažer vytváří tým konzistentní se Scum Mastery a dalšími vedoucími pracovníky (pokud je to potřeba).
  • Každý Scrum Master staví svůj tým na základě požadavků a časového rámce pro dodání.

Proces hybridního řízení projektů

V příslušném manifestu je uveden i schématický náčrt průběhu „hybridu“ (zdroj – https://www.binfire.com/hybrid-project-management-manifesto/):

Hybridní projektové řízení

Definice pojmů

  • Komponenty: Jednotlivé stavební moduly vycházejí z dokumentu s požadavky na produkt. Například mobilní telefon má elektroniku, displej, WIFI a softwarové komponenty. Softwarový produkt může mít uživatelské rozhraní, obchodní logiku a komunikační komponenty. Požadavky na produkt určují, které komponenty jsou v projektu potřebné.
  • Trať: Cesta pro vývoj a vydání každé komponenty. Některé tratě mohou být kratší nebo delší než jiné.
  • Backlog: Seznam úkolů pro jednotlivé komponenty. Úkoly pro každý sprint jsou odvozeny z backlogu stejné trati. Backlog upravuje jak manažer projektu, tak srum masteři.
  • Sprint: Vývojové úsilí trvající 4 až 8 týdnů. Každý sprint zahrnuje vývoj, testování a vydání (nasazení). Každá trať má svůj vlastní backlog a sprinty. Sprinty z různých tratí probíhají paralelně. Výstup každého sprintu z různých tratí se může nebo nemusí kombinovat se sprinty z jiných tratí.
  • Projektový tým: Každý projektový tým je složen z vyhrazených členů týmu. Základní členové jsou 100% přiřazeni k projektu a nedochází ke sdílení zdrojů napříč více projekty. Členové týmu zodpovídají scrum masterům za každodenní vývojové úsilí.

Hybridní řízení projektů podle Robinse má své mouchy

Celkově dané myšlenky a principy dávají určitý smysl. Lze si to vlastně představit jako postup, kdy je projekt na vyšších úrovních detailu plánován a řízen konvenčně, zatímco vlastní výroba a vývoj probíhá agilně v iteracích. Takže na úrovni PM vzniká rámcová WBS, roadmapy a rozpočty, zatímco týmy operují na takticko-operativní úrovni. To si ještě dokážu představit a do jisté míry jsem něco takového i viděl fungovat.

Vkrádají se však určitá, mnohá ALE. V Robinsově pojetí je SCRUM Master spíše manažer týmu – zodpovídá za realizaci sprintu a jeho výsledky. V jeho manifestu se doslova píše: „In Hybrid the Project Manager is assigned the overall project ownership, and the individual Scrum Master is responsible for executing Sprint. Nebo: „Project Manager develops WBS with help of Scrum Masters. Scrum Master perform Task Assignment for each sprint.

To ale není to, jak je role SCRUM Mastera myšlena. Není tu nic o zodpovědnosti týmu a jeho sebeorganizaci. Nebo o hodnotě. Celé to tak trošku zavání temným scrumem, kdy jsou z agilního světa převzaty některé postupy a nástroje, ale mindset, přístup a filozofie, zůstaly v prediktivním světě.

V hybridním manifestu jsou i velmi pozitivní body, jako např. pasáž ohledně definice projektového týmu: Každý projektový tým je složen z vyhrazených členů týmu. Základní členové jsou 100% přiřazeni na projekt a nedochází ke sdílení zdrojů napříč více projekty. To je skvělé, tak to má být. Ovšem hned následující věta je z hlediska SCRUMU katastrofální: Členové týmu zodpovídají SCRUM Masterovi za každodenní vývojové úsilí.

Další problém vidím v získávání zpětné vazby na úrovni teamů. Z obrázků i popisu to vypadá, že je zpětná vazba poskytovaná na celý release, primárně zřejmě osobě projektového manažera, který to tlumočí dál do projektu. Riziko tiché pošty je zde velké. Stejně jako vzdálenost týmů od zákazníka. A také se získává jen jednou za dlouhé období. To není pro agile dobře.

Je tedy zřejmé, že i principy a filosofie jsou v daném pojetí hybridního řízení projektů určitým hybridem. Kombinujícím iterace a prvky jako stabilní týmy s hierarchickým reportováním a rozdělováním práce.

Je takový hybrid vlastně hybrid?

Když nad tím přemýšlím, ptám se sám sebe – a kde je v tom vlastně ten agile? Sprinty trvající 4 až 8 týdnů? Vždyť vlastně, kdybychom si nastavili při „standardním pojetí“ plán řízení projektu tak, že:

  • je PM a pak garanti jednotlivých výstupů (či manažeři podprojektů),
  • PM určuje master WBS, kde jsou dány klíčové výstupy a jejich požadované parametry,
  • garanti výstupů pak vytváří detailní plány pro své výstupy,
  • garanti výstupů mají 100% alokované klíčové členy svých týmů, kteří disponují dostatečnými dovednostmi pro realizaci dané části projektu,
  • realizace projektu je členěna na etapy s dobou trvání 2 měsíce,
  • detailně se plánuje vždy na jednu etapu dopředu (rolling wave planning), s využitím techniku user stories a týmového kanbanu s úkoly,
  • na konci každé etapy by měla být zjištěna zpětná vazba od zákazníka a podle té je upraven plán následné etapy,
  • základní reportovací cyklus je na celém projektu stejný a je to jeden či dva týdny,

tak máme vlastně to samé, co je popsáno jako hybridní projektové řízení. Tedy, pokud teamleaderům budeme říkat Scrum masteři.

Může hybridní řízení projektů přesto fungovat?

Dejme tomu, že se to snad ztratilo někde mezi řádky či v překladu a předpokládejme, že na úrovni Scrum Masterů a jejich týmů budeme SCRUM dělat správně. Tedy, že si nastavíme:

  • krátké sprinty (1 až 2 týdny),
  • zpětnou vazbu napřímo pro týmy,
  • scrum mastera jako servant leadera sebeorganizovaného týmu,
  • tým zodpovědný za své výsledky,
  • projektového manažera jako product ownera.

Pak by mohla daná filosofie fungovat s tím, že „klasická PM část“ řeší to, co SCRUM jako takový neřeší – a to dlouhodobý záměr a celkové cíle. PM pak řeší jakýsi hlavní jízdní řád (třeba formou roadmapy, master WBS atd.), politiku ve firmě, vztahy se zainteresovanými stranami, marketing projektu, globální rizika atd. V rámci výkonu role Product Ownera sem spadá i plánování releasů, zodpovědnost za návratnost vynaložených prostředků a další věci, pro které lze klidně využít některé metody a postupy klasického PM.

Pokud by se jednalo o rozsáhlejší projekt s více „vlákny“, které řeší dílčí týmy, dalo by se hovořit i o určitém způsobu škálování agilu. Nebo o realizaci projektu s podprojekty či programu. Záleží na úhlu pohledu.

Když si u toho pohlídáme respekt k univerzálním agilním principům, můžeme klidně experimentovat a hledat podobné fúzní a hybridní formy. A když to nebude fungovat, tak to při další retrospektivě změnit.

To je to, co je na agilitě krásné. Zkoušet nové věci a formy a nenechat se svazovat jedním konkrétním rámcem. Každá organizace je jiná, každý tým je jiný a jedna cesta nebude sedět všem. Hledejme tu svou.

O autorovi článku

Jan Doležal

Jan Doležal

V současné době se zabývá především agilitou v organizacích, Managementem 3.0 a vývojem simulačních her sloužících jako trénink projektového řízení, včetně Agile.

Dříve mimo jiné zastával pozici vedoucího projektové kanceláře a řídil velké mezinárodní projekty (Evropa, Jižní Amerika).

Má zkušenosti především s projekty z IT, strojírenství nebo elektrotechniky. Projektovému řízení se aktivně věnuje od roku 2001. Disponuje certifikací PMI PMP, IPMA B a CSPO – Certified SCRUM Product Owner a A-CSM – Advanced Certified SCRUM Master od SCRUM Alliance. Další podrobnosti čtěte zde.

Další zdroje informací

Komentáře (0)

Zatím žádný komentář.

Přidejte váš komentář

Vaše e-mailová adresa nebude zveřejněna. Pole označená hvězdičkou (*) jsou povinná.