Остановите расползание масштаба, разрушающее ваш проект

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

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

Определить границы проекта трудно, но без четкого определения вы навлекаете на себя проблемы.

Что такое масштаб проекта?

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

Что вызывает расползание масштаба?

Главные причины расползания масштаба:

• Плохой анализ требований.
• Отсутствие заблаговременного вовлечения пользователей.
• Недооценка сложности проекта.
• Отсутствие контроля за изменениями.
• «Золочение».

Рассмотрим каждую из них более подробно:

Плохой анализ требований

Проблема:

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

Решение:

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

Отсутствие заблаговременного вовлечения пользователей

Проблема:

Мнение, будто вы знаете, что необходимо пользователям, является серьезной ошибкой. Важно вовлекать их на этапах анализа требований и проектирования. Чем больше они вовлечены в процесс на начальных этапах проекта, тем выше вероятность того, что вы избежите расползания масштаба.

Решение:

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

Недооценка сложности проекта

Проблема:

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

Многие проекты сталкиваются с трудностями из-за того, что они новые в отрасли промышленности и никогда не выполнялись ранее. Неизвестно, чего ожидать, нет накопленного опыта и нет людей, с которыми можно посоветоваться. При таких обстоятельствах расползания масштаба вряд ли можно избежать, что вызовет перерасход бюджета и задержку сдачи проекта.

Решение:

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

Отсутствие контроля за изменениями

Проблема:

Следует ожидать наличия определенной степени расползания масштаба в большинстве проектов, поэтому важно спланировать процесс для управления данными изменениями. Можно выполнять простой процесс документирования, рассмотрения, утверждения и выделения ресурсов.

Решение:

Введите способ контроля за изменениями и журнал регистрации изменений в начале проекта. Разъясните их использование заказчику и проектной группе. Формально записанный запрос на изменение позволит вам оценить коммерческую выгоду любого изменения и получить одобрение до включения его в масштаб как дополнения. Присоедините затраты и сроки к любому изменению, чтобы заказчик точно понял его влияние. Просьба к заказчику пройти через формальный процесс помогает обеспечить наличие стремления к однозначной коммерческой выгоде изменения.

Золочение

Проблема:

Золочение – понятие, обозначающее метод выхода за пределы масштаба проекта по причине уверенности в том, что это повысит эффективность. В проектах разработки программного обеспечения разработчики нередко добавляют новые возможности, считая, что они повысят удовлетворенность заказчика. Данные изменения расходуют время и бюджет, и нет гарантии, что они повысят удовлетворенность заказчика.

Решение:

Убедитесь, что все члены группы полностью осознают масштаб проекта и сосредоточены на реализации его и ничего больше. Удостоверьтесь, что спецификации достаточно подробные, чтобы избежать любой неопределенности, способной привести к выполнению лишней работы.

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

Если к окончанию проекта остались время и деньги, позвольте заказчики решить, что делать с ними.

Краткие выводы

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

Часто невозможно избежать увеличения масштаба в течение проекта, особенно если имеется веская коммерческая причина сделать так. Но оно должно управляться должным образом. Разработайте процесс контроля за изменениями, чтобы обеспечить, что все изменения правильно документированы, рассмотрены, утверждены и обеспечены ресурсами. Примечание: Когда бюджет и сроки увеличиваются вместе с масштабом, это изменение обычно не рассматривается как расползание масштаба.

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

Если вы считаете, что только 32% всех проектов бывают абсолютно успешными; то вам лучше потратить время на реализацию требований, согласованных в начале проекта, и избегать золочения.

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