Scope Creep
Scope Creep — самый частый риск проектов. По исследованиям PMI, 52% проектов сталкиваются с этим явлением.
Причины
- Слабо определённый scope в начале.
- Стейкхолдеры просят «маленькие добавки».
- Неотлаженный Change Control Process.
- «Gold plating» — команда добавляет фичи «бесплатно».
- Внешние изменения (рынок, регуляция).
Как бороться
- Чёткий Project Charter и WBS в начале.
- Change Request — любое изменение проходит через формальный процесс с пересчётом сроков и бюджета.
- Stakeholder management — регулярная коммуникация ожиданий.
- В Agile — фиксированный спринт, изменения в Product Backlog не влияют на текущий спринт.
Когда применять и когда нет
Применять
- Любой проект с фиксированным scope
- Мониторинг — постоянно
Не применять
- Чисто Agile — там «scope creep» — это нормальная адаптация
Примеры применения
Проект сайта на 3 месяца. На середине заказчик: «Давайте ещё блог сделаем». Потом: «И корзину тоже». Потом: «И мобильное приложение». PM соглашается без формального Change Request. Итог — проект растягивается на 8 месяцев, бюджет вырастает в 2 раза.
Часто задаваемые вопросы
Изменение требований — формально утверждённое через Change Request с пересмотром сроков/бюджета. Scope Creep — неформальное «маленькое добавление» без пересмотра. Первое — нормально, второе — риск.
Иногда. Если рынок меняется и проект адаптируется — это рациональный pivot. Но любое изменение должно проходить через Change Request, иначе теряется контроль.