Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
10 июля 2018 Все для начинающего РМа
1 762 2

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

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

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

Вообще 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 боретесь?

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

2комментария

сначала новые
по рейтингу сначала новые по хронологии
1

Удивительно… проблема в том, что вы чего-то там не сделали 🙂 мб всё-таки что-то сделали не так? Это абсолютно разные вещи. Это как: проблема в том, что вы не внедрили нашу систему :))

Автор2
Юлия Бажанова

А можете, пожалуйста, привести конкретный пример, что именно не так, и что должно быть изложено по-другому? В данном контексте лично для меня да, разницы нет. Например, если вы построили процесс управления изменениями “нет так”, то это равноценно тому, что вы его вообще не построили, раз он не сработал.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: