Дорогие “делатели” проектов и “выпускатели” продуктов, не забывайте про менеджмент изменений. Достаточно просто подумать об этом на старте, и вы сразу снизите неопределенность, скорректируете роудмап и выявите гору скрытых рисков.

Change management – это управление переходом людей и процессов из текущего состояния в новое, чтобы результат проекта не просто был “сдан”, а реально начал использоваться.

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

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

В базовой цепочке scope → сроки → бюджет → delivery появляются новые звенья: stakeholders → сопротивление → коммуникации → обучение → adoption → закрепление изменений

Пример. В компании решили уйти от легаси CRM-ки. Запустили дискавери, выделили MVP, собрали роадмап, всё посчитали, но не подумали о change management.

А там, оказывается, нужно пользовательские инструкции написать для бэк-офиса, коммерции. Подготовить сценарии для службы поддержки. Провести парочку вебинаров и объяснить, как этим пользоваться и как теперь изменится привычный рабочий распорядок дня.

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

И давайте не будем забывать, что всё это нужно обслуживать и поддерживать – нужен ИТ-шный ресурс, и хорошо бы ИБ-шников подключить.

В итоге оказывается, что сделать намного проще, чем внедрить. Но об этом почему-то думают в последнюю очередь.

Так что, если PM хочет сделать действительно что-то важное, а не просто зарелизиться ради KPI, то думать о change management нужно еще на старте.