Photo by Carl Raw on Unsplash
Photo by Carl Raw on Unsplash

Управление рисками

Риск — слово, которое воспринимается в русском языке исключительно в негативном ключе. Тем не менее, в менеджменте это понятие имеет как отрицательную, так и положительную окраску.

Понятие риск подразумевает позитивное или негативное по влиянию на проект событие, которое может произойти или не произойти.

Управление рисками — неотъемлемая часть проектного менеджмента в IT: здесь рассматриваются вероятности наступления событий, которые могут случиться, а могут и нет.

Сила управления рисковыми ситуациями — визуализация резервов, формулирование планов на случай А и В, а также назначение ответственных (снижение нагрузки с менеджера проектов).

В книге Эдварда Йордона «Путь Камикадзе» есть интересная мысль — к любому проекту стоит относиться как к заведомо провальному. И уже исходя из этого принятого априори факта выстраивать стратегию развития, то есть продумывать набор тех действий, которые помогут сделать проект успешным.

Работа с рисками в отрасли информационных технологий

Пример негативного риска — из команды выдернут важного сотрудника.

Пример позитивного риска — что-то могло не случиться, но мы сконцентрировали усилия, все продумали, сделали чуть больше — и это произошло.

Управление рисками сводится к двум понятным парадигмам: мы пытаемся увеличить вероятность возникновения положительных ситуаций из числа тех, которые могут произойти (или нет) и снизить вероятность провальных исходов.

Базовый инструмент работы с рисками — реестр. Рекомендуется вести его как для положительных, так и для отрицательных событий в разных таблицах. А план управления рисками включать в общий план управления проектом.

NB: До 90% значимых угроз должно быть нивелировано, отсюда следует, что 10% рисков может сработать.

К числу таких угроз можно отнести те, о которых мы не догадываемся или которые невозможно взять под контроль, предотвратить или разрешить (например, изменение в законодательстве или всеобщий карантин).

Внедрение управления рисками

На каждом (еженедельном) совещании нужно уделять время для мониторинга текущей обстановки.

Например: «Коллеги, что у нас с рисками? Что-нибудь новое возникло? А может что-то из старого можно вычеркнуть?»

Или спрашивать у людей про плохое:  «Что у нас может пойти не так? Я сейчас вас не ругаю и не спрашиваю, почему вы «накосячите». Расслабьтесь и подумайте, что вам может помешать, а что может помешать всем нам, чтобы это вовремя предотвратить».

Как идентифицировать риски

Сесть и посмотреть в «хрустальный шар», используя принципы проектного менеджмента — командность и проактивность. То есть размышлять не в одиночку, а привлекать для этой цели команду.

Задача ставится простая: выписать все, что придет в голову. Даже если это кажется странным и совершенно несбыточным. Достаточно помнить, как весь мир закрыли на карантин на несколько месяцев. Такую ситуацию не мог предугадать никто, тем не менее, она произошла.

Как идентифицировать возможные риски и степень их вероятности:

  • Посмотреть документы (например, планы прежних проектов, «извлеченные уроки»);
  • Обсудить с коллегами (PM, HR, финансы);
  • Обсудить с командой;
  • Спросить у заказчика, спонсора;

В качестве примера приведем проект длительностью в полгода, с командой в 7 человек — здесь можно идентифицировать более 100 возможных рисков. Тем не менее, не всеми нужно управлять и не все нужно детально контролировать. Анализ и сортировка рисков происходит на следующем этапе — качественной оценки. Сейчас работает другой принцип — «вали кулем, потом разберем».

Качественная оценка

На этом этапе мы сортируем возможные вероятности по степени значимости: какие из рисков очень значимы, а какие не очень. Оцениваем не в процентах, не в деньгах, а в категориях — большое, среднее, маленькое.

Пример качественной оценки рисков:

РискВероятностьВлияниеЗначимость
Уход сотрудника с проектанизкаявысокоесредняя
Недостаточная пропускная способность интернет-каналасредняянизкоенизкая
Отсутствие вовлеченности топ-менеджмента со стороны клиентавысокаянизкоесредняя
Изменение требований в конце проектавысокаявысокоевысокая
Отмена командировки в офис клиентанизкаянизкоенизкая

После того, как закончили проводить качественную оценку — смотрим на последнюю колонку и решаем — какие риски мы оставляем и будем дальше с ними работать.

Очевидно, что берем значимые и не берем самые незначительные.

Что делать со средними рисками? Решаем буквально — либо берем, либо не берем, в зависимости от конкретной ситуации и решения проектного менеджера.

Пример. Если менеджер ведет флагманский (важный для компании) проект, то стоит брать в работу и средние по значимости риски.

Если это обычный проект, такой, которых много — можно брать только значимые риски.

В итоге, из всей той простыни, которую мы идентифицировали ранее, остается небольшая часть, с которой реально можно будет работать.

Количественная оценка

Ключевая задача — рассчитать резервы.

Здесь рождается вероятность и влияние. Вероятность оценивается в процентах, влияние — в деньгах. Произведение одного на другое дает нам значимость.

Ключевой показатель количественно оценки — EMV (Expected Monetary Value) — это ожидаемое денежное значение, другими словами — сколько будет стоить нечто.

EMV = P * I

P — probability — вероятность
I — impact — влияние

Для каждого риска оцениваем его P (вероятность — в процентах) и его I (влияние — в деньгах или времени), в случае если этот риск реализуется.

Если вы корректно оценили вероятность, то все риски разом никогда не сработают. Сработает только часть,  с остальной части рисков можно и заимствовать резервы.

Планируем реагирование на риски

После проведения качественной и количественной оценки приступаем к планированию реагирования. Для этого вводим понятия План А и План B.

На языке проектных менеджеров, План А называется Contingency Plan (план непредвиденных ситуаций), План B  — Fallback Plan (план отступления).

План А — это то, что мы сделаем прямо сейчас, чтобы риск не сработал, либо сработал но с наименьшими последствиями. Другими словами — действия для снижения вероятности возникновения риска.

План B — этот план вступает в силу, если не сработал План А, то есть событие произошло.

Другими словами, План B делается для остаточных рисков.

Триггер риска

Триггером риска называют симптом, то есть некие действия, по которым можно судить о возможности наступления риска.

Пример: Junior разработчику поставили большую задачу. Менеджер проекта решает, что если в течении двух недель разработчик затягивает сроки, значит это триггер.

Хозяин риска

Пример риска: Junior разработчик может «завалить» кусок работы.

Хозяином этого риска может быть тимлид или технический лидер. То есть тот человек, который увидит симптом (триггер).

Хозяин риска смотрит на триггер и это фактически означает, что План А не сработал, нужно задействовать План B.

Наблюдаем за рисками

Отслеживаем изменения событий в течении проекта на собраниях с командой:

  • открываем новые
  • закрываем старые
  • меняем старые на более свежие

Как не надо делать: единожды идентифицировать риски и больше не следить за ними. Это привьет всей команде отвращение к риск-менеджменту.

Об авторе

Денис Фурсенко

Просмотреть все сообщения

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *