Управление проектами - это философия управления, а не инструмент или техника

Все проекты имеют (или должны иметь) набор предоставляемых результатов, выделенный бюджет и расчетное время завершения. Есть согласованные требования и задачи, которые нужно выполнить до завершения проекта. Они образуют масштаб проекта. Любое изменение в масштабе проекта может повлиять на график, бюджет и, в свою очередь, на успех проекта.

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

Согласно PMBOK (основы управления проектами) версии 4, расползание масштаба определяется как добавление свойств и функций (масштаб проекта) без учета влияния на сроки, стоимость и ресурсы, или без одобрения клиента. Этот процесс может происходить, когда масштаб проекта должным образом не определен, не документирован или не контролируется. Обычно это считается негативным явлением, которого нужно избегать.

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

Расползание масштаба может возникать из-за:

Плохой реализации контроля за изменениями.
Неполного сбора требований перед началом выполнения проекта.
Недостаточного участия важных заинтересованных лиц (включая клиента).
Отсутствия поддержки главного спонсора.

Расползание масштаба делится на:

Техническое расползание масштаба
Коммерческое расползание масштаба

Техническое расползание масштаба происходит тогда, когда проектная группа хочет угодить клиенту и не способна отвергнуть запрос клиента на изменение в требованиях во время выполнения проекта. “Золочение” – еще одна причина, способная вызвать техническое расползание масштаба. В этом случае проектная группа (или группа разработки/проектирования), чтобы угодить клиенту, добавляет дополнительные свойства и функции, не входящие в изначальные требования.

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

Расползания масштаба можно избежать путем эффективного управления масштабом проекта. Есть несколько способов контроля или предотвращения расползания масштаба:

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

Здесь нужно отметить еще два момента:

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

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