← Назад к базе знаний

Pre-mortem

Pre-mortem — фреймворк

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

Какую боль решает

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

  • Крупная сделка сорвалась по причине, которую кто-то в команде предвидел, но промолчал
  • Внедрение у клиента затянулось из-за доступов и согласований
  • План запуска продукта не учитывал реакцию партнёров
  • Реестр рисков заполнен формально

Ваш ли это случай

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

Ситуация Подходит? Что взять вместо
Старт проекта, внедрения, крупной сделки Да —
Нужно оценить и вести риски на протяжении проекта Вместе с Risk Matrix и RAID Log
Проект уже провалился, нужно понять почему Нет 5 Whys
Нужно подготовить несколько вариантов будущего Частично Сценарное планирование
Сделка: понять, что может её остановить Да Вместе с MEDDICC

Как устроено

Шаг сессии Время Суть
Сценарий провала 5 минут Ведущий описывает: прошло полгода, проект провалился
Индивидуальные причины 10 минут Каждый молча пишет свои причины
Сбор по кругу 20 минут По одной причине от каждого, пока не закончатся
Группировка и оценка 15 минут Объединить похожие, оценить вероятность и влияние
Действия 15 минут Для главных рисков — профилактика, сигнал и владелец

Как применять

  1. Соберите команду проекта и тех, кто будет участвовать со стороны клиента или партнёра, если возможно.
  2. Опишите провал конкретно: срок, масштаб, последствия.
  3. Дайте время на индивидуальную запись, чтобы не было эффекта первого мнения.
  4. Собирайте причины по кругу, без обсуждения правильности.
  5. Сгруппируйте и выберите пять-семь главных по вероятности и влиянию.
  6. Для каждого запишите профилактическое действие, ранний сигнал и владельца, добавьте в план проекта.

Пример: внедрение у крупного клиента

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

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

Где ломается

Симптом Причина Что делать
Названы только внешние причины Неудобно говорить о своих слабостях Ведущий просит назвать хотя бы одну внутреннюю причину каждого
Список рисков без действий Сессия закончилась на сборе Выделите время на профилактику и владельцев
Мнения совпадают с руководителем Руководитель говорит первым Индивидуальная запись и руководитель — последним
Делают один раз Риски меняются по ходу Повторите на ключевых вехах

До и после

Рамка редко работает одна. Вот что обычно стоит перед ней и что после.

Этап Что делаем Чем
До Определить цель и границы проекта План проекта
Сама рамка Найти риски до старта Pre-mortem
После Оценить и приоритизировать Risk Matrix
После Вести риски, допущения, проблемы RAID Log

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

Сколько длится сессия
Около часа для проекта среднего размера.
Можно ли проводить с клиентом
Да, и это сильный ход: совместная сессия показывает зрелость подрядчика и выявляет риски на стороне клиента.
Чем отличается от обычного анализа рисков
Вопрос «почему провалилось» вместо «что может пойти не так» снимает оптимизм и даёт больше конкретных причин.
Материал оказался полезным?