Управление рисками проекта: реестр, оценка и реакция

Риск и проблема — разные вещи

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

Формулировка риска содержит причину, событие и последствие: «из-за того, что поставщик один, поставка может задержаться, и это сдвинет ввод в эксплуатацию на месяц». Формулировка «риск срыва сроков» бесполезна — из неё не следует ни одного действия.

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

Оценка: вероятность и влияние

Каждому риску ставится оценка вероятности и влияния — обычно по трёхуровневой или пятиуровневой шкале. Точность здесь иллюзорна, и стремиться к ней не надо: смысл оценки не в числе, а в упорядочивании списка.

Практический приём — оценивать влияние в тех же единицах, что и цель проекта: дни задержки, деньги, потеря функциональности. Тогда сравнение рисков перестаёт быть спором о категориях: риск на месяц задержки очевидно важнее риска на два дня.

Полезно разделять исходный риск и остаточный: каким он был до принятых мер и каким останется после. Это единственный способ показать, что работа с рисками даёт результат, а не просто ведётся.

Четыре стратегии реагирования

Для каждого значимого риска выбирается стратегия, и вариантов немного. Важно, что «принять» — тоже полноценная стратегия, а не отсутствие работы.

• Уклониться. Изменить план так, чтобы событие стало невозможным: сменить технологию, убрать работу из содержания.
• Снизить. Уменьшить вероятность или влияние: прототип на рискованном участке, второй поставщик, запас времени.
• Передать. Переложить последствия на другую сторону: страхование, фиксированная цена у подрядчика, гарантии.
• Принять. Осознанно ничего не делать, но заложить резерв и договориться, при каком признаке включается план Б.

Регулярная работа с реестром

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

У каждого риска должен быть владелец — конкретный человек, а не «команда». Владелец следит за признаками приближения события и запускает реакцию. Без него реестр остаётся документом, к которому все относятся с уважением и никто не обращается.

Отдельно полезно отслеживать признаки-триггеры: что именно станет сигналом, что риск реализуется. «Если к 15-му числу нет подтверждения от поставщика — включаем второй вариант». Так реакция запускается по факту, а не по интуиции руководителя.

Резервы: чем обеспечены принятые риски

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

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

Разговор с заказчиком о резерве честнее, чем завышенные оценки. Он позволяет обсуждать неопределённость прямо: «эта часть новая, закладываем 20% запаса; эта отработана, запаса почти нет».

Матрица приоритета рисков

Чек-лист качества реестра рисков

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

Как вести реестр рисков в Shtab

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

Частые вопросы