Ризик-менеджмент – це процес, що передбачає прийняття та реалізацію рішень задля зниження ймовірності виникнення негативних результатів проєкту та мінімізації можливих втрат, якщо уникнути їх все ж не вдасться. Це важливий аспект у роботі кожної команди, тож у цьому матеріалі ми поговоримо про наступне:
- Культура ризик-менеджменту – чому робота з ризиками вкрай необхідна для успішної реалізації проєкту.
- Інструменти та техніки ризик-менеджменту – що використовується у спілкуванні з командою щодо наявних ризиків та управління ними.
- Роль команди в управлінні ризиками – як кожен учасник команди може зробити свій внесок у виявлення, оцінку та мінімізацію ризиків.
- Ризик-менеджмент в Agile-проєктах – чи існує взагалі ризик-менеджмент в Agile, чи може ефективне управління ризиками допомогти досягти успіху в таких проєктах.
Культура ризик-менеджменту
Перед тим, як почати говорити про культуру ризик-менеджменту, варто зупинитися на питанні, що таке ризики та якими вони бувають.
Виділяють загальні та індивідуальні ризики. Чітке визначення цим поняттям надає Інститут управління проєктами (PMI):
- «Загальний ризик – це вплив невизначеності на проєкт в цілому. Це більше, ніж сума індивідуальних ризиків, оскільки він стосується всього проєкту, а не його окремих елементів чи завдань, і включає всі джерела невизначеності проєкту. Він представляє вплив зацікавлених сторін на наслідки змін у результатах проєкту, як позитивних, так і негативних».
- «Індивідуальний ризик – це конкретні події або умови, які можуть мати вплив на цілі проєкту. Індивідуальний ризик може позитивно чи негативно вплинути на одну, чи декілька цілей, елементів або завдань проєкту».
Говорячи про різницю між загальними та індивідуальними ризиками, варто навести такий приклад. Індивідуальний ризик – це якщо ми не маємо можливості розробляти якусь User Story, тому що потенційно можемо бути заблоковані фронтенд-розробниками. Цей ризик пов’язаний з конкретною задачею на проєкті, і ми його або приймаємо, або намагаємося нівелювати.
Загальні ж ризики ширші. Їх прикладами може слугувати:
- вірогідність того, що з проєкту піде власник продукту (PO – product owner), і це вплине на наповненість беклогу, на продуктивність команди;
- небезпека якоїсь катастрофи у регіоні й необхідність перевозити офіс в інше місце;
- звільнення менеджера проєкту (PM – project manager) та інше.
Рівень індивідуальних та загальних ризиків вимірюється за допомогою двох параметрів: ймовірності та впливу. Тобто рівень серйозності ризику можна оцінити за формулою:
Перший показник (ймовірність, або probability) вимірюється у відсотках, а другий (вплив, або impact) – у грошових одиницях, і демонструє, скільки втрачає проєкт в результаті настання конкретної події. Якщо ці показники перемножити, отримаємо expected monetary value – очікувану грошову вартість, яка й буде показувати, наскільки серйозний ризик.
Цей підхід у реальних проєктах використовується нечасто, адже така прискіпливість вимагає значних часових та фінансових затрат, у чому клієнти зазвичай не зацікавлені. Тому зазвичай застосовується якісна оцінка – це, знову ж таки, визначення ймовірності та впливу ризику, але у словесному вираженні, тобто говорять про низький, середній або високий рівень ризику. Кількісна ж оцінка, про яку ми детально поговорили вище, використовується в більшості випадків у великих корпоративних проєктах.
Формат опису ризиків
Про це не всім відомо, але існує певний формат опису ризиків, тобто недостатньо просто написати «Звільнився PM» чи «На проєкті немає PO». Потрібно дотримуватися чіткої структури, що визначена міжнародними стандартами:
Ризик <подія, яка має вплив на цілі проєкту> через <причина>, що впливає на <наслідки>.
В цьому форматі ми бачимо, який ризик існує, що до цього призвело і на що це впливає. Наприклад:
- Ризик зниження якості коду через нестачу тестувальників, що матиме вплив на задоволення клієнта.
- Ризик, що ми не вийдемо своєчасно в реліз, адже під час роботи над проєктом хворіло багато спеціалістів, що вплине на наше фінансове становище / призведе до несплати клієнтом інвойсів.
З наведених вище прикладів видно, що просто констатація факту існування ризику викликає багато питань:
- Чому так сталося?
- Які будуть наслідки?
- На кого це вплине?
Детальніший формат розкриває всю суть проблеми. Він базується на культурі ризик-менеджменту, поняття якої визначене у Стандарті управління ризиками ISO 31000:
«Культура ризик-менеджменту – це система цінностей і поведінки в організації, яка формує рішення керівництва та співробітників з урахуванням наявних ризиків».
Усі довкола говорять про Data driven decisions – прийняття рішень на основі даних. Однак, на жаль, про Risk driven decisions – прийняття рішень на основі ризиків – згадують набагато рідше, хоча насправді це дуже важливо. Краще заздалегідь зрозуміти, що потенційно може відбутися, з якою ймовірністю, і вирішити, що робити в кожній такій ситуації.
4 стовпи культури ризик-менеджменту
Основні фундаментальні напрямки культури управління ризиками:
- Tone on the Top. Ризик-менеджмент не працюватиме, якщо немає чітких домовленостей між керівництвом та клієнтом, що ризик-менеджмент на проєкті має бути. На жаль, є багато проєктів, де управління ризиками існує досить формально – так би мовити, у документації PM. Тобто на початку роботи менеджер зібрав ризики, записав їх, оцінив, і на цьому все закінчується. Наступного разу про них можуть згадати лише тоді, коли компанія стикнеться з проєктним аудитом.Така ситуація складається, коли керівництво не цікавиться можливими ризиками. Всі готові «гасити пожежу», витрачати кошти на усунення наслідків якихось подій, та ніхто не хоче присвятити пів години часу, щоб обговорити ризики.
- Risk reporting and metrics. Щоб почати говорити про ризики, їх потрібно десь показувати – хоча б в спрощеному вигляді нагадувати вашій команді та стейкхолдерам, що вони існують і з ними потрібно працювати.
- Risk management education. Навчання співробітників, що обіймають посади всіх рівнів, – обов’язкова умова. Потрібно проводити курси з ризик-менеджменту, надавати доступ до платформ Udemy, Pluralsight та інших освітніх ресурсів, на яких люди зможуть зрозуміти, що таке культура ризик-менеджменту, як управляти ризиками, якими вони бувають.В багатьох компаніях проблеми виникають саме через нестачу інформації. Керівництво вважає недоцільним втрачати час на обговорення потенційних ризиків, а згадують про них лише тоді, коли одна із непередбачених ситуацій вже виникла. Такими були пандемія Covid-19, потім війна. Лише після того, як подія вже відбулася, C-level менеджери багатьох організацій замислилися, що набагато краще дивитися на кілька кроків уперед.
- KPIs / OKRs for risk owners. Якщо команда досягає найвищого рівня розвитку управління ризиками, у її менеджерів з’являються KPIs / OKRs, тобто показники оцінки ризиків для проєкту.
Чому команді потрібен ризик-менеджмент?
Звичайно, можна мотивувати впровадження ризик-менеджменту простим аргументом, що у команди було вже досить невдач, тому вона більше не може собі дозволити працювати над проєктами без урахування ризиків. Та все ж існує три чіткі причини доцільності такої практики:
- Прийняття обґрунтованих рішень. Часто менеджери приймають рішення інтуїтивно. Деколи це працює, деколи до інтуїції долучають дані, факти та цифри аналітичних досліджень. Однак найбільш обґрунтовані рішення приймаються саме на основі ризиків.
- Управління проєктами, що приносять цінність клієнту та бізнесу. Логічно, що будь-який проєкт повинен надавати цінність, а для цього команда має виконувати його цілі. Враховуючи той факт, що саме ризики безпосередньо впливають на досягнення цілей, ними потрібно грамотно управляти.
- Захист ресурсів компанії, стейкхолдерів та клієнтів від негативних подій. Якщо ви заздалегідь проаналізуєте ризики та складете так званий «План Б», то витратите потенційно менше, ніж якщо станеться якась непередбачена ситуація.
Як долучити команду до управління ризиками? Зробити це можна за допомогою інструментів управління ризиками або через підрахунок часу і грошей, які витрачає команда на виправлення помилок. Інструменти, що застосовуються, доцільно розділити за фазами проєкту, за його циклом та процесами:
#1. Pre-sale stage or Product validation (Передпродажна стадія або перевірка продукту)
На цій стадії для долучення команди варто застосувати інструмент стратегічного управління Business Model Canvas, за допомогою якого ви перевіряєте, чи є взагалі потреба у вашому продукті. Вам слід відповісти на ряд питань: для кого він призначений, як реалізувати, як ви його будете продавати, яким чином вимірювати успішність і т.д.
Тут важливу роль відіграє ризик-менеджмент. Адже можна говорити тільки про продукт, а можна – і про продукт, і про ризики – для клієнта, пов’язані з маркетингом, безпосередньо з продуктом та ін. Якщо ви будете вивчати Kanban як систему, а не як просто дошку, то дізнаєтеся, що в ній є церемонії, так звані каденції, присвячені ризикам. Їх рекомендується періодично проводити, щоб контролювати ситуацію.
Risk identification in Business Case (Ідентифікація ризиків у бізнес-кейсі).
Питання про ризики виникне і в тому випадку, якщо ви прийдете до топменеджера або фінансового директора захищати бізнес-кейс – наприклад, про необхідність купівлі якоїсь CRM-системи для нарощення капіталізації, автоматизації процесів, оптимізації витрат і т.д.
Щоб підготуватися до такої зустрічі, вам доведеться зібратися з командою і змоделювати потенційні ситуації. У прикладі з придбанням системи це можуть бути проблеми з вендором, який її впроваджуватиме, безпосередньо з цифровим продуктом. Також не виключена ситуація, що компанія придбає готове програмне рішення, витратить на нього значну суму, а потім вирішить, що вона унікальна, не може адаптуватися під загальні практики й почне кастомну розробку.
Якщо всі ці ризики обговорити одразу, реально уникнути додаткових витрат. Наприклад, на зустрічі з топменеджментом компанії може бути прийняте рішення, що немає сенсу купувати CRM-систему, що вже існує на ринку, а краще одразу почати розробку програмного продукту на замовлення, тим самим зекономити та задовольнити всі потреби компанії.
Обов’язково проговорюйте з командою, скільки ви будете платити, якщо зменшите ризик, а скільки – якщо відреагуєте на нього. Якщо ви розробляєте бізнес-фічі й ніколи не виконуєте технічних задач, то забуваєте про рефакторинг, не думаєте про баги, які вже давно існують на продакшені, та, звісно, нічого з ними не робите. В результаті під час надвисокого навантаження система просто не витримує – виникає збій, у якому звинувачують IT-спеціалістів.
Щоб зменшити ризик, можна, наприклад, додавати 10-15 % до кожного спринта і домовлятися, що цей час буде витрачатися на виконання технічних задач – рефакторинг, оптимізацію платформи й т.д. Про це важливо говорити ще до старту проєкту, а не тоді, коли процес уже запущено, а у команди й так надлишок бізнес-задач.
Risk identification in contracts (ідентифікація ризиків під час підписання контрактів).
Коли ви підписуєте контракти, їх типи теж потрібно обирати з огляду на результати аналізу ризиків та клієнта: чи не збанкрутує клієнт через два роки? Чи цей стартап підніме другий раунд інвестицій?
Якщо мова йде про продуктову компанію, чи готові ви інвестувати у нові фічі? Потрібно зробити порівняння з ринком, подивитись на конкурентів, визначити time-to-market – швидкість випуску на ринок. Це слід враховувати під час укладання контракту: PM повинен достеменно знати, що написано в договорі про надання послуг (MSA), не кажучи вже про технічне завдання (statement of work, чи SOW).
Все це необхідно робити, щоб під час реалізації проєкту не виникало неприємних сюрпризів. Також ми можемо говорити з командою про cost of quality – вартість якості. Прикладів сценаріїв таких розмов безліч. Припустимо, що необхідні кошти на розширення команди, оскільки на вісім розробників один тестувальник. Або потрібні senior-спеціалісти, адже виникає багато дефектів через те, що набрали на проєкт тільки junior-розробників.
Звісно, такі питання слід вирішити – найняти спеціалістів, передати певні задачі на аутсорс, підкоригувати свої процеси – одним словом, завжди потрібно знаходити баланс. Тут варто згадати про проєктний трикутник, який складається з часу, обсягу робіт та їх якості. Саме якістю легко маніпулювати – визначати, чим заради неї є змога пожертвувати. І це також буде інструментом для розмови з бізнесом – з його допомогою можна з’ясувати, чи готові вони інвестувати у проєкт.
Risk identification in proposal form (ідентифікація ризиків у формі пропозиції).
Якщо ви працюєте на аутсорсі, у формі пропозиції обов’язково потрібно прописати ризики, щоб у майбутньому у клієнта до вас не було претензій. Задля цього слід разом з командою виконати певні дії:
- розробити архітектурне рішення;
- оцінити беклог;
- вказати технічні, архітектурні, деплоймент та бізнес-ризики – все, що можна передбачити на момент складання форми.
Про перелічені вище ризики потрібно говорити з усіма учасниками команди. Якщо дехто з них не має досвіду роботи з ризиками, можна не заглиблюватися у термінологію, а просто поставити питання, які наштовхнуть їх на ідентифікацію ризиків. Наприклад, що може завадити нам досягти цілей проєкту?
Існують деякі досить екзотичні інструменти, які пропонує PMI: Work breakdown structure, Feature breakdown structure та Risk breakdown structure. Зупинимося детальніше на останньому.
Risk breakdown structure – фасилітаційний інструмент, який широко використовується у спілкуванні з командою. Ви ставите перед нею питання стосовно ризиків проєкту. Команда, звичайно, перерахує деякі з них, але краще, якщо у вас є заготовка за категоріями – тоді зручно розташувати потенційні ризики відповідно до них. Наприклад, бюджетні, ресурсні, стратегічні та інші. Такі розмови будуть більш продуктивними.
Крім того, можна використовувати fishbone-діаграму, affinity-діаграму – загалом у ризик-менеджменті існує близько 30 різних інструментів.
Пріоритизація на основі ризиків
Пріоритизація, що базується на ризиках, має відбуватися з командою та з клієнтом. Як приклад можна розглянути WSJF (Weighted Shortest Job First) – модель пріоритизації, що використовується для упорядкування робіт з метою отримання максимальної економічної вигоди. Її застосовують в Scaled Agile Framework (SAFe) та інших фреймворках, обчислюючи за формулою:
Для обчислення Cost of Delay в SAFe також існує спеціальна формула:
Визначення цих показників дозволяє:
- зрозуміти, чи покриває розробка певної фічі конкретні ризики;
- порахувати, скільки компанія заробить на її впровадженні та взагалі – чи доцільно це;
- розставити пріоритети у створенні функціонала.
Risk Identification in SAFe PI Planning
SAFe – фреймворк, який використовується для роботи з багатьма командами. Мова про те, коли доводиться працювати з 10-15 командами, в яких 90 і більше людей. На таких масштабних проєктах завжди присутній PI Planning – планування інкременту продукту на квартал. У цьому процесі значну роль відіграє ризик-менеджмент. У SAFe ця практика прийшла з Kanban-системи та класичного проєктного менеджменту.
Проте у Scaled Agile Framework існує своя стратегія управління ризиками, яка дозволяє вам вирішити, прийняти, пом’якшити ризики або ж взяти на себе відповідальність за їхнє усунення. В залежності від цього, в SAFe виділяють чотири типи ризиків:
- Resolved risks (вирішений ризик) – ваша команда погодилася, що ризик більше не становить проблеми й можна рухатися далі.
- Owned risks (власний ризик) – хтось бере відповідальність за ризик, який не може бути усунений негайно.
- Accepted risks (прийняті ризики) – ризики, з якими неможливо впоратися, тому їх залишається тільки прийняти.
- Mitigated risks (пом’якшені ризики) – у команди є план зі зменшення самих ризиків або їх впливу на проєкт.
Яку б стратегію ви не вибрали, якщо ви з командою під час планування інкременту продукту на квартал або розбивання функції на історії користувачів подумаєте про ризики, ймовірність того, що станеться щось непередбачуване, значно знижується. Точніше, статися це може, але ви розумітимете, що вам робити, а отже, зменшите наслідки.
#2. Execution phase (фаза виконання)
На цій стадії використовується інструмент Risk Register (реєстр ризиків) – документ, призначений для управління ризиками. У PM, як правило, є декілька реєстрів – для клієнта, внутрішніх стейкхолдерів та команди. На середньому проєкті, до якого залучено до 30 людей, стандартний Risk Register міститиме до 50 ризиків – і це небагато. Інший же проєкт може мати всього 10 – це теж нормально.
Для долучення команди потрібно періодично переглядати цей документ – під час Risk Review Meeting (наради з розгляду ризиків), на ретроспективах або на зустрічах у будь-яких інших форматах.
Risk Register може бути реалізований в Jira. Він дозволяє збирати ризики як окремі елементи, додавати їх до ризик-матриці й управляти ними.
Метрики для спонсорів
Спонсор, або інвестор також є частиною команди, адже від нього залежить фінансування проєкту. Отже, його теж варто долучити до ризик-менеджменту. Щоб це зробити, потрібно монетизувати ризики. Для цього якнайкраще підходить Probability Impact Matrix, яка наочно демонструє, як різні за рівнем серйозності ризики впливають на бюджет або тривалість проєкту. Власне, представники бізнесу бачать те, що для них найважливіше – відхилення від запланованого time-to-market або від передбаченої суми інвестицій.
Risk Reports (звітність з ризиків)
Цей інструмент застосовується для долучення всієї команди, незалежно від рівня співробітника. Навіть якщо ви працюєте за Scrum і робите звіти по спринтах, туди теж варто додавати ризики. Хоча класичний Scrum захищений від ризиків, та через додання до класичного фреймворку якихось елементів вони в ньому таки можуть виникати.
Ризик менеджмент в Agile-проєктах
Якщо розглядати Agile-фреймворки, в них є вбудовані інструменти пом’якшення ризиків. Управління беклогом, релізами, щоденні стендапи, ретроспективи – все це проводиться для їх уникнення. Тобто, по суті, Agile-розробка запобігає ризикам – саме це малося на увазі, коли ми говорили про класичний Scrum.
Якщо ж ви все-таки вирішите відхилитися від класичного способу ведення Agile-проєкту та ввести церемонії розглядання ризиків, це можна робити під час стендапу. В команді має з’явитися культура обговорення ризиків. Головне, щоб всі вони були видимі для кожного члена команди. Далі робота з ними відбувається за схемою:
- визначення ризику;
- перетворення його на конкретну дію з усунення чи пом’якшення;
- виконання цієї дії разом з командою.
Щоб Risk Register не залишився просто формальним документом проєктного менеджера, всі дії з пом’якшення ризиків, які ви розробили з командою, мають перетворюватися на конкретні задачі. Наприклад, існує ризик того, що в наступному спринті не буде доступний QA-інженер. Для його зниження можна зробити так, щоб команда допомагала у тестуванні цифрового рішення. Ви можете скоротити кількість задач у спринті або сфокусуватися на завданнях, де менше тестування.
Risk-based backlog adjustment (коригування на основі ризиків)
Суть такого коригування полягає в тому, що ми на основі ризиків, пов’язаних з User Stories, можемо будувати стратегії. Тут, знову-таки, йдеться про пріоритизацію на базі ризиків. Варто використовувати модель WSJF, та існує і простіший підхід. Є певна User Story, ми обмірковуємо, які ризики з нею пов’язані, до яких витрат вони можуть призвести, і далі вже розставляємо всі User Stories згідно з пріоритетами, заснованими на ризиках.
Фінальні думки
Перед впровадженням ризик менеджменту важливо врахувати розмір проєкту, досвід команди й наявність в ній культури ризик менеджменту. Також варто дотримуватися рекомендацій:
- Почніть проговорювати ризики під час стендапів.
- Створіть Risk Register та спробуйте його вести.
- Виконайте якісну оцінку, а вже потім переходьте до кількісної чи інших різновидів.
- Не ведіть непотрібну документацію.
Одним словом, беріть до уваги особливості вашого проєкту та те, що необхідне саме для його успіху.
Якщо ви хочете отримати набір сучасних інструментів для управління проектними ризиками долучайтеся до курсу Project Risk Management Online.