Реестр рисков открывают, когда у проекта накапливаются потенциальные угрозы, но они живут либо в голове PM, либо всплывают только в момент, когда уже стали проблемой. Без отдельного risk-register команда обычно обсуждает риски реактивно, а не управляет ими заранее.
Что это за подход
Risk register полезен как явный контур для идентификации, оценки, владельцев и реакций на риски. Для PM это не список тревожных мыслей, а способ держать угрозы в наблюдаемой и управляемой форме.
Когда он нужен
- проект сложный или рискочувствительный;
- есть внешние зависимости и неопределённость;
- важно поднимать угрозы до их материализации;
- статус и решения должны опираться не только на факт проблемы, но и на ранний сигнал.
Когда он не нужен
- если проект очень маленький и формальный реестр явный перебор;
- если риск-register не пересматривается и не влияет на решения;
- если риск путают с уже случившейся проблемой.
Что из него реально применимо для PM
- держать перечень ключевых угроз и реакций;
- различать уровень вероятности, влияния и срочности внимания;
- связывать риск-контур со статусом, планом и зависимостями;
- делать риск обсуждаемым до кризиса.
Какие артефакты, ритуалы и правила важны
- owner риска;
- стратегия реакции;
- дата пересмотра и статус;
- связь со статусом и decision points.
Какие ошибки чаще всего делают при внедрении
- записывают риски без владельца и реакции;
- не обновляют оценку по мере развития проекта;
- создают слишком длинный список без приоритета;
- обсуждают риски отдельно от реального плана и статуса.
Чем можно заменить или упростить
- коротким top-risks блоком в статусе;
- RAID log, если нужен более объединённый контур;
- weekly risk review без отдельного тяжёлого реестра.