Úskalí plánování a realizace projektu

Co říkají standardy, které jsou často nazývány jako teorie?

Ať už otevřeme standard PMBoK od PMI, ICB od IPMA nebo PRINCE2 od APMG či snad dokonce doplněk normy ISO 9000, návodku ISO 10 006, vždy se dozvíme, že projekt má probíhat v určitém sledu kroků, kterému se říká životní cyklus a že každá fáze řízení projektu má své náležitosti.

V detailech se jednotlivé prameny mírně liší (především mírou detailu), celkový obraz je však téměř totožný. Viz obr.:

Obecná posloupnost kroků standardizované přípravy projektů

Nejprve bychom si měli rozmyslet, co vlastně tak nějak zevrubně chceme, nejlépe strategicky a v návaznosti na strategii naší organizace. Poté bychom měli stanovit cíl, který by neměl být jen tak nějaký hloupý cíl, ale SMART. Následuje další rozpracovávání záměru a jeho proveditelnosti, analýza možných rizik, někteří zpracovávají i logický rámec a používají další moderně, efektivně a kvalifikovaně znějící nástroje, techniky a metody.

Vše urputně vytvořené by měl fundovaně posoudit k tomu určený top manager, který rozhodnutím o spuštění nebo nespuštění projektu (ano nebo ne zní častěji podle typu organizace) de facto přebírá osobní zodpovědnost za použitelnost výstupů projektu, jeho smysluplnost, efektivitu, návratnost atd.

Rozhodnutí je obvykle ztělesněno nějakou formou identifikační nebo zakládací listiny projektu (ILP), která vyjmenovává klíčové údaje, jako je vytyčený cíl, finanční a časový rámec a také nešťastníka, pardon, projektového manažera, který má cíle v uvedených mantinelech dosáhnout a dodat zamýšlené výstupy.

Dotyčný manažer projektu srdnatě shromáždí své nejvěrnější, tedy řídicí tým projektu a jde projekt dále rozebírat, zkoumat a prohlížet ze všech možných stran a úhlů. Vzniká hierarchický rozpad všech výstupů v k dodání (WBS – Work breakdown structure), za kterým v ostrém sledu navazuje Scope, tedy vymezení projektu ve všech relevantních dimenzích.

Problém je tedy dobře popsán, je tedy čas se zamyslet, jak k jeho řešení nejlépe přistoupit a vzniká plán řízení projektu, který popisuje, jak bude sestavován rozpočet, jak bude projekt plánován, jak bude probíhat analýza rizik a další důležité operace přípravy a řízení projektu.

Nyní už má řídicí tým projektu poměrně pevnou půdu pod nohama a tak již poměrně svěže generuje prvotní plán činností, které ohodnotí časovou a zdrojovou náročností, které poskládá v logických vazbách a najde i kritickou cestu, řetěz nebo cokoliv jiného, co je kritické. Z daného již rychle vyplývá i finanční stav plánu projektu a případné odchylky vůči ILP jak ve zdrojích, tak v čase, které potřeba vyřešit, což tým bravurně a efektivně zvládá.

Zvídavý top manager opět zasahuje a po zevrubném posouzení plán a harmonogram projektu posvěcuje a pouští do realizace nebo jej vrací k přepracování. Zodpovědnost je nyní spíše sdílená mezi manažerem projektu a jeho nadřízeným, kdy je to ale opět nadřízený, kdo zodpovídá zase svému nadřízenému a ten zase svému nadřízenému atd. Ve velmi vzácných okamžicích o projekt projeví letmý zájem i šéf šéfa vašeho šéfa, ovšem jen informativně, neboť si je dobře vědom, že o projektu a jím řešené problematice v podstatě nic neví.

Pokud dostane projekt zelenou, což je při dodržení výše uvedeného postupu velmi pravděpodobné, zahajujeme výkopem na fotbalovém hřišti, tedy kickoffem projektu. V případě, že není v dosahu žádný fotbalový stadion, postačí i plácek za budovou naší organizace, ve výjimečných, náhradních případech i zasedačka… což je ovšem odsouzeníhodné a ortodoxní manažer projektu by to nedopustil.

Projekt je tedy zahájen a jeho realizace probíhá více či méně, spíše více, podle promyšleného, detailního plánu, operativně jsou řešeny odchylky, změny jsou kontrolovatelně řízeny a po posouzení zapracovávány nebo zamítány, projektový tým je efektivní, výkonný a o motivovaný, stejně jako manažer projektu, který jim všem jde příkladem a je opravdovým vůdcem.

Díky kvalitně zpracované analýze rizik projektový tým máloco překvapí a není divu, že je dosaženo požadovaných výstupů v rozumném tolerančním pásmu času a finančních i jiných zdrojů.

Organizace se však nenechává opít úspěchem a sotva je projekt věcně i finančně ukončen, začíná jej zpětně zkoumat a rozebírat, aby odhalila jak výtečné nápady, tak ty méně šťastné. Které není radno opakovat.

Organizace má vůbec o projekty enormní zájem, dokonce se je mezi sebou snaží koordinovat a různě vhodně propojovat tak, aby vše fungovalo co možná nejvíc hladce a efektivně. S dobou péčí se toto úsilí také celkem daří, často za pomoci nějakého vhodného softwarového nástroje, které jsou (alespoň podle jejich prodejců) zázračným všelékem na nefunkční systém projektového řízení a projekty v podstatě řídí samy…

Co říká „zkušený“ praktik?

Kdo má nějaké zkušenosti s projekty dobře ví, že podle výše uvedeného procesu obvykle neprobíhají. Je to přeci zbytečně byrokratické, dlouhotrvající a není čas na takové nesmysly, jako je logický rámec. A když už to někdo chce, tak se to zadá nějakému nepotřebnému členu skupiny, která se nazývá projektový tým, kdy se tato skupina v podstatě náhodně vytvoří více či méně formálním jmenováním. Jak to tedy v praxi obvykle probíhá?

Záměr na realizaci nějaké akce se rodí tak nějak mimovolně, prostě s ním někdo přijde (což je obvykle doména spíše komerčních organizací, kde se to všelijakými nápady jen hemží). Nebo, což je zřejmě více četný případ v případě nekomerčních organizací, je po projektu „politická“ poptávka. Typicky: „Vedení po nás chce čerpat nějaké prostředky z programu XY, tak prý máme něco vymyslet.“

Ať už myšlenka vznikne jakýmkoliv způsobem, obvykle je nahozena spíše vágně a neurčitě tak, abychom se nemuseli zabývat přílišnými detaily a pod název akce šlo schovat ledasco.

Zamýšlená aktivita se po čase dostane i na stůl některého z vedoucích pracovníků, který tomu sice nerozumí, ale nechce mít problémy. Proto akci obvykle schválí (je-li prezentována jako zcela bezpečná a bezproblémová, což je základní úkol předkladatele takového záměru), ovšem veškerá odpovědnost bude na realizátorovi.

Obvykle je snaha spojit tvůrce myšlenky s realizací akce marná, protože tvořitel myšlenky má přeci jiné starosti a spoustu práce. Postarat by se měl přeci ten nově nastoupivší mladý pracovník, alespoň se něčemu přiučí o tom, jak naše organizace vlastně funguje. Tím se dostáváme do situace, že veškerou zodpovědnost za realizaci nějaké akce, která je obvykle důležitou změnou v rámci pořádající organizace nese někdo nezkušený, kdo nikdy nic takového nedělal, nezná ani organizaci, ani jak vlastně změna vznikla, a proč by se vlastně měla dělat.

Pozn.: Zde nemáme na mysli např. projektové manažery firem, které implementují nějaký SW a dělají to už po dvacáté, myslíme obvyklé lidi na straně zákazníka.

Pro nově zapojeného pracovníka, který nově obdržel funkci „manažer projektu“, což je pro dotyčného poněkud obtížně představitelná role (ale zní to tajemně, je to cool a mají to všichni), je to nepříliš pohodlná situace.

Je v zájmu nově instalovaného manažera, aby cíle projektu a případné výstupy nebyly definovány přespříliš konkrétně – co kdyby se jich náhodou nedařilo dosáhnout? Obvyklé řešení je pak jednoduché. Nejdříve se na původně vágně definovaný záměr vybere (vysoutěží) dodavatelská firma (v případě, že se jedná o ryze interní projekt, hraje roli dodavatelské firmy manažer projektu nebo lépe, někdo lidí, kteří mu jsou přiděleni, jakože tým). Termín a maximální rozpočet jsou tímto krokem nepřekročitelně dány.

Následně se shromáždí veškerá dostupná dokumentace, která by mohla mít s předmětem řešení cokoliv společného (hlavně jí musí být dostatečné množství) a tento balík je následně odeslán vybrané externí firmě, která by měla výstupy zrealizovat. Ať už si s tím poradí, oni jsou přeci odborníci.

Manažer projektu jásá a myje si ruce, protože pokud bude v budoucnu jakákoliv kritika, vždy se dá bez problému přenést na dodavatelskou firmu. Fajn, takže pojďme zahájit realizační fázi projektu.

Obecná posloupnost kroků běžně realizovaného projektu

Jakmile se v rámci předmětné organizace roznese, že se začala dělat nějaká akce, které se kdo ví proč říká projekt (Zas nějaký zbytečný zápaďácký výmysl, nikdy jsme nic takového nedělali, tak proč teď?), začnou se doslova rojit různé zlepšovací návrhy, jak by to měl tým dělat jinak, co dalšího by bylo dobré v projektu udělat, co naopak neudělat a vůbec se najednou okolí projektu jeví jako nadprůměrně inteligentní a světaznalé. Čím vyšší je hierarchická pozice zdroje nápadů, tím častěji z něj padají, nezávisle na tom, k čemu je dotyčný kompetentní nebo co zná a umí (to je v tomto případě až absurdně irelevantní). Pro dotyčné myslitele je to naprosto bezpečná činnost. Kdyby se myšlenka osvědčila, získají cenné body, pokud se neosvědčí, neměl ji přeci manažer projektu realizovat, je to jeho zodpovědnost.

Operativní řízení takového projektu (o jiném způsobu řízení nemá smysl uvažovat) pak připomíná snahu pochytat notně potrhaný pytel blech. Manažer projektu se buďto snaží alespoň hasit požáry a zachraňovat co se dá, nebo (pokud naslouchá sebezáchovnému pudu) nechává věcem volný průběh a veškeré problémy předává na dodavatelskou firmu spolu se zodpovědností za jejich vyřešení. Konec konců, v podstatě stejně ani nemá čas na cokoliv jiného než na vnášení stejných údajů do několika různých kusů informačního systému (což je někdy pozitivem – kdo nic nedělá, nic nezkazí), kde se tyto informace ztrácí neznámo kam a celkově má snaha užitek pouze v trénování dotyčného v psaní na klávesnici.

Již jen drobnou vadou na kráse jsou nejrůznější kapacitní a kompetenční problémy v rámci organizace, kdy každý pracuje na několika projektech a není vždy zcela jasné, na kterém zrovna. Pro manažera projektu to pouze znamená velmi šikovný důvod, proč není splněn ten nebo onen interní milník, když mu přeci zdroje sebral jiný projekt. Postupně, jak se blíží původně avizovaný termín, nervozita stoupá. Rozpracovaného je toho hodně, hotového nic a dokončení každého výstupu skýtá výhled na pěkných pár týdnů.

Dodavatelská firma dostane na jednání výprask, termín je blahosklonně posunut a vedení za nic nemůže. Jeden případ. V případě šikovné firmy je tento obrat doprovázen navýšením rozpočtu za původně neplánovanou a dodatečně vyžádanou funkcionalitu (manažer projektu se stydí a dostává od šéfa výprask, protože připustil, aby se v zápisu z některé porady objevilo, že jde o nově vymyšlenou funkci, která v původním zadání nebyla – to se tak přeci nedělá…).

Tento proces kauzálního posouvání termínu se několikrát zopakuje a minimálně režijní náklady začnou významně překračovat původně zamýšlenou částku.

Ve chvíli, kdy jsou rozpočet a harmonogram překračovány už opravdu hodně, dokonce tak, že by si tiši šéf šéfa mohl nelibě povšimnout, vyhlásí se úspěšné dokončení projektu a dodatečně se do jeho zadání popíše aktuální stav.

Tím je vše vyřešeno a všichni jsou spokojeni. A protože úspěch motivuje, ihned někdo vymyslí, že by bylo dobré přeci jenom dané dílo posunout směrem k provozuschopnému stavu a začne vznikat nový námět na projekt. Cyklus je v tomto případě skutečně cyklem, protože vše začíná nanovo, viz obr. výše.

Závěr

Je vcelku zřejmé, že případ onoho „zkušeného“ praktika je stejně tragický jako běžný. Vychází z komplexní neznalosti a nedostatečných kompetencí průřezově celou organizací, od jednotlivých pracovníků v různých odděleních až po top manažery a generální vedoucí.

Když už se někde, v nějakém oddělení, zpravidla z řad středního managementu objeví někdo, kdo ví co je to projekt a je kompetentní k tomu jej řídit (tzv. ostrůvek pozitivní deviace), naráží na neznalost a nepochopení na všech stranách.

Samozřejmě ani organizace, která často funguje na stejných principech jako před desítkami let a ve které naplno platí již fousaté Parkinsonovy zákony (typu že od určité velikosti oddělení se toto plně zaměstná samo sebou), není v podstatě ani schopna zrealizovat ve svém rámci projekt, protože to systémově není možné.

Bohužel, dochází někdy i k dost zavádějícímu výkladu a následném pochopení výkladu jednotlivých standardů, které jsme popisovali v úvodu článku. Je zřejmé, že byl popsán opravdu ideální a idealizovaný stav, kterého zřejmě nejde dosáhnout – vždy budou nějaké nepravidelnosti a odchylky (což ale neznamená, že bychom se jej neměli snažit dosáhnout).

Uvedené standardy přeci nejsou dogma. Jsou především jakousi inspirací, doporučením, pro efektivní definici, přípravu a realizaci projektů. Pokud specifika některé konkrétní organizace potřebují popsané postupy upravit, doplnit nějaké interní kroky nebo dokumenty, není celkem důvodu, proč to neudělat.

Vytváření takového systému řízení projektů v organizaci však potřebuje několik prvků, bez kterých vznikne jen velmi obtížně nebo tak nějak do ztracena. Těmito prvky jsou:

• nadkritické množství znalých, tedy takových pracovníků, kteří vědí, o co jde a jak to funguje, a to na všech úrovních řízení, včetně vrcholové, průřezově v celé organizaci,
• N kompetentních, tedy takových, kteří mají plně rozvinuté kompetence pro řízení projektů, případně pro vytváření systému řízení projektů, kdy N je odvozeno od velikosti organizace a předpokládaného počtu realizovaných projektů,
• ochota a vůle managementu provést a dokončit zásadní změnu organizační struktury i kultury (systém projektového řízení nelze zavádět „zdola“),
• strategie, aneb organizace ví, co a proč chce.

Poslední bod se v obdobných výčtech příliš často neuvádí, je ale zcela jistě neméně důležitý než ostatní. Pokud nejsou projekty pevně zakotveny v alespoň pomyslném schématu mise – vize – strategie – program – projekt, budou jen velmi obtížně přinášet nějaký znatelnější užitek nebo přidanou hodnotu, případně takovýto benefit půjde jen obtížně změřit nebo i hledat.

Jak je vidno, problémy s řízením projektů jsou často jen důsledkem způsobu řízení celé organizace a jejího směřování. Zde je případně potřeba začít.