Описание содержания[17] представляет собой письменное изложение целей, этапов и продуктов проекта (рис. 5.5). Описание содержания отвечает на вопрос, имеющий основополагающе значение: «Что мы производим в данном проекте?» Это позволяет оценить желаемый результат и составить базовый план содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле базовый план содержания можно сравнить с границами проекта – он говорит о том, что выход за границы не допускается без санкции руководителя и что все, находящееся в этих границах, представляет собой пространство решений, в котором разрешается действовать команде проекта. Хотя существует множество версий описания содержания, формат, представленный ниже, основан на утверждении, что проект – это бизнес-предприятие.

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

Сбор исходной информации.Качество описания содержания во многом зависит от качества исходной информации. В частности, при разработке полноценного описания особенно важны:

•голос заказчика;

•устав проекта;

•SWOT-анализ проекта.

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

Рис. 5.5.Простой пример описания содержания

Возможно, при разработке устава также использовались инструменты. Как документ, авторизующий проект, устав должен был опираться на бизнес-нужды и цели, ради которых инициирован проект. Эти бизнес-нужды и цели крайне важны для описания содержания, в частности для тех его элементов, которые определяют бизнес-цель и задачи проекта. Кроме того, устав, вероятно, уже включает в себя предварительное описание продукта проекта, сведения о дальнейшей детализации продукта, соответствующие результаты, контрольные события и цели. Еще один источник информации – SWOT-анализ проекта. Очевидно, что описание содержания и его логика должны учитывать данные о сильных и слабых сторонах, благоприятных возможностях и угрозах проекта, полученные в ходе анализа разрывов. Прежде чем приступить к определению содержания проекта, подумайте, не разумнее ли описывать содержание параллельно с разработкой СДР: такой подход позволяет достичь согласования ответов на вопросы «Что мы производим в данном проекте?» (содержание) и «Как мы это производим?» (СДР).

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

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

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

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

Определение бизнес-цели.Давно минули те времена, когда проекты рассматривались исключительно как технические предприятия, цель которых состояла в производстве некоторого продукта или услуги. Сегодня, помимо такого производства, любая фирма должна стремиться к достижению ряда бизнес-целей, к которым относятся желаемая прибыль, доля рынка, накопление знаний, удовлетворение клиентов, определенный уровень производительности и т. д. [19]. Как следствие, разработка содержания начинается с обоснования проекта – с его бизнес-цели. Каких бизнес-целей должен достичь проект? Какие бизнес-планы он будет поддерживать? Для обычного менеджера рассмотрение проекта в терминах бизнеса – дело нелегкое. Но таковы современные проекты. И требования к ним предъявляются соответствующие: быстрее, дешевле и лучше, чем было в прошлом году. Некоторые специалисты полагают, что бизнес-цель проекта должна называться «констатацией предмета страсти проекта» и отвечать на вопрос «Какую уникальную ценность представляет ваш проект для клиента и для бизнеса компании?» Немецкий философ Гегель однажды сказал, что «ничто великое в мире не совершается без страсти».

Определение целей проекта[18]. Сколь бы призывной и вдохновляющей ни была бизнес-цель, она представляет собой лишь общее направление, не содержащее деталей о конкретных целевых установках проекта. Эти установки определяются целями проекта по части сроков (временная цель), стоимости (стоимостная цель) и качества (качественная цель) – см. элемент «цели проекта» на рис. 5.5. Конкретизируя дату завершения проекта (например, 1 мая 2003 г.), вы тем самым устанавливаете свою временную цель. Чтобы достичь ее, необходим конкретный бюджет, который вы должны определить (например, «бюджет проекта модернизации фабрики составляет 400 миллионов долларов»). В отраслях, где бюджеты средств не используются, допускается указание желательного количества часов работы ресурсов (например, «1200 часов работы ресурсов»). В отличие от временных и стоимостных/ресурсных целей, выражение качественной цели конкретным и измеримым образом может представлять собой проблему. Так как под качеством подразумевается удовлетворение или превышение требований заказчика, обычно описываемых какими-либо стандартами, разумно по согласованию с клиентом определить качественную цель проекта путем ссылки на тот или иной стандарт – например, «пользовательское руководство для данного проекта соответствует PMBOK» [5] (см. главу 8).

Поставив цели, мы наверняка столкнемся со ставшим уже притчей во языцех трехсторонним ограничением – удачный способ сформулировать тот факт, что три наши цели конкурируют друг с другом [5]. Если сократить целевое расписание проекта, придется увеличивать бюджет средств. Также изменение целевой установки по качеству может повлиять на стоимостную и временную цели. Очевидно, что эти цели взаимосвязаны и управлять ими – значит находить компромиссы. По названной причине во многих проектах принято расставлять приоритеты целей: наивысший приоритет – сроки, затем – качество, наинизший приоритет – стоимость. Иначе говоря, в ситуации, где требуется компромисс, мы в первую очередь должны стремиться соблюсти сроки, не обращая внимания на цели с более низкими приоритетами. Эта проблема существенно усложняется при разработке новых продуктов, когда необходимо ввести четвертую цель и четвертое ограничение – стоимость продукта [2]. Чтобы принимать решения в условиях четырехстороннего ограничения, нужно очень хорошо понимать тонкие взаимодействия между целями проекта.

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

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

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

•«отчет о технологических картах выполнения операций готов» – 15 февраля 2002 г.;

•«конфигурирование программного обеспечения завершено» – 28 февраля 2002 г.;

•«план обучения составлен» – 28 февраля 2002 г.;

•«прототип разработан» – 30 марта 2002 г.;

•«персонал обучен» – 16 апреля 2002 г.;

•«программное обеспечение выпущено» – 30 апреля 2002 г.

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

Определение основных допущений и ограничений.Во время определения содержания вы будете принимать как данность ряд факторов, которые на самом деле не известны точно либо являются неопределенными. Мы называем их допущениями. Несколько лет назад в работе над неким проектом команда основывалась на том допущении, что платформа продуктов, которую они разрабатывают, будет использоваться только в их бизнес-единице. Как следствие, описание содержания было составлено соответствующим образом. Когда их исполнительный директор увидел этот документ, он немедленно изменил допущение, сказав: «Я хочу, чтобы новая платформа использовалась также нашими зарубежными дочерними компаниями», – после чего содержание было изменено. В другом проекте допущение состояло в том, что для выдерживания сроков все десять программистов компании в течение двух месяцев должны работать круглосуточно. Впоследствии и допущение, и содержание пришлось изменить, поскольку вице-президент по инжинирингу потребовал, чтобы труд программистов в течение этого периода был разделен между несколькими проектами. Подобные неопределенности, имеющие техническую, экономическую, ресурсную или иную природу, возникают в современном бизнесе постоянно.

Следует заметить также, что все проекты сталкиваются с серьезными ограничениями, которые могут изменить способ представления работ, получения результатов и достижения контрольных событий. Эти ограничения могут быть физическими, техническими, ресурсными или иными. Рассмотрим восхождение на Эверест как проект. Физическое ограничение здесь – климат, следовательно, проект реализуем лишь в определенные месяцы. В другом случае, когда некая консалтинговая компания принимала участие в тендере на выполнение проекта разработки справочника (технического руководства) проекта (17), владелец потребовал, чтобы все консультанты этой компании имели сертификат профессионала по управлению проектами, выдаваемый Институтом управления проектами (PMI). Такое условие вынудило компанию изменить первоначальное описание работ и образовать совместное предприятие с другой консалтинговой компанией, в которой было больше сертифицированных сотрудников. В третьем случае руководство поручило менеджеру проекта выполнить проект разработки программного продукта в режиме быстрого прохода. Однако из-за недостатка ресурсов для оперативного тестирования программы контрольные события пришлось изменить и сдвинуть на несколько месяцев. Мы привели лишь несколько примеров, говорящих об одном: сначала идентифицируйте основные ограничения и только потом разрабатывайте содержание и приступайте к выполнению проекта. В противном случае будьте готовы к тому, что ваш проект потерпит неудачу.

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

Определение исключений.Избавиться от любой привычки весьма сложно. В начале 1990-х годов некий подрядчик, занимающийся внедрением технологии в Африке, включил в содержание своих проектов поставку вычислительных центров в комплекте с офисной мебелью. Владельцам африканской компании потребовалось несколько лет, чтобы осознать, что покупать офисную мебель на месте гораздо дешевле, чем импортировать ее из Европы. Подрядчика попросили вычеркнуть мебель из содержания. Офис подрядчика был надлежащим образом уведомлен, однако мебель продолжала поставляться. Почему? Мебель стала привычной частью содержания, а уведомление не было ни достаточно сильным, ни достаточно заметным. Во избежание подобных ситуаций необходимо использовать исключения: особым образом отмечать то, что часто считается относящимся к проекту, но в данный момент не является частью содержания.

Базовая документация.Для того чтобы четко выдерживать направление и не выходить за границы, описание содержания должно быть лаконичным, возможно написанным в повелительном наклонении (см. врезки «Как надо поступать при подготовке описания содержания – простые правила» и «Как не надо поступать при подготовке описания содержания – простые правила»). Технические и другие детали в описании обычно не упоминаются: они должны быть включены в сопроводительную документацию. Если вы привыкли помещать в документацию технические спецификации, ваш подход можно только приветствовать.

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

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

1.Если описание содержания занимает несколько страниц, разделите его на две части: резюме объемом в одну страницу (как на рис. 5.5) и вспомогательную документацию.

2.Не повторяйте во второй части то, что уже изложено в первой.

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

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

5.Добейтесь утверждения документа руководством.

1.Не приступайте к определению содержания, если не знаете, как его структурировать.

2.Не превращайте содержание в чисто техническое описание проекта.

3.Не используйте неточностей (например, «около, приблизительно»).

4.Не смешивайте большие и малые цели, результаты и контрольные события.

5.Не начинайте выполнение проекта до тех пор, пока содержание не будет рассмотрено независимыми экспертами.

Время использования.При наличии всей необходимой информации опытной команде на разработку описания содержания малого или среднего проекта потребуется от 30 до 90 минут. Увеличение размеров и сложности проекта неизбежно приведет к увеличению затрат времени на составление описания.

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

Преимущества и недостатки.Описание содержания обладает рядом не подлежащих сомнению преимуществ:

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

•простота.Простота описания упрощает понимание многочисленных переменных задач проекта;

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

К основным недостаткам описания содержания относятся:

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

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

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

•анализ целевого рынка (кто именно рассматривается в качестве предполагаемых пользователей);

•определение концепции продукта и выгод, которые должны быть получены;

•очерчивание стратегии позиционирования;

•список характеристик, атрибутов, требований и спецификаций продукта (с расстановкой приоритетов по принципу «что нужно иметь», а не «что хотелось бы иметь»).

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

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

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

2.Как определяется сфера полномочий по контролю за изменениями? Например, комитет уполномочен вносить значительные изменения, существенно затрагивающие содержание. Для обеспечения оперативного реагирования председателю комитета дается право утверждения модификаций, то время как остальные члены рассматривают (но не утверждают!) задачи, соответствующие их профессиональным знаниям. Изменения, не влияющие на содержание или влияющие на него незначительно, находятся в ведении менеджера проекта.

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

4.Как осуществляется управление управленческим резервом? Для ослабления риска изменений следует выделить некоторую денежную сумму в качестве управленческого резерва (см. раздел «План реагирования на риски» главе 9) и определить порядок его использования.

5.Каким образом утвержденные изменения реализуются на практике? Например, вполне приемлемым решением может быть назначение администратора.

6.В какой момент жизненного цикла проекта нужно начать и закончить использование процедуры запроса на изменение? Этот момент должен конкретизироваться с помощью контроля за изменениями (см. раздел «Запрос на внесение изменения в проект» в главе 11).

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

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

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

Убедитесь, что описание содержания:

• основывается на исходной информации, взятой из устава проекта, голосе заказчика и анализе стратегических разрывов;

• включает в себя все элементы, определенные форматом;

• обеспечивает согласованность всех элементов;

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