Як впровадити управління ризиками в проєкті

Проєктний менеджмент – це важлива роль в IT-розробках абсолютно різних масштабів. Від невеличкого додатка, у якому користувач може рахувати калорії, до повноцінної кросплатформової хмарної системи. Станом на 2023-ій існує близько 168 000 компаній, що займаються розвитком фахівців цього профілю та їх інтеграцією в аутсорсингові проєкти (чи навіть дозволяють бізнесу наймати експертів для розширення штату).

Така статистика демонструє нам, що роль PM зараз є критично важливою, а також досить популярною серед тих, хто або вчиться на цю професію, або просто бажає перекваліфікуватись. Для роботи такі спеціалісти використовують профільне ПЗ, ринкова капіталізація якого сягне вартості в $9.81 млрд уже до 2028-го. І знову ж, на прикладі цієї статистики ми бачимо, що ніша є важливою, а роль ціниться тими, хто користується послугами PM, тобто IT-фахівцями.

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

Сьогодні ж поговоримо про важливість управління проєктними ризиками, детально проаналізуємо:

• Які є церемонії менеджменту ризиків.
• Як візуалізуються ці ризики.
• Які бувають ролі та відповідальність в процесі.
• Як продати цю послугу клієнту.
• Чому проєкт лише виграє від менеджменту ризиків.

Стаття сформована провідними фахівцями, які з власного досвіду знають нюанси всього, що пов’язане з BA та PM. Гарантуємо, ви не нудьгуватимете, читаючи цей матеріал.

І почнемо ми з тезисного визначення терміну «культура ризиків».

Коротко про головне: що таке культура ризиків і навіщо вона потрібна проєктному менеджеру. Де шукати підтримки?

«Культура ризиків» означає відношення до ризиків та їх прийняття на всіх рівнях. Тобто від топменеджменту і до безпосередньо розробників проєкту.

Як правило, «культура ризиків» тримається на чотирьох китах:

1. Правильне відношення «зверху». Важливо, щоб топменеджмент подавав приклад того, як потрібно дотримуватись цінностей компанії та реагувати на ризики.
2. Підзвітність. Необхідно, щоб всі залучені до проєкту фахівці розуміли цінності тих же ризиків і вміли адекватно реагувати на них чи навіть нівелювати за потреби безпосередньо в процесі роботи.
3. Ефективне реагування на зміни. Відсутність рамок, які б стримували коригування процесів, цілей чи цінностей проєкту, реакцій на ризики тощо.
   Засоби заохочення. Фінансове чи нефінансове стимулювання працівників, винагороди за активність та ініціативність, інтеграція метрик KPI в процеси.

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

Інвестор

Має бути інтегроване таке поняття, як «спонсор ризиків»: клієнт або інвестор повинні зрозуміти (зазвичай на прикладі фінансів та цифр), яким чином той чи інший ризик вплине на проєкт.

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

Це дозволить зацікавленій особі прийняти превентивне рішення та сфокусуватись на розв’язанні проблеми ще до її виникнення.

Потреби бізнесу

Обов’язково потрібна підтримка серед тих, хто бере участь у безпосередньому процесі розробки. Це можуть бути як функціональні менеджери, так і стейкхолдери, інвестори, начальники відділів.

Першочергово вам потрібно сформувати тезиси, чому менеджмент ризиків є важливим для компанії. Наприклад, щоб:

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

І це далеко не повний список аргументів, які можна використати для просування та популяризації ідеї керування ризиками у компанії (пріоритетно – серед топменеджменту).

GAP Analisys

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

Або ж можна провести GAP-аналіз, в процесі якого встановиться:

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

Це дозволить продемонструвати зацікавленим особам важливість менеджменту ризиків не лише для актуального проєкту, але і для бізнесу в цілому.

Дорожня карта інтеграції менеджменту ризиків

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

Тому, згідно з канонами жанру, вам, як PM, необхідно реалізувати дорожню карту імплементації. Як це зробити:

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

У підсумку ви зможете ефективно, а головне – послідовно, без різких змін запровадити менеджмент ризиків у компанії (чи хоча б у конкретному проєкті).

Ролі

Ще одним значним фактором у формуванні менеджменту ризиків є ролі. Ролі в дуже умовному сенсі, оскільки вони розподіляються між всіма зацікавленими особами.

Наприклад:

• Керівний комітет. Можна сказати, що це своєрідна комісія, яка стежить, щоб ризики були ідентифіковані, а процеси по їх нівелюванню виконані превентивно. Зазвичай включає стейкхолдерів, інвесторів, власників продуктів тощо. І за ними ж закріплюється право приймати ключові рішення щодо того, що робити далі з ризиками.
• Власники ризиків. Відповідальні особи (найчастіше тімліди, керівники відділів тощо, аж до окремих розробників), які на кожному рівні контролюють ризики, усувають їх чи хоча б мінімізують вплив на проєкт.
• Проєктний менеджер. Своєрідний «стовп» всього процесу менеджменту ризиків. Слідкує, щоб правила та процеси виконувались всіма, хто залучений до проєкту. Також комунікує з верхніми та нижніми рівнями для синхронізації розуміння того, що це за ризики, які вони матимуть наслідки та як їх усувати чи попереджувати.
• Бізнес-аналітик. Особа, що документує та аналізує ризики, їх потенційний вплив на проєкт. Ну і, відповідно, комунікує з PM, стейкхолдерами, топменеджментом, щоб розробити ефективну стратегію керування ризиками.

Без зазначених ролей вся система менеджменту ризиків розвалиться раніше, ніж почнеться її повноцінна імплементація. Тому зважайте на це і розподіляйте ролі на ранніх етапах впровадження методики.

Менеджмент ризиків: інтеграція та акценти на різних етапах

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

Етап ініціації чи передпроєктний реліз

Перш за все, про ризики потрібно думати разом з командою, щоб ефективніше їх ідентифікувати. Причому у двох ключах: позитивному та негативному.

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

Уявіть, які перспективи відкриваються, якщо замінити регіон публікації з СНД, наприклад, на Європу, США чи Азію. Це і ширша ЦА, і кращі умови монетизації, і демократичніші регулятори. Чим не профіт?

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

Також ще на етапі ініціації важливо проговорити ризики з трьох боків:

1. Клієнтського. Сегментація, канали просування, моделі монетизації, цінність, попит тощо.
2. Продуктового. Проблема/рішення, цінність рішення та пропозиції, метрики вимірювання і т.д.
3. Ринкового. Альтернативи, канали дохідності, вартість реалізації, потенційний ROI, перспективи.

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

Наступне, на що слід звернути увагу – контракти, а точніше, їх типи. Кожен вид контракту несе певні ризики всім сторонам. Тому важливо знайти золотий компроміс і, як правило, це модель T&M (Time and Materials). Слід одразу ж прописувати ризики, всі, які будуть ідентифіковані на ранніх етапах.

Зверніть увагу ще на один аспект, а саме – COQ (Cost of Quality). Помилки завжди коштують більше, тому варто одразу ж сфокусуватись на якості проєкту. Навіть стандарт ISO 9001 має таке положення, що якість продукту цілком залежить від керування ризиками. Тому мовою якості вам буде простіше переконати клієнта у необхідності запровадити таку систему.

Проєктний менеджмент ризиків

Ризики допомагають досягти якісних цілей проєкту. Саме вони показують, де і як ми відхилилися від курсу розробки та що потрібно зробити, щоб повернутися в правильний потік цього вектора робіт.

Щоб запобігти потенційним проблемам, і впроваджують менеджмент ризиків проєкту. Зазвичай він складається з 7 ключових етапів:

1. Планування. Вибір інструментарію й методик, розставлення акцентів та пріоритетів, розподіл ролей тощо.

2. Ідентифікація. Визначення ризиків, локалізація та опис, підготовка плану з їх нівелювання. А також розподіл за категоріями, наприклад:

• • Проєктні.
  • Технічні.
  • Організаційні.
  • Бізнесові.
  • Зовнішні.
  • Фінансові.
  • Репутаційні.

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

4. Ще один аналіз. Переклад ризиків мовою фінансів та часу. Зазвичай використовується для роботи з інвесторами, стейкхолдерами чи замовниками. Візуально демонструє, скільки та чому може втратити клієнт.

5. Планування відповідей на ризики. Фокусування на тому, щоб спроєктувати адекватні дії, які будуть виконані в залежності від ситуації. Зазвичай мають такі варіанти:

• • Ескалація. Винесення питання за рамки проєкту.
  • Ухилення чи використання. Перший випадок – ми міняємо план для виключення ризику. Другий випадок – ми користуємось можливістю для досягнення якогось результату.
  • Перекладання чи розділення. Перший випадок – делегуємо ризик іншій стороні. Другий випадок – делегуємо можливість іншій стороні.
  • Зменшення чи підсилення. Перший випадок – мінімізуємо вплив ризику на проєкт. Другий випадок – використовуємо можливість «на повну».
  • Прийняття. Тут без коментарів.

6. Запровадження відповідей на ризики. Опис того, як контролюються ризики та які є сценарії реагування на них.

7. Моніторинг ризиків. Умовно – стратегія ROAM із SAFe:

• • Resolved. Ризик вирішено, можливість використано.
  • Owned. Ризик є, він на контролі.
  • Accepted. Прийняли ризик, керуємо ним.
  • Migrated. Передано іншій стороні.

Для всіх ризиків має бути впроваджена система звітності. Вона необхідна, щоб ефективно контролювати активні, вирішені, делеговані чи ігноровані ризики. А також, щоб звітувати про виконання плану менеджменту ризиків перед стейкхолдерами, інвесторами, командою і т.д.

На що звернути увагу до того, як починати імплементувати менеджмент ризиків

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

Отже, до того, як почати імплементацію, оцініть:

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

Якщо ж ви впевнені, що впораєтесь з квестом, тобто забезпечите ресурси та досвід для ефективного керування ризиками, то вперед, налагоджуйте систему й отримуйте профіт!

Підсумуємо

Якість продукту, як і його підсумкова вартість, а також репутація студії-розробника та провайдера IT-рішення цілком залежать від ефективності керування ризиками. І хоч роль PM фокусується на інших аспектах розробки, впровадження системи ризиків є додатковою опцією, яка здатна вплинути на кар’єрне зростання фахівця. Але це, скоріше, корисливі аспекти.

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

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

Якщо ви хочете отримати набір сучасних інструментів для управління проектними ризиками долучайтеся до курсу Project Risk Management Online.