Почему PM управляет известными рисками, но пропускает то, на чём держится весь проект

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

Но проблемка не в матрице. Важно, что именно команда в неё записывает.

Обычно туда попадают риски, которые люди уже способны увидеть и сформулировать. Но под проектным планом есть ещё один слой – предположения, которые команда не замечает, потому что воспринимает их как факты.

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

Почему это сразу не заносят в риски? Потому что внутри команды нет формулировки: “Есть вероятность, что заказчик не сможет быстро принимать решения”. Есть другая мысль: “Заказчик будет принимать решения раз в неделю”. Это уже встроено в план как данность и поэтому не обсуждается.

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

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

Он не игнорирует эти риски. У него просто нет опыта, чтобы их увидеть.

В проектах то же самое. Опытный PM знает больше типовых рисков, чем начинающий. Но и он ограничен своим опытом, контекстом и тем, что команда считает очевидным.

Поэтому до заполнения матрицы рисков полезно отдельно спросить:

“Что должно оказаться правдой, чтобы наш проект сработал по этому плану?”

Так появляются предположения.

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

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

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

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

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

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

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

Накидайте 🔥 – напишу о таких фейлах из своего проджектовского прошлого