V předchozím článku jsme naznačili otázku smysluplnosti vytváření plánu, o kterém víme, že nebude zcela naplněn. Důvody jsou však zřejmé. Bez plánu řízení projektu není jasné, jaké, kolik a kdy potřebujeme lidi, zdroje atd., nemáme srovnávací základnu k aktuálnímu stavu projektu a nejsme schopni vyhodnotit stav projektu ani relevantně odhadnout další vývoj, nejsme schopni efektivního změnového řízení a nastávají různé komunikační a kompetenční šumy. To vše samozřejmě platí v případě, že je plán řízení projektu dostatečně kvalitní. Vzhledem k rozsahu článku se budeme nadále zabývat především částí plánu řízení projektu, která se zabývá časem, tedy harmonogramem projektu. V ostatních oblastech (rozsah, rozpočet, …) uvedené platí analogicky.

Jak tedy pracovat s plánem během realizace?

Pamatuji si několik situací, kdy jsem se ocitl na jednání o projektu v neuspokojivém stavu. Začali jsme vymýšlet, co s tím. Na otázku, zda mohu vidět harmonogram projektu, jsem poměrně často dostal kladnou odpověď. V některých případech jsem následně obdivoval i pěkně vyvedený harmonogram projektu zpracovaný v adekvátním softwaru. Pak jsem si ale všiml, že v harmonogramu není nijak naznačeno, jak se projekt od začátku vyvíjel. Ptal jsem se tedy dál: „Jak starý je tento harmonogram?“ „To je plán projektu, se kterým byl před osmi měsíci spuštěn,“ zněla nejčastější odpověď. „Aha, a kde je aktualizace k dnešnímu datu? Jak se projekt v čase vyvíjel?“ pokračuji v dotazování. Zamyšlené pohledy: „Nic takového nemáme.“

„Takže stav projektu odpovídá tomuto harmonogramu,“ nedám si pokoj. „To ani náhodou, to už je úplně mimo,“ dostává se mi odpovědi. Následně konstatuji, že mají hezkou, barevnou malůvku na zeď, ale jako podklad pro řešení situace na projektu je to v podstatě k ničemu. Základním pravidlem je aktualizace, respektive práce s plánem projektu, který obsahuje reálný stav k danému datu, reflektuje případně schválené změny atd. Zní to triviálně, ale překvapivě často tomu tak není.

Jak zjednodušit a popsat realitu?

Způsobů, jak určovat stav jednotlivých činností, je poměrně mnoho. Některé se snaží o maximální jednoduchost, jiné zase o co nejvyšší informační komplexnost a hodnotu. Mezi ty nejjednodušší patří tzv. stavové metody. Například postup 0–50–100 pracuje se třemi stavy činnosti v harmonogramu. Dokud není práce zahájena, činnost má nula procent hotovo. Ve chvíli, kdy se začne pracovat, je přiznána padesátiprocentní dokončenost, která zůstává až do dokončení, kdy je teprve přiznáno sto procent. Ač to vypadá až trapně jednoduše, má to své kouzlo v rychlosti a snadnosti použití, přičemž výsledky jsou často přesnější, než když se tým snaží postupovat tzv. procentuální metodou, při které se projektový tým snaží určit přesné procento rozpracovanosti úkolu. Je diskutabilní, jak poznám, že je činnost z 37 procent hotova, a navíc je často poněkud rozostřeno, co dané číslo vlastně znamená. Utraceno 37 procent času? Peněz? Vytvořeno 37 procent výstupů? Dále je také velmi úsměvný, byť pravdivý bonmot, že prvních osmdesát procent činnosti zabere osmdesát procent času, zbylých dvacet procent činnosti zabere dalších osmdesát procent času. Není pak přeci jen lepší ne zcela přesná pravda, navíc rychle a levně získaná, než pracně vytvořený pravděpodobný omyl?

Přiznám se bez mučení, že pokud mám alespoň trochu možnost, snažím se aplikovat přeci jen o něco složitější postup, při kterém se reportuje skutečně odvedená práce a odhad práce do dokončení, například v člověkodnech. Tento způsob v sobě totiž od základu obsahuje predikci dalšího vývoje, který projektového manažera zajímá ze všeho nejvíc. Daný reporting od lidí zodpovědných za konkrétní činnosti přitom může obsahovat i jen jedno číslo – kolik člověkodnů je odhadováno do dokončení. Vše ostatní si vhodně nastavený informační systém dohledá a spočítá sám. Pravda, chci poté reporting třeba i každý den. Nicméně, znáte jednodušší reporting než jedno číslo? Zabere to deset sekund i s přihlášením do systému a máme každý den aktuální přehled o stavu projektu.

Pokud máme projekt, kde z vývoje jednotlivých činností nelze na stav moc usuzovat, respektive je aktivita rozmístěna v diskrétních časových intervalech, jako jsou například projekty z oblasti vzdělávání a jiné tzv. měkké projekty, chce to něco jiného. Jednou z možností je tzv. milníková metoda, při které po úvodním vytvoření harmonogramu definuji větší počet milníků, ke kterým se snažím co nejpřesněji určit stav (co má být vytvořeno, kolik má být v rozpočtu atd.), a ke každému milníku pak uspořádám schůzku, na které probereme odchylky od požadovaného stavu a rozdáme adekvátní úkoly. De facto tak do jisté míry opouštíme Ganttův diagram a nahrazujeme jej řetězcem definovaných stavů – milníků. V případě výraznějších změn je však obvykle potřeba se ke Ganttu vrátit.

V případě, že se jedná o velmi složité, třeba i stavebně investiční projekty, které jsou velmi náročné na tok peněz a další aspekty, je vhodná metoda řízení dosažené hodnoty (EVM – earned value management), jejíž aplikaci v IT pěkně popsali pánové Mareček a Čermák v IT Systems č. 10/2013. Princip EVM je založen na porovnání plánované hodnoty činnosti (vyjádřené v penězích, člověkodnech nebo i v jiných vhodných jednotkách) se skutečně vytvořenou hodnotou k danému datu (poměr nula až sto procent plánované hodnoty) a skutečnými náklady k danému datu. Výstupem je pak report, že podle plánu měla být vytvořena hodnota deset člověkodní, ve skutečnosti je vytvořena hodnota odpovídající pěti člověkodnům a bylo utraceno již dvanáct člověkodnů. Tedy velmi komplexní informace, se kterou lze dále pracovat.

Kdy a jak měnit plán projektu?

Zásahy na základě aktuálních reportů z daných činností (například činnost jsme začali o dva dny později a skončili čtyři dny po termínu) by měly být do plánu zadávány nejlépe automatizovaně. Jinými slovy operativně, a plán by se nám tedy měl neustále měnit těmito drobnými zásahy. To však obvykle neznamená nic zásadního. Až v případě, že mají například posuny v termínech jasný trend nebo přesahují tolerovanou mez, je potřeba plán skutečně změnit.

Základními zásahy tu může být posun termínu na základě trendu nebo nějaké neočekávané události, která nás skokově posunula, nebo snaha o taková opatření, která by zajistila dodržení původního termínu. Změny, respektive jejich zdroje, lze zcela nejobecněji rozdělit na ty:

• způsobené naším nesprávným odhadem,
• způsobené vnějšími vlivy, se kterými nic nenaděláme,
• které můžeme, ale nemusíme realizovat.

První případ je celkem jasný. Prostě jsme odhadli, že nám bude něco trvat deset dnů, ale ukázalo se, že to bude patnáct. Toto je typický příklad změn, které mohou mít trend (vše „podsekávám“ o patnáct procent). Ve druhém případě se může jednat o změnu legislativy, živelnou pohromu, zánik dodavatele atd. – zde nezbývá než se přizpůsobit. To je případ skokové změny. Třetí oblast jsou požadavky vznesené některou zainteresovanou stranou, o kterých lze vždy jednat. V každém případě je vhodné udělat analýzu, jaký bude mít změna dopad na čas, rozsah a náklady projektu, případně i další dopady. V první a druhé oblasti změn to je v podstatě součet škod, ve třetí to jsou náklady na provedení změny, které musí být žadatelem uhrazeny. Pro tento případ se nám bude opravdu hodit takový plán řízení projektu, vůči kterému půjde požadovaná změna dobře porovnat ve všech relevantních oblastech a půjde dobře vyčíslit, jaké prodloužení termínu a vícenáklady představuje.

Co když jsme pod úrovní detailu harmonogramu?

Na každé poradě a velmi často i mimo ni vyvstane mnoho nejrůznějších záležitostí k řešení, které však nevyžadují žádný zásah do plánu řízení projektu, neboť jsou pod jeho rozlišovací úrovní. Zároveň je však potřeba se jim věnovat, jinak mohou přerůst ve vážnější problémy. Efektivním nástrojem na zvládání této operativy je seznam bodů k řešení, do kterého zapisují všichni členové projektového týmu v okamžiku, kdy problém (bod k řešení) vznikne (nečekají tedy na poradu projektového týmu). O každém novém záznamu by měl dostat obratem informaci projektový manažer, který přiřadí jednotlivé body někomu k řešení (o čemž by měl dotyčný ihned dostat informaci) a dbá na to, aby byly včas a uspokojivě vyřešeny a zadavatel o tom byl informován. Seznam bodů k řešení je vhodné sdílet s celým týmem. Proto je standardně veden jako seznam na vhodném webu projektu apod. (může mít například podobu výše uvedené tabulky).

Provedení může být samozřejmě i v Excelu v nějakém sdíleném úložišti apod. Podstatná je dostupnost členy týmu a nejlépe automatizované rozesílání informací o nové položce či změně stávající.

Příště

Některým změnám se nevyhneme, jiné lze předvídat a třeba i předem eliminovat. Nejen k tomu slouží analýza rizik a další nástroje, které si příště představíme. Náš projekt také řádně ukončíme a poučíme se z něj.

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.