Как работать с изменениями на проекте

Изменения — неизбежная часть проектов. Обычно они вызваны новыми требованиями, новыми рыночными реалиями, технологическими улучшениями или сменой руководства компании. В то же время, каждое изменение — это дополнительные риски, ресурсы и давление на сроки. Так что же делать с изменениями?

Менеджер проектов Dinord делится правилами, которыми руководствуется на своих проектах.

1. Старайтесь избегать изменений

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

2. Формализуйте процесс внесения изменений

Четко прописанный на старте проекта процесс управления изменениями позволит избежать хаоса. Dinord рекомендует такой подход:: 

1. Продумайте процедуру фиксации изменений — реестры, системы регистрации тикетов и т.д.
2. Оцените их влияние как от реализации изменения, так и отказа от реализации (включая влияние на бюджет, сроки, команду проекта)
3. Проверьте на соответствие целям и выгодам проекта
4. Утвердите или отмените изменение. Заранее определите, кто может принимать такие решения, и зафиксируйте это в матрице RACI

Но даже с формализованной процедурой управления изменениями мы настоятельно рекомендуем не забывать о правиле №1. Если изменение уже возникло, что же делать с ним дальше?

3. Выносите изменения за рамки проекта

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

Эти три правила позволяют держать изменения под контролем. Теперь на конкретном примере покажем, как действуем в условиях  внесения изменений 

Кейс Dinord по работе с изменениями. Фармацевтическая компания и учет свободной мощности

Один из наших клиентов — крупная фармацевтическая компания — инициировала проект по доработке и унификации текущего решения по фактическому учета и планированию свободной мощности, с тиражированием на предприятия компании (5 БЕ). В процессе проектирования и реализации не была учтена часть работ по плановой калькуляции, которая не попала в ПР и в расчет стоимости текущего объема работ

Порядок действий Dinord в этом случае:

1. Выявили проблему

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

2. Проанализировали причины

Команда Dinord выяснила, почему плановая калькуляция не была учтена:

1. На стадии инициации работ были заложены и фактическая, и плановая калькуляция. 
2. В 2023 году было принято решение о старте работ на БЕ 1, и подготовка первой версии FS была для данной БЕ, где есть только фактическая калькуляция. Таким образом FS была только по фактической калькуляции.
3. Проект был заморожен с конца 2023 года по начало 2024.
4. После рестарта проекта была произведена замена первой БЕ для запуска с БЕ1 на БЕ2
5. На проекте поменялся эксперт, который взял в работу согласованный ранее FS и расчет стоимости проекта сделали по ней, т.е. по FS БЕ1, в которой была учтена только фактическая калькуляция.
6. FS был повторно согласован с ВПБ и уже по нему были выполнены работы, к постановке 2023 года не возвращались

3. Нашли оптимальное решение

Мы предложили следующее: реализовать функционал по плановой калькуляции для БЕ в счет текущего проекта без привлечения доп.средств, но при необходимости тиражирования этого функционала на другие 4 БЕ открыть новую активность с новым бюджетом.

4. Утвердили решение с клиентом

Заказчик согласился с нашим решением, но предложил условия: если тираж будет, то в бюджет проекта разрешено включить ту стоимость работ, которую мы понесли при реализации плановой калькуляции для БЕ2.

5. Результат

Функционал, который ошибочно не был включен в объем проекта мы перевели в статус доп.требования и провели работу по управлению изменениями.

6. Выводы

1. При подключении к проекту на более поздних этапах важно запросить всю исходную документацию и проинтервьюировать владельца бизнес-процесса. Это поможет уточнить цели и задачи проекта, а также обеспечить точность их формулировки.
2. Хранить все исторические данные, чтобы можно было корректно проанализировать причину возникновения спорной ситуации.
3. Ограничивать объем проекта очень четко и дополнительно уже по ходу проекта проговаривать его и напоминать клиенту.