Vymezení EPMS vůči PRINCE2® a PMBOK®

Metodika EPMS - metodika projektového řízení uzpůsobená na specifické podmínky České republiky vznikla v průběhu let 1996 - 2003. Principy jejího fungování byly a jsou neustále ověřovány a zpřesňovány na významné množině složitých projektů. Její autor, Ing. Jaromír Horák, v době jejího vzniku jako majitel dvou společností aktivně řídil realizaci mnoha složitých projektů. Obecné metodiky projektového řízení nebyly v té době reálně a výkonně v prostředí dynamicky se rozvíjející ČR použitelné, což vyústilo ve vznik první verze EPMS. EPMS je proto možné vnímat jako výsledek potřeby řídit svou práci systémem, který by umožnil každý další projekt realizovat s menším vynaloženým úsilím díky opakované aplikaci již ověřených a „vyladěných“ postupů.

Metodika Equilibrium Project Management Solutions vychází z axiomu, že cílem řízení projektů by mělo být zachování rovnováhy projektu, jeho okolního prostředí a rovnováhy jednotlivých cílových skupin mezi sebou. Proto EPMS vede projektové manažery tak, aby výsledky jejich práce nijak negativně neovlivnily vnitřní či vnější prostředí projektu. EPMS podporuje projektové manažery v úsilí vidět projekty z více úhlů, díky čemuž je pak možné identifikovat negativní boční efekty, kterými projekty působí na své okolí.

EPMS ukotvuje všeobecně platný životní cyklus projektu skládající se z šesti fází (Identifikační, Ověřovací, Přípravné, Realizační, Provozní a Likvidační). Projektem dále integrálně prostupují proces „Stabilizace“ získávající strukturovanou i nestrukturovanou zpětnou vazbu od zájmových skupin vně i uvnitř projektu a průběžně korigující cíle projektu dle zjištěného, a proces „Audit a dohled projektu“ provádějící nezávislou kontrolu řízení a průběhu projektu a to zejména po metodické, věcné a smluvní stránce. EPMS dále definuje kompetence, znalosti, ale také morálněvolní charakteristiky projektového manažera.

EPMS je metodika jednoznačně a pragmaticky zaměřená do české praxe, vystavěná za využití letitých koncentrovaných zkušeností s maximální srozumitelností a „tahem na branku“.

Následující schéma přehledně graficky formou spider grafu znázorňuje na škále od jedné do pěti ohodnocení jednotlivých metodik z uvažovaných úhlů pohledu. Logika bodového ohodnocení oceňuje kvalitu pokrytí dané oblasti metodikou přímo úměrným počtem bodů, kdy maximální dosažitelný počet bodů je pět.

Hlavni význačné charakteristické rysy jednotlivých metodik v hodnocených oblastech zdůvodňující výsledek ohodnocení jsou zachyceny níže v textu.

Srovnání metodik:

a) v oblasti životního cyklu projektu

• PMBOK definuje životní cyklus jen velmi obecně a ve srovnání k ostatním metodikám nedostatečně.
• EPMS definuje maximální životní cyklus od identifikace tématu až po likvidaci daného řešení a identifikaci modernějšího řešení funkcionality původní řešení nahrazující.
• PRINCE2 velmi dobře v hierarchii organizační struktury (od řídícího výboru přes projektový tým až po týmy dodávající určitou ucelenou část řešení) popisuje, v jazyce EPMS, realizační fázi životního cyklu projektu.
• PMBOK i PRINCE2 jsou koncentrovány na realizační fázi životního cyklu projektu, kdežto EPMS pokrývá životní cyklus projektu v celé jeho komplexitě.

b) v oblasti dokumentace

• PMBOK nedefinuje žádné šablony dokumentů vystupující z jednotlivých procesů znalostních oblastí.
• EPMS jednoznačně definuje věcnou strukturu výstupních dokumentů, které musí být generovány jednotlivými fázemi životního cyklu projektu. Formální podoba jednotlivých dokumentů není rigidně dána a je zde ponechán určitý stupeň volnosti pro uzpůsobení dokumentu dle zvyklostí organizace a odvětví, ve kterém organizace působí.
• PRINCE2 navrhuje a v šablonách ukotvuje strukturu požadovaných dokumentů vznikajících během projektu. Při určitých aplikacích metodiky může robustnost požadované dokumentace vést na přebyrokratizování celého projektu a zahlcení jednotlivých rolí vypisováním dokumentů. PRINCE2 zde nezapře svou genezi – z metodiky lze snadno poznat její původní orientaci na projekty pohybující se v oblasti informačních a komunikačních technologií a následné zobecnění i mimo tuto oblast.
• Zatímco PRINCE2 předkládá šablony pro každý z definovaných dokumentů vznikajících v průběhu aplikace definovaného procesního rámce na projekt. EPMS nastiňuje ve formě hmatatelných dokumentovaných výstupů, co je třeba v jednotlivých životních fázích projektu ošetřit pro umožnění řízeného přesunu do fáze následující.

c) dle procesů ČSN ISO 10006:2004

Následující srovnávací tabulka mapuje jednotlivé požadavky ČSN ISO 10006:2004 tak, jak je ověřuje certifikační audit této normy projektového řízení, na srovnávané metodiky. Každý z požadavků ISO 10006, respektive kvalita jeho pokrytí metodikou, je ohodnocen na pětistupňové škále:

• 0 – vůbec nepokrývá
• 1 – formálně zahrnuje
• 2 – pokrývá průměrně
• 3 – metodika říká co a jak v požadovaném procesu konat
• 4 – metodika říká nejen co a jak, ale i proč daný proces konat

d) dle náhledu na roli projektového manažera v projektu

• PMBOK chápe projektového manažera jako: „Osobu přiřazenou k projektu k dosažení projektových cílů a zodpovědnou za řízení projektu“. Projektový manažer musí rozhodovat o vhodnosti a hloubce aplikace dané procesní skupiny na projekt. Dle definice procesních skupin a jejich integrálního využívání v průběhu celého projektu je patrné, že role projektového manažera dle PMBOK je tedy zejména plánovací (co a kdy se má stát), produkční = zajištěním patřičných zdrojů pro výkon (kdo to vykoná) a monitorovací (tj. sleduje a vyhodnocuje odchylky od projektového plánu), plus navíc formálně zahajuje danou fázi projektu a řídí její ukončení akceptací výstupů.
• PRINCE2 ustavuje roli projektového manažera do čtyřvrstvé organizační struktury a chápe ho jako roli zodpovědnou za řízení projektu na každodenní bázi, kdy nestandardní situace (výjimky) a rozhodování o nich je v gesci projektové rady. Projektový manažer má za povinnost této projektové radě reportovat o průběhu projektu.
• EPMS chápe roli projektového manažera nejen v logice procedurálně zahajující a ukončující danou fázi, plánující a alokující si zdroje, ale také natolik zodpovědnou za definované výstupy, že v kritických případech fyzicky vykoná aktivity nutné pro doručení výstupu zákazníkovi.