Описание проекта

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

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

Планы

Необходимыми атрибутами планов являются: собственно описание требуемых действий; информация о событиях, «запускающих» эти действия; описание взаимной зависимости действий между собой; информация об исполнителях. Календарный план (schedule), кроме этого, содержит информацию о прогнозируемых датах начала и окончания действий. Наиболее распространенным видом планов является план-график проекта в нотации Ганта и Перта.

Исследовательские проекты, а также проекты, управляемые временем (time-driven project), могут обходиться без планов-графиков. В таких проектах планирование может иметь неглубокий горизонт, а планы на будущий период фиксироваться, например, в регулярных отчетах.

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

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


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: