Управление рисками проекта (Project Risk Management)

Управление рисками проекта (Project Risk Management) — систематический процесс выявления, анализа и реагирования на неопределённые события, которые могут повлиять на цели конкретного проекта — срок, стоимость, содержание, качество. В своде знаний PMBOK риск определён как неопределённое событие или условие, которое в случае наступления оказывает положительное или отрицательное влияние на цели проекта; поэтому в полном смысле управление рисками охватывает и угрозы, и возможности. Практический смысл: не пытаться предсказать будущее, а заранее выяснить, что может пойти не так (или неожиданно хорошо), оценить значимость и подготовить ответ — прежде чем событие произошло. Тема связана с PMBOK, реестром рисков, оценкой рисков, FMEA и Premortem.

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

Происхождение и исследовательская база

Управление рисками проекта в современном виде оформлено в стандартах: PMBOK Guide Института управления проектами (PMI), PRINCE2, международный стандарт ISO 31000 и ряд отраслевых документов. В PMBOK структура процессов менялась от издания к изданию, и это важно помнить при чтении пересказов. В 5-м издании (2013) область «Управление рисками проекта» включала шесть процессов: планирование управления рисками, идентификация рисков, качественный анализ, количественный анализ, планирование реагирования на риски и мониторинг и контроль; в 6-м издании (2017) появился седьмой — «внедрение реагирования на риски»; в 7-м издании (2021) описание сменилось: вместо процессов — принципы и области результативности, а риски рассматриваются в области «Неопределённость». Универсальные идеи при этом остаются: реестр рисков, приоритизация, стратегии реагирования и регулярный пересмотр.

Стратегии реагирования в PMBOK для угроз — избегание (устранить причину или изменить план), передача (переложить последствия на третью сторону, например, страхованием или контрактом), снижение (уменьшить вероятность или воздействие) и принятие (сознательно не действовать, возможно, создав резерв); в 6-м издании к ним добавлена эскалация (передача риска на более высокий уровень). Для возможностей используют зеркальные стратегии: использование (обеспечить реализацию), совместное использование (разделить с партнёром), усиление (увеличить вероятность или эффект), принятие. Различают также индивидуальные риски проекта и общий риск проекта (совокупная неопределённость), а в резервах — резервы на непредвиденные события (для известных рисков) и управленческие резервы (для неизвестных).

Научная часть темы — психология оценок: люди систематически недооценивают сроки и затраты (ошибка планирования), склонны к чрезмерному оптимизму и не любят рассматривать редкие катастрофические события. Дэниел Канеман и Амос Тверски описали «ошибку планирования» в 1979 году; Бент Фливбьерг развил идею «прогнозирования по референтному классу» — оценки по статистике похожих проектов, а не по внутреннему плану. Это важная поправка к формальному процессу: даже идеально заполненный реестр рисков не спасает, если оценки вероятностей и последствий систематически искажены.

Документированные кейсы

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

Кейс 1. «Челленджер» (1986): риск был известен и стал «нормой»

28 января 1986 года космический челнок «Челленджер» разрушился через 73 секунды после старта, погибли семь астронавтов. Причина — отказ уплотнительного кольца (O-ring) в стыке твердотопливного ускорителя при необычно низкой температуре на стартовой площадке. Комиссия Роджерса (1986) установила, что проблема эрозии колец была известна и отмечалась на предыдущих полётах, а накануне запуска инженеры подрядчика рекомендовали не стартовать при низких температурах. Социолог Дайан Воон в книге «The Challenger Launch Decision» (1996) описала механизм, который назвала «нормализацией отклонений» (normalization of deviance): повторяющиеся благополучные полёты с повреждёнными кольцами воспринимались не как накопление свидетельств о нерешённой проблеме, а как доказательство того, что отклонение допустимо; правило «не стартовать ниже определённой температуры» постепенно превратилось в аргумент «более низкие температуры — в направлении худшего для колец».

Уроки для управления рисками проекта: риск был в реестре («принят»), но принятие не пересматривалось при появлении новых данных; порог безопасности размывали под давлением графика; сообщение инженеров о риске не превратилось в остановку. В терминах метода это ошибки: единожды принятый риск не пересматривался, оценка вероятности опиралась на «пока обходилось», а реакция на новые сведения (мониторинг) не сработала. Оговорка: причины катастрофы включают организационные, технические и коммуникационные факторы; популярные пересказы упрощают роли конкретных людей.

Кейс 2. Сиднейский оперный театр и «железный закон мегапроектов» (Фливбьерг)

Сиднейский оперный театр — классический пример проекта, стоимость и срок которого были недооценены. По данным, приводимым в описаниях проекта, первоначальная оценка составляла около 7 миллионов австралийских долларов, здание открыли в октябре 1973 года, то есть примерно на десять лет позже планировавшегося срока, а итоговая стоимость составила около 102 миллионов долларов. Одна из причин — начало строительства до завершения проектирования уникальной конструкции крыши-оболочек, что вызвало множество изменений и конфликтов.

Бент Фливбьерг в статье «What You Should Know About Megaprojects and Why: An Overview» (Project Management Journal, 2014) на большом массиве данных показал, что мегапроекты систематически превышают бюджет и сроки, и сформулировал «железный закон мегапроектов»: «over budget, over time, under benefits, over and over again» (сверх бюджета, сверх срока, с недобором выгод — снова и снова). Он оценивает глобальные расходы на мегапроекты в 6–9 триллионов долларов в год (около 8 % мирового ВВП) и рекомендует прогнозирование по референтному классу и скептическое отношение к внутренним оценкам. Для управления рисками проекта отсюда следует: типичные риски (изменения, недооценка сложности, оптимизм) стоит закладывать в оценки заранее, а не считать их «непредвиденными». Оговорка: выводы Фливбьерга относятся к крупным проектам инфраструктуры и в спорах о методике оценки его данные критикуют; для небольших проектов закономерности могут быть слабее.

Ключевые идеи и принципы

1. Принцип: реестр рисков — живой центральный артефакт

   Идентификация рисков — не разовое мероприятие: реестр обновляется на протяжении всего проекта по мере появления новых рисков и изменения статуса старых. Для каждой записи фиксируют формулировку («если… то… что приведёт к…»), причину, вероятность, воздействие, владельца, стратегию, срок, статус и триггеры. Хороший реестр невелик и читаем: 15–30 действительно значимых рисков полезнее сотни общих. Источники: интервью, сессии выявления, анализ уроков прошлых проектов, Premortem, FMEA для технических изделий.

2. Принцип: сначала приоритизация, потом реакция

   Не все риски заслуживают одинакового внимания. Качественный анализ через матрицу «вероятность — воздействие» позволяет выделить главные риски и сфокусировать ресурсы. При этом нужно помнить о слабостях матрицы: шкалы условны, нижняя ячейка «маловероятно, но катастрофично» недооценивается, а риски, попавшие в одну ячейку, могут быть несопоставимы; поэтому для критичных рисков применяют количественный анализ (сценарии, дерево решений, моделирование).

3. Принцип: стратегия зависит от природы риска

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

4. Принцип: возможности — часть управления рисками

   Неопределённость бывает и благоприятной: досрочное появление технологии, скидка поставщика, свободные ресурсы. Идентификация возможностей и стратегии для них (использование, совместное использование, усиление) входят в полноценное управление рисками. Практически возможности редко попадают в реестр, поэтому полезно отдельно спросить команду: что может пойти лучше, чем планировали, и как этим воспользоваться?

5. Принцип: мониторинг и пересмотр решений о рисках

   Решения «принять» и «снизить» не окончательны: при появлении новых данных их пересматривают (урок «Челленджера»). Для этого определяют триггеры — наблюдаемые признаки приближения риска — и регулярные точки пересмотра. Полезны ключевые индикаторы риска и обязательная эскалация: любой участник может поднять риск, а решение «принять» дублируется на уровне, который отвечает за последствия.

6. Принцип: как применять подход в организации

   Порядок: определить подход (роли, шкалы вероятности и воздействия, порог допустимого риска, периодичность пересмотра); провести выявление (сессия команды, интервью, анализ прошлых проектов, Premortem); оценить и приоритизировать; выбрать стратегии и резервы для ключевых рисков; назначить владельцев и срок; включить риски в регулярную отчётность и точки принятия решений; после завершения проекта записать уроки. Для небольших проектов достаточно простого реестра в таблице и получасового обсуждения раз в неделю или две.

7. Принцип: как оценивать пользу применения подхода

   Заранее выберите метрики. Категории устойчивы: число рисков в реестре, у которых есть владелец, стратегия и срок; доля рисков, пересмотренных за последний период; число возникших рисков, которых не было в реестре («сюрпризов»), и доля предусмотренных; отклонение фактических сроков и стоимости от плана (с учётом и без учёта резерва); доля резерва, израсходованная на известные риски; время от появления триггера до реакции; число заявленных возможностей и использованных. Если «сюрпризов» много, выявление рисков поверхностно.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: идентификацию рисков делают один раз.

   Реестр формируют на старте и не пересматривают, поэтому новые риски и изменения статуса старых остаются незамеченными.

   Как избежать

   регулярно пересматривать реестр в течение всего проекта, добавлять триггеры и пересматривать решения «принять».

2. Ошибка 2: одинаковая реакция на все риски.

   Команда пытается одинаково активно отвечать на все записи, распыляя ресурсы вместо концентрации на значимых.

   Как избежать

   приоритизировать риски по вероятности и воздействию перед выбором стратегии.

3. Ошибка 3: учитывают только угрозы.

   Возможности не выявляются и не используются, теряется часть ценности процесса.

   Как избежать

   включать в выявление возможности и планировать стратегии их использования и усиления.

4. Ошибка 4: нормализуют известный риск.

   Риск «принят» и не пересматривается, потому что до сих пор обходилось, как с уплотнительными кольцами «Челленджера».

   Как избежать

   для принятых рисков задавать триггеры и пересматривать решение при появлении новых данных; уровень принятия соответствует уровню ответственности.

5. Ошибка 5: реестр без владельцев и действий.

   Риски записаны, но у них нет ответственных, сроков и бюджета, и реестр не влияет на решения.

   Как избежать

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

6. Ошибка 6: оценки берут из внутреннего оптимизма.

   Сроки и стоимость рисков оценивают по плану проекта, игнорируя статистику похожих проектов, и систематически недооценивают.

   Как избежать

   сопоставлять оценки с данными референтного класса и прошлых проектов, привлекать независимых оценщиков.

План внедрения

1. Неделя 1: план управления рисками и первичный реестр

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

2. Неделя 2: качественный анализ

   Оценить вероятность и воздействие каждого риска и разместить их на матрице; выделить приоритетные риски; для критичных выполнить количественный анализ.

3. Неделя 3: стратегии реагирования

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

4. Неделя 4: мониторинг и пересмотр

   Установить периодичность пересмотра реестра, триггеры и порядок эскалации; связать риски с отчётностью проекта и точками принятия решений.

   Далее: интеграция с контролем проекта — связать мониторинг рисков с общим циклом контроля хода проекта, а не рассматривать его изолированно; после проекта записать уроки.

Как реализовать этот план с помощью фрейма «Управление рисками проекта (Project Risk Management)» в OrgDevTools

Фрейм «Управление рисками проекта» в OrgDevTools — сетка из четырёх блоков-карточек в два столбца с тремя вкладками: «Карточки», «Визуализация» и «Итоги». Он построен на общем движке карточек. Ниже описано именно то, что фрейм делает и не делает.

• Вкладка «Карточки» — четыре блока: «Реестр рисков» (непрерывно обновляемый артефакт; неделя 1 плана), «Матрица вероятность-воздействие» (приоритизация перед выбором стратегии; неделя 2), «Стратегия реагирования» (избегание, передача, снижение, принятие; неделя 3), «Возможности, не только угрозы» (положительные неопределённые события; неделя 4). В каждом блоке — список пунктов свободного текста: пункт добавляется по кнопке или клавишей Enter, пункты можно удалять. Матрицы как таблицы во фрейме нет: оценки записываются текстом.

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

• Вкладка «Итоги» — вердикт и кнопка создания задачи (с общей формулировкой по умолчанию).

• Вердикт общий для карточных фреймов: если пунктов нет — просит начать с любого блока; если какие-то блоки пусты — перечисляет их; если заполнены все четыре — сообщает общее число пунктов и самый насыщенный блок. Специальной вводной фразы для этой методики нет.

• Чего фрейм не делает — не строит матрицу и не считает вероятность, воздействие и приоритет; не связывает риск с владельцем, стратегией, сроком и триггером; не следит за датой обновления реестра (прежнее утверждение о том, что вкладка «Итоги» предупреждает о необновлении реестра, неверно — вердикт учитывает только пустые блоки); достаточно по одному пункту в каждом блоке, чтобы вердикт стал зелёным. Записывайте в пунктах формулировку риска, оценки, владельца, стратегию, срок, триггер и дату пересмотра.

Книги по теме

Project Management Institute — «A Guide to the Project Management Body of Knowledge (PMBOK Guide)». Официальный свод знаний по управлению проектами, включающий описание управления рисками; структура процессов меняется по изданиям, поэтому нужно использовать актуальное.

Д. Воон — «The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA» (1996). Социологический разбор нормализации отклонений и принятия решения о запуске «Челленджера».

Б. Фливбьерг — «What You Should Know About Megaprojects and Why: An Overview» (Project Management Journal, 2014). Статья о систематических превышениях бюджета и сроков в мегапроектах и рекомендациях по оценке.