facebook LinkedIN LinkedIN - follow
IT SYSTEMS 10/2013 , Projektové řízení

Přístupy k řízení rizik v IT projektech



DeloitteŘízení rizik by mělo být nedílnou součástí realizace projektů bez ohledu na to, co je vlastním předmětem jejich dodávky. Není tedy žádnou překvapivou informací, že projekty v oblasti informačních technologií nejsou v tomto ohledu výjimkou a rizika jsou během projektu aktivně řízena.


Doporučený přístup k řízení rizik je dnes součástí každého z nejvíce rozšířených a mezinárodně uznávaných standardů pro řízení IT projektů, tedy PMBOK (Project Management Body of Knowledge), PRINCE 2 (Projects in Controlled Environments) a IPMA (International Project Management Association). I když v rámci své praxe na pozici projektového manažera primárně využívám především standardu PMBOK, dovolím si po bližším náhledu do zbylých dvou standardů konstatovat, že v oblasti řízení rizik se od sebe odlišují jen v drobných detailech. Vzhledem k této skutečnosti budu při dalším popisu procesu vycházet primárně z výše uvedeného standardu, který je v rámci společnosti Deloitte při realizaci projektů využíván.

Standardizované řízení rizik

Standard PMBOK definuje riziko jako nejistotu, která v případě, že nastane, může mít negativní nebo pozitivní vliv na projekt. Obecně se ale v projektech pracuje spíše s riziky majícími negativní dopady. Jak již bylo výše řečeno, mezinárodně uznávané standardy definují základní set procesních kroků řízení rizik, které by měly být v daném IT projektu realizovány. Za jejich dodržování primárně odpovídá projektový manažer, případně dedikovaný manažer rizik (risk manager). Je důležité si uvědomit, že řízení rizik je periodicky se opakující proces po celou dobu životního cyklu projektu, a to až do jeho ukončení. Kromě krátkodobých projektů, kde může dojít k situaci, že je seznam rizik identifikovaných na počátku projektu konstantní po celou dobu běhu projektu, dochází v praxi většinou k neustálému doplňování, analyzování a uzavírání rizik. Jako podpora řízení rizik jsou buď využívány více či méně sofistikované nástroje umožňující automatizované workflow procesů, nebo je nutné procesy administrovat manuálně, což může způsobovat vyšší časovou náročnost a potenciální chybovost v procesu.

Podívejme se nyní na kroky, kterou jsou v rámci procesu řízení rizik IT projektů definovány standardem PMBOK.

Plánování řízení rizik

Při plánování procesu je vedením projektu definován způsob, jakým budou rizika v projektu řízena. Jedná se zejména o definici odpovědných osob, formy vedení seznamu rizik, frekvenci jeho aktualizací, komunikaci rizik v projektu či definování eskalační pyramidy procesu. Tato pravidla jsou běžně formalizována v dokumentu Plán řízení projektu, u větších projektů bývá zpracován separátní plán řízení rizik. Je důležité, aby byla pravidla řízení rizik schválena či jinak zafixována řídícím výborem nebo přímo sponzorem projektu, předchází se tak budoucím neshodám mezi jednotlivými stranami projektu. V praxi mají organizace většinou metodiku projektového řízení, z níž projektový tým vychází, nebo návrh procesu požadují přímo po dodavateli projektu.

Identifikace rizik

Prvotní identifikace projektových rizik probíhá během plánovací fáze projektu, kdy jsou rizika zaevidována v seznamu rizik (někdy nazývaném i registr rizik), který bývá umístěn na sdíleném úložišti projektové dokumentace, nebo přímo v softwarovém nástroji. Nejčastějším zdrojem tohoto prvního seznamu bývá SWOT analýza provedená před zahájeními projektu, brainstorming projektového týmu nebo to mohou být generická rizika. V průběhu projektu jsou rizika identifikována na projektových schůzkách na základě vývoje dodávky projektu nebo vyplývají ze změny okolního prostředí projektu (změny v organizaci, legislativě, na trhu, v projektovém portfoliu apod.). Je důležité si uvědomit, že identifikace rizik není pouze záležitostí projektového manažera, ale všech členů projektového týmu, kteří by měli projektovému manažerovi své návrhy komunikovat.

Kvalitativní analýza rizik

Pro každé identifikované riziko je následně prováděna jeho kvalitativní analýza, jejímž cílem je určení pravděpodobnosti rizika a závažnosti dopadů, pokud by dané riziko skutečně nastalo. Těmto dvěma ukazatelům jsou následně přiděleny numerické hodnoty tak, aby bylo možné jejich násobením získat tzv. index kritičnosti rizika. Běžně jsou pro každý ukazatel využívány hodnoty jedna až čtyři, kdy součinem těchto hodnot vzniká přehledová matice 3×3, 3×4 či 4×4, přičemž rizika s nejvyšším indexem jsou logicky považována za ta nejkritičtější a jsou řešena v rámci projektu prioritně. Kvalitativní analýza rizik pracuje se subjektivní mírou abstrakce, což při vynechání následujícího kroku (tj. kvantifikace), může způsobit zkreslení kritičnosti jednotlivých rizik. V rámci projektů je tato skutečnost nejčastěji řešena obhajobou stanovených hodnot před řídícím výborem projektu nebo quality assurance (řízením kvality) projektu.

Kvantitativní analýza rizik

Během kvantitativní analýzy rizik jsou prováděny simulační techniky, jejichž cílem je převedení numerických hodnot do skutečných finančních hodnot (tj. kvantifikace) tak, aby měla daná organizace co nejbližší představu, jaké pro ni může mít příslušné riziko dopady. Tento převod z abstraktních do finančních hodnot umožní návrh dalšího postupu, jak s rizikem naložit (tj. akceptace, mitigace, eliminace apod.). Pro příklad, kdy neznáme finanční dopad rizika a rozhodneme se riziko plně eliminovat, může nastat situace, že vlastní náklady na jeho eliminaci jsou vyšší než potenciální škody, které může riziko na daný projekt či organizaci mít. Kvantifikace tedy slouží jako důležitý nástroj pro rozhodování, jak bude s jednotlivými riziky v průběhu projektu nakládáno. U velkých projektů jsou často na začátku projektu alokovány finanční rezervy na pokrytí výše uvažovaných škod, u menších projektů je to však velmi výjimečné.

Prevence rizik

Pro každé z identifikovaných a analyzovaných rizik je projektovým manažerem určen způsob, jakým bude dané riziko řízeno. V praxi je nejvyužívanějším přístupem mitigace rizika, kdy jsou provedeny kroky směřující k minimalizaci rizika, ale ne jeho úplné eliminaci. Riziku je přidělen jeho vlastník (může to být i projektový manažer osobně), jehož odpovědností je příslušné kroky realizovat a informovat projektový tým o jejich průběhu. Jednotlivé kroky popisuje vlastník rizika v rámci registru rizik projektu. V praxi jsou tyto kroky nejčastěji nazývány jako opatření prevence rizika (OPR) nebo nápravná opatření.

Monitoring řízení

V projektu je na pravidelné bázi kontrolován projektovým manažerem stav registru rizik a realizace jednotlivých OPR. Stav řízení rizik je u projektů standardní položkou na programu hlavního nebo řídícího týmu projektu. Příslušné úrovně projektu jsou zároveň také eskalačními úrovněmi pro řešení jednotlivých rizik, což znamená, že členové daného týmu jsou oprávněni rozhodovat o změnách OPR, akceptacích rizik apod. U větších projektů jsou zřizovány dedikované platformy (risk committee), na kterých jsou řešena pouze projektová rizika. Frekvence monitoringu rizik je závislá na několika faktorech, kterými jsou zejména délka a rozsah projektu. Nejčastěji je využíván jedno- až dvoutýdenní interval pro aktualizaci stavu řízení rizik.

Rizika neberme na lehkou váhu

Pro úspěšnou realizaci IT projektů v organizacích je důležité, aby proces řízení rizik nebyl brán na lehkou váhu. Často se stává, že řízení rizik je v rámci projektu v analogickém postavení jako řízení bezpečnosti v organizaci, kdy těmto procesům není věnována patřičná pozornost. Oba procesy pracují s potenciálními proměnnými, což mívá často za následek to, že se nejdřív musí v projektu či organizaci stát nějaká nepříjemná událost, aby si řídící výbor či management uvědomili jejich důležitost a nezbytnost. Nejvhodnějším přístupem, jak tomu předejít, je nastavit standard řízení rizik projektů v organizaci tak, aby byl důsledně využíván při realizaci všech projektů. Kontrolu kvality nastavení standardu poté může ověřovat periodicky interní či externí auditor, dle možností dané organizace.

Ondřej Kadlec

Autor působí jako senior konzultant oddělení IT Consulting ve společnosti Deloitte. Specializuje se na projektový management, řízení kvality IT projektů, a to zejména v oblasti bankovnictví a finančních služeb, energetiky, výrobních podniků a veřejné správy.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.