Что такое scope creep, и как его избежать

…и как бороться, если избежать не удалось?

Вообще scope creep – это неконтролируемо разрастание или “расползание” границ проекта, приводящее к срыву сроков, перерасходу бюджета или снижению качества, чтобы удержаться в границах проекта.

У меня как раз на днях был отличный пример, когда в идущий четвертый месяц проект разработки системы управления компетенциями сотрудников попытались впихнуть разработку мобильного приложения для проверки компетенции на местах. Ну правда, с точки зрения Заказчика очень удобно – пришел на производство, осмотрелся вокруг, ткнул пальчиком в экран айфона – и тут же узнал, что Василий Петрович, негодяй, полез в шкаф на 10 киловольт, не имея необходимого уровня допуска. И функционал же тот же самый! Просто проверка обученности на основе тех же компетенций!

Но это для Заказчика, а для нас – минимум 2 новые платформы (айфоны-то не у всех, у кого-то андроид), заботы о том, чтобы человек с этим айфоном не взлетел на воздух (взрывоопасность на производстве никто не отменял), работа с юристами (т.к. большой вопрос, одобрят ли они классную идею публикации корпоративных приложений в Google Play или AppStore), отдельные навыки специалистов службы поддержки, отсутствие покрытия 3G на производственных объектах и прочее, прочее, прочее. И вот “тот же функционал” взял и превратился в утроенный объем того же проекта.

Хорошая картинка в тему:

Еще есть схожее понятие feature creep или фичеризм – бесконечное добавление «бантиков» к продукту, которые не влияют на его основной функционал, но при этом отбирают ресурсы и усложняют дальнейшее развитие. Ну, например, возможность изменения цветовой схемы системы или подтягивание последних новостей из мира управления компетенциями на главную страничку решения – это приятно, но ни разу не необходимо, и задачи, поставленные перед системой (управлять компетенциями персонала) не решает.

Почему происходит scope creep

Причин появления scope creep множество, вот самые частые:

• Вы не обозначили границы проекта или сделали это очень размыто. И либо Заказчик сейчас вами манипулирует, либо он действительно не понимал, что мобильного приложения не будет.
• У Заказчика поменялись приоритеты или бизнес-процессы, и ему теперь нужно не совсем то, что было заявлено в начале проекта.
• Вы не выявили всех стейкхолдеров в начале проекта, а они вдруг взяли и материализовались со своими вполне законными требованиями.
• Вы не дружите со словом «нет» либо у вас не хватает полномочий его сказать.
• Первоначальный анализ был проведен плохо, и вы (или ваши аналитики) не поняли, что именно и зачем надо Заказчику (какую проблему он решает), и теперь удивляетесь. С вашей точки зрения – требования «из ниоткуда», с точки зрения Заказчика – «это же очевидно!».
• Вы изначально не построили процесс управления изменениями и не сделали его прозрачным для Заказчика. Один раз согласились, второй раз включили в объем, потому что «там же немного, и для них это важно», третий раз не просчитали влияние изменения и пришлось переписывать большой кусок – и вот сроки проекта поехали на два месяца.

Как вы можете заключить из этого перечня – обычно в scope creep виноват все-таки руководитель проекта, т.к. в большинстве случаев его можно предотвратить. И даже если предотвратить scope creep  было нельзя, задача РМа – увидеть его на самых ранних стадиях и предпринять корректирующие действия.

Как понять, что происходит scope creep

Самый простой способ понять, что происходит scope creep – это попытаться ответить на вопрос “как вот этот вот функционал помогает достижению цели, обозначенной в уставе проекта?” (вы ведь его написали и заверили у спонсора и Заказчика, правда?). Если ответ неочевиден и приходит не сразу, через много «если-то» – то стоит задуматься.

Также стоит задуматься, если в проекте появились новые технологии (планировали делать на вебе, а тут подтянулась мобильная платформа), новые процессы (изначально речь шла про управление компетенциями, но в проекте уже появился процесс годовой оценки по этим компетенциям) или новые роли (проверяющий из Ростехнадзора, которому надо передавать информацию удаленно и сразу в их систему).

Что делать, если scope creep уже произошел

Если вы вдруг осознали, что, кажется, объем «поплыл», то самое время предпринять корректирующие действия. Что именно делать – зависит от ситуации, но более-менее стандартный набор шагов выглядит так:

1. Внимательнее изучить имеющиеся факты, подготовить статистику. А то иногда кажется, что «ой, поплыло!», а при ближайшем рассмотрении новые требования оказываются вполне в рамках разумного.
2. Определить корневую причину (см.список выше).
3. Если это в рамках ваших полномочий или добрые отношения с Заказчиком или Спонсором позволяют – попытаться решить вопрос на своем уровне. Очень часто достаточно просто поговорить с другими участниками проекта, чтобы эту причину устранить и в мире и согласии делать проект дальше. В таких ситуациях очень помогает, если у другого человека есть опыт управления проектами, но такое счастье редко случается.
4. Если договориться не удалось – проанализировать влияние scope creep на проект, построить прогноз («если мы будем делать мобильное приложение – это х4 к срокам и х6 к бюджету»), сформулировать конкретные предложения по выходу из сложившейся ситуации с плюсами и минусами. Чаще всего это предложение «давайте не будем распыляться, сделаем один кусок и сразу за ним другой. И деньгами и сроками будет управлять проще, результат вы получите раньше» либо «ок, это важный объем, давайте сделаем его вместо вот этого куска, его тогда из проекта выкидываем». Хотя возможны и ситуации типа «взять какую-то часть в объем проекта», особенно если, например, бюджет уже поплыл, и это способ вернуться к запланированным показателям.
5. Согласовать предложения со своим руководителем и со спонсором, вынести на Управляющий комитет и решить, что делать дальше. Даже если предложения услышаны не будут – вы хотя бы попытались.

Частая ошибка! Вы выносите ваши наблюдения на Управляющий комитет проекта, говорите, что происходит scope creep и надо бы его остановить, показываете влияние на сроки и стоимость, и вообще вроде бы делаете все от вас зависящее. И – бинго! – вам говорят, что вы умничка, мы все услышали, мы тебе даем плюс три месяца к срокам и плюс три миллиона рублей к бюджету, только сделай это мобильное приложение!

Если это так, то scope creep празднует победу. И, несмотря на сдвинутые ограничения проекта, вы теперь:

а) дробите внимание команды на очень разноплановые задачи, получая снижение эффективности и падение морального духа;

б) оправдываетесь перед другими стейкхолдерами за сдвинутые сроки (несмотря на то, что это решение Управляющего комитета – вы останетесь «тем РМом, из-за которого мы в марте не запустились»);

в) размываете результат проекта.

Банально, но чем больше и разноплановей объем – тем меньше управляемость, поэтому по возможности такой ситуации лучше избежать.

Как предотвратить scope creep

Лучше, конечно, предотвратить, чем ликвидировать. В целом для этого нужно ликвидировать причины, описанные раньше, а именно:

• Четко обозначить границы проекта, и не только то, что мы делаем, но и то, что мы не делаем (это даже важнее).
• Идентифицировать всех стейкхолдеров и их «хотелки», разработать прозрачную и понятную систему приоритезации требований и управления ими.
• При анализе требований учитывать не только сказанное вслух, но и стараться смотреть «сверху» – зачем это заказчику? Как это может поменяться в ходе проекта? Как это требование связано с поставленной целью?
• Построить процесс управления изменениями и не допускать нарушений этого процесса, даже если это «совсем маленькое изменение».
• Заложить разумный запас бюджета и времени на изменения, т.к. они все равно будут.

И, конечно, важно не только написать все вышеперечисленное в бумажках, но и донести до заказчика и других участников проекта, чтобы сформировать правильные ожидания.

Ну и, конечно, scope creep – это чаще всего последствие ошибок, допущенных в работе со стейкхолдерами или в управлении рисками.

Если вы хотите узнать больше о рисках и о том, как с ними работать – вы можете приобрести наш большой курс по управлению рисками. Шаблон реестра рисков проекта и чек-лист для идентификации рисков в подарок!

Купить курс за 2990 руб

Подробнее про курс

А если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!
Купить курс за 2990 руб

Подробнее про курс

А вы как со scope creep боретесь?