Управление изменениями: Расползание границ проекта и как с ним бороться?

“Расползание” границ проекта.

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

Расползание границ проекта - это изменение требований, которые пытаются включить в проект уже на этапе реализации. Часто эта попытка приводит к задержке выпуска основной функции, для которой предназначен сервис.
Как понять, что границы проекта начинают расширяться:

⚡Появляются дополнительные функции, которые не были изначально запланированы
⚡Появляются запросы на улучшение, вытекающие из первоначальных вводных проекта
⚡Появляются изменения в целях проекта - без корректировки бюджета или сроков
⚡Выявляются скрытые проблемы (в системах, с которыми происходит интеграция, в данных, в процессах и пр.), решение которых требуется для успеха проекта
⚡Меняется состав заинтересованных сторон - и, как следствие, другой взгляд на результаты
⚡Меняется рынок - внешние факторы могут повлечь за собой новые вызовы, стоящие перед создаваемой системой
⚡Команда начинает понимать, что недооценила сложность проекта.

Куда бежать и что делать (ДО ПРОЕКТА)?

1⃣ PMBOK включает главу про управление изменениями. У вас должен быть выстроен процесс управления изменениями, который определяет, содержит идентификацию изменений, оценку воздействия и процесс утверждения. Не важно какое будет изменение - оно должно пройти этот рабочий процесс.

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

Если апдейт требований неизбежен - то вот что нужно знать:

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

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

✅Важно четко понимать среднюю производительность команды. Вы должны понимать не только оценку в часах разработки, но и то, сколько в целом займет добавление новой функции со всеми согласованиями/ тестированием/ обсуждениями, включая время на проработку. Тогда дополнительное время становится хотя бы прогнозируемо.

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

✅Новые требования можно включить в следующий релиз! Да-да, все просто. Только нужно взвесить все за и против и правильно расставить приоритеты.

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

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