Какие ваши действия? или Как РМу реагировать на риски + Шаблон
Всем привет! Так получилось, что я в прошлых статьях довольно плотно прошлась по артефактам, которые могут быть использованы на этапе инициации проекта:
- Бизнес-кейс — чтобы ЛПР могли принять решение о запуске или отклонении проекта на основании экономической обоснованности проекта (описание и стоимостное выражение выгод, расходов и эффективности);
- Lean Canvas — чтобы быстро погрузить человека в суть проекта, знать выгоды и возможности, ключевые показатели, принять решение о запуске, отклонении или паузе проекта;
- Резюме проекта — чтобы аккумулировать всю ключевую информацию о проекте в одном месте и фиксировать цели, ограничения по бюджету и срокам, стейкхолдеров проекта.
Поэтому я подумала сохранить последовательность и перейти к еще одному инструменту, который появляется на этапе инициации, а также принадлежит к процессу управления рисками и используется на всех этапах проекта.
Я буду вам рассказывать про Реестр последующих действий, но в зависимости от того, в каком подходе / методе / методологии вы работаете, это может быть карта рисков, анализ рисков, список рисков, SWOT-анализ, стратегия реагирования на риски проекта и т. д.
То есть какая у нас логика: появилась некая идея проекта — ее зафиксировали, описали и оценили с помощью Бизнес-кейса или Lean Canvas, поняли, какие есть ограничения, какие есть сроки и желаемые результаты от проекта в конце, примерно поняли, кто потребуется для реализации, решили дать проекту шанс — зафиксировали в Резюме ключевое по проекту, обозначили старт, и теперь нужно на самом берегу посмотреть вперед и понять:
- с какими рисками придется столкнуться, насколько они существенны и критичны для проекта
- как на эти риски можно будет реагировать
Для этого в P3.express существует такой документ как Реестр последующих действий. Сам по себе документ достаточно универсальный и легко может стать частью вашего риск-менеджмента на проекте, даже если вы не работаете по этому фреймворку.
Что такое Реестр последующих действий в контексте риск-менеджмента?
Реестр последующих действий — это документ, который используется для фиксации и отслеживания возможных рисков проекта, а также действий, которые необходимо предпринять в случае их возникновения.
Реестр помогает команде не только выявлять риски на ранних этапах, но и управлять ими в процессе реализации проекта.
Чтобы понимать место этого артефакта в общем управлении проектом и рисками, давайте немножечко базанем по самым основам, вот вам прям краткая справка по основным терминам:
Риск — это возможность возникновения события, которое может оказать как негативное, так и положительное влияние на достижение целей проекта, то есть риск и про событие, и про последствия.
Виды рисков:
-- Технические риски — связаны с технологией и выполнением задач (сбои в системе, ошибки разработки, появление новой технологии на рынке).
-- Операционные риски — касаются внутренних процессов, операционки проекта и отделов обеспечения (нехватка ресурсов, сбои в поставках).
-- Финансовые риски — затрагивают бюджет и финансы (превышение затрат, недофинансирование, выигранный грант).
-- Регуляторные риски — связаны с законодательством и нормами (изменения в законах, несоответствие стандартам).
Внутри своих видов риски могут быть контролируемыми и неконтролируемыми. Работаем, разумеется, с первыми, вторые смиренно принимаем или стараемся снизить эффект от наступления.
Основа измерения риска — это комбинация двух показателей, вероятности наступления риска и степени его влияния на проект. Эти параметры помогают определить приоритетность реагирования. Здесь может помочь Тепловая карта рисков.
Основные стратегии реагирования на риск:
-- Избегание — прокладываем маршрут, избегая все риски на пути (есть риск не успеть за две недели, закладываем три).
-- Митигация — от англ. mitigation — смягчение последствий, пришло из сферы реагирования на стихийные бедствия, стратегия снижения негативного влияния риска.
-- Перенос — передаем риск третьей стороне (например, страхуем проект).
-- Принятие — осознанное и смиренное принятие риска без изменений.
Митигация рисков может быть проактивная, как то действия, направленные на предотвращение риска до его возникновения (например, обучение команды), и реактивная, то есть меры, принимаемые уже после наступления риска для минимизации его последствий (например, план действий на случай кризиса).
Смотрю на эти понятия, смотрю на определение Реестра последующих действий, и понимаю, что мой Реестр должен включать в себя:
- описание риска, его вид
- оценку риска (то есть вероятность, критичность)
- приоритетность реагирования (на базе оценки)
- стратегию реагирования, и само название, и описание конкретных действий (что делать-то надо)
Что забыла? Правильно, забыла еще важные атрибуты управления: люди и сроки, то есть еще нужно указывать, кто ответственный за выполнение этих действий, и даты, когда наступил риск, когда последствия его устранены были.
Как составить и как вести Реестр последующих действий?
Составить Реестр довольно просто, можно взять шаблон с сайта P3.express, можно составить самостоятельно, отразив пункты, которые мы выше обозначили, как нужные, добавив свои важные и особенные, а можно взять мой шаблон:
Давайте для удобства обозначим, что мы сейчас порядок работы с Реестром описываем на примере.
Мы хотим провести Вебинар с приглашенным лектором. Вещать будем из студии, лектор туда приедет, сделаем ему грим, свет, звук, он нам подготовит презентацию, мы настроим вещание и проведем, собственно, мероприятие.
Это наша идея проекта, мы на этапе инициации, мы еще не приступали к планированию, и сейчас самое время заглянуть в будущее и подумать, а что может случиться хорошего и плохого с нами и проектом, его результатом желаемым.
Как мы можем заглянуть в будущее? Правильно, сначала посмотрев в прошлое, то есть мы можем открыть документацию прошлых похожих проектов, посмотреть, а с какими ситуациями менеджер сталкивался там (поэтому документация, фиксирование событий и действия так важны).
Мы можем спросить у более опытных коллег, кто тоже организовывал вебинары, с какими событиями сталкивались они, как они влияли на вебинар, как они справлялись (прям как делали, чтобы исправить последствия или приумножить положительный эффект).
Открываем документ и записываем в него, все, что считаем справедливым и вероятным для нашего проекта, построчно заполняя его:
То есть мы:
- описываем ситуацию, как положительную, так и отрицательную, наступление которой может потребовать от нас или команды проекта каких-то определенных действий
- описываем все последствия наступления события, а в соседних колонках оцениваем вероятность и влияние последствий на результат проекта
Вы можете добавить в файл еще столбец с приоритетом реагирования, его просто определить по сумме вероятности и влияния, то есть в нашем примере приоритет у технического риска выше, чем человеческого, и если нам будет не хватать времени, мы можем отреагировать только на более приоритетный риск.
Оценка вероятности и влияния может быть намного сложнее (например, рассчитываемой по коэффициентам), и тогда вы можете поставить в файл нужные вам формулы или факторы, по которым оценивается и вероятность, и влияние, и приоритет.
Дальше мы смотрим, а как же нам реагировать:
- выбираем стратегию
- описываем детально действия, которые нужно предпринять ответственному члену команды, чтобы с этим риском справиться
- назначаем ответственного
Что тут важное? Ответственный должен быть в курсе, что он ответственный.
Поэтому доступ к Реестру последующих действий должен быть у всех членов команды проекта, вы как менеджер проекта должны всем показать, какие предвидите риски, какие есть возможные пути спасения (это ваш инструктаж по технике безопасности на проекте).
Так как мы на стадии инициации, то эти события с нами не случились еще, и последствия мы не устраняли. Поэтому даты могут быть пустыми (и если мы не включили действия из реестра последующих действий в план работ и в реальные задачи на проекте, то и даты наступления не будет, но будет дата закрытия последствий, например).
По мере реализации проекта список событий и действий будет расти, обновляться, меняться, а после завершения вы, как менеджер проекта, должны оставить этот документ в архиве компании, чтобы на другом похожем проекте у менеджера была возможность обратиться к мудрости предков.
Пишите свои мнения, рассуждения, насколько вам с вашими текущими проектами пригодился бы такой артефакт, или чем он у вас на проекте заменен, и как вы в целом работаете с рисками. Буду ждать историй, мне всегда очень интересно, как и из чего складывается чужой опыт.
Рассказать можно тут, или в канале:
На одном из собеседований задавали следующий вопрос: "Вы находитесь на начале разработки проекта - появился риск который маловероятно произойдёт к концу разработки". Примерная длина общего цикла разработки проекта 9 месяцев.
Каковы ваши действия касательно работы с этим риском?
Интересно послушать ваше мнение