Někdy mám pocit, že trošku chybí mezioborový nadhled. Pokud se nějaký přístup či metoda osvědčí v jednom z oborů, ostatní obory to hned zavrhnou a řeknou si něco jako: „EVM je pro stavebně investiční akce, to není nic pro nás.“ Je to škoda, protože v podstatě vše lze poměrně jednoduše modifikovat a s úspěchem použít.

Princip EVM, která je často brána jako velmi komplikovaná metoda pro sledování projektu, je přitom velmi jednoduchý. Plán postupu ve věcné, časové a nákladové rovině porovnáváme v konkrétní časový okamžik se skutečně vytvořenými výstupy a se skutečnými náklady, které jsme k danému okamžiku vynaložili.

To přece není tak složité. Skutečná obtíž je spíše v tom, že jako vstup musím mít plán (!) a pak že jsem také schopen určit stav rozpracovanosti… To je to skutečně těžké.

Plánování projektu je základ

Jak zní jeden z mých oblíbených PM bonmotů: „Plán je k ničemu, plánování je všechno.“ Pokud mám mizernou WBS a mizerný plán projektu, je to jako nasypat do základů domu piliny místo štěrku a pak se divit, že mám problémy.

Plánování a prognózování je v projektovém managementu opravdu významným prvkem a vždy tomu tak bude. Je to základ nejen pro EVM, ale i pro většinu dalších procesů při řízení projektu a následně pro úspěch projektu. Nelze jej podceňovat.

Stanovení rozpracovanosti

Předpokládejme, že jsme schopni vytvořit dostatečně kvalitní plán projektu. Jak na rozpracovanost? Tedy pokud to chceme dělat tak, aby se tomu dalo alespoň trošku věřit? Říct, že máme nějaký úkol ze 40 % hotov, je samozřejmě jednoduché, ale je to opravdu tak? Můžeme se na to spolehnout?

Pokud něco stavíme, kopeme, taháme apod., lze prostě změřit, co je hotovo, a je to. Ale při návrhu SW a podobných abstraktnějších činnostech prosté „kouknu a vidím“ moc nefunguje. Ani takové případy ale nejsou ztracené.

Jednou z cest jak vyřešit danou situaci je tvorba řádné WBS na dostatečnou úroveň detailu – samozřejmě výsledkově orientované a se zákaznickou perspektivou (tedy, že dané výsledky, pracovní balíky, prvky WBS jsou formulovány z pohledu jejich příjemce, nikoliv tvůrce).

Stav rozpracovanosti pak lze určovat podle počtu dokončených pracovních balíků, které si v rámci plánování samozřejmě adekvátně naceníme počtem člověkodnů nebo jinými jednotkami, ve kterých chceme sledovat nákladovost projektu.

Tento postup vám možná připomíná agilní přístupy s jejich seznamy požadavků a burn down chartem… A máte pravdu. Je to v podstatě to samé, jen se jiným způsobem došlo k balíkům práce, k provedení a burn down chart se kreslí shora dolů, zatímco S křivky v EVM zdola nahoru. Principiálně však jde o totéž.

Další možný způsob v případě, že nechceme nebo nejsme schopni vytvořit WBS na potřebném stupni detailu, spočívá de facto v pomocné aplikaci milníkové metody. Stanovíte si větší počet konkrétních stavů (např. uživatelské testování modulu X hotovo apod.) a těm přiřadíte stanovený stupeň rozpracovanosti. Není to přesné, ale je to alespoň něco, s čím můžete pracovat.

Práce se změnami

Pokud si teď v duchu říkáte, že s tím počtem změn, které se nám na projektech kupí, a s tím, jak zákazník vlastně neví, co chce, je strašně obtížné plánovat… Tak to v podstatě ani neděláme. Ano, takové situace nastávají.

Pokud se stále jedná o poměrně dobře definovatelný výstup na konci a rozumný počet změn, je stále možné a výhodné zůstat u výše popsaného přístupu s tím, že každou změnu je zkrátka potřeba do plánu adekvátně vložit a de facto vytvořit nový plán počínaje aktuální okamžikem – není pak samozřejmě možné nějak hluboce analyzovat předchozí verze plánu, ale o to ani nejde. To byl jiný projekt, před změnou. Jde o sledování aktuální výkonnosti nad aktuální verzí plánu/projektu.

Pokud je prostředí opravdu velmi turbulentní, zákazník i my máme jen velmi mlhavou představu o výsledku projektu atd., je vhodné zvážit některý z agilních přístupů k řízení projektu, které jsou pro takové situace navržené. To ale není chyba EVM, to je prostě jiná situace.

Ing. Jan Doležal, Ph.D. Autor článku je ředitelem společnosti PM Consulting s.r.o.