Scope Creep. Проблема ли это вообще?

🔝В проектных сообществах, что наших, что зарубежных, среди Топ-5 проблем, беспокоящих руководителей проектов обязательно окажется Scope Creep. Хмм... Прочитаем средневзвешенное по нескольким AI определение: Scope creep — это непрерывное, неконтролируемое расширение объема работ проекта без соответствующей корректировки сроков, бюджета, ресурсов или целей.

Хоть убейте, не понимаю, а в чем здесь проблема? Это же - наша обычная жизнь, изменений много, все неконтролируемые и перпендикулярны твоим целям и срокам, просто случаются - и всё :)

Пример 1: 🏪 Ты пошел в ближайший магазин за хлебом, по дороге позвонили из дома и говорят: "о, раз ты в магазин пошел - купи еще и молока (пива)" Проблема? Повод для паники? Уверен, что ты в моменте отлично знаешь, как на этот звонок отреагировать

Пример 2: 🛠Ты стартовал ремонт квартиры. У тебя есть выделенный бюджет и дедлайн по срокам. Вы договорились с бригадой на деньги и сроки, процесс пошел. И вот обнаруживается в ходе работ скрытый дефект (сняли полы, а там …), который требует доп. работ, а как следствие, затрат бюджета и времени. Разве это катастрофа?

Пример 3, прямо из ИТ: 💻 ИТ-команда делает доработку приложения, внедряете крутое улучшение функционала и клиентского пути. За неделю до внедрения прибегает Лидер Продукта и говорит: "конкуренты внедрили киллер-фичу, нам вот с этим внедряться вообще бесполезно. Давайте допилим так и так". Достаточно распространенная ситуация - не повод ни писать заявление об уходе, ни считать лидера продукта идиотом, ни впадать в депрессию.

🍃А еще мы живем в динамичном мире, с беспрецедентной скоростью изменений -в общем в любой момент может произойти то, что потребует той или иной корректировки планов.

❓Так если изменения - обычная ситуация, то что не так? В самом деле, может ли считаться проблемой, что в Москве в любой день с весны по осень может пойти дождь, а зимой - снег?

✍️ Любая теория проектного управления содержит описание процесса управления изменениями, который в таких случаях и надо применять. А если по простому - то это изменение надо просто правильно в проекте обработать.

То есть: 1️⃣На берегу или хотя бы при первом изменении скоупа договариваемся с Заказчиком, что каждое новое или измененное требование перед взятием в работу оценивается, согласовывается и фиксируется в некотором специальном реестре. Каждое! Даже незначительное и даже которое проще сделать, чем описать.

2️⃣Согласовываем в команде и с Заказчиком хотя бы минимальный процесс ведения этого реестра в деталях. Например: сначала обсуждаем изменение и потом вносим в реестр или сначала вносим - потом обсуждаем. А так же формат запроса на изменение, кто может подать, какая периодичность, время реакции и т.д.

3️⃣ Реестр с изменениями выкладываем в общий проектный доступ.

Приблизительный формат такого реестра кидаю в первый комментарий.

Плюсы: 🎯Каждое изменение и его влияние на проект согласовано Заказчиком и исполнителем. 🎯Какое-нибудь изменение может быть снято Заказчиком или отнесено на поздние фазы - после того как Заказчик осознал его влияние на проект. 🎯Минимизированы риски претензий (сделали не то, не так, не вовремя) 🎯Ретроспективно и в любой момент времени доступно понимание почему мы сейчас здесь. 🎯Упрощен процесс внесения изменений в договор/контракт

Минусы: Не вижу. Только трудозатраты на ведение реестра - правильнее взять на себя РП.

Итого, проблема Scope Creep-то где? В чем?

Ах проблема именно тогда, когда реестр не ведется и требования заходят бесконтрольно? Так это проблема в менеджере, а не в каком-то там Scope Creep 😀

Я чего-то не правильно понимаю? Напишите в комментах, помогите разобраться ✍️ P.S. Картинку взял тут