Повышение успеха проекта при помощи лучшего управления масштабом

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

Проблемы с масштабом проекта

С масштабом проекта могут возникнуть следующие проблемы:

Неопределенность
Неопределенность в масштабе приводит к беспорядку и ненужной работе. Чтобы предотвратить это, масштаб должен быть четким и относящимся к делу.

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

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

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

Фиксация масштаба проекта

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

Для фиксации масштаба проекта полезны следующие инструменты и методы:

• Определение необходимости проекта
• Выявление ключевых заинтересованных лиц
• Выявление стимулов проекта
• Разработка оперативных концепций
• Выявление внешних интерфейсов

1. Определение необходимости проекта

При определении масштаба проекта очень важно определить необходимость в проекте. Здесь совершаются ошибки, так как большинство людей определяет реализацию, а не необходимость.

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

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

2. Выявление ключевых заинтересованных лиц

PMBOK определяет заинтересованных лиц так: "Люди и организации, которые активно участвуют в проекте, или чьи интересы могут быть затронуты положительно или отрицательно в результате выполнения проекта или успешного завершения проекта".

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

В число заинтересованных лиц проекта могут входить люди, которые:

• Покупают его
• Продают его
• Используют его
• Учат других использовать его
• Конструируют его
• Разрабатывают его
• Тестируют его
• Продают его на рынке
• Обслуживают его
• Рассчитывают получить прибыль от него.

3. Выявление стимулов проекта

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

4. От потребностей – к  требованиям. Разработка оперативных концепций

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

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

5. Выявление внешних интерфейсов

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

Внешние интерфейсы делятся на две большие категории:

• Пользователь (обычно человек) и
• Всё остальное

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

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

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

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

Заключение

Более 70% проектов терпят неудачу. Когда проекты терпят неудачу, она редко бывает исключительно технической. Свыше 80% неудавшихся проектов терпят неудачу из-за управления проектами. Проекты, как и бизнес, часто терпят неудачу, так как они не управляются надлежащим образом. Расширение масштаба – это главная причина провала проекта. Этого можно избежать, если следовать таким простым правилам, как наличие документа масштаба, достижение согласия всех заинтересованных лиц,  и наличие у проекта  плана управления изменениями, если в масштабе предполагается выполнение изменений. Управляйте масштабом и сделайте ваш проект частью успешных 30%.