Vysoká rizikovost je projektům vlastní

S každým projektem jsou spojena určitá rizika, tedy nejisté události, které mohou nastat a ovlivnit, zpravidla negativně, jeho průběh. Je zřejmě tuzemským specifikem, že se rizika obecně moc neřídí, respektive že se neřídí formálně. Na rozdíl od některých jiných národů a etnik je u nás poměrně vyvinutý jakýsi šestý smysl, intuice, která tak nějak sama o sobě řadu rizik identifikuje, analyzuje, vyhodnotí a navrhne vyšším hladinám vědomí adekvátní řešení. V malých projektech a týmech to i docela dobře funguje. Komplikace nastávají ve chvíli, kdy tým není tvořen konzistentní skupinkou lidí, kteří jsou z jednoho oddělení, každý den se opakovaně potkávají, mohou věci diskutovat při obědě apod. Pak se vytrácí schopnost vzájemného upozorňování se na vlastní postřehy a úhly pohledu na věc s výsledkem, že je méně rizik identifikováno a dále řešeno, což následně vede k většímu výskytu reálně dopadnuvších rizik na projekt. Ještě náročnější je situace v rozsáhlých a mezinárodních týmech. Ona schopnost intuice a improvizace opravdu není dána všem.

Ve výsledku i v malém a čistě tuzemském týmu je vždy prospěšné si ta nejvýznamnější rizika alespoň sepsat, základně rozebrat, a především určit každému riziku majitele. Vyhnete se tak situacím typu: „No, já si od začátku myslel, že by tento problém mohl nastat, ale měl jsem za to, že to řeší někdo jiný...“ Dobrým nástrojem pro takový počin může být například registr rizik, jehož možnou podobu ukazuje tabulka 1.
 

Tab. 1

Nejprve provedeme základní identifikaci a popis dané nejisté události. Zde je velmi důležité popsat scénář, který se může uskutečnit až do konkrétního, nejlépe vyčíslitelného dopadu na projekt. Následně se v rámci protiopatření snažíme preventivně zajistit, aby se daný scénář nejlépe vůbec nerealizoval nebo aby pravděpodobnost či dopad takového scénáře byly minimalizovány. U nejvýznamnějších rizik je pak vhodné zamyslet se i nad situací, kdy prevence selže, jak to co nejdřív poznáme (spouštěč) a co s tím potom dál. Na proces řízení rizik existují i mnohem sofistikovanější metody a nástroje, i výše uvedený postup však v drtivé většině případů plně postačuje, a to za předpokladu, že se s ním průběžně pracuje a není brán jen jako formalita.

Proč se zabývat koncem?

V některých případech se setkávám se situací, kdy v organizacích a firmách nejenže není jasné, kdy projekt vlastně začal, ale ono není zřejmé, ani kdy skončil. Typickým příkladem je nějaká zakázka, která vlivem změn a dalších faktorů výrazně změnila svůj harmonogram. Když už byla situace nějakým způsobem fakturačně kritická, tak se něco zakceptovalo, s významnými připomínkami, které byly následně více či méně rychle dále zpracovávány. I zde pak třeba došlo ke změnám, částečné akceptaci atd., až se projekt jaksi vytratil do ztracena, respektive nepřehledné změti oprav původního řešení, změnových a nových požadavků.

Tento postup je typický pro IT projekty, ale není to zdaleka uzavřená množina. I v dalších oblastech tomu tak často je. Příčiny přitom leží většinou na začátku projektu: vágní zadání, nejasný rozsah projektu, díky tomu obtížné řízení změn (a následné chaotické změny), chybí definice akceptačních kritérií apod. Poté vlastně není výsledek s čím srovnávat a vzniká velký prostor pro ono vyšumění do ztracena a neschopnost projekt jakkoliv vyhodnotit. To, jak tyto úvodní věci pohlídat, jsme si ukázali v předchozích dílech našeho seriálu. Dále tedy předpokládejme, že jsme dané kroky byli schopni uspokojivě zvládnout.

Kdy je začátek konce?

Procesní pojetí standardu PM BoK od PMI pěkně rozděluje procesy na projektu do skupin zahajovacích, plánovacích, realizačních, ukončovacích a monitorovacích. Tyto procesy spolu cyklicky souvisí, a to na různých úrovních detailu (viz obrázek 1). Dané schéma shodně platí pro projekt, etapu realizace projektu i pro dílčí činnost. Uvedené pojetí velmi dobře ilustruje fakt, že něco bude ukončováno již od začátku. Například již sestavení Identifikační listiny projektu musí být v některém okamžiku zřetelně ukončeno. Stejně tak plánování projektu jako takové (alespoň co se výchozích směrných plánů týče) a pak i postupná realizace jednotlivých činností a pracovních balíků. Obsah procesů ukončování je vždy založen na předání výsledku osobou zodpovědnou za danou dodávku zadavateli, který prověří, že předávané odpovídá dříve domluveným parametrům a je bez vad. A toto v nejlepším případě platí již na úrovni jednotlivých činností, nejhůře na nejnižší úrovni WBS. V projektu tedy dochází k aplikaci ukončovacích procesů v podstatě průběžně a neustále. Je dobré mít to na zřeteli již při sestavování plánu řízení projektu.
 

Obr. 1

Dobrá dokumentace dělá přátele

V případě předávání, přebírání a akceptace jednotlivých výsledků a dodávek více než kdy jindy platí zásada kvalitní dokumentace těchto kroků. Přitom stejně jako v jiných případech nemusí jít o složité dokumenty a formuláře. Pro akceptaci dílčího výsledku, nebo i celého díla stačí jednoduchý formulář, ve kterém bude uvedeno, co, kdo, kdy a s jakým výsledkem (bez výhrad, s výhradami) akceptoval nebo ne. Velký pozor je třeba dát na rozdíl mezi výhradami oproti zadání a nově vniklými požadavky. Zatímco první skupina je jednoznačně k dořešení tvůrcem, druhá by měla vždy projít adekvátním změnovým řízením. Jen tak lze projekt udržet pod kontrolou. V některých případech (smluvně dané termíny předání apod.) je pak výhodné mít i jednoduchý předávací protokol, který potvrdí především termín předání výsledku, který musí být nejprve prověřen a třeba i několik týdnů testován, než může dojít k vlastní akceptaci.

V samotném závěru projektu je pak vhodné vypracovat i vyhodnocení, nejlépe ve formě jednoduchého dokumentu, který porovná zadání projektu s jeho výsledky, například ve formě, kterou ukazuje tabulka 2. Poslední řádek, tedy upřesnění kontextu, je velmi důležitý. Na projektech se děje velká řada dynamických jevů, které je potřeba v rámci vyhodnocení reflektovat. Nejčastěji jde o nejrůznější změny, ať už volitelné či takové, vůči kterým bylo zkrátka nutné se přizpůsobit. Pouhé porovnání tvrdých kritérií úspěšnosti může být poněkud zavádějící. V některých případech mohou být odchylky od plánu velmi významné nebo může jít i o předčasné ukončení projektu. I v těchto případech je vhodné projekty řádně, formálně ukončit. A třeba nastartovat projekt další, který dořeší nedodělky. Pokud to neuděláme, dostaneme se do kolotoče starých a nových požadavků zmíněného v úvodu.

V každém případě je třeba si uvědomit, že docela dobře platí i další z bonmotů projektových manažerů: úspěšný projekt je takový, který je tak vnímán. A to především klíčovými zainteresovanými stranami. Vše výše uvedené plně platí jak pro projekty na komerční bázi, tak pro ryze interní projekty. Byť se to může zdát nadbytečné, i v projektech typy „firma sama sobě“ je velmi užitečné akceptovat dílčí i celkové výsledky.

Tab. 2

Osobní zkušenost zvyšuje hodnotu člověka, sdílená posiluje organizaci

Hospodaření se zkušenostmi v rámci firmy (knowledge management) je dnes velmi diskutované téma, které velmi přesahuje možnosti tohoto článku i seriálu. Nicméně alespoň v souvislosti s oblastí projektového řízení zmiňme několik bodů a zásad pro předávání zkušeností mezi projektovými manažery v organizaci:

• Vycházet lze nejlépe ze seznamu bodů k řešení nebo z registru rizik.
• Smysl dává předávat dál především takové informace, které nejsou nedílně spjaté pouze s jedním konkrétním řešením (projektem), ale spíše zkušenosti obecnějšího charakteru.
• Záznam „naučených lekcí“ (lessons learned) je nejlepší dělat do nějakého vhodného online systému založeného na databázi, ve které se dá vyhledávat. Klidně to může být i formulář či seznam na bázi Sharepoint webu apod. Slohové dílo ve Wordu si kromě tvůrce už nejspíš nikdo nepřečte. Vhodným formátem pro záznam zkušeností může být třeba jednoduchá tabulka (viz tabulka 3).

Tab. 3

Závěr

Náš seriál je tímto na svém konci. Neměl ambici poskytnout vám komplexní metodiku pro řízení projektů, spíše ukázat, že řadu věcí lze správně dělat i jednoduše, a naopak že ani složité postupy aplikované bezmyšlenkovitě, nemusí vést k cíli. Pokud vás zaujaly některé z prezentovaných nástrojů, tak je spolu s dalšími ve formě řešených příkladů naleznete v naší knize 5 kroků k úspěšnému projektu, kterou vydala Grada na jaře roku 2013. Přeji mnoho úspěšných projektů!

Jan Doležal Autor je ředitelem společnosti PM Consulting. Je držitelem certifikací PMI PMP a IPMA level B. Zabývá se především optimalizací systémů řízení projektů v různých firmách a organizacích.