Projektový manažer v roce 2020 – výzvy i příležitosti

Kdo je projektový manažer v roce 2020? Co dělá a co by měl umět? Jak moc se daná profese či role posunula?

„Klasické“ projektové řízení spočívalo především v tvorbě plánů a postupů pro dosažení cíle projektu a následné koordinaci členů projektového týmu v mezích daných plánů. Většina standardů projektového řízení, jako IPMA ICB či PMI PM BoK nebo i metodika PRINCE2 popisovaly procesy, metody a techniky tvorby takových plánů a následné sledování průběhu projektu. Respektive plnění těchto plánů. Certifikace podle těchto standardů pak byly plné otázek a příkladů na příslušné metody. Jako je CPM (metoda kritické cesty), EVM, WBS, analýza rizik a další, především tzv. tvrdé metody a techniky pracující s čísly. Především IPMA pak byla inovativní v zahrnutí i tzv. behaviorálních kompetencí. Měkkých dovedností, potřebných pro úspěch manažera (což se pak okolo roku 2015 silně objevilo i v PMI PM BoK, který do té doby řešil tyto aspekty spíše mezi řádky).

V posledních verzích daných standardů (a také zkoušek podle nich) se však děje poměrně velké zemětřesení reflektující posun celého oboru. A také toho, co je projektový manažer, respektive, jakými dovednostmi by měl oplývat. Kdo, či co je role projektový manažer v roce 2020?

V jakém prostředí se formoval „klasický“ projektový manažer

První iterace standardizace profese projektových manažerů (a samozřejmě i manažerek) probíhaly již v 60. letech 20. století. Jako první vznikla organizace IPMA – International project management asociation, založená roku 1965 pod názvem Internet (tento název se později dostal do jistého konfliktu a byl roku 1996 změněn).  Předmětem zájmu byly tehdy především velké stavebně-investiční nebo strojírenské projekty, na kterých spolupracovaly firmy z různých zemí postupně se propojující Evropy. Někdy více byznys, jindy politika, ale ve více a více případech spolupracující týmy z rzůných zemí. A to si vyžadovalo zavést určitou úroveň standardizace. Certifikovat projektové manažery začala IPMA v roce 1998.

V roce 1969 byl USA založen Project Management Institute (PMI). Zaměřoval se na projekty ve stavebnictví a také vojenském průmyslu (aerospace, defence a další oblasti). Standard PM BoK byl poprvé vydán roku 1996.

V roce 1989 byla vytvořena metodika PRINCE (PROMPT II IN the CCTA Environment, později PRojects IN Controlled Environments), jakožto standard britské vlády pro IT projekty. Od roku 1996 jako PRINCE2. Tedy ano – strojařům a stavařům se do toho začaly míchat i ajťáci…

Společné faktory

Všechna tři hlavní certifikační schémata projektových manažerů tedy vznikla v prostředí, ve kterém probíhaly rozsáhlé investice a projektové týmy čítaly mnoho lidí. A velmi často se pracovalo s nějakou státní organizací. Z toho také logicky vyplývá zaměření na jasně definované cíle, předem určený rozsah plnění, harmonogram a rozpočet – trojimperativ projektu. Úkolem, kterého se měl projektový manažer zhostit, bylo vytvoření sofistikovaných, podrobných plánů a následně řízení týmu k jejich realizaci. S tak málo odchylkami, jak jen bylo možné. Daná forma přístupu k řešení projektu se začala v IT světě označovat jako vodopád (návrh – analýza – vývoj – testování – nasazení).

Vzhledem k „tempu“ dané doby to docela dobře fungovalo. I na výrobu samotných plánů byly měsíce, i roky času. Stejně jako na realizaci. A během této doby se obvykle nic zásadního nezměnilo.

Taková doba už je ale (bohužel / bohudík) pryč.

A mimochodem, minimálně v oblasti produktového vývoje nám začala již v osmdesátých letech vznikat i trošku jiná hra, která se po roce 2000 rozšířila jako SCRUM.

Projektový manažer v roce 2020

Jak zmiňuje i koncept CYNEFIN (o kterém jsme psali zde), současnost není ve všech ohledech jiná. Pokud je třeba postavit most z jedné strany údolí na druhou, pořád velmi dobře, respektive nejlépe, funguje postup vyvíjený již od 60. let minulého století. Tedy, že nejprve je stavba zaměřena, pak ji někdo navrhne a spočítá, pak se vytvoří realizační plán a následně se jde na věc. V takových případech to prostě pořád dává největší smysl. Údolí se nám zřejmě z měsíce na měsíc dramaticky nezmění a není také zřejmě dobrý nápad začít stavět most, o kterém bych nevěděl, jak má vypadat. I řada dalších aktivit a změn je prostě svým charakterem takto lineární, vodopádovitá.

Třeba i turné nějaké kapely po světě má prostě svůj jízdní řád a každá změna či výraznější odchylka by hodně bolela. Vzpomínám na dokument o Rolling Stones, kde se pódium na daném místě turné začínalo budovat asi 2 měsíce před koncertem a byla perfektně sladěná logistika všeho možného. Musela být, jinak by třeba na koncertě chyběla světla. Takže prediktivní způsob plánování má stále v určitém kontextu své místo a smysl.

Proč tedy něco měnit?

Situací a prostředí, kde máme takový luxus, že známe podobu výsledku a můžeme se spolehnout, že po dobu, co jej budeme popisovat a následně realizovat, se nám prostředí významně nepromění, znatelně ubylo. Svět se stal z celkem predikovatelného světem VUCA (Volatility, Uncertainty, Complexity and Ambiguity, tedy kolísavý, nejistý, složitý a dvojznačný či mnohoznačný). Dějí se výrazné a rychlé změny, které jsou často způsobovány exponenciálním růstem technologií. Vývojové cykly se zkracují na zlomky původních dob trvání. Určitý zlom nastal v tomto ohledu okolo roku 2015, s výrazným nástupem cloudových služeb. Najednou jste pro poskytování pokročilých aplikací nepotřebovali vlastní drahý HW a obsluhující personál. Stačilo si koupit potřebnou kapacitu někde… Více o těchto změnách píšeme zde.

Představa, že budeme dnes třeba rok analyzovat nějaký informační systém, abychom jej pak další dva až tři roky implementovali, tak, jak byl na počátku vymyšlen, začíná být absurdní. Vždyť za čtyři roky lze očekávat zcela jinou situaci.

A není to jen o IT technologiích a SW, byť tam už je to jasné delší dobu (v roce 1995 byla publikována první formální verze SCRUM procesu).

Nejistota výsledků a proměnlivost prostředí roste téměř všude. Krom IT se můžeme zcela jistě bavit o marketingových projektech, HR projektech, organizačních projektech, transformacích a změnách, atd. Vlastně krom investiční výstavby asi všude… a i v té výstavbě různé BIM techniky, 3D modelování atd. významně urychlují doby realizace.

Výzvy pro projektové manažery v roce 2020

Projektový manažer by tedy měl být schopen tyto výzvy dynamiky a proměnlivosti adresovat. V pomyslném kufříku na nářadí si musí trošku uklidit (pokud neřídí projekty investiční výstavby apod.). Zřejmě bude třeba odložit robustní, výpočetně složité prediktivní metody, protože je nejspíš nebude mít kde využít. Místo nich je potřeba přisypat do zavazadla techniky a dovednosti pro facilitaci týmu, iterativní a obecně agilní metody a nástroje a především – trošku jinou filosofii, přístup.

Ryze vodopádový projekt beze změn prostě asi jen tak nepotkáme. Pokud vůbec někdy nějaký takový proběhl – mě osobně to připadá trošku jako Yetti. Nikdy jsem se osobně nesetkal s projektem, který by opravdu odděleně postupně procházel bez výraznějších změn všemi fázemi. Taková představa byla tak trošku lhaní si do kapsy i dříve. Je prostě potřeba vzít jako fakt, že i v prediktivně plánovaném projektu byla, je a bude sousta změn. Cíle budou často „plovoucí“, rozsah nejasný a že se názory se budou průběžně vyvíjet. Tak to prostě je.

Ale není důvod k panice…

To samozřejmě neznamená, že bychom teď všichni měli najednou vše zahodit a začít dělat výhradně SCRUM nebo jinou čistě agilní cestu. V nějakém kontextu to smysl má, v jiném ne. Že ale bude muset každý na pozici projektový manažer absorbovat určité množství agility, je jistota (pomůckou pak mohou být univerzální agilní principy).

Podobně, jako je vzácný či nereálný čistý vodopád, je nesnadné najít i optimální scrumové prostředí – i v takovém případě po vás (či po product ownerovi) organizace bude chtít nějakou vizi, nějaký business case daného produktu, nějaký jízdní řád releasů atd. Nemluvě o tom, že někdo musí o vývoji nějakého produktu rozhodnout a ustavit daný scrum tým… což prostě scrum jako takový neřeší (řeší jen realizaci, ne jak to vznikne či co s tím potom).

Pravděpodobně se tedy budeme pohybovat v prostředích s různým stupněm agility (od slabé až po totální) a bude třeba si s tím umět poradit.

Co říkají aktuální standardy?

Když pomineme čistě agilní Scrum Guide v páté revizi z roku 2017, který roli projektový manažer vůbec neobsahuje, tak „klasické“ PM standardy jsou v roce 2020 v jakémsi transformačním stavu.

IPMA ICB

IPMA má svou IPMA Competence Baseline ve verzi 4 od roku 2018. Od verze 3 se, kromě určitého přeskupení kompetencí a způsobu jejich ověřování, liší především začleněním kompetencí a nástrojů ohledně agilního vývoje. Najednou se vedle WBS objevuje Product Backlog, vedle Ganttova diagramu se objevil KANBAN atd. Je to asi tak v poměru 90 klasika/10 agile, ale i tak je to velký skok.

U IPMA se také (nejen) v naší zemi poměrně značně změnila certifikační zkouška. Historicky se jednalo o písemku s mnoha abcd otázkami, otevřenými otázkami a početními příklady, jako např. spočítat EVM, kritickou cestu apod., které testovaly znalosti a dovednosti tvorby prediktivních plánů. Po písemce u vyšších stupňů následovala zpráva o projektu a pohovor.

I v novém pojetí zůstala písemka, ovšem s praktičtějším zaměřením. Otázka u příkladu už není kolik je rezerva činnosti H apod., ale co bystě dělali v situaci, kdy je projekt ve stavu XY.  A přibyly otázky z agilního světa. Dále pak nově po samotné písemce následuje zkušební simulace. Několik kandidátů na certifikaci naživo spolupracuje na zadaných úkolech (jako tvorba záměru na projekt apod.) a zkoušející mají možnost vidět a posoudit jejich kompetence na vlastní oči.

IPMA tím jde skutečně naproti svému pojetí, že netestuje znalosti, ale skutečné kompetence, dovednosti.

A pak má IPMA také nově svůj vlastní referenční „guide“ pro agilní svět. A vzniká rovněž certifikace Certified Agile Leader (v níž je ČR jednou z pilotních zemí).

PMI PM BoK

PMI hodně změnilo pojetí již v období páté verze standardu z roku 2013. Ne přímo v dané verzi standardu, ale okolo roku 2015 se začal řešit tzv. PMI Talent Triangle…  a začal se chtít sběr rozvojových bodů (PDU) ze tří oblastí: Technického PM, Leadershipu a Strategického a byznys managementu. Což vykazovalo značnou podobnost s tím, jak měla IPMA již dlouhá léta rozdělené kompetence na technické, behaviorální a kontextové. A jen to potvrzovalo, že je správné chtít po PM něco víc, než jen spočítat plánovanou dobu trvání projektu.

Na PMI Global kongresu 2015, kterého jsem se zúčastnil, pak byla značná část příspěvků o agile. Ne většina, to zdaleka ne, i tak ale bylo dané množství v do té doby konzervativním světě PMI překvapivé.

V roce 2017 pak přišlo menší zemětřesení neb s novou verzí standardu vyšel rovnou i  tzv. Agile practice guide. Z certifikačních testů posléze začaly mizet otázky na EVM apod. metody a místo nich se objevily otázky s agilními tématy. A přibyla certifikace PMI Agile Certified Practitioner (PMI-ACP)^®.

PMI rozhodně není u konce, protože v době nedávné provedlo akvizici „Disciplined Agile Delivery“ (DAD) metodického rámce pro agile ve velkých firmách (který vznikl v IBM). Šlape tedy do agilního světa velmi razantně. Poměrně smysluplně, protože PMI bylo vždy především o korporacích a velkých projektech a DAD řeší komplexně agilitu v takovém prostředí. Zatímco SCRUM je ve své podstatě spíše o startup prostředí a týmu devíti lidí… a škálování SCRUMU nebo jeho implementace do „zkostnatělé a zbytnělé korporace“ je dost velký oříšek, který SCRUM jako takový moc neřeší. Lze to, ale DAD podle PMI umí adopci agility v korporaci usnadnit a urychlit.

Tak uvidíme, je to čerstvé a chystá se PM BoK verze 7, který bude výše uvedeným jistě silně ovlivněn.

PRINCE2

Metodika PRINCE2 obdobně výše uvedeným přišla v roce 2017 s novou verzí. A ta již obsahovala i manuál a zkoušky PRINCE2 Agile. V pojetí P2 se jedná o to, jak agilní vývoj včlenit do procesů klasického P2 projektu. Respektive, kde jsou vazby a místa, kde by si tyto dva systémy měly „povídat“. Daný trend je tedy přítomen i zde.

Co má tedy projektový manažer v roce 2020 dělat?

Rozvíjet se a vzdělávat. To po něm už nyní chtějí všechna certifikační schémata…. nejen PM, ale i Scrumu. Pro „klasicky“ zformované PM rozhodně doporučuji seznámit se s filosofií, postupy a nástroji agilního vývoje. Jinak prostě reálně hrozí, že ujede vlak. Že se bude něco z toho hodit, je jistota. De facto všechny projekty již nyní obsahují značné prvky nejistoty a mnoho změn. Takže určitá míra agility při jejich řízení je zcela na místě. Na druhou stranu, ruku na srdce, mnohým agilistům chybí schopnosti si rozplánovat práci i v rámci jednoho sprintu, takže určitý PM hardskill je také na místě.

Projektový manžer v roce 2020 v optimálním případě kombinuje znalosti a dovednosti. „Klasické technické“, agilní, umí komunikovat a pracovat s týmem i zainteresovanými stranami a má také přehled o byznysu a své organizaci. A především, to nejtěžší, musí umět myslet. Nebýt otrokem jedné metodiky či rámce a snažit se jej rigidně nacpat všude. Ale uvažovat v kontextu dané situace a „tahat z kufříku“ to, co se nejvíc hodí nebo interpolovat a vymýšlet nové přístupy. Pak dokáže být v některých případech spíše něco jako Product owner. Někdy spíše Scrum master, někdy spíše klasický PM a někdy třeba i člen týmu. A vždy si uvědomí, co v daném případě a kontextu chybí do optimálního stavu a nějak tento nedostatek řeší.

Tak nějak se ta úloha PM stala více VUCA a o to je i více zajímavá, živá, ale také náročná. Zřejmě se do budoucna budeme bavit o nějakém fúzním či hybridním projektovém managementu. A to je skvělé, protože organizovat desátý ročník konference na téma WBS by byla nuda ;).