Як врятувати проєкт від невдачі: 9 гріхів ризик-менеджменту

Привіт! Я — Орест Дмитрасевич, PMO Competency Manager в Eleks. Також я веду найбільший українськомовний блог про менеджмент — Kaizen, проводжу тренінги, вебінари, записую відео про проєктний менеджмент на YouTube та сприяю розвитку професійності ПМів в Україні.

Робота з ризиками є, мабуть, однією з найскладніших частин роботи менеджера. Звісно, якщо не враховувати роботу з людьми :) В цій статті хочу поділитись своїм досвідом і помилками. Набагато приємніше вчитись на чужих помилках, ніж на своїх, правда ж?

Я брав участь у проєктах, де не було часу на управління ризиками, і результати там були дуже сумними. Все, що ставалось, було для нас несподіваним, на усунення наслідків йшло багато грошей і часу (а час — це також гроші). Звичайно, контролювати всі потенційні ризики неможливо, але якщо продумати хоча б якусь частину, можна врятувати проєкт від невдачі.

Ілюстрація Марії Рибак

Що таке ризики

Перш ніж перейти до основної частини, розберімось з базою. Отже, що таке ризик? Якщо подивитись у PMBok, то там пише, що ризик — це невизначена подія або умова, яка у разі настання може позитивно або негативно вплинути на одну або більше цілей проєкту. Важливо розуміти, що ризик завжди стосується майбутнього. Якщо у вас сталась неприємність на проєкті, то це вже не ризик, а факт. Тож правильно описувати ризики можна за допомогою простої формули: причина → ризик → наслідок.

Формулювання ризиків

З цього і випливає перша помилка в ризик-менеджменті, а саме неправильне формулювання ризиків, яке не дає розуміння ні наслідків ризику, ні потенційного варіанта вирішення проблеми. Поясню на прикладі:

  • «Ми витрачаємо багато часу на комунікацію із замовником» — неправильно. В цьому варіанті в нас нема ризику, ми просто констатуємо факт.
  • «Через різницю в часових поясах ми можемо отримувати відповідь від замовника невчасно, що спричинить затримки з релізом продукту» — правильно. Ось тут ми вже розуміємо, чим ризикуємо (затримка з релізом продукту) і що є причиною (різниця в часових поясах). Відповідно можемо придумати стратегію роботи з цим ризиком. Наприклад, зсунути графік команди так, щоб більше часу перетинатись із замовником, домовитись про базові години для комунікації, щоб вирішувати критичні запитання, погодити час, за який замовник повинен надати відповідь тощо.

Наголошу: що чіткіше ви опишете ризик, то легше вам буде з ним працювати. Це особливо стосується частини з наслідками, в ідеалі потрібно розуміти, який ефект в грошах цей ризик матиме.

Ідентифікація ризиків лише на початку проєкту

Друга помилка, яка стається з ідентифікацією ризиків, — ми це робимо лише на початку проєкту (якщо робимо взагалі). Що раніше будуть виявлені ризики, то швидше можна скласти плани щодо зменшення їх наслідків. Але не варто думати, що ви зможете визначити всі ризики ще на старті проєкту. Ми всі працюємо в динамічних середовищах, і нові можливості чи ризики виникають ледь не щодня. Тому будьте спостережливими та постійно оновлюйте ваш реєстр. Я рекомендую мати регулярні зустрічі (раз на два тижні) з огляду ризиків з ключовими людьми проєкту і, власне, на цих сесіях обговорювати не лише статус вже ідентифікованих ризиків, а й потенційну появу нових.

Ризики визначає лише менеджер

Третя помилка — ризики ідентифікує лише менеджер. Часто я помічаю, що керівники проєктів вважають роботу з ризиками лише своїм завданням. Звичайно, менеджер несе повну відповідальність за (не) успіх проєкту, але ви не можете знати все. Тому що більше людей залучено для визначення ризиків, то краще! В цьому процесі круто використовувати техніку мозкового штурму. Декілька основних правил з брейн-шторму ризиків:

  • уся проєктна команда має брати участь у мозковому штурмі;
  • критика будь-яких пропозицій заборонена;
  • усі потенційні ризики мають бути задокументовані, незалежно від того, чи вся команда це підтримує.

Неправильно обраний метод оцінки ризиків

Четвертий гріх — це неправильно обраний метод оцінення ризиків (кількісний чи якісний). Найпростіший та найбільш звичний для нас спосіб — якісний. Таку оцінку можна провести для будь-якого типу ризику. Вона передбачає експертну думку та суб’єктивний аналіз оцінки події.

Оцінюють за попередньо визначеною шкалою. Це зазвичай або від 1 до 3, або від 1 до 5, залежно від того, наскільки детально ви плануєте аналізувати ризики. Оцінка 1 тут означає найнижчий вплив чи ймовірність, а 5 — найвищий. Також ймовірність часто визначають у відсотках. Тоді я роблю таку шкалу:

Така оцінка є доволі простою, але не завжди точною, бо, як правило, вона базується на сприйнятті людей та особистому досвіді. При такому підході рекомендую не оцінювати ризики самостійно, особливо якщо ви менеджер-початківець, а залучати до цього процесу команду чи інших експертів, які допоможуть.

Інший спосіб оцінювання ризиків — це кількісна оцінка. Такий аналіз можна використовувати, лише коли маємо чисельні дані для вимірювання та прогнозування ймовірності та впливу ризику.

Як правило, це охоплює аналіз впливу ризику навіть на час і витрати. Наприклад, ми можемо правильно оцінити ризик затримки з оформленням вимог до проєкту. Якщо в команді є 10 людей і зарплата кожного працівника в середньому 500 доларів в тиждень, то кожен тиждень затримки буде коштувати 5000 доларів.

Здається, що така оцінка є більш надійною, але це не завжди так, адже не все ми можемо виміряти кількісно. Крім того, така оцінка є більш часо- та трудозатратною, відповідно її рекомендовано використовувати тільки для складних проєктів і найбільш пріоритетних ризиків (які ми вже визначили якісною оцінкою). Також варто зазначити, що кількісний аналіз ризику є життєво важливим у певних галузях. Це, наприклад, будівництво чи медична сфера — там, де під загрозою є життя людей, не варто покладатись на якісну оцінку.

Позитивне мислення

Багато проєктів починаються з безпідставними очікуваннями, що вони не можуть зазнати невдачі. Навіть якщо проєкти чітко визначені з погляду планування, обсягу та ресурсів, то це не гарантує автоматичний успіх. Моя рекомендація — завжди очікуйте гіршого, це допоможе вам мати буфер у разі виникнення неприємностей.

Ризики не пріоритезуються

Чи справді ми повинні щось робити з кожним ризиком? Ні, всі ризики не усунеш. Це нереально і непрактично. Потрібно звернути увагу на найбільш критичні та працювати в рамках обмежень бюджету, часу та скоупу робіт.

Надто загальний план реагування

План реагування є надто загальним (без конкретних дій і власників ризику). В кожного ризику обов’язково повинен бути Risk Owner — людина, відповідальна за реакцію на нього. Це дуже важливо, бо якщо ми цього не визначимо, то всі думатимуть, що цим займеться хтось інший :) Також варто прописувати максимально детальний план дій у разі настання цього ризику, щоб ви просто могли відкрити документ і йти по цьому плану, а не витрачати час на чергові обговорення.

Лише один план реагування

Круто, якщо ваш план реакції на ризик спрацює. Але це не завжди так. Тому я рекомендую мати щонайменше дві (в ідеалі — три) стратегії реагування на випадок, якщо план А не спрацює. Наприклад, у вас на проєкті є ризик звільнення ключової людини. Пом’якшити його можна постійною комунікацією з працівником, визначенням його мотивації та роботи з нею. Але, на жаль, цього може бути недостатньо. Тому план Б, який можна запускати навіть у паралель — передача частини знань цього фахівця (тренінги для інших членів команди, оновлення проєктної документації тощо) і зменшення Bus Factor.

Емоційна реакція

And last but not least — це невиконання власного плану. Коли ризики стаються, це завжди викликає багато емоцій. І в цьому пориві ми можемо забути про те, що планували, і піддатись паніці. Тому моя порада — глибоко вдихніть і видихніть, відкрийте ваш реєстр ризиків, який пропрацьовували протягом всього проєкту, і подивіться, які ж плани реакції ви там складали. Реагувати потрібно швидко, але не емоційно.

Як отримати максимум у роботі з ризиками

  1. Зберіть якомога більше інформації — у тому ж Google можна знайти списки типових ризиків, це є гарною точкою старту. Створіть такий же список ризиків, які стаються у вас, і переносьте його з проєкту на проєкт і постійно доповнюйте.
  2. Майте на увазі невідомі ризики — не все можна прорахувати, тому пам’ятайте про закладання резерву на невідомі ризики (15–30%).
  3. Складіть три плани управління ризиками (Mitigation, Contingency & Fallback Plan).
  4. Регулярно переглядайте ризики та вносьте зміни до планування.
  5. Комунікуйте про результати.
  6. Плануйте, плануйте і ще раз плануйте :)

І пам’ятайте: основою ефективного управління ризиками є розуміння того, що будь-який проєкт може зазнати невдачі.

👍ПодобаєтьсяСподобалось18
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Автор молодець, чекаю наступні статті

Корисна стаття 👍
Все не передбачиш, але однозначно ризики треба постійно моніторити та працювати з найбільш ймовірними з сильним впливом на проект.
Було б круто, якби в статті були посилання на ресурси зі списком типових ризиків та більше прикладів.

Дякую за статтю, але тут дуже б стали в нагоді приклади з ваших власних проектів — як ви правильно врахували ризики і як неправильно (і що з цього вийшло).

Через різницю в часових поясах ми можемо отримувати відповідь від замовника невчасно, що спричинить затримки з релізом продукту" — правильно. Ось тут ми вже розуміємо, чим ризикуємо (затримка з релізом продукту) і що є причиною (різниця в часових поясах). Відповідно можемо придумати стратегію роботи з цим ризиком. Наприклад, зсунути графік команди так, щоб більше часу перетинатись із замовником

Згоден, що ризики потрібно враховувати, але не зовсім згоден з вашим планом їх мінімізації.
З таким же успіхом, можна вимагати знизити зарплати розробників вдвічі, щоб точно влізти в бюджет проекту і уникнути ризику його перевищення.

ому що більше людей залучено для визначення ризиків, то краще! В цьому процесі круто використовувати техніку мозкового штурму. Декілька основних правил з брейн-шторму ризиків

Дивно, але я ще ні в одному проекті не зустрічав brainstorming ризиків.
Орест, як часто ви це у себе проводите і скільки часу витрачаєте?

Скорочу до змісту:
1. Плани ніколи не виконаються як задумано.
2. Плануйте, плануйте, і ще раз плануйте. Бо дешевше 10 разів змінити плани ніж 1 раз потонути в хаосі. Єдина цінність планів в тому, що їх можна міняти постійно, але коли є час (чи інший ресурс), який треба ефективно розподілити — завжди під рукою є актуальний план. Навіть якщо ресурсу не було, було лише передбачення, що він може з′явитися.

Проблема ризик-менеджменту в тому, що ризик є невід’ємною складовою будь-якого процесу. А від так, ризик не можна відокремити. Лише особливі ризики, які краще назвати форс-мажорами, можуть бути передбачені окремо та створений план реагування.

Якщо процес у вас Agile, то і ризик-менеджмент має бути Agile. Намагання автора довести необхідність вотерфолу самими лише базвордами — то вибачайте. Вотерфол ризик-менеджменту гальмує процес. Навпаки, власне сам Agile має починатися з Agile ризик-менеджменту.

PS. Зроби ризики канбанами, тобто картками, побачиш наскільки ними простіше керувати як купкою карток аніж городити систему.
Так, це призведе до обґрунтування овертайму. Але й до обґрунтування його оплати. Япона-менеджмент однако. А якщо хтось помре на роботі... так просто дістань відповідну картку, ти ж передбачив цей ризик. (— ¢ —)

Підписатись на коментарі