Upozornění pro čtenáře a uživatele této knihy
Všechna práva vyhrazena. Žádná část této tištěné či elektronické knihy nesmí být reprodukována ani šířena v papírové, elektronické či jiné podobě bez předchozího písemného souhlasu nakladatele. Neoprávněné užití této knihy bude trestně stíháno.

Ing. Jan Doležal, Ph.D., a kolektiv

Projektový management
Komplexně, prakticky a podle světových standardů – 2. vydání

Vydala Grada Publishing, a.s.
U Průhonu 22, 170 00 Praha 7
tel.: +420 234 264 401
www.grada.cz
jako svou 8714. publikaci

Autorský kolektiv:
Ing. Jan Doležal, Ph.D.
Ing. Jiří Krátký
Ing. Martin Hájek, CSc.
Doc. Ing. Branislav Lacko, CSc.
Ondřej Cingl
Mgr. Zuzana Ježková

Odpovědný redaktor Petr Somogyi
Grafická úprava a sazba Eva Hradiláková
Formát ePub Štěpán Böhm
Návrh a zpracování obálky Zdeněk Dušek
Počet stran 432
Druhé vydání, Praha 2023
Vytiskly Tiskárny Havlíčkův Brod, a.s.

© Grada Publishing, a.s., 2023
Cover Photo © Depositphotos/jméno autora

ISBN 978-80-271-6725-8 (ePub)
ISBN 978-80-271-6724-1 (pdf)
ISBN 978-80-271-3619-3 (print)

O autorech

Ing. Jan Doležal, Ph.D. (vedoucí autor publikace)

Vystudoval automatizaci a informatiku na Fakultě strojní Vysokého učení technického v Brně, kde dokončil i doktorské studium (disertační práce se věnovala tematice projektového řízení).

V současné době se zabývá především agilitou v organizacích (scrum, SAFe), Managementem 3.0 a vývojem simulačních her sloužících jako trénink projektového řízení, včetně agilního přístupu. Působil jako specialista na volné noze, krátce jako projektový manažer v IT firmě, ještě dříve pracoval několik let ve východočeské společnosti Mikroelektronika, s.r.o., která je dodavatelem systémů odbavování v hromadné dopravě s celosvětovou působností. Zastával v této společnosti pozici vedoucího projektové kanceláře a řídil velké mezinárodní projekty (Evropa, Jižní Amerika). Zavedl v ní rovněž projektové řízení. Má zkušenosti především s projekty a produkty z IT, strojírenství, elektrotechniky, akademického i veřejnoprávního sektoru. Projektovému řízení se aktivně věnuje od roku 2001, agilním přístupům pak od roku 2014. Disponuje certifikacemi IPMA, PMI, SAFe, Scrum Alliance i Scrum.org.

Ing. Martin Hájek, CSc.

Vystudoval Fakultu jadernou a fyzikálně inženýrskou na Českém vysokém učení technickém, kde poté pracoval jako výzkumný pracovník. Po několika letech v Ústavu teorie informace a automatizace při České akademii věd působil v letech 1992–2005 v soukromém sektoru, a to na top manažerských a statutárních pozicích. Získal celou řadu certifikátů z obecného i specializovaného managementu a aplikované psychologie.

V letech 2006–2018 se věnoval trenérské a lektorské praxi se zaměřením na rozvoj osobního, týmového a organizačního vůdcovství. Nyní je v důchodu a věnuje se aktivnímu odpočinku.

Ing. Jiří Krátký

Absolvoval Fakultu ekonomicko-správní Univerzity Pardubice. Je členem Výboru Společnosti pro projektové řízení a certifikovaným projektovým manažerem IPMA® Level C. Působí jako poradce a lektor ve společnosti PM Consulting s.r.o. Zabývá se rozvojem projektového řízení v organizacích, vytváří a realizuje kurzy, tréninky a simulační hry pro rozvoj znalostí i dovedností projektových týmů. Má zkušenosti s rozvojem projektového řízení jak ve firmách, tak v neziskových organizacích i veřejné správě.

Je autorem knihy Projektový management do kapsy a online vzdělávacích kurzů v projektovém řízení na portálu seduo.cz. Rovněž je držitelem mezinárodních certifikátů IPMA, PMI, Prince2 a Scrum Alliance. Působí také jako zkoušející v rámci certifikace projektových manažerů podle IPMA.

Doc. Ing. Branislav Lacko, CSc.

Po studiu průmyslového oboru výroba letadel na Letecké fakultě Vojenské akademie v Brně absolvoval v letech 1977–1982 na Fakultě elektrotechniky Vysokého učení technického v Brně externí aspiranturu v oboru technická kybernetika. Habilitační práci obhájil na Fakultě strojního inženýrství Vysokého učení technického v Brně v roce 1995 v oboru automatické řízení. Odbornou praxi získal ve výpočetním středisku TOS Kuřim v letech 1967–1990, kde pracoval jako programátor, analytik, systémový programátor a vedoucí výpočetního střediska. Podílel se na podnikových projektech i oborových projektech v rámci trustu Továren strojírenské techniky Praha. Na Vysokém učení technickém v Brně působí od roku 1991. Od roku 2005 je výzkumným pracovníkem Fakulty strojního inženýrství VUT.

Je členem Společnosti pro projektové řízení, národní členské organizace mezinárodní společnosti International Project Management Association, společnosti rizikových specialistů ASPAR ČR a Českomoravské společnosti pro automatizaci.

Spolupracoval s řadou vzdělávacích firem jako externí lektor. Věnuje se aplikaci systémového přístupu na oblast analýzy projektových rizik. Je autorem metody RIPRAN pro analýzu rizik a spoluautorem metody DYPREP pro predikci průběhu projektů. Rovněž je certifikovaným projektovým manažerem IPMA. Ve Společnosti pro projektové řízení (dnes IPMA Czech Republic) zastával v letech 2006–2010 funkci prezidenta.

Ondřej Cingl

Certiﬁkovaný projektový manažer a scrum master. Pracuje na volné noze jako agilní kouč a trenér projektového řízení a manažerských dovedností. Je (spolu)tvůrcem několika manažerských her, mimo jiné simulace projektu Paciﬁcká železnice a deskové hry agilního vývoje. Realizoval projekty v oblasti IT (vývoj aplikací, hardwarová a softwarová infrastruktura), business developmentu (vývoj a uvedení produktu na trh) i mnohé další.

Závodně běhá ultramaratony a věnuje se lyžování a horolezectví.

Mgr. Zuzana Ježková

Projektová manažerka, konzultantka, lektorka, psycholožka a koučka. Projektovému řízení se věnuje od roku 2004, řídila projekty především v oblasti vzdělávání a výzkumu. Jako lektorka inspirovala už přes tisíc manažerů (v dubnu 2022 za sebou měla na školeních více než 1800 odučených hodin). Její specializací je příprava na certifikaci IPMA a PRINCE2 a aplikace psychologie do manažerské praxe (například rozhodování, time management, motivace, komunikace apod.). Je rovněž pedagožkou na Katedře hudební produkce Janáčkovy akademie múzických umění v Brně.

Je spoluautorkou publikace Projektové řízení – jak zvládnout projekty a autorkou e-knihy Hodina navíc každý den. Je držitelkou certifikací IPMA® Level C Certified Project Manager, PMI® Project Management Professional (PMP®), certifikovaný PRINCE2® Practitioner a akreditovaný PRINCE2® trenér Certifikovaný konzultant pro řízení projektů IPMA® PMC.

Předmluva

Držíte v ruce knihu, která je přímým následníkem publikace, jež vyšla ve dvou vydáních v roce 2009 a 2012 pod názvem Projektový management podle IPMA a ve třetí přepracované verzi už jako Projektový management (2016).

Čtvrté vydání reflektuje především masivní nástup agilních přístupů, technik a nástrojů a celkové sblížení projektového a produktového managementu. V této souvislosti došlo k významným modernizacím všech světových standardů a metodik projektového řízení, což je pochopitelně nutné zohlednit a zapracovat.

Kniha je tedy komplexním aktuálním (rok 2022) přehledem metod a technik projektového řízení, včetně hlavních trendů v oblasti agilních přístupů, avšak bez přímé vazby na některý ze světových standardů. Zároveň je však s nimi plně kompatibilní. Snažíme se vyjádřit, jak vnímá danou záležitost IPMA® ICB, PMI® PM BoK, PRINCE2®, případně i SAFe nebo scrum, a jaké jsou také naše praktické zkušenosti v dané oblasti.

Pokud tedy hledáte publikaci, která shrnuje většinu světových znalostí a trendů v oboru projektového řízení a vývoje produktu, doplněnou o praktické zkušenosti z řízení tuzemských i mezinárodních projektů, jste na správném místě.

Jsme rovněž přesvědčeni, že jsme vytvořili kromě praktického pomocníka projektových manažerů i poměrně univerzální učebnici, ať už se připravujete ke zkoušce IPMA®, PMI® nebo studujete na některé z našich vysokých škol.

Kapitoly jsme se snažili seřadit v rozumné posloupnosti, nicméně je potřeba vzít v potaz vzájemnou provázanost jednotlivých aspektů. Někde například použijeme slovo „lean“, i když termín bude vysvětlený až v některé následující kapitole. Nedalo se tomu vyhnout. Jedná se o komplexní problematiku, která dává smysl především jako celek.

Rád bych na tomto místě poděkoval všem, kteří se na tvorbě knihy podíleli, jakýmkoliv způsobem přispěli k jejímu vzniku nebo trpěli důsledky tvůrčích aktivit autorů (zejména naši rodinní příslušníci), případně neustálými požadavky a dotazy vedoucího autora. Děkuji i týmu nakladatelství Grada Publishing nejenom za dobrou práci, ale především za vstřícnost a trpělivost s autorským kolektivem.

V případě jakýchkoliv dotazů nebo připomínek ohledně této publikace a jejího obsahu se na mne prosím neváhejte obrátit. Budu se vše snažit reflektovat v dalším vydání. Moje e-mailová adresa je jd@pmconsulting.cz.

Ing. Jan Doležal, Ph.D.,

ředitel a jednatel PM Consulting, s. r. o.

1.Úvod

Projektový manažer je řemeslo jako každé jiné. Pokud máte zdravotní problém, obvykle navštívíte příslušně atestovaného lékaře. Nikoliv veterináře nebo třeba automechanika.

S projekty je to stejné. Pokud chcete úspěšný projekt, nejlepší je ho svěřit odborníkovi znalému nejlepší praxe, který je kompetentní danou nejlepší praxi v kontextu aplikovat. Máte tak nejvyšší pravděpodobnost (byť ne jistotu) úspěchu, bez zbytečných časových, materiálních a dalších ztrát.

Každý obor se vyvíjí. Nelze sice upřít obrovskou hodnotu zkušeností, zřejmě ale dáte přednost chirurgovi s přístroji a postupy aktuálního roku než někomu, kdo používá věci, které byly aktuální před třiceti lety.

1.1Projektový management v proměnách času

O projektovém řízení (projektovém managementu) jakožto o oblasti managementu, případně o profesi projektového manažera se začíná hovořit někdy po druhé světové válce. Už v dávné minulosti však probíhala řada akcí, které měly projektový charakter. Dobrým příkladem jsou například stavby různých starověkých monumentů nebo různá vojenská tažení.1 Už tehdy se začaly vyvíjet různé metody, postupy a techniky pro zvládání mimořádných, rozsáhlých a organizačně náročných akcí.

Oproti současnosti ovšem existuje několik zásadních rozdílů. Předně byla doba „pomalejší“. Pokud jste například ještě v době ne zas tak dávné poslali někam zprávu, dorazila na místo určení tak rychle, jak rychle ji tam byl někdo schopen dovézt. Nějakou dobu pak zabralo formulování odpovědi, která opět docela dlouho putovala zpět. A nebylo vždy jisté, že na místo doputuje.

Dnes dorazí e-mail kamkoliv na světě během několika vteřin. Telefonovat lze snadno po celé zeměkouli, dokonce i s přenosem obrazu. Týmy z nejrůznějších koutů světa mohou spolupracovat v reálném čase.

Ještě v druhé polovině 20. století bylo ve většině oborů možné vcelku úspěšně plánovat na několik let dopředu a bylo možné se spolehnout na určitou stabilitu. Měli jsme tedy čas si vše dobře promyslet, naplánovat dopředu, a až pak spustit realizaci, která sice jistě obsahovala nějaké změny oproti plánu, avšak tyto změny většinou nebyly zásadní. Tomuto přístupu se říká prediktivní (nebo též vodopádový) a „klasické“ postupy projektového řízení vznikly právě pro tento přístup, založený na racionalismu.2

Zhruba od šedesátých let 20. století lze vysledovat v oblasti projektového řízení snahy o mezinárodní standardizaci – se vznikem mezinárodních projektů a projektových týmů vznikla i potřeba se dobře domluvit a efektivně spolupracovat. Vše v prediktivním duchu, mimo jiné i proto, že šlo ve velké většině o projekty z oborů investiční výstavby, státem financované projekty (NASA) apod.

S nástupem a větším a větším významem IT prakticky ve všech oborech však začal být prediktivní přístup (především v otázkách souvisejících s vývojem softwaru) postupně více a více rozporován jako nefunkční a neefektivní.

Na rozdíl od situace, kdy je potřeba postavit čtyřproudý most přes řeku a kdy skutečně dává velký smysl si vše nejprve rozmyslet, spočítat, naplánovat a až poté začít stavět, je vývoj softwarových (a na ně navázaných) produktů jiný. Málokdo je totiž schopen dobře popsat, jak by měl výsledek přesně vypadat. Celá situace je velmi komplexní. Pokusy o vodopádový přístup v tomto ohledu velmi často končily katastrofou nebo minimálně rozčarováním.

Už v sedmdesátých, osmdesátých a devadesátých letech 20. století (především však po roce 2000) se pro daný kontext objevily tzv. agilní přístupy, založené na empirismu.3 Zastánci se vzdali myšlenky (nebo si to konečně připustili), že je možné v daném kontextu promyslet vše předem do všech důsledků, a začali postupovat iterativně, s intenzivním sběrem zpětné vazby po každé iteraci a jejím zohlednění v dalším postupu.

Do toho všeho se ještě namíchal tzv. lean, soubor principů, nástrojů a metod, jejichž původ sahá až do čtyřicátých let 20. století, kdy začaly vznikat v japonské automobilce Toyota.

Díky tomu se mění přístupy a postupy nejen v oblasti projektového řízení, ale ve způsobu fungování organizací celkově. A projektové řízení na to přirozeně reaguje. Přestává být nejlepší praxí aplikovat jeden přístup, model, životní cyklus. Velkou částí kompetence projektového manažera (a dotčené organizace) začíná být schopnost dobře vyhodnotit situaci a aplikovat vhodný přístup.

Například aktuální sedmá verze standardu PMI PM BoK definuje jakési spektrum od agilního přístupu přes tzv. hybrid (ve kterém se určitým způsobem kombinují agilní a prediktivní prvky) až po prediktivní přístup. Se spoustou odstínů šedi. A podle PMI má kompetentní projektový manažer zvládat celé toto spektrum.

Postupně si tedy všechny relevantní přístupy představíme.

1.2Stav oboru po roku 2020

Doba po roce 2020 je oproti 20. století, ve kterém vznikala cela řada technik prediktivního přístupu, velmi jiná. Je rychlá, nepředvídatelná, dynamická, vzájemně provázaná. Hovoří se o VUCA světě (volatile, uncertain, complex, ambigious – nestálý, nejistý, složitý, nejednoznačný).

Zřejmě jsme prošli bodem zvratu digitální technologické revoluce, jsou nastolovány nové byznys modely a pro celou ekonomiku jsou určující hráči, kteří před pár lety vůbec neexistovali.

Například v lednu 2007 Apple představil první iPhone. V březnu téhož roku koupila firma Nokia (Kdo že? Aha – tehdejší dominantní výrobce mobilů…) za 8,1 miliardy USD firmu Navteq. Ta se zabývala navigací pro automobily a tehdy dominovala na trhu uličních senzorů: hardwarových prvků, které monitorovaly stupeň dopravy a případně odkláněly navigovaná auta na jiné trasy. Nokia zamýšlela díky těmto senzorům ovládnout trh s navigací a konkurovat tak Googlu a Applu. Ve stejné době vznikl v Izraeli malý startup Waze…

Waze nic nevlastní. Nemusí nákladně udržovat a spravovat síť hardwarových senzorů (cena jejich upgradu by se pohybovala minimálně v řádech desítek milionů USD). Každý uživatel Waze má svůj vlastní senzor – mobil, ze kterého aplikace sbírá data o provozu. Waze má tak přístup k datům z desítek milionů senzorů po celém světě, které tuto firmu nestály ani cent.

V roce 2012 tržní hodnota Nokie spadla ze 140 miliard USD na 8,2 miliard – tedy na cenu, za kterou koupila Navteq. Zato Waze byl v roce 2013 odkoupen Googlem za 1,1 miliardy USD, s necelou stovkou zaměstnanců a de facto žádným majetkem či infrastrukturou. Pěkná alegorie Davida a Goliáše, že?

Možná nejtěžší je si uvědomit fakt, že v podstatě každý byznys je dnes do značné míry softwarový (či informační), nebo je touto oblastí velmi silně dotčen. V IT světě je dnes již nesporné, že kdo se nestane firmou se značnou mírou agility, založenou na dodávání hodnoty (value driven) se zákazníkem v centru zájmu (customer centric), a to velmi rychle, nepřežije nebo bude jen živořit. Určitě budou existovat i výjimky (třeba firmy dodávající software do nějakého silně regulovaného a specifického oboru), ale nebude jich mnoho.

Týká se to ale i jiných oborů než ryze IT – například osobní dopravy (Uber, BlaBlaCar), logistiky (Coyote Logistics – Uber v nákladní dopravě), ubytování (Booking, AirBnB), televizního, video a hudebního průmyslu (Netflix, Spotify), bankovnictví (Revolut, N26)… je třeba pokračovat?

Řeknete si – dobrá, ale jsou věci, které nelze takto jednoduše měnit. Odvětví, kterých se to netýká. Opravdu?

•Třeba… výroba hodinek? Od roku 2019 je největším výrobcem hodinek Apple.

•Třeba… výroba automobilů? V roce 2020 překonala Tesla svou tržní kapitalizací Ford v poměru 14 : 1. CEO společnosti BMW předpokládá, že v blízké budoucnosti budou více než polovinu pracovníků vývoje v této firmě tvořit vývojáři softwaru.

•Třeba… dodávky elektřiny a dalších komodit? Nedávno proběhla médii informace, že firmy již vyjde levněji (cena za kW) vyrobit vlastní elektřinu (solární systémy apod.) než ji kupovat.

Byla například představena střešní taška s integrovanou funkcí fotovoltaické elektrárny, domácí výrobníky vodíku pro palivové články a tak dále. Dnes jsou ještě drahé, ale Mooreův zákon platí i zde. Poměr cena/výkon se vyvíjí exponenciálně. 3D tiskárna stála před deseti lety okolo 40 000 USD. Dnes je to u nejlevnějších modelů asi 150 USD. Stalo se z ní spotřební zboží. Čekají nás jistě velké věci.

Mám s tím i velmi osobní zkušenost. V roce 2021 došlo ke krachu firmy Bohemia Energy a tisíce domácností (včetně té naší) ze dne na den spadly do tzv. režimu dodavatele poslední instance. Bylo potřeba si poměrně rychle najít nového řádného dodavatele, jinak hrozilo, že se dodávka elektřiny a plynu domácnosti prodraží o dost tisíc.

Když jsem to začal řešit, někteří dodavatelé vůbec nebyli schopni pružně reagovat a mít pro tuto situaci nějaký smysluplný online formulář a nabídku. Některým systémy díky přetížení nefungovaly vůbec, nebo po vás chtěli návštěvu pobočky. Jiní ale byli schopni rychle přijít s řešením, kde si bylo možné „naklikat“ nové smlouvy online během několika minut z pohodlí domova a vše bylo hned hotovo. Kterého dodavatele jsem si asi vybral? Jde o krásný příklad, jak se v dané situaci stal z energetiky byznys založený na IT, respektive na softwaru.

1.3Budeme všichni agilní?

Záleží, jak se na to podíváme. Pokud by byla otázka myšlena tak, jestli se musí stát naše firma či organizace jako taková více adaptivní, agilní, pak nejspíš ano – pokud chce přežít. Alespoň z části.

Pokud otázka znamená, zda budeme všichni realizovat agilní vývoj čehokoliv, tak nejspíš ne. V každé organizaci probíhá a bude probíhat více typů aktivit, budou se řešit různé problémové oblasti a každá z nich vyžaduje jako optimální určitý konkrétní přístup.

1.3.1CYNEFIN napoví

Existuje vynikající rámec CYNEFIN [KUN-iv-in] (původem slovo z velštiny znamenající oblíbené místo, místo výskytu apod.), se kterým přišel v roce 1999 Dave Snowden z IBM Global Services. Jako všechny modely samozřejmě nepokývá 100 % všeho a není zcela univerzální. Nicméně pro dané úvahy je velmi užitečný. Rozděluje kontext, ve kterém se pohybujeme, na pět domén (viz obrázek 1.1).

Obrázek 1.1 CYNEFIN (zdroj: J. Doležal)

Jasné/jednoduché

První doména představuje dobře známé problémy s jasným očekávaným výsledkem a postupem řešení (také nazýváno jako „známé známé“). Jsou známa pravidla či nejlepší praxe, prostředí je stabilní a existuje jasná posloupnost: „když A, pak B“.

Doporučené chování v této doméně je „porozumět, zařadit, zareagovat“. Poté, co pochopíme situaci, je třeba ji správně zařadit, a pak už jen konat podle daných pravidel pro danou situaci. Například může jít o příchozí objednávku. Pracovník, ke kterému objednávka dorazí, ji zařadí podle předem daných kategorií a poté aplikuje příslušný postup – třeba předání na příslušné oddělení k vyřízení a vystavení zálohové faktury.

Je tedy zřejmé, že tato doména je doménou procesů, jasně daných postupů a obecně osvědčené praxe (například u objednávky od klienta typu X vždy požadovat platbu předem). Ve zkratce jde tedy o nalezení příslušného pravidla a jeho aplikaci.

Bohužel se někdy stává, že manažeři mají tendenci některé problémy a situace příliš zlehčovat a tlačit je do této domény. Může to mít katastrofální důsledky s koncem v doméně „zmatek“ (implementovat nový ERP systém je přece jednoduché, stačí to jen nastavit…).

Komplikované

Druhá doména sestává ze „známých neznámých“. Pro správnou reakci (a posouzení vztahu „jestliže – pak“) je potřeba analýza situace a výběr z možných správných řešení (dobré praxe).

Příkladem problému z této domény může být například již zmíněná stavba mostu. Neexistuje jeden typ/návrh mostu vhodný do všech prostředí. Pro návrh a stavbu mostu však existují normy a standardizované postupy, materiály atd.

V této doméně jsou tedy klíčovými hráči inženýři, specialisté, experti apod., kteří jsou schopni správné analýzy dané situace a návrhu správného řešení. Ten pak již stačí zrealizovat (což nemusí být vůbec jednoduché).

Nejedná se samozřejmě jen o stavby. Do této domény může patřit například i migrace databáze, vesmírná mise nebo koncert Rolling Stones a veškerá logistika s ním spojená.

Prediktivní (vodopádové) přístupy a projekty mají domov především v této doméně.

Komplexní

Ve třetí doméně nám neurčitost dále narůstá a pracujeme s „neznámým neznámým“. Vztah „jestliže – pak“ je možné dedukovat pouze zpětně. Nelze dopředu úspěšně zjistit, co je správné řešení.

Doporučení pro tuto doménu je „prozkoumat – porozumět – zareagovat“. Tedy zkusit něco udělat (prototyp, experiment), pochopit, co se stalo, a následně na to reagovat.

Rozdíl mezi komplikovaným a komplexním je podobný jako rozdíl mezi letadlem a firemní kulturou. Letadlo je jistě velmi komplikované, nicméně zkušený technik ví, kde hledat problémy a jak je řešit, aby letadlo dále fungovalo a bylo to stále dané letadlo. Na druhé straně třeba změna dodavatele stravovacích služeb může vést i k velmi nečekaným a nepředvídatelným dopadům v rámci korporace, například ke zvýšené fluktuaci zaměstnanců nebo snížení nemocnosti atd.

Jako komplexní situace jsou obecně označovány například bojiště, trhy, ekosystémy, firmy a další systémy, které jako celek představují mnohem více než pouhou sumu jednotlivých částí.

V neposlední řadě patří do této domény i drtivá většina vývoje softwaru a souvisejících věcí. Je to tedy doména agility.

Chaos

Čtvrtá doména je reprezentována naprostou nejasností vztahu „jestliže – pak“. Doporučeným postupem je zde de facto hledání ostrůvků stability. Není čas a prostor dělat komplexní analýzy k pochopení situace.

Proto je také doporučen postup „jednat, porozumět, zareagovat“. Tedy začít něco dělat, porozumět, co je a není stabilní, a následně reagovat se snahou změnit chaos na komplexní situaci.

Příkladem chaosu může být situace těsně po nějaké katastrofě nebo třeba teroristickém útoku. Na začátku není vlastně moc jasné, co se vlastně stalo, jak je to velké atd., nicméně (poněkud zjednodušeně) hasiči prostě začnou hasit, záchranáři odvážet zraněné a situace se po nějakém čase „dostane pod kontrolu“. Na začátku je třeba především předejít panice – a „prostě začít něco dělat“.

Zmatek

Temná pátá doména uprostřed je to, co většina lidí v Česku intuitivně označuje jako chaos (CYNEFIN však „chaos“ přece jen definuje jako zvládnutelnou čtvrtou doménu). V CYNEFIN doméně „zmatek“ (disorder) především „nikdo nic neví“. Není jasné, do jaké z úvodních čtyř domén problém patří, lidé se hádají mezi sebou a celkově se jedná o jistou kakofonii, během níž „levá ruka neví, co dělá pravá“.

Jedinou cestou ven je případné rozdělení situace na dílčí části, které pak lze zařadit do příslušných domén.

Pohyb mezi doménami

Je obvyklé, že s rostoucí mírou zkušeností a znalostí se týmy a firmy postupně mohou posouvat po směru hodinových ručiček – to, co bylo zpočátku chaosem, představuje po získání zkušeností komplexní situaci, komplexní situace se pak s ustálením dobré praxe stává komplikovanou situací, a ta se zase může po zvládnutí redukovat až na jednoduchý problém.

Vyvíjet se může i samotná situace. Například vybudování pobočky mezinárodní firmy může ze začátku představovat komplexní problém, který se poté, až vybudujeme tři pobočky, mění na komplikovaný (už máme zkušenosti a praxi) a posléze na jednoduchý (rozjíždíme stopadesátou stejnou franšízu).

Pohyb může samozřejmě vést i opačným směrem, například když z firmy odejdou pracovníci s klíčovými zkušenostmi a jejich znalost je tak ztracena.

1.3.2Co z toho vyplývá pro organizace?

V každé normální firmě se běžně vyskytují všechny CYNEFIN domény. Čas od času se vyskytne i ta čtvrtá (chaos) – covid, lockdown, zaseknutá loď v Suezském průplavu…

Poznámka

Některé organizace mají jako hlavní standard pátou doménu (zmatek), těmi se však zabývat nebudeme. Rozhodně nefunguje přístup ve stylu, že pokud nejsme schopni řešit prediktivní situaci projektem, vyřešíme ji agilem, který už vůbec neumíme.

Uvažujme organizaci, která běžně řeší agendu v prvních třech doménách. Zjednodušeně řečeno: na něco má procesy (jednoduché), na něco projekty (komplikované), k něčemu potřebuje přistoupit agilně (komplexní). Proč? Protože to dává smysl a je to v dané situaci nejlepší řešení.

Ve všech CYNEFIN doménách je přitom potřeba postupovat profesionálně a kompetentně. Pokud je řešená záležitost z komplikované domény a je vhodný prediktivní přístup, je potřeba jej znale a dovedně aplikovat. Je to obdobné zjištění, jako že při řešení určitého problému bude potřeba zatlouct nějaké hřebíky. Takže si vezmeme adekvátně velké kladivo (a nikoliv palici, šroubovák, pantofel nebo něco úplně jiného) a zručně hřebíky zatlučeme. Pokud to neumíme, ublížíme si i s kladivem správné velikosti. Natož když jej chytíme za tmavou a těžkou část a mlátíme do hřebíků dřevem na druhém konci. Prostě to nebude fungovat.

Bylo tomu tak vždy, jen se mění poměr agend v jednotlivých doménách. Komplexních věcí je čím dál více. V 21. století není komplexní vše, ale je toho prostě mnohem a mnohem více než ve 20. století. Ubývá věcí, které jsme schopni úspěšně promyslet dopředu a následně je „jen“ zrealizovat (prediktivní přístup k řešení projektu).

Samozřejmě existují výjimky. Pokud je společnost montovna, bude nadále řešit především procesy a občas projekt, to je zřejmé. Řešíme zde především organizace a společnosti s vyšší přidanou hodnotou, které mají vlastní vyvíjené produkty a poskytované služby.

Některé záležitosti typu „stavba mostu“ nebo „sonda na Mars“ samozřejmě budou asi vždy spíše prediktivní povahy (především během realizační části). Prostě je musíme promyslet dopředu (což může mít i velmi agilní průběh), protože někdy už ani následně dělat změny nelze. A tedy dává smysl je řešit prediktivně. Když už sonda odletěla, už ji obvykle nejste schopni nějak upravovat. Most dodávaný po částech (první čtvrtina) asi moc smysl nemá… začne mít významnou hodnotu, až když je hotový, až jako celek.

Na druhou stranu lze agilní styl práce a některé agilní praktiky úspěšně aplikovat i v „nekomplexních“ doménách. Řada týmů, které dnes realizují prediktivní projekty, používají různé kanbany, roadmapy a další techniky s původem v agilním světě. Proč? Protože pro ně mají hodnotu a užitek.

Problematiku toho, jak se konkrétně rozhodovat a který přístup aplikovat, si nechme na později, až se s nimi blíže seznámíme.

Obrázek 1.2 Staceyho matice (zdroj: J. Doležal)

1.3.3Staceyho matice (Stacey matrix)

Dalším modelem, který se snaží pomoci se zvládáním komplexity, je matice Ralpha Staceyho. Spočívá v porovnání dvou os – míry shody ohledně výsledku a jistoty ohledně výsledku. Tyto osy vytváří vlastní matici, tedy prostor, který Stacey dále dělí na několik oblastí, v nichž doporučuje určitý postup (viz obrázek 1.2).

1.Blízko ke shodě, blízko k jistotě: V této oblasti matice lze sbírat historická data a použít je k předpovídání budoucnosti. Například stavební a inženýrské projekty obvykle obsahují velké množství technických údajů, které umožňují dobře specifikovat a naplánovat vše potřebné pro dodání. Práce je řízena sledováním podle předem připravených podrobných plánů.

2.Daleko ke shodě, blízko k jistotě: V některých projektech je velmi jisté, které cíle jsou možné a jak jich lze dosáhnout. Ovšem méně se zúčastnění shodují na tom, které cíle mají největší hodnotu. Příkladem může být situace, kdy při formulaci a vytváření projektu účinkuje více zainteresovaných stran s odlišnými názory na hodnotu a priority. V této oblasti jsou důležité dovednosti jako vyjednávání, dosahování kompromisu a vytváření koalic. Rozhodování se stává spíše politickým než technickým.

3.Blízko ke shodě, daleko k jistotě: Projekty mohou mít vysokou úroveň shody ohledně požadovaných cílů, ale nemusí nabízet příliš jistoty ohledně vazeb příčin a následků, které k nim povedou. Do této oblasti můžeme spadnout, pokud hodně spoléháme na neověřené předpoklady. V této oblasti je nezbytný silný pocit sdílené vize mezi zainteresovanými stranami a flexibilní a realistický přístup k plánování. Projektový manažer a sponzor musí viditelně směřovat k dohodnutému budoucímu stavu (plánu), i když konkrétní cesty nejsou zcela předem určeny.

4.Zóna komplexity: Tato zóna pokrývá oblast, kde kombinace nízké úrovně shody nebo nízké úrovně jistoty činí z projektu komplexní problém řízení. Je to oblast, která často spouští nesprávné rozhodovací postupy, když to, co skutečně potřebuje, je vysoká úroveň kreativity, inovace a osvobození od minulých omezení při vytváření nových řešení. Adaptabilita a agilita zde představují klíčové dovednosti nejen pro projektového manažera, ale i pro sponzora, členy týmu a zainteresované strany. Užitečné jsou zde přístupy jako systémové myšlení apod.

5.Daleko od shody, daleko od jistoty: Je-li málo shody a málo jistoty, může zavládnout anarchie. Jednotlivci a organizace se někdy uchylují k vyhýbání se takovým situacím, což však nelze dělat vždy. K řešení těchto situací – pokud nastanou – jsou zapotřebí vhodné strategie. Tato zóna je často označována spíše jako chaos než jako anarchie, hranice mezi touto zónou a zónou komplexity je známá jako „hrana chaosu“.

Vztah ke CYNEFIN

Pokud si zkusíme Staceyho matici porovnat s výše představeným CYNEFIN rámcem, tak Staceyho zóna 1 docela odpovídá jednoduché doméně, zóny 2 a 3 komplikované doméně, zóna 4 komplexní a zóna 5 chaosu.

Je tedy zřejmé, že i tento model nám poskytuje podobnou informaci. Projekty mohou být různé a budou pro ně vhodné rozdílné přístupy – stejně jako se na hřebíky hodí kladivo a na vruty šroubovák.

1 Značná část díla Umění války od mistra Sun-c‘, které vzniklo v 5. století př. n. l., je věnována analýze plánování a přípravy vojenského tažení. Z dnešní perspektivy jde o jedny z nejstarších písemných pramenů popisujících postupy a techniky přípravy a plánování projektu.

2 Filozofický směr, který zjednodušeně řečeno tvrdí, že jsme vše schopni promyslet dopředu.

3 Filozofický směr, který zjednodušeně řečeno zastává názor, že poznání přichází skrz zkušenost.

2.Základní pojmy projektového řízení

Projektovým řízením (project management) se obecně vždy rozuměl soubor norem, doporučení a„best practice“ zkušeností popisujících, jak řídit projekt.

Vzhledem krůznorodosti projektů jako takových se veskrze jedná spíše ovšeobecně platné skutečnosti, ourčitou filozofii přístupu křešení dané problematiky než okonkrétní apodrobné směrnice, návody apod. (byť itakové pokusy existují). Ataké se nám tento soubor včase mění. Co je tedy „best practice“ po roce 2020? Pro odpověď na tuto otázku si budeme muset nejprve upřesnit, co je to vlastně „projekt“.

2.1Projekt

Odpověď na otázku „co je to projekt?“ není totiž tak jednoduchá, jak by se na první pohled mohlo zdát. Problém je, že včeském jazyce má slovo projekt několik různých významů.

Například práce architekta může být označena jako projekt. Ve stavebnictví je projekt často používaným výrazem, vzpomeňme například profesi „projektant“, která však sprojektovým řízením jako takovým obvykle nemá nic společného. Ivdalších oborech se můžeme setkat soznačením projekt.

Všechna tato použití však mají často jedno společné: jsou ekvivalentní soznačením návrh (design). Pod výrazem návrh si můžeme například představit:

•specifikaci funkčních parametrů,

•technické řešení,

•výběr použité technologie,

•technickou dokumentaci (výkresy, kusovníky, výpočty atp.).

Zjednodušeně řečeno: výraz návrh často označuje popis výstupu (výstupů) projektu.

Voblasti projektového řízení chápeme termín projekt (project) odlišně. Existuje mnoho různých definic, smysl však mají všechny méně či více totožný.

Projekt je – nejobecněji řečeno – definovaná avymezená změna znějakého výchozího stavu do cílového stavu (viz obrázek 2.1).

Obrázek 2.1 Projekt jako změna zvýchozího stavu do stavu cílového (zdroj: J. Doležal)

Výše uvedená definice je velmi široká avešlo by se do ní jistě mnoho změn. Proto vznikla vprůběhu času itzv. projektová kritéria:

•Jedinečnost cíle (nejedná se orutinně opakovanou akci, odlišnost může být například ivprostředí, lokalitě, personálním obsazení apod.).

•Vymezenost (termín, rozpočet, zdroje, legislativa, …).

•Potřeba realizace projektovým týmem (potřeba několika pracovníků různých dovedností aznalostí, specializací, oborů).

•Komplexnost asložitost (nejedná se otriviální problém).

•Nadprůměrné riziko, nejistota (de facto vyplývá zpředchozích atributů – daná věc se vdaných podmínkách ještě nedělala, je omezený čas, peníze izdroje, podílí se na něm celá řada různých lidí avšechno je složité, takže je dost pravděpodobné, že se něco pokazí).

Pokud zamýšlená akce splňuje daná kritéria, je vhodné ji řídit pomocí nástrojů apostupů projektového řízení, protože ty jsou nastaveny aověřeny právě pro takové situace. Dá se dokonce říci, že většina nástrojů ametod projektového řízení je určena ktomu, aby se lidé mezi sebou uměli efektivně domluvit azkoordinovat. Což je přesně to, co je na projektech potřeba.

Návrh (design) je samozřejmě součástí činností souvisejících sprojektem. Vněkterých případech je známý hned od začátku, jindy může být vytvořen až vprůběhu projektu. Projekt si můžeme také představit jako určité „obalení“ návrhu vším, co je potřeba kjeho vytvoření – především tedy organizačními, koordinačními, vedoucími adalšími činnostmi.

Na projekt jako takový existuje mnohdy dost odlišný úhel pohledu arůzné zúčastněné (zainteresované) strany často na projektu vnímají odlišné aspekty azajímají se oně. Například pokud použijeme určitou analogii (jejíž princip je však obecně platný), uvažujme projekt jako změnu ze stavu Ado stavu B.

Roli, kterou můžeme nazvat třeba investor, vpodstatě nezajímá, co se mezi body AaB děje. Investora zajímá především přínos (užitek) po nastolení stavu B. Například vprojektu výstavby kancelářského komplexu nějaký subjekt (banka, fond atp.) investuje do daného projektu určitou sumu peněz. Hlavním bodem zájmu je především výnos po dokončení projektu, doba návratnosti, rizikovost investice apod. Jak probíhá vlastní výstavba arealizace jako taková, není předmětem zájmu – pokud není ohrožen termín nebo se neprodlužuje tak, že je ohrožena návratnost investice apod.

Na druhé straně spektra role, kterou můžeme nazvat realizátor, řeší především technické provedení – návrh. Vnašem příkladu to mohou být různé stavební asubdodavatelské firmy, které řeší přímo fyzicky stavbu jako takovou. Hlavním předmětem zájmu je kromě zisku (který se netýká přímo dané stavby – pokud by nepřinesla zisk, dělalo by se něco jiného) dodržení technických parametrů, správně provedená technologie atd. Budoucí použití výstupu (postavené budovy), natož výnos pro investora je téměř vždy naprosto mimo předmět zájmu těchto subjektů.

Někde uprostřed se pak pohybuje role, kterou nazvěme developer. Je spojovacím článkem. Na něm je řízení realizátora azajištění kompatibility výstupu akce sočekáváním investora (tedy vnašem příkladu to, že postavené kanceláře bude možné avhodné použít kzamýšlenému účelu, pro danou cílovou skupinu, atd.) adosažení předem definovaného cílového stavu. Tato role provádí většinu organizačních aktivit, koordinaci, komunikaci atp.

Vuvedeném rozdělení rolí nejvíce odpovídá roli manažera projektu právě developer. Názvy investor, developer, realizátor můžeme klidně zaměnit za top manažer, projektový manažer, člen projektového týmu nebo jakékoliv jiné označení podle příslušného oboru.

Je velmi podstatné si uvědomit, že mnohem důležitější než vztah „výstupy – cíl“ je vztah „cíl – přínosy“, který je základní myšlenkou, důvodem, proč je projekt realizován. Tento vztah se velmi často označuje jako business case.

Typickými projekty jsou například akce typu:

•zavádění nového procesu výroby,

•vývoj azavádění informačního systému,

•stavebně-investiční akce,

•stěhování (přesun) organizace,

•vývoj nového produktu,

•inovace produktu,

•koncertní turné populární kapely,

•kulturní festival adalší spíše humanitně zaměřené akce,

•výzkumná expedice atd.

Optimální adobře zvládnutelná doba trvání projektu je do dvanácti měsíců. Delší projekty jsou rizikovější, mají větší sklon ke sklouzávání jak vtermínech, tak vrozpočtu. Je tomu tak například izdůvodu postupného vyčerpání projektového týmu (únavy, vyhoření).

Pokud se jedná ovelmi komplexní projekt sdobou trvání přesahující uvedený jeden rok, je vhodné jej rozdělit na několik podprojektů, které již uvedený parametr splňují adohromady dosahují cíle komplexního projektu.

Projekty se mohou sdružovat vprogramech nebo portfoliích, jimiž se zabývají některé následující podkapitoly.

2.1.1Od projektu kproduktu

Vroce 2018 napsal Mike Kersten knihu snázvem Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. Do značné míry symbolizuje výrazné sblížení projektového aproduktového managementu ataké potřebu větší agility, především voblasti produktů aprojektů nějakým způsobem spojených sIT avývojem softwaru. Atakových projektů dnes je, jak už bylo zmíněno vúvodu této knihy, opravdu hodně.

Vmnoha situacích akontextech vlastně pojem „produkt“ a„projekt“ de facto splývají. Ato ipřesto, že především někteří vášniví zastánci agilních přístupů až snáboženským zanícením slovo „projekt“ potírají, kde mohou. Pokud vás někdo začne takto „kádrovat“, je velmi pravděpodobné, že toho okvalitním projektovém řízení mnoho neví. Navíc asi mnoho neví ani oagilitě, kterou se tak mocně ohání. Porovnejme například, jak definuje PMI projekt aScrum Guide produkt:

•PMI: „Projekt je časově ohraničené úsilí, směřující kvytvoření unikátního produktu nebo služby, na němž se podílí více lidí, spojených na dobu trvání projektu do tzv. projektového týmu.“

•Scrum Guide: „Produkt je prostředek kdoručení hodnoty. Má jasné hranice, známé stakeholdery, dobře definované uživatele nebo zákazníky. Produktem může být služba, fyzický produkt nebo něco abstraktnějšího.“

Jsou to dvě úplně rozdílné věci, že? Nebo by být rozdílné nemusely? Nemusely. Ale mohou… Pokud hovoříme oprojektu, zásadní je, že by měl mít nějaký poměrně jasný začátek akonec. Není to prostě průběžný, nekonečný vývoj, který je vpřípadě produktu možný.

Vtom je asi hlavní významová nuance. Jenže samozřejmě iryze agilní vývoj produktu někdy začne abude mít nějaké fáze. Třeba vytvoření tzv. minimálního životaschopného produktu do určitého data. Ato lze sklidným svědomím vdaném kontextu označit jako „projekt“ – dočasné úsilí pro vytvoření jedinečného produktu. Koneckonců Scrum Guide uvádí, že každý sprint (iteraci) lze vnímat jako malý projekt. Vnějaké firmě tedy mohou klidně používat termín „softwarový projekt“ jako označení pro ryze agilní vývoj.

Musíme chtě nechtě dojít ke zjištění, že se dané definice zvelké části překrývají. Navíc PMI ve svém standardu PM BoK (Project Management Body of Knowledge) uvádí, že klíčovým měřítkem úspěchu projektu je hodnota dodaná zákazníkovi projektu.

Prakticky vzato to znamená, že projektoví manažeři zkrátka potřebují kompetence izoblasti produktového managementu. Aže uněkterých projektů nebude tak úplně jasné kritérium vymezenosti. Aže někdy bude člověk spíše než vroli projektového manažera vroli vlastníka produktu.

2.1.2Cíl projektu

Na více místech jsme už použili slovní spojení „cíl projektu“. Je velmi vhodné si uvědomit, jak zmíněný cíl projektu správně vnímat aco se chápe jako úspěšný projekt.

Rozhodně není best practice (anikdy nebyla) mít cíl projektu ve smyslu: Do dd.mm.rrrr bude implementován systém DocMaster verze 6.21 za maximálně xyz peněz. Apokud bude rozpočet nebo termín jakkoliv překročen, je to špatně. Toto pojetí ssebou nese obrovské omezení vpodobě určení konkrétního produktu ajeho verze azároveň vůbec neřeší, pro koho aproč se všechno vlastně dělá.

Je to použitelné možná už jen vkontextu pomezí jednoduché akomplikované CYNEFIN domény, tedy na pomezí procesu aprojektu, kde je jasný anesporný výsledný stav icesta, jak jej dosáhnout, ajde jen oto, jak všechno zkoordinovat. Dnes by šlo spíše ovýjimečný případ, ve kterém by ale tento přístup stále dával smysl.

Takové pojetí vede obvykle k„papírově“ správně zrealizované dodávce podle objednávky, kterou ale nelze využít, nebo trpí zásadními nedostatky.

Také dnes už asi neplatí, že by bylo špatné, pokud překročíte rozpočet projektu oněkolik procent apřitom dodáte lepší než plánovanou hodnotu. Koneckonců jak uvádí PMI PM BoK na straně 34: Value is the ultimate indicator of project success. Dodaná hodnota je zásadním měřítkem úspěchu projektu. Ne jediným, ale zásadním.

Mnohem větší smysl vždy dávalo definovat smysluplný stav na konci projektu: novou možnost, schopnost, dovednost (organizace). Něco ve smyslu: Od nového roku probíhá vmaximální možné míře interní dokumentace elektronicky spředpokládanými náklady xyz peněz aúsporou času anákladů xxx peněz.“ Takové pojetí umožňuje mnohem větší flexibilitu vřešení acelkovém pojetí, motivuje kpřemýšlení opoužívání výsledku konkrétními uživateli acelkové smysluplnosti celé aktivity.

2.1.3Role apůsobnost projektového manažera

Projekt zmíněný vpředchozí podkapitole by pravděpodobně obsahoval několik částí, oblastí křešení:

•aplikaci, která by řešila elektronizaci papírových dokumentů aveškeré související záležitosti,

•úpravu procesů apostupů dané organizace,

•výbavu potřebných míst nějakým hardwarem,

•zaškolení všech do práce vnovém systému,

•případné legislativní implikace.

Vkontextu roku 2022, ve kterém vzniká tento text, je asi vpořádku říct, že můžeme zapomenout na to, že bychom řídili první část tohoto projektu (vývoj/úpravy/implementaci softwarové aplikace) nějak silně prediktivně, vodopádově. Proč? Protože by to bylo špatně. Pomalé, drahé, nejspíš srozporuplným výsledkem.

Projektoví manažeři se musí naučit přijmout fakt, že toto téma již není jejich. Nechť zde nastoupí scrum tým nebo jiný agilní tým adělá, co umí. Samozřejmě předpokládám kompetentní tým, který to skutečně „umí“. Iagile je vurčitém slova smyslu řemeslo alze jej mistrovsky zvládnout – nebo také nezvládnout.

Poznámka

Pro účely této publikace si dovolím pracovat spředpokladem, že když někomu něco svěříme, dostatečně jsme se přesvědčili, že je adekvátně kompetentní.

Projektový manažer se vtomto kontextu (vzávislosti na konkrétní situaci) stane jednou ze zainteresovaných stran, product ownerem nebo reprezentantem uživatelů.

Ostatní oblasti daného projektu (procesy, hardware, …) pak budou probíhat srozdílnou dávkou potřebné agility nebo prediktivity. Je asi zřejmé, že dává smysl psát uživatelskou dokumentaci azaškolovat uživatele až na něco, co funguje podle našich představ. Smysl asi také dává, že pokud dodávka nějakého hardwaru trvá tři měsíce, musím si vurčitý okamžik vybrat, objednat auž to, pokud možno, neměnit.

Vneposlední řadě je dobré si uvědomit, že zmíněný agilní tým (ať už interní, nebo externí) se bude zřejmě především zabývat vlastní aplikací ajeho členové nejspíš nebudou pobíhat po osmdesáti lokacích, kde budou zapojovat aoživovat hardware. Aasi také nebudou nejlepší školitelé.

Takže do celé akce, do komplexní akomplikované změny bude prostě zapojeno víc lidí srozdílnou mírou koordinovanosti. Agilní tým by se měl být schopen řídit sám. Možná budeme mít ijednotlivá pracoviště svysokou mírou sebeorganizace. Ovšem například parta pro zapojení hardwaru bude představovat jistý cizorodý prvek.

Atím se dostáváme kroli projektového manažera (aprojektového řízení) po roce 2020. Rozhodně to není omikromanagementu vývojářů softwaru. Takové pojetí role PM je již vpropadlišti dějin jako jedna ze slepých uliček.

Někdo ale bude ke koordinaci celého „cirkusu“ potřeba. Musí zajistit tok atransparentnost informací mezi všemi zúčastněnými. Musí to být někdo, kdo bude schopen celkového systémového pohledu ve vazbách. Někdo, kdo bude nositelem celkové vize dané změny abude pro ni schopen získávat ostatní. Spíše (servant) leader než manažer. Dobře prováděné projektové řízení se ktakovému úkolu velmi dobře hodí!

Projektové řízení je totiž mimo jiné charakterizováno především těmito principy:

•systémový přístup (zvažování jevů vsouvislostech),

•systematický, metodický postup (řízení různých projektů vykazuje stejné prvky),

•strukturování problému astrukturování včase (rozkládání problému na menší kousky),

•přiměřené prostředky (výběr metod aprocesu řízení adekvátně řízenému prvku),

•interdisciplinární (cross-functional) týmová práce (fungující tým dosahuje lepších výsledků než skupina individualit),

•aplikace zásad trvalého zlepšování (není problém udělat chybu, ale neustále ji opakovat, nepoučit se),

•integrace (lidí, procesů, zdrojů, …).

Poněkud sofistikovaněji amožná moderněji by se dalo výše zmíněné pojetí role projektového manažera (aprojektového řízení) popsat jako zajištění komplexní změny vbyznys toku hodnoty. Ano, vím, vtuto chvíli jsem to asi příliš nezjednodušil. Tak se ktomu vrátíme později.

Každopádně lze konstatovat, že kompetentní manažer projektu vsoučasné době dostatečně chápe, zná aovládá prediktivní iagilní přístupy aje schopen znale fungovat vobou kontextech nebo ivprostředí smíšeném (hybridním).

2.2Program

Podle standardu IPMA® v4 je program definován takto: „Program je chápán jako dočasná organizace projektů, které jsou navzájem řízeny tak, aby umožnily provedení změn adosažení přínosů. Jsou definovány pro dosažení strategického cíle organizace.“

Standard PM BoK v7 definuje program jako definovanou skupinu souvisejících projektů, podprogramů aprogramových aktivit, které jsou společně koordinovány tak, aby mohly být získány přínosy nedosažitelné individuálním řízením (bez vzájemné koordinace).

Program tedy není složitý, komplexní projekt. Jedná se okvalitativně jinou záležitost. Zatímco projekty, včetně těch komplexních, se zaměřují na realizaci konkrétních apoměrně dobře specifikovaných výstupů, management programu je především ovzájemných vazbách uvnitř ivně programu, řízení změn, řízení konfigurace apod. Cílem programového řízení je vzájemný soulad asynergie jednotlivých prvků programu tak, aby byly dosaženy strategické přínosy.

Příkladem programu může být vybudování sídla nějaké velké organizace apřesun této organizace do nového působiště. Ičást takového programu, věnovaná například IT, bude velmi komplexní záležitost. Zřejmě bude obsahovat projekty na vybudování samotné infrastruktury, nastavení serverů, aplikací, migraci uživatelů, dat atd., to vše samozřejmě sdodržením všech bezpečnostních atechnologických standardů (které se také včase mění).

Pokud by se jednalo omodernizaci systému prodeje nějaké firmy, může to zahrnovat projekty jako standardizace acentralizace IT systému prodeje, projekt optimalizace logistiky atřeba iprojekt úpravy kariérního řádu zaměstnanců prodeje. Všechno jsou to projekty svlastními cíli, harmonogramem apod., každý znich bude znamenat určitý přínos, nicméně plný efekt bude mít až realizace všech tří ve vzájemném souladu.

Přínosů se může dosahovat buď postupně (jako vpříkladu výše), nebo najednou – po dokončení poslední aktivity programu.

Řízení programu by se mělo postarat oto, aby výstupy všech vprogramu obsažených projektů bylo možné integrovat svýstupy ostatních projektů apřípadně isprvky stávajícího prostředí – aby je bylo možné použít vkontextu.

Zřejmě vás napadá: dobrá, ale oto by se mohli aměli starat manažeři projektů, ne? Ano ine. Do určité míry komplexity nepochybně ano. Nicméně pokud se jedná osložité prostředí, ve kterém je potřeba realizovat spoustu projektů aje pravděpodobné velké množství změn, nebude takový postup efektivní. Projektoví manažeři by pak místo řízení svých projektů jen zjišťovali, jestli není náhodou někde něco jinak ajestli by to nemohlo ovlivnit jejich projekt. Kromě toho, že by tím přicházeli očas na řízení projektu, nebudou velmi pravděpodobně ve svém úsilí 100% úspěšní avznikne mnoho chyb.

Sdružení skupiny do programu centralizuje toto aktivní zjišťování změn ajejich vzájemných dopadů avýrazně tak zefektivňuje řízení takového celku. Pokud tedy vprojektu Avznikne změna, je její vliv posouzen ivkontextu programu, apokud je schválena, provedou se případně potřebné úpravy ivdalších projektech programu. To je vpodstatě jeden zhlavních důvodů sdružení projektů do programu.

Pro podporu rozhodnutí, zda věci řídit jako program, nebo jako projekt či komplexní projekt, si zkusme představit následující situace.

Řekněme, že jste pracovníkem dopravního podniku vněkterém zvelkých měst. Právě jste byli pověřeni úkolem vyměnit ve všech sto dvaceti trolejbusech informační ceduli smapou linek MHD. Můžeme to považovat za samostatný úkol, ato ivpřípadě, že máte kruce několik pomocníků. Komplexita je velmi nízká – prostě si vyzvednete nově vytištěné mapy, ajak se postupně vdepu střídají trolejbusy, vyměníte vnich mapy. Není to projekt, maximálně nějaký dílčí výstup, pracovní balík vrámci projektu.

Pokud vás ale vedení pověřilo úkolem redesignu všech informačních cedulí vtrolejbusech, lze to již považovat za projekt. Budete řešit grafické návrhy, texty, výrobu anakonec isamotnou obměnu, kčemuž budete potřebovat sice malý, ale přece jen projektový tým.

Příkladem komplexního projektu pak může být přechod celé organizace na nový design, což zahrne veškeré dopravní prostředky MHD, včetně servisních amanažerských vozů, veškerá zařízení slogem organizace, různé IT systémy (především ty, které mají interface kzákazníkům apartnerům), designové astavební úpravy poboček aprodejních míst, marketingovou kampaň ke komunikaci nové podoby vaší organizace, nové hlavičkové papíry, vizitky ajakékoliv tiskoviny, powerpointové prezentace atd. Taková akce je de facto shlukem podprojektů aje výhodné ji tak řídit. Nicméně je stále dobře ajasně definována aje dobře řiditelná. Má stabilní rozsah (komplikovaná doména CYNEFIN).

Program je však přece jen něco jiného. Představte si situaci, ve které chce kraj zajistit všem lidem vrámci svého území co možná nejjednodušší cestování. Rozjede tedy program krajské karty, ukteré je nutné definovat technické parametry tak, aby bylo možné do systému vkládat další adalší partnery – především dopravce. Kdokoliv chce být součástí systému, musí se přizpůsobit danému základnímu formátu amusí také vstoupit do systému tzv. „clearingu“, ve kterém se rozdělují platby jednotlivým subjektům (na kartě je řekněme měsíční kupón pro cestování aje třeba dané prostředky rozdělit podle toho, jaké služby cestující využívá). Takovou kartu lze pak následně využít například ikzaplacení vstupu do různých sportovních akulturních zařízení atd.

Tohle už zní dost složitě akomplexně, že? Vtakovém případě je zkrátka výhodnější nechat běžet jednotlivé akce (typu „vstup partnera“) jako samostatné projekty, nesnažit se je všechny přímo řídit, ale pohlídat si ujednotlivých projektů soulad spožadovanými parametry, aby si akce sedly věcně ivčase, aby měly zajištěné potřebné finanční prostředky (pokud je sami financujete nebo spolufinancujete), atp. Neřídíte osobně jednotlivé aktéry aprojekty, ale monitorujete situaci, identifikujete možné potíže asnažíte se je ipreventivně řešit – řídíte danou záležitost jako program.

Je zřejmé, že vdaném nastavení by byli zřejmě jasní úvodní partneři dané krajské karty (jinak by se program asi nerozjel), ovšem následný vývoj již tak zřejmý není. Jinými slovy– rozsah se již zpodstaty takové akce bude vbudoucnu významně měnit.

Podstatným zhlediska kvality řízení programu je stanovení konkrétního cíle programu, který bude vztažen ke konkrétnímu datu – nikdo ve skutečnosti nechce nekonečný příběh. Neznamená to, že by byl celý systém například po pěti letech ukončen, ale je třeba vyhodnotit, zda bylo dosaženo očekávaných přínosů, aprogram adekvátně redefinovat pro další období (nebo iukončit, pokud to bude nejlepší řešení).

Uvýše uvedeného příkladu komplexního projektu by byl zřejmě cíl formulován ve smyslu: Od xx.yy.zzzz funguje celá organizace na bázi nového designu. Je to věc, kterou je prostě potřeba udělat abude splněna. Nicméně upříkladu programu by byl cíl takového počinu zřejmě něco ve smyslu: Od xx.yy.zzzz využívá 50 % cestujících krajskou kartu, což je mnohem méně přímo dosažitelný výsledek anení úplně zřejmé, co vše bude potřeba během následujících období všechno udělat ktomu, aby byl takový cíl splněn.

Příkladem pak může být třeba iprogram Apollo – mise NASA všedesátých asedmdesátých letech 20. století, zaměřené na přistání na Měsíci. Tento program byl na počátku poměrně obecně definován avprůběhu času do něho vstupovalo velké množství projektů. Nejenom samotné mise (projekty), ale ivše okolo – výzkum, vývoj avýroba nejrůznějšího zařízení avybavení, vzdělávání personálu, PR kampaně atd. – bylo potřeba vzájemně zkoordinovat apokud možno neudělat chybu typu, že by spolu různá zařízení nekomunikovala atp.

Důležitým momentem programu je fakt, že stejně jako ve výše uvedených příkladech, nemusí být nezbytně veškeré projekty adalší aktivity konkrétně adetailně známé ve chvíli, kdy program definujeme azahajujeme.

Důležitou vlastností jsou také změny vprůběhu realizace programu. Strategie není něčím úplně konstantním amůže se vprůběhu času měnit, přizpůsobovat se aktuálním podmínkám, situaci na trhu, politické orientaci atd. Tyto efekty se pak velmi často přenášejí ina programy, které mohou být rozvíjeny, utlumovány nebo iukončeny. Program je tedy mimochodem ze své podstaty poměrně agilní.

Vpřípadě Apolla došlo zhlediska řízení programu kzajímavému vývoji. Po dosažení cíle programu přistáním Apolla 11 na Měsíci náhle zájem veřejnosti imédií opadl, stejně jako ochota program financovat… proč ktomu došlo? Protože cíl programu (dopravit člověka na Měsíc abezpečně ho vrátit zpět) byl splněn. Anový cíl nebyl konkrétně stanoven apodpořen. Proto tento program za několik let poněkud vyšuměl abyl ukončen.

2.3Portfolio

Zjednodušeně řečeno: projekty aprogramy dělají věci správně, zatímco portfolio je sestaveno proto, aby se realizovaly ty správné věci.

Ve standardu IPMA® v4 se dočteme: „Portfolio je chápáno jako soubor projektů a/nebo programů, které nejsou mezi sebou nutně propojeny, avšak jejich propojení umožňuje optimální využití zdrojů organizace adosažení strategických cílů organizace při minimalizaci rizika portfolia.“

Definice vPM BoK v7 je mírně odlišná: „Portfolio je skupina programů, projektů nebo činností řízených jako skupina za účelem dosažení strategického cíle.“

Rámec pro škálovanou agilitu SAFe ve verzi 5.1 zase hovoří otzv. lean portfoliu, ve kterém je snaha za dané zdroje maximalizovat hodnotu dodávanou tzv. toky hodnoty (value streams).

Standardy se shodují vtom, že portfolio je sestaveno za účelem naplnit strategický cíl (cíle) – například maximalizace ROI vdaném segmentu trhu.

VPM BoK se následně uvádí, že řízení portfolia se zaměřuje na zajištění posuzování projektů (produktů) aprogramů zdůvodu potřeby prioritizace přidělení zdrojů. To je totiž pro správné řízení portfolia signifikantní. Nejde jen okoordinaci aoptimalizaci, ale především oto, aby ty nejpřínosnější projekty nepřicházely ozdroje na úkor nedůležitých, avšak na zdroje velmi náročných projektů. Jde oto, aby si organizace uvědomila, že může cokoliv, ale ne všechno.

PMI® standard pro řízení portfolia jde vtomto ohledu ještě dál adoslova uvádí: „Pokud není projektové portfolio navázáno na strategii organizace, je relevantní otázkou, zda by se práce vněm obsažená měla vůbec dělat. Portfolio by ztohoto důvodu mělo být reprezentací zájmů organizace, jejího směřování apostupu.“

Portfolio mohou tvořit veškeré projekty aprogramy dané organizace, nebo vpřípadě velké rozsáhlosti může organizace rozdělit své projekty aprogramy ido více portfolií, sdělicím znakem organizační příslušnosti, nebo podle oboru či tématu – podle toho, co je vdané situaci aorganizaci vhodné.

Jediným společným znakem projektů aprogramů zahrnutých do portfolia může být iprostý fakt, že projekt či program je realizován předmětnou organizací nebo některými jejími zdroji, tedy organizačními složkami, útvary, ale ijednotlivými zaměstnanci, zařízením atd.

Například se může jednat oportfolio vývojových projektů, obchodních projektů ainterních projektů nebo zkrátka oportfolio projektů aprogramů společnosti XYZ.

Řízení portfolia je klíčovou řídicí činností vedení organizace. Vrámci této činnosti se sledují strategické priority, optimalizují se zdroje, vyhodnocuje se výkonnost atd.

2.4Vzájemný vztah projektu, programu, portfolia astrategie organizace

Jak je zpředchozího textu patrné, na projekty lze vrámci organizace nahlížet zněkolika různých úhlů:

•Problematika řízení jednoho konkrétního projektu.

•Problematika implementace rozsáhlých akomplexních změn do organizace (často strategických), které jsou často realizovány skupinou více projektů vdelším časovém horizontu.

•Problematika koordinace různých projektů, systematické hospodaření se zdroji ajejich alokace na tyto projekty.

Těmito základními pohledy se zabývají základní tři oblasti managementu spojené sproblematikou projektů, které spolu tvoří ucelený avzájemně propojený systém. Jedná se oprojektový, programový aportfolio management. Pokud tedy budeme řešit jednu část ztéto PPP (projekt, program, portfolio) trojice, vždy musíme uvažovat vkontextu všech tří.

Lze rovněž definovat hierarchický vztah mezi danými třemi prvky vnávaznosti na strategii azaměření celé organizace.

•Na základě mise avize je vedením organizace definována konkrétní strategie dosažení vize (buď jako souhrnná sdílčími strategickými cíli, nebo jako sada dílčích strategií vjednotlivých oblastech).

•Určitá oblast strategie je obvykle seskupena ařízena jako portfolio.

•Kjednotlivým strategickým cílům řešeným vrámci portfolia jsou definovány programy kjejich dosažení, jakožto určité vymezené útvary, vjejichž rámci probíhají různé projekty (ale ijiné aktivity), které směřují knaplnění vytyčeného strategického cíle. Vrámci portfolia mohou figurovat isamostatné projekty nebo ijiné aktivity.

•Projekty dosahují jednotlivých dílčích cílů avýsledků, které by společně, postupně aspolu sdalšími aktivitami měly dosáhnout daného strategického cíle, vjehož rámci je projekt realizován.

•Projekty jsou mezi sebou vzájemně koordinovány asynchronizovány tak, aby byly plynule alokovány disponibilní zdroje acelková strategie byla komplexně naplňována– neustále se tedy prověřuje, jestli jednotlivé projekty mají stále svůj „byznys“ smysl, jakou mají pro organizaci přidanou hodnotu, adochází kdynamickému stanovování vzájemných priorit.

Obrázek 2.2 Hierarchický vztah projekt – program – portfolio
(zdroj: J. Doležal)

Zobrázku 2.2 izvýše uvedeného textu je patrné, že se skutečně jedná opoměrně komplexní pojetí avzájemně intenzivně provázaný systém. Diskutovat zvlášť ořízení programů nebo projektů tedy vpodstatě postrádá smysl, vždy je třeba zvažovat celkový systém.

2.5Různá pojetí životního cyklu projektu

Už bylo zmíněno, že kprojektu můžeme přistoupit prediktivně (tedy svírou, že jsme schopni vše dostatečně promyslet dopředu), nebo agilně (bez této víry). Nicméně paleta přístupů kvýběru je samozřejmě oněco pestřejší. Můžeme uvažovat čtyři základní modely, které jsou případně schopné různé míry flexibility:

•Vodopád, zřejmě nejvíce prediktivní přístup. V„ryzí“ podobě předpokládá, že jakmile proběhne určitá fáze projektu, je vyřešena anení třeba se kní vracet. To se samozřejmě vpraxi stává velmi vzácně, takže je vrámci tohoto přístupu potřeba věnovat značnou pozornost řízení změn arizik. Někdy se také používá tzv. rolling wave princip, při kterém do detailu plánujeme pouze nejbližší etapu, tu další pak až na základě aktuálního stavu.

Obrázek 2.3 Vodopádový přístup
(zdroj: J. Doležal)

•Iterativní přístup spočívá vpostupu, kdy nejprve nahrubo načrtneme výsledné řešení, abychom si dokázali odsouhlasit daný směr, který dále rozpracováváme do dalších detailů. Například se může jednat onějakou stavbu, ke které nejprve proběhne architektonická soutěž. Vybereme si styl řešení, následně vítězný architekt vytvoří podrobnější návrh, pak projektanti rozpracují konkrétní dokumentaci krůzným stupňům schvalování až po dokumentaci kprovedení stavby. Astavba je následně podle dané dokumentace skutečně vytvořena.

•Inkrementální, při kterém vytváříme výsledek po částech. Máme developerský záměr postavit na získaných pozemcích novou čtvrť azačneme třeba prvními dvěma bytovými domy. Pak sodstupem postavíme další tři atak dále.

•Agilní, který do určité míry kombinuje inkrementální aiterativní. Pracuje se vkrátkých cyklech, iteracích, které vždy přinesou dílčí výsledek, který dává smysl aje na něj možné získat zpětnou vazbu od zákazníka, uživatele. Klíčový pojem je zde „hodnota“ asnažíme se vytvářet nejdříve ty části, které mají nejvyšší přepokládanou hodnotu (což redukuje riziko nesprávných předpokladů).

•Hybridní, který buď včase, nebo vrámci rozsahu obsahuje různé prvky zvýše uvedených. Například fáze vývoje může být agilní, zatímco fáze výroby prediktivní. Nebo mohou být prediktivní některé výstupy, zatímco jiné mohou být agilní.

2.5.1Životní cyklus prediktivního projektu

Prediktivní projekt jako celek můžeme zmanažerského hlediska, časového hlediska apodle charakteru prováděných činností rozdělit na několik fází řízení projektu, které dohromady tvoří životní cyklus řízení projektu.

Fáze řízení projektu lze vnejobecnějším pojetí rozdělit na:

•předprojektovou fázi (vznik myšlenky projektu, její prověření atd.),

•projekt (zahájení, plánování, realizace, ukončení),

•poprojektovou fázi (vyhodnocení, provoz, realizace přínosů).

Je zřejmé, že projekt ještě před svým zahájením musí nějak vzniknout apro zahájení musí existovat nějaké zadání, například vrámci nějakého programu apod. Obdobně je vhodné po ukončení projektu provést zpětné vyhodnocení nezávislým týmem. Tyto fáze však již nejsou přímou součástí řešeného projektu, spíše jsou otázkou systému aprocesů řízení projektu vdané organizaci.

Sohledem na častou praxi je třeba uvést, že čas bývá nejhůře řízen vpředprojektové, zahajovací, plánovací apak vpoprojektové fázi. Přestože jsou tyto fáze zcelkového pohledu velmi významné, bývají opomíjené se zdůvodněním, že „máme málo času“ (což je velká fikce daných aktérů).

Upřednostňuje se realizační fáze, nejen vzhledem kvelké náročnosti akvelkému počtu činností, ale iproto, že se jedná ofázi obsahující vlastní tvorbu výstupů, zatímco ty přípravné „vlastně nic nevytváří“ (apo projektu již není čas se zabývat historií). Nicméně známé rčení upozorňuje na fakt, že ten, kdo nezná svou historii, je odsouzen ji opakovat.

Podcenění přípravy může mít ipoměrně nešťastné důsledky asvědčí onaprostém nepochopení prediktivní projektové problematiky, která se především snaží co nejvíce omezit nejistotu, jež je ivprediktivním projektu vždy velká. Situaci si můžeme představit na analogickém příkladu. Řekněme, že se nacházíme vnějakém horském středisku (Pec pod Sněžkou), je ráno anaším úkolem je dopravit se do západu slunce na nejvyšší vrchol vokolí (Sněžka) azase zpět.

Obrázek 2.4 Úkolem je dojít na Sněžku (zdroj: J. Doležal)

Situaci lze samozřejmě řešit způsobem, že se prostě otočíme avyrazíme směrem na Sněžku, která je zmnohých míst daného střediska dobře vidět – na co se zdržovat přípravou? Nicméně jakmile vstoupíme do údolí, Sněžka se nám zvýhledu ztratí, cesta se různě klikatí avětví… která je ta správná? Neskončíme na nějakém jiném kopci, nebo zpět vPeci? Navíc za chvíli přestane být cesta zasfaltu ana kamenech se žabky, které máme na nohou, moc nehodí…

Obrázek 2.5 Úkolem je dojít na Sněžku – rozcestí (zdroj: J. Doležal)

Uspět je vdaném případě především otázka náhody avelkého štěstí.

Štěstí však přeje především připraveným. Proto pokud „ztratíme“ dvacet minut tím, že si někde seženeme mapu, na které si cestu naplánujeme abudeme sledovat ináš postup, zvážíme, jakou si vzít obuv, asbalíme si do batohu pláštěnku asvačinu, bude pravděpodobnost našeho úspěchu odost vyšší než vpředchozím případě. Neznamená to samozřejmě, že nemůže přijít bouřka nebo něco podobného. Avšak ivtakovém případě budeme mnohem lépe připraveni apřípadně škody nebudou tak velké.

Tohle je vlastně podstata prediktivního přístupu kpřípravě ařízení projektu. Uvědomit si cíl vkontextu, analyzovat situaci, připravit se – aaž poté realizovat.

Fáze řízení projektu

Popsat projekt podle fází vobecné rovině alespoň vrámci organizace nebo organizační jednotky je přínosné zhlediska standardizace vdané organizační jednotce amezi zúčastněnými subjekty. Usnadní to komunikaci, umožní to vytvořit určitá pravidla, procesy anástroje, které budou kdanému fázovému modelu vztaženy, zvýší se iporozumění všech zúčastněných postupu přípravy arealizace projektu, včetně okamžiků důležitých rozhodnutí. Vneposlední řadě může takový model sloužit kporovnávání avyhodnocování různých projektů, atím ikpodpoře řízení projektového portfolia.

Každá organizace by měla podle svého charakteru acharakteru jednotlivých projektů identifikovat svůj vlastní životní cyklus, respektive charakteristický životní cyklus nebo cykly projektů, které realizuje.

Nikdy nezapomínejme, že existují výjimky apřílišná konkretizace životního cyklu může být spíše na obtíž. Může bránit flexibilitě, tolik potřebné vdnešním silně turbulentním prostředí.

Uvedené základní fáze řízení projektu mají rovněž jednu podstatnou vlastnost: nepřekrývají se amohou být realizovány isurčitým časovým odstupem. Například je možné provést plánovací fázi akfázi realizační přistoupit třeba až po několika měsících nebo iletech. Lze hovořit iojakési inkubační době projektu.

Vprůběhu realizační fáze řízení projektu se pak – vzávislosti na podobě konkrétního projektu – používá rozčlenění do realizačních etap, skupin navzájem logicky souvisejících činností, vrcholících obvykle dokončením některého zhlavních dodávaných výstupů nebo jeho klíčové komponenty. Etapy se obvykle nepřekrývají amimo jiné slouží křízení globálních rizik projektu, jako určité body kontroly souladu výstupů splánem aočekáváními ohledně správného postupu projektu.

Poznámka

Je třeba rozlišit fáze řízení projektu, které mohou být pro více projektů stejné akteré vpodstatě svěcnou podstatou projektu nesouvisí, aetapu realizace projektu, jež je naopak jedinečně spojená svěcnou podstatou projektu.

Rozhraní fází řízení projektu nebo idílčích částí těchto fází jsou také okamžikem, kdy je vhodné projekt přezkoumat, posoudit jeho aktuální smysluplnost abuď jej „pustit dál“, nebo zastavit. Některá pojetí řízení projektu využívají této vlastnosti jako základní přístup kudržení projektu pod kontrolou. Jedná se orůzné stage-gate (bránové) modely, jejichž obdobu využívá iPRINCE2® metodika. Vtomto pojetí se nejen fáze řízení projektu, ale irealizační etapy rozdělují do jasně oddělených, sekvenčních celků, na jejichž konci dojde kpřehodnocení projektu aje rozhodnuto, zda může být projekt „vpuštěn“ do další fáze rovnou, nebo zda je potřeba vzhledem kvývoji další fázi přeplánovat, či projekt úplně zastavit.

Pro zřetelné oddělení etap, ale imenších dílčích částí projektu, se používají především tzv. milníky (zanglického milestone – kámen ucesty označující vzdálenost). Milník je jasně definovaná významná událost projektu (časový okamžik), ve které se měří rozpracovanost produktů. Milník představuje bod zpětné kontroly, bod přijetí rozhodnutí nebo bod přejímky. Milník má vharmonogramu obvykle nulovou délku trvání. Při počátečním plánování se často pracuje právě smilníky, do podrobnějšího pohledu na projekt se dostáváme až později.

Pokud se tedy pokusíme otvorbu obecně použitelného modelu fází řízení projektu, můžeme dojít například knásledujícímu výsledku (viz obrázek 2.6).

Obrázek 2.6 Životní cyklus projektu

Na obrázku je uveden obecný životní cyklus projektu, kompatibilní snad se všemi standardy aprediktivními pojetími projektového řízení, se kterými se lze setkat. Po definici námětu na projekt je zpracován logický rámec aprozkoumána proveditelnost, navržen optimální způsob realizace (patří sem idoporučení projekt nerealizovat).

Po schválení studie může nastat prodleva, čekání na vhodný okamžik, kdy projekt spustit. Předprojektová fáze tímto končí. Po určitém čase může být projekt spuštěn fází zahájení (první zfází řízení projektu). Je zpracována zakládací (identifikační) listina projektu (project charter). Po definici základních parametrů projektu asestavení základního řídicího týmu projektu je přistoupeno kfázi řízení projektu „plánování“. Během té je definován plán řízení projektu (project management plan), který obsahuje minimálně definovaný rozsah projektu (WBS) aharmonogram projektu. Po schválení plánu řízení projektu se přistoupí kvlastní (fyzické) realizaci, vjejímž průběhu probíhá reporting, sledování projektu avše ostatní spojené srealizací, včetně předávání aakceptace výstupů.

Závěrečnou fází (poslední fází řízení projektu) je ukončení projektu, během kterého dochází kuzavření všech procesů, tvorbě závěrečné zprávy apod. Po ukončení projektu by mělo dojít knezávislému zpětnému vyhodnocení, především co se týče realizace zamýšlených přínosů.

Uvedené rozhodovací uzly jsou tedy následující:

•Je námět projektu OK? Dává smysl?

•Víme, jak ho realisticky asmysluplně provést? Dává to ekonomický (byznys) smysl?

•Máme připraveno vše potřebné pro úspěšnou realizaci?

•Byl splněn cíl projektu? Lze cíle projektu dosáhnout?

Tyto uzly jsou hlavními „bránami“, jimiž musí projekt úspěšně projít, aby mohl pokračovat. Nebo je vtěchto okamžicích zastaven. Vzhledem kobvyklému průběhu nákladů na projektech je to správné (viz obrázek 2.7).

Obrázek 2.7 Průběh projektu, který se vymkl kontrole (zdroj: J. Doležal)

Je zřejmé, že čím dříve je projekt případně zastaven, čím dříve je rozpoznána nereálnost záměru nebo jeho finančních ačasových parametrů, tím lépe. Vždy, když je zjištěno, že původní odhady nebyly správné (respektive podmínky pro business case projektu se změnily), je na místě zvážit, zda aza jakých podmínek vprojektu pokračovat, co případně změnit apod.

Jedno staré indiánské přísloví praví: „Jedeš-li na mrtvém koni, sesedni. Lepší podkovy nepomohou, lepší seno nepomůže, nová stáj nepomůže. Ten kůň dál nepojede.“ Sledovat různé mediálně propírané projekty (ale nejenom je) je vtomto kontextu často úsměvné. Poučte se zmoudrosti starých indiánů avyhýbejte se černým dírám na peníze, čas ienergii všech zúčastněných. Ukončit projekt včas je známkou velmi vyspělého projektového řízení.

2.5.2Životní cyklus agilního projektu

Ivpřípadě agilně pojatého způsobu práce lze hovořit oživotním cyklu. Izde musí nejprve vzniknout nějaký námět či vize, který je následně validován, amusí padnout rozhodnutí, jestli se do dané záležitosti pustit, nebo ne. Obvykle se této fázi říká product development aje plná experimentů, prototypů aponaučení, kudy cesta nevede.

Aby bylo jasno, product development vtéto fázi nemá za úkol určit přesné, fixní zadání. Spíše jde ovalidaci vize jako takové aohrubé upřesnění směru, kudy jít, aby to dávalo smysl. Pak je zde otázka, kdo „to“ bude dělat. Máme nějaký „volný“ tým, kterému můžeme daný projekt/produkt svěřit? Nebo budeme vytvářet tým nový? Tohle všechno je úkol pro organizaci, nositele projektu.

Až budeme mít tým, musí proběhnout ještě bezprostřední příprava před realizací, úvodní product discovery. Když už zhruba víme kudy jít amáme tým, můžeme provádět například úvodní storymapping, úvodní naplnění backlogu apod.

Apoté už začne vlastní iterativní realizace, jejíž výstupy – přírůstky hodnoty – mohou změnit vše včetně úvodní vize. Protože vtomto pojetí ověří naše předpoklady adomněnky až reálná zpětná vazba. Cyklus je znázorněn na obrázku 2.8.

Obrázek 2.8 Agilní životní cyklus projektu (zdroj: J. Doležal)