Предварительное описание содержания проекта

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

· цели проекта и продукта;

· требования к продукту или услуге и характеристики таковых;

· критерии приемки продукта;

· требования и результаты проекта;

· первоначальную организацию проекта;

· первоначально сформулированные риски;

· контрольные события (вехи) расписания;

· первоначальную иерархическую структуру работ (ИСР);

· смету расходов с указанием порядка величин;

· требования к управлению конфигурацией проекта;

· требования к одобрению.

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

План управления проектом

Процесс разработки Плана управления проектом относится к группе процессов планирования.

План управления проектом объединяет следующие планы:

· План управления содержанием;

· План управления расписанием;

· План управления стоимостью;

· План управления качеством;

· План управления обеспечением проекта персоналом;

· План управления коммуникациями проекта;

· План управления рисками;

· План управления поставками;

· План управления изменениями.

185.238.139.36 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Процессы управления содержанием проекта

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

Правила определения состава работ

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

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

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

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

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

Процессы планирования и управления содержанием проекта

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

  • определение содержания проекта;
  • определение состава работ.

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

  1. Планирование управлением содержанием.
  2. Сбор требований.
  3. Определение содержания.
  4. Создание ИСР.
  5. Подтверждение.
  6. Контроль.

Три последних процесса мы рассмотрим в отдельных материалах сайта.

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

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

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

СОСТАВЛЕНИЕ ОПИСАНИЯ СОДЕРЖАНИЯ

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

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

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

Читайте так же:  Что такое основные требования средневековых ересей

ОПИСАНИЕ СОДЕРЖАНИЯ Название проекта: Излечивать Дата: 12 марта 2002 г.

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

по срокам: быть завершенным к 15 сентября 2002 г.;

по стоимости: 150 тысяч долларов; •

по качеству: в соответствии с соглашением об уровне обслуживания

Описание содержания работ проекта:

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

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

Основные контрольные события: •

технологические карты выполнения операций проанализированы: к 15 марта 2002 г.; •

прототип разработан: к 15 августа 2002 г.; •

программное обеспечение выпущено: к 15 сентября 2002 г.; •

конфигурирование закончено: к 15 апреля 2002 г.; •

обучение завершено: к 15 августа 2002 г.

С ключевыми разработчиками (проектировщиками) сотрудничать в июне будет невозможно, поскольку они уедут к европейскому партнеру фирмы

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

Данный проект не включает в себя обучение персонала навыкам обслуживания клиентов

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

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

НОВАТОРСКИЕ СПОСОБЫ РАЗРАБОТКИ УСТОЙЧИВОГО

К ИЗМЕНЕНИЯМ ОПИСАНИЯ СОДЕРЖАНИЯ

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

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

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

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

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

ятных возможностях и угрозах проекта, полученные в ходе анализа разрывов. Прежде чем приступить к определению содержания проекта, подумайте, не разумнее ли описывать содержание параллельно с разработкой СДР: такой подход позволяет достичь согласования ответов на вопросы «Что мы производим в данном проекте?» (содержание) и «Как мы это производим?» (СДР).

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

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

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

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

Читайте так же:  ТС комарова методические пособия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИСПОЛЬЗОВАНИЕ ОПИСАНИЯ СОДЕРЖАНИЯ

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

Читайте так же:  Индексация пенсия август 2018

КАК НАДО ПОСТУПАТЬ ПРИ ПОДГОТОВКЕ ОПИСАНИЯ СОДЕРЖАНИЯ — ПРОСТЫЕ ПРАВИЛА 1.

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

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

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

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

поставщиками ресурсов. 5.

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

КАК НЕ НАДО ПОСТУПАТЬ ПРИ ПОДГОТОВКЕ ОПИСАНИЯ

СОДЕРЖАНИЯ — ПРОСТЫЕ ПРАВИЛА 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПЛАН КОНТРОЛЯ ИЗМЕНЕНИЙ ЗАДАЕТ НАПРАВЛЕНИЕ КОНТРОЛЯ

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

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

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

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

Планирование содержания 3.

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

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

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

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

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

В малом проекта описание должно включать только бизнес-цель, цели проекта и контрольные события Добавление отличительной особенности — Включить в описание элемент «определение

продукта» (актуально для разработчиков аппаратного программного обеспечения); —

добавить информацию об основных исках и реагировании на них (полезно для проектов в сфере высоких технологий) Удаление характеристики Удалить из описания содержания элемент «описание работ» (часто практикуется компаниями, ориентированными на результат) Модификация конкретной характеристики Комбинировать результаты и контрольные события (полезно для проектов в сфере высоких технологий) Глава 5

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

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

ПРОВЕРКА ОПИСАНИЯ СОДЕРЖАНИЯ

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

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

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

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

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