Riziko projektu – jak na něj aby to k něčemu bylo?

| Jan Doležal

riziko projektu

Riziko projektu je podle definice nejistá událost nebo podmínka, která pokud nastane, má negativní vliv na dosažení cíle projektu. Jedná se tedy o něco, co může být, ale také nemusí! Nejedná se o již známý problém typu nedostatečného rozpočtu nebo jistotu nevhodnosti zvolené technologie do daného prostředí. Riziko projektu je zkrátka něco možného, co ale zatím nenastalo a proto máme obvykle trošku problém jej popsat (byť se najdou jedinci, kteří popisují možná rizika vždy a všude). Správná formulace rizika projektu je významnou, avšak obtížnou součástí řízení rizik projektu (které je souhrnněji popsáno v naší PM wiki). Pojďme si ukázat, jak na to.

Mnoho projektových manažerů, kteří se snaží své projekty řídit dobře však v oblasti projektových rizik zůstává na půl cesty. Rizika tak nějak řídí, ale není to ono. V mnohých registrech rizik lze nalézt v kolonce „Riziko projektu“, případně „Popis rizika“ formulace jako:

  • Nedostatečná součinnost zákazníka
  • Problém s dodavatelem (zpoždění)
  • Problémy a průtahy s vývojem

K tomu je následně přiřazena nějaká hodnota rizika (v lepším případě na základě odhadu pravděpodobnosti a dopadu) a formulováno více či méně obecné opatření „ujistit se o součinnosti zákazníka“ apod.

Takový registr rizik je pak spíše formální záležitostí bez větší přidané hodnoty. Obzvláště pokud jej čte někdo jiný, než kdo jej psal – moc užitečných informací se nedozví.

Riziko projektu jako sled událostí

Správný popis rizika projektu je ve formátu hrozba – scénář – popis dopadu, přičemž scénář může být složen i z vícero příčin a následků za sebou: hrozba – událost 1 událost 2  událost 3 – popis dopadu.

Tedy co nejkonkrétněji, s co nejpřesněji uvedenými dopady do našeho projektu. Je zřejmé, že se bude jednat o více či méně přesné odhady, ale je potřeba mít „něco v ruce“. Formulace typu „nedostatečná součinnost zákazníka způsobí zpoždění“, opravdu nestačí, protože s tak nekonkrétními informacemi se nedá dále smysluplně pracovat. Není se čeho chytit. Při stanovování pravděpodobnosti a určování míry možného dopadu se totiž budeme potřebovat o něco opřít a následné hledání nějakého opatření ke snížení rizika obvykle spočívá v přerušení (ovlivnění) toku příčin a následků ve scénáři daného rizika. A pokud žádný tok není, není co přerušovat.

Lépe je tedy formulovat dané riziko projektu jako:

Zákazník nebude v potřebných termínech dodávat podklady nebo budou tyto obsahovat nedostatky, což způsobí průtahy při vývoji v řádu týdnů a neefektivní alokaci týmu, nebude tedy moci být splněn termín projektu až o jeden měsíc a vícenáklady spojené s čekáním a předělávkami až 20 čld.“

Nebo:

Dodavatel se zpozdí se subdodávkou až o jeden měsíc, takže zamluvení pracovníci již budou alokováni na jiný projekt, takže pokud budeme chtít projekt udělat v termínu, budeme muset najmout vnější zdroje, což projekt prodraží až o 1 500 000, což povede ke ztrátě byznys casu projektu (k čemuž dojde i při nedodržení termínu).“

Pokud formulujeme riziko projektu tímto způsobem, tedy od identifikace příčiny, přes scénář (sled událostí) až po kvantifikovaný (!) popis dopadu na některé z aktiv (termín, rozpočet, …), je mnohem jasnější, co by se mohlo stát a jak závažné to asi je. Také se nám bude mnohem lépe hledat vhodné opatření pro takové riziko projektu.

Řízení rizik je souhrnněji popsáno zde.

Jak rizika řídit Vás naučíme i na našem kurzu Projektové řízení krok za krokem , další informace se dozvíte např. i v knize Projektový management.

Kniha Projekvý management obsahuje i pojem riziko projektu

O autorovi článku

Jan Doležal

Jan Doležal

V současné době se zabývá především hybridními přístupy, agilitou v organizacích (SCRUM, SAFe, LeSS), Managementem 3.0 a vývojem simulačních her sloužících jako trénink projektového řízení nebo agilních přístupů.

Dříve mimo jiné zastával pozici vedoucího projektové kanceláře a řídil velké mezinárodní projekty (Evropa, Jižní Amerika). Má zkušenosti především s projekty z IT, strojírenství nebo elektrotechniky. Projektovému řízení se aktivně věnuje od roku 2001.

Je vedoucím autorem několika knih o projektovém řízení, např. „Projektový management“, „Agilní přístupy vývoje produktu a řízení projektu“ nebo „Projektový management v praxi“.

Disponuje certifikací PMI PMP, IPMA B a CSPO – Certified SCRUM Product Owner a CSP-SM – Certified SCRUM Professional – SCRUM Master od SCRUM Alliance. Další podrobnosti čtěte zde.

Další zdroje informací

Komentáře (0)

Zatím žádný komentář.

Přidejte váš komentář

Vaše e-mailová adresa nebude zveřejněna. Pole označená hvězdičkou (*) jsou povinná.