Цель проекта должна быть конкретной и измеримой. Избегайте неясно выраженных целей вроде «Создать продукт современного уровня». Цели проекта могут включать следующее.

• Список планируемых результатов (Результаты. Осязаемые и измеряемые результаты, последствия или элементы, которые необходимо произвести для завершения проекта или части проекта. Обычно группа, работающая по проекту, и заинтересованные стороны согласовывают результаты проекта перед началом проекта.) проекта.
• Конкретные сроки, как в отношении полного завершения, так и для промежуточных вех (Веха. Опорная точка, отмечающая важное событие в проекте и используемая для контроля за ходом выполнения проекта. Любая задача с нулевой длительностью автоматически отображается как веха. Однако имеется возможность отметить как веху любую задачу с произвольной длительностью.).
• Конкретные критерии качества, которым должны удовлетворять результаты работы.
• Предельный уровень затрат, который не должен быть превышен в ходе проекта.

Чтобы цели были реальными, важно, чтобы все заинтересованные стороны (Заинтересованные стороны. Лица и организации, активно участвующие в проекте, либо те, чьи интересы могут быть затронуты проектом.) официально одобрили их. Часто руководитель проекта создает специальный документ с описанием целей, который становится неотъемлемой частью проекта. Если документ создан в программе, отличной от Project, можно присоединить его к файлу проекта для удобства доступа.

При использовании Microsoft Office Project Web Access 2003 (Компонент Project Web Access. Веб-интерфейс пользователя для доступа к информации на сервере Project Server.) можно с легкостью загрузить вспомогательные документы в начале работы над проектом. Это полезно в том случае, если у группы нет общей папки или веб-узла с информацией, относящейся к проектам и решению других корпоративных задач.

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

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

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

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

Выдвигая предположения относительно проекта, примите во внимание следующие его аспекты.

• Получение результатов из других проектов и других отделов: если данный проект зависит от результатов работы других людей, осознают ли они такую зависимость и готовы ли предоставить результаты в соответствующие сроки?
• Доступность и загруженность ресурсов (включая людей, материалы и оборудование): если некоторые из сотрудников, работающих над проектом, вам не подчиняются, то кому они подчиняются? И разрешил ли вам их руководитель использовать эти ресурсы?
• Предполагаемая длительность (Длительность. Общий промежуток активного рабочего времени, необходимый для выполнения задачи, т. е. промежуток рабочего времени от начала до окончания задачи в соответствии с календарем проекта и ресурсов.) задач: основаны ли оценки на надежной информации или на догадках?
• Предполагаемые затраты (Затраты. Общие запланированные затраты на задачу, ресурс, назначение или весь проект. Иногда их называют текущими затратами. Для базовых затрат в приложении Project используется термин «бюджет».) на проект: насколько велико их значение? Кто должен одобрить бюджет (Бюджет. Оценочные затраты на проект, заданные в базовом плане в приложении Project.) или увеличить его в случае необходимости?
• Имеющееся время: если известен крайний срок (Крайний срок. Намеченная дата, указывающая время завершения задачи. Если крайний срок пройден, а задача не завершена, в Microsoft Project выводится соответствующий индикатор.), реально ли выполнить все задачи с приемлемым уровнем качества?
• Результаты работы: отвечает ли перечень результатов ожиданиям заказчика и других заинтересованных сторон (Заинтересованные стороны. Лица и организации, активно участвующие в проекте, либо те, чьи интересы могут быть затронуты проектом.) ? Если необходим компромисс, согласованы ли с заинтересованными сторонами те аспекты результата, по которым в первую очередь можно пойти на компромисс?

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

Обычно различают три основных типа ограничений:

• календарный план (Календарный план. Расписание и последовательность выполнения задач в проекте. Календарный план в основном содержит сведения о задачах, зависимостях задач, длительностях, ограничениях и другие сведения о временных параметрах проекта.), например фиксированная дата окончания или крайний срок для одной из важных вех (Веха. Опорная точка, отмечающая важное событие в проекте и используемая для контроля за ходом выполнения проекта. Любая задача с нулевой длительностью автоматически отображается как веха. Однако имеется возможность отметить как веху любую задачу с произвольной длительностью.);
• ресурсы (Ресурсы. Исполнители, оборудование и материалы, используемые для выполнения задач в проекте.), например заранее установленный бюджет (Бюджет. Оценочные затраты на проект, заданные в базовом плане в приложении Project.);
• область охвата (Область охвата. Комбинация всех целей и задач проекта, а также работ, необходимых для их выполнения.), например требование, оговаривающее разработку трех моделей продукта.

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

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

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

 Примечание.   В Project термин «ограничение» означает лимитирующее условие, накладываемое на задачу (Задача. Действия, имеющие начало и конец. Планы проектов состоят из задач.). Например, можно потребовать, чтобы выполнение задачи начиналось в определенный день или заканчивалось не позднее определенного срока.

Область охвата проекта — это комбинация всех целей и задач проекта, а также работ, необходимых для их выполнения.

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

В план управления областью охвата может входить следующее.

• Оценка вероятности изменения области охвата, а также частоты и масштабов таких изменений.
• Описание правил идентификации и классификации изменений области охвата. Например, в строительном проекте можно предусмотреть такое правило: если клиент просит внести конструктивное изменение, которое обойдется менее чем в 10 тыс. рублей, прораб вправе согласиться на это, но если затраты, вызванные изменением, будут выше, руководитель проекта и клиент должны заново оценить область охвата проекта с точки зрения стоимости, ресурсов и прочих факторов.
• План действий в случае изменения области охвата (например, оповещение спонсора и выдача распоряжения об изменении контракта).

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