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

• Проинформировать все заинтересованные стороны о том, что уже случилось; например, часть команды ушла (поменяла работу)
• Предоставить бизнесу выбор одного из возможных путей: например, архитектурное решение (криво и быстро или качественно и долго)
• Сказать бизнесу что-то, что до этого никто не хотел слышать; например, что если постоянно срывать ресурсы с проекта, ничем хорошим это не закончится

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

Распределение ответственности на коллектив (против индивидуальной ответственности) крайне важно, поэтому остановлюсь здесь чуть подробнее:

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

А теперь сделаем шаг назад и определим проектное изменение. Это изменение одного из трёх компонентов проекта: объёма, сроков, бюджета. Всё просто? Тогда ответьте для себя на несколько проверочных вопросов:

• Является ли смена команда или даже одного руководителя проекта проектным изменением?
• Является ли смена архитектуры решения проектным изменением?
• Является ли появление нового риска проекта проектным изменением?

Надеюсь, вы проверили себя, а теперь правильные ответы:

• Даже смена руководителя проекта является проектным изменением; любому человеку, особенно на крупном проекте, требуется сначала изучить вводные, а новый руководитель проекта может вообще не подтвердить плановые сроки, которые оставил после себя его предшественник; вы можете не выделять задачи на "адаптацию новой команды", тогда сроки тоже съедут, но бесконтрольно;
• У архитектурного решения, с одной стороны, есть жизненный цикл (проектирование, разработка, тестирование, внедрение), а с другой стороны, зависимости (системы, которые интегрируются с решением) или предположения, которые были сделаны по срокам ряда задач при том, старом архитектурном решении; безусловно это проектное изменение и требуется заново оценить всё, что может поехать (прежде всего, сроки и бюджет);
• Сами по себе риски не являются проектным изменением, и в любом плане управления рисками есть вариант "забить"; а вот если появляются новые задачи (читай, объём) по управлению / митигации рисков, это уже безусловно является проектным изменением.

Есть много других пограничных случаев: изменения требований к качеству проектных результатов (изменение объёма), смена бизнес-заказчика (высокий риск изменения объёма), появление технического долга (если не забить на него, а разгребать, то это появление новых задач = изменение объёма), форс-мажор (ковид и невозможность командировок, очной поддержки, очного обучения – тут надо смотреть, но растягивание сроков с неактивным заказчиком очень вероятно). В идеале спрогнозировать сдвиги проектного плана заранее, при анализе изменения, а также сдвиги зависимых задач. Часто бывает так: ну сдвинется проект, и ладно, а вот то, что сдвинется зависимый от него большой и важный проект / запуск / бизнес-показатель – этого уже допустить никто не может. И часто важность последствий перевешивает.

В чём же роль проектного менеджера здесь?

1. Не паниковать. Всем страшно, но не любое событие является проектным изменением. Задачей проектного менеджера является анализ того, что происходит. Для этого есть шаблон запроса на изменения. На что в действительности влияет новая информация? Какие есть варианты решения? Что будет, если "оставить, как есть сейчас"?
2. Сообщить всем заинтересованным сторонам. И формализованный запрос на изменение это существенно облегчает: все получают доступ к абсолютно одинаковой актуальной трактовке того, что происходит. Обычно проектного изменения (без лишних деталей) хватает и для статуса проекта, и для Проектного комитета, и для любых других заинтересованных сторон.
3. Пересобрать проект относительно произошедшего изменения (выбранного варианта): подвинуть зависимые задачи, заложить дополнительные запасы в виде времени, если неопределённость увеличилась, добавить задачи (при той же смене проектной команды). Да, все будут против, будет много писка и истерик. Если пискуны хотят порулить проектом – "флаг им в руки, барабан на шею". Здесь вестись нельзя.

Ну и последнее напутствие в этой части: привыкните слышать "нет". Если бы мне платили $5 за каждое "нет", после которого я всё равно сдвигал сроки, на что-нибудь ощутимо материальное точно бы хватило. "Нет" – это бытовое сопротивление тому, что есть в реальности. Также и сами проекты приводят к изменениям, а люди, в основном, хотят сохранить статус кво. Так что это лишь ещё одна контр-интуитивная вещь в проектном управлении. Особенно забавно это звучит в части программной разработки, поскольку её трудоёмкость объективна. "Нет" говорят люди, которые думают, что у них власть, но на самом деле:

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

Всё, что им остаётся – это недовольно стучать ножками и морально давить. Блин, если вы на это ведётесь, мне жаль.