Alternativa k Asaně pro řízení rizik projektu: registr, který není seznamem

Registr rizik, který je seznamem úkolů

Asana má hotovou šablonu registru rizik a šablonu matice. Jejich logika je správná: popíšete hrozbu, ohodnotíte pravděpodobnost a dopad, určíte vlastníka a přidáte plán reakce. U jednoho projektu a tuctu rizik to stačí. Předčí to i tabulku, protože registr sedí tam, kde probíhá práce, a srovnání FlexiProject a Asany funkce po funkci vykresluje širší obrázek.

Omezení je v konstrukci. Riziko zde není samostatný objekt, jen úkol s poli navíc. Vše, co plyne z toho, že riziko není práce k udělání, se musí organizovat mimo nástroj.

Co šablona dá a co neumí

Šablona uspořádá informace, a to je její skutečná hodnota. Tři věci nedá.

Riziko nemůže ukázat na jiný úkol, protože samo je úkolem. Nelze tedy zaznamenat, že se daná hrozba týká konkrétní dodávky v harmonogramu. Rizika také nejde porovnávat napříč projekty, protože vlastní pole fungují jen uvnitř jednoho projektu. A neexistuje úroveň nad projektem. Každý registr je sám o sobě úplný a slepý k tomu, co je vedle. Tři týmy mohou řešit stejné riziko dodavatele a žádný z nich se to nedozví.

Tři příznaky, že registr přestal fungovat

Registr aktualizovaný až těsně před řídicím výborem místo průběžně s prací. Pokud je aktualizace samostatná činnost, děje se, když si o ni někdo řekne. Obvykle příliš pozdě na to, aby se dalo něco změnit.

Rizika ručně přepisovaná do zakládací listiny projektu a měsíčního reportu. Tato práce nevytváří žádnou novou informaci a ve firmě nakonec kolují tři verze stejného seznamu.

Otázka „řeší to už někdo“, na kterou se nemá kdo zeptat. Bez úrovně, kde se rizika z různých projektů potkávají, se každé řeší od nuly. Věnujeme se také tomu, na co se dívat, když zvažujete aplikace podobné Asaně.

Co požadovat od registru rizik

Rozdíl mezi seznamem a modulem se scvrkne na sedm věcí. Každou z nich buď řeší systém, nebo se dělá ručně.

Dohromady popisují, co musí software pro řízení rizik poskytnout. Níže procházím požadavky jeden po druhém a ukazuji, jak je FlexiProject řeší.

Matice v rozměrech, které už používáte

Konfigurace matice rizik vypadá jako detail. Je jedním z nejčastějších důvodů, proč modul rizik v PPM systému zůstává prázdný. Firma roky vyvíjela matici tři na tři a v zaváděném systému je natvrdo pět na pět. Nikdo nepřeškolí třicet projektových manažerů na novou škálu jen proto, že to dodavatel rozhodl. Výsledek je předvídatelný: modul se nepoužívá a riziko se vrací na slide.

Ve FlexiProject se rozměry matice nastavují při zavádění, bez programování. Firma přinese škálu, kterou její lidé znají, spolu se zvykem, že daná známka vyžaduje danou reakci. Standard, který jste vyvinuli, tak přežije změnu nástroje.

Karta rizika místo řádku v tabulce

V systému pro řízení projektů FlexiProject je registr rizik samostatným modulem projektu. Každé riziko má název, stav, vlastníka, vazbu na úkol v harmonogramu, kategorii, dopad, pravděpodobnost a datum identifikace. Dopad na harmonogram a dopad na rozpočet se hodnotí zvlášť. To má praktický význam: riziko zpožďující akceptaci o měsíc a riziko přidávající sto tisíc k nákladům si žádají různé reakce. Sdílená známka „vysoký dopad“ je nerozliší.

Nad registrem stojí karta rizika. Kromě dat z registru drží přílohy, plán řízení té hrozby a komunikátor, kde tým řeší toto konkrétní riziko. Vypadá to jako maličkost, ale řeší to skutečný problém. Diskuse v týmovém kanálu zmizí za dva dny. Konverzace zaznamenaná u rizika u něj zůstává. Když se za půl roku někdo zeptá, proč byla zvolena právě tato reakce, odpověď leží na stejném místě jako rozhodnutí.

Riziko připnuté k úkolu v harmonogramu

Registry rizik bývají ploché. Zacházejí s rizikem týkajícím se celého projektu, třeba nedostatkem zdrojů, stejně jako s rizikem týkajícím se jednoho úkolu, například dodávkou od subdodavatele. Jsou to dvě různé situace a řídí se odlišně.

Ve FlexiProject lze každé riziko navázat na konkrétní úkol v modulu harmonogramu projektu. Riziko dodavatele přiřadíte úkolu, který na dodávce závisí, a regulatorní riziko úkolu schvalování. Od té chvíle harmonogram nese informaci o hrozbách. Na řádku úkolu se objeví trojúhelník s vykřičníkem a vedle něj kolečko: červené, když je riziko aktivní, šedé, když ne. Projektový manažer vidí místa, která vyžadují pozornost, aniž by otevíral registr.

Nejvíc to pomáhá, když se plán mění. Když se harmonogram posune, hned víte, která rizika se stala naléhavějšími. Týkají se úkolů, které se přiblížily tvrdému termínu nebo se posunuly na kritickou cestu. Tato informace je i v plochém registru, ale musíte si ji odvodit sami porovnáním dvou seznamů. Takže to obvykle nikdo neudělá. Odděleně vysvětlujeme, jak zvládnout plánování projektů, které si systém udržuje sám.

Riziko jako znalost organizace, ne jednoho projektu

Ve většině firem se způsob, jak týmy identifikují a hodnotí rizika projektu, scvrkne na úvodní schůzku, kde si někdo představuje, co by se mohlo pokazit. Metoda je nespolehlivá. Lidé podceňují hrozby, se kterými se dosud nesetkali. Firma jako celek je obvykle už viděla, jen na jiném projektu.

Šablony se seznamem typických rizik

Seznam možných rizik pro daný typ projektu lze zabudovat do šablony. Tým startující zákaznickou implementaci, výzkumný projekt nebo investici začíná s hotovou bází a upravuje ji na svůj případ. To mění povahu schůzky. Místo vymýšlení hrozeb tým prochází známé a rozhoduje, které platí. Je to rychlejší a účinnější, zvlášť u méně zkušených týmů.

Uzavírací karta a reporty rizik

Druhou stranou tohoto mechanismu je zaznamenání toho, co se skutečně stalo. Uzavírací karta projektu může vyjmenovat rizika, která nastala, a jak byla vyřešena. Týmy plánující pozdější projekty mají přístup k historickým uzavíracím kartám.

Třetím prvkem jsou reporty. V modulu reportů lze postavit zobrazení rizik pro projekty jedné kategorie nebo z jedné organizační oblasti. Nový tým dostane konkrétní odpověď: toto jsou hrozby, které nastaly v podobných projektech. Dohromady tyto tři mechanismy znamenají, že řízení rizik už nezávisí na kompetenci jednoho manažera.

Kategorie rizik a zobrazení pro útvary

Riziko se málokdy týká jen projektového manažera. Právní chce vědět, jaké závazky a spory jsou v portfoliu. Výroba se ptá na technologické výzvy, nákup na hrozby na straně dodavatelů. S registrem zamčeným uvnitř projektu nemůže žádný z nich položit svou otázku.

V nastavení FlexiProject definujete vlastní seznam kategorií rizik, sladěný s tím, jak je ve firmě rozdělena odpovědnost. Zde struktura rozpadu rizik (RBS) přestává být diagramem a stává se něčím, podle čeho systém umí filtrovat. Na tom se staví reporty napříč projekty. Právní vidí právní rizika ve všech projektech, výroba svá, nákup svá. Riziko přestává být soukromou věcí projektového manažera. Samostatně rozebíráme, co znamená skutečná kontrola rozpočtu projektu.

Úroveň portfolia aneb konec řízení stejného rizika třikrát

U několika desítek projektů se některé hrozby ze své podstaty opakují. Stejný dodavatel, stejná změna regulace, stejná nezralá technologie. Jsou-li registry zamčené uvnitř projektů, každý manažer si vede svou verzi toho rizika a dochází k mírně odlišným závěrům.

Software pro portfolia projektů to řeší jinak. Každé portfolio ve FlexiProject má samostatnou záložku rizik. Sbírá hrozby ze všech projektů daného portfolia. Koordinátor vidí opakování a může riziko vyřešit centrálně, s využitím veškeré dostupné znalosti místo jedné perspektivy. Trojnásobné úsilí se mění v jednoho vlastníka a jednu reakci. Odstraňuje to i situaci, kdy tři projekty uplatňují na stejného dodavatele tři různé strategie. Samostatně popisujeme, čím musí být alternativa k Asaně pro PMO.

Konec přepisování: zakládací listina a statusový report

Nejnápadnější úspora se týká přepisování, ne analýzy. V mnoha firmách postup vyžaduje, aby nejvýznamnější rizika dorazila do zakládací listiny projektu a jednou měsíčně do reportu pro vedení. Se samostatným registrem někdo tytéž záznamy přenáší na dvě místa a kontroluje, že se verze shodují.

Ve FlexiProject modul zakládací listiny projektu tahá rizika z registru automaticky. Oba dokumenty jsou konzistentní už z principu, ne díky něčí pečlivosti. Cyklický statusový reporting funguje stejně. Obsahuje-li report sekci rizik, plní se sám z registru a manažerovi zbývá komentář k tomu, jak jsou tyto hrozby řízeny. Činnost, která nevytvářela žádnou novou informaci, mizí, a zmizela z nejhoršího týdne v měsíci.

Kdy stačí šablona

Vedete jeden projekt, řídíte ho sami, máte tucet rizik a nikdo nevyžaduje formální reporting? Šablona registru v úkolovém nástroji stačí. Samostatný modul přidá formalitu, ne kontrolu, protože výše popsané problémy se objevují až ve větším měřítku. Chcete-li širší pohled na možnosti, nejlepší software pro řízení rizik jsme porovnali zvlášť.

Signály, že toto měřítko nastalo, jsou konkrétní. Přibude druhý a třetí projekt a rizika je třeba porovnávat mezi nimi. Někdo mimo projekt se ptá na hrozby v určitém řezu. Postup vyžaduje rizika v zakládací listině a v reportu. Od tohoto bodu seznam s vlastními poli stojí víc práce, než ušetří.

Jak to za dva týdny vyzkoušet na vlastním registru

Srovnání funkcí rozhodne málo, protože stránka každého dodavatele odpovídá na vše ano. Test na vlastních datech řekne víc. Vezměte registr jednoho běžícího projektu a přeneste ho celý, spolu s vaší hodnoticí škálou. Tento první krok ukáže, zda vaše matice do nástroje sedne, aniž byste měnili zvyky týmu.

Pak čtyři testy. Navažte tři rizika na úkoly v harmonogramu a ověřte, že je vidíte v Ganttově diagramu. Posuňte jeden z těch úkolů o dva týdny a podívejte se, zda se obraz hrozeb změní. Postavte report rizik pro jednu kategorii, třeba dodavatele, přes několik projektů. Otevřete záložku rizik portfolia a zkontrolujte, zda se nějaká hrozba opakuje na více místech. Tento poslední test obvykle ospravedlní změnu sám o sobě.

Často kladené otázky

Má Asana registr rizik?

Asana nabízí šablonu registru rizik a šablonu matice. Vytvoří seznam s poli jako pravděpodobnost, dopad, vlastník a plán reakce. Není to samostatný modul, jen projekt složený z úkolů. Riziko tedy nelze navázat na úkol v harmonogramu, porovnat ho napříč projekty ani ho vidět na úrovni portfolia.

Jaký je rozdíl mezi registrem rizik a seznamem úkolů s vlastními poli?

Stejný jako mezi rizikem a prací k udělání. Registr chápe riziko jako samostatný objekt s vlastním životním cyklem, hodnocením, vlastníkem, plánem reakce a vazbami na harmonogram a rozpočet. Seznam úkolů umožní tyto informace zapsat, ale ne je použít mimo jeden projekt.

Co přináší navázání rizika na úkol v harmonogramu?

Ukazuje, kde v plánu hrozba sedí. Ve FlexiProject nese úkol s navázaným rizikem výstražnou ikonu v Ganttově diagramu a barva vedle říká, zda je riziko aktivní. Po každé změně harmonogramu vidíte, které hrozby se staly naléhavějšími.

Můžeme si ponechat vlastní matici rizik?

Ano. Rozměry matice se nastavují při zavádění, takže firma pracující se škálou tři na tři nemusí přecházet na pět na pět. To je jedna z důležitějších podmínek toho, aby se modul rizik používal, a ne obcházel.

Jak začít, když je náš registr rizik dnes v Excelu?

Přenesením jednoho běžícího projektu, spolu s jeho aktuální hodnoticí škálou a kategoriemi. Tabulka obvykle drží všechny potřebné informace. Chybí jí vazby: na úkoly, na jiné projekty a na dokumenty, které stejně vyplňujete ručně. Právě tyto vazby jsou důvodem ke změně, ne pouhý fakt, že registr vedete.

Alternativu k Asaně pro řízení rizik projektu lidé nehledají proto, že by nebylo kam hrozbu zapsat. Důvod je jiný: zapsaná hrozba pak nic nedělá. Registr, který je seznamem, končí u dokumentace. Informace existuje, ale nenapojuje se na harmonogram, nesčítá se napříč projekty, nevrací se firmě na příštím projektu a musí se přepisovat do každého dokumentu zvlášť. Registr, který je modulem, tyto čtyři věci dělá sám. Manažerovi nechává to jediné, co za něj žádný systém neudělá: rozhodnout, jak reagovat. Pokud se váš registr dnes aktualizuje hlavně před řídicím výborem, nejlevnějším způsobem, jak to ověřit, je přenést jeden projekt a navázat tři rizika na úkoly v harmonogramu.