Как работать с рисками и для чего они нужны в проектном менеджменте?
Как мы знаем, риски занимают одно из самых важных мест в проекте. Я напишу, зачем нужно определять риски, как и на что они влияют и как с ними работать.
🪩Overview
Работа с рисками помогает нам понять, какие есть/будут или могут быть препятствия в ходе разработки продукта. Своевременное реагирование на те или иные риски позволит избежать сложностей в ходе разработки продукта. Если позаботиться о риск-менеджменте заранее, то это сэкономит много времени и нервов на идентификацию во время их возникновения.
PMBOK рекомендует управлять рисками в 4 этапа: Инициация, анализ, планирование, мониторинг и контроль.
Риски бывают разные. Например, технические, со стороны бизнеса (заказчика), человеческого фактора, системные, политического характера, финансовые и т.д.
Рекомендуется определить риски до стадии планирования проектных работ (на стадии инициации) после сбора информации и требований о проекте.
Стратегии реагирования на риски: Transfer, Accept, Mitigate
Есть множество подходов и практик, как вести риск-менеджмент план (реестр рисков) и как на них реагировать. Расскажу один из способов с точки зрения практики.
Для начала нужно отталкиваться от того, что это за продукт, его домен, бизнес-цели, для чего и для кого продукт, сроки разработки, модель договора, какие технологии будут применяться в разработке, какие сервисы будут подключаться в процессе и какие будут использоваться после выпуска в продакшен, etc. Все эти и другие детали помогут определить риски. Чем больше мы задаем вопросов, тем больше можем определить возможных рисков. Некоторые риски можно определить быстро, например, ограниченный бюджет в сравнении с объемом работ — работ больше, чем выделено бюджета на проект. Это риск.
🏋🏻Практическая часть
Итак, для этапа инициации рисков PM собирает всю команду на встречу, на которой каждый участник озвучивает потенциальные риски. Задача — собрать как можно больше рисков (50-100). Затем, выделить самые критичные, например, 20-30. Все риски нужно распределить в таблицу (реестр рисков) относительно “причина-риск-эффект”.
Затем, PM организовывает встречу с лидами проекта. Каждый участник оценивает риск из таблицы по 10-бальной шкале с точки зрения “Вероятность” и “Последствия”. Встреча заканчивается.
Далее, PM считает важность рисков как “Вероятность” умноженное на “Последствия” и сортирует список по убыванию “Важности”. PM обозначает риски, превысившие границу “Важности” в списке.
📅Планирование
Фактически, на данном этапе происходит управление проектом. Для каждого критического риска, которые мы выделили, необходимо придумать стратегию, которая наш проект от него обезопасит:
1. Transfer. Переносим ответственность за последствия риска на третью сторону (заказчика, компанию партнера, страховую компанию, etc). Применять эту стратегию есть смысл, если мы сами не можем повлиять на риск и есть на кого эту ответственность переложить.
2. Accept. Принимаем ответственность за последствия риска на себя, но ничего не делаем, оставляем всё как есть. Применять этот подход есть смысл только когда с риском мы поделать ничего не можем, а делать трансфер на третью сторону неоправданно дорого.
3. Mitigate. Боремся с риском, принимая ответственность на него на себя. Для борьбы с риском хорошо иметь несколько планов. Основной, для того, чтобы риск подавить, и отходной, на случай если риск все-таки случился и влияет на проект:
• Основной план необходимо внедрять сразу до того, как риск случился. Он должен понижать либо “Вероятность”, либо “Последствия” риска. Здесь нам поможет запись рисков в формате “причина-риск-эффект”. Чтобы понизить “Вероятность” риска, нужно бороться с его причиной. Чтобы побороть “Последствия”, нужно защищать предмет его воздействия. • Отходной план внедряется в случае, если меры по борьбе с риском не принесли результатов, риск случился и стал проблемой.