Текст книги "Руководство к Своду знаний по управлению проектами (Руководство PMBOK)"

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

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

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

♦ Пакет работ. Самым нижним уровнем ИСР является пакет работ с уникальным идентификатором. Данные идентификаторы предоставляют структуру для иерархического суммирования информации о стоимости, расписании и ресурсах, а также формируют код учета. Каждый пакет работ является частью контрольного счета. Контрольный счет – это элемент управления, в котором содержание, бюджет и расписание объединяются и сравниваются с освоенным объемом для измерения исполнения. Контрольный счет имеет два или более пакетов работ, хотя каждый пакет работ связан с единственным контрольным счетом.

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

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

• идентификатор кода учета,

• описание работ,

• допущения и ограничения,

• ответственную организацию,

• контрольные события расписания,

• связанные операции расписания,

• требуемые ресурсы,

• оценки стоимости,

• требования к качеству,

• критерии приемки,

• технические ссылки,

• информацию по соглашениям.

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

♦ Журнал допущений. Описан в разделе 4.1.3.2. Журнал допущений обновляется путем внесения дополнительных допущений или ограничений, которые были определены в ходе процесса создания ИСР.

♦ Документацию по требованиям. Описана в разделе 5.2.3.1. Документация по требованиям может обновляться с целью включения утвержденных изменений, возникших в результате процесса создания ИСР.

Подтверждение содержания – процесс формализованной приемки полученных поставляемых результатов проекта. Ключевая выгода данного процесса состоит в обеспечении объективности процесса приемки и повышении вероятности приемки конечного продукта, услуги или результата путем подтверждения каждого поставляемого результата. Этот процесс осуществляется периодически на протяжении всего проекта, по мере необходимости. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-15. На рис. 5-16 показана диаграмма потоков данных процесса.

Рис. 5-15. Подтверждение содержания: входы, инструменты и методы, выходы

Рис. 5-16. Подтверждение содержания: диаграмма потоков данных

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

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

Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего:

♦ План управления содержанием. Описан в разделе 5.1.3.1. План управления проектом устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта.

♦ План управления требованиями. Описан в разделе 5.1.3.2. План управления требованиями описывает, как производится подтверждение требований проекта.

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

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

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

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

♦ Документацию по требованиям. Описана в разделе 5.2.3.1. Требования сравниваются с фактическими результатами с целью определить, требуются ли изменения, корректирующие или предупреждающие действия.

♦ Матрицу отслеживания требований. Описана в разделе 5.2.3.2. Матрица отслеживания требований содержит информацию о требованиях, включая порядок их подтверждения.

Проверенные поставляемые результаты – это поставляемые результаты проекта, полученные и проверенные на правильность в рамках процесса контроля качества.

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

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

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

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

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

Полученные поставляемые результаты, которые не были формально приняты, документируются с указанием причин, по которым они не были приняты. Такие поставляемые результаты могут потребовать запроса на изменение для исправления дефекта. Запросы на изменения (см. раздел 4.3.3.4) проходят процесс рассмотрения и принятия решения об исполнении в соответствии с процессом интегрированного контроля изменений (см. раздел 4.6).

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

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

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

♦ Матрицу отслеживания требований. Описана в разделе 5.2.3.2. Матрица отслеживания требований обновляется за счет внесения результатов подтверждения, включая сведения о примененном методе и конечном результате.

Контроль содержания – процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию. Ключевая выгода данного процесса состоит в том, что ведение базового плана по содержанию осуществляется на протяжении всего проекта. Этот процесс осуществляется на протяжении всего проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-17. На рис. 5-18 показана диаграмма потоков данных процесса.

Рис. 5-17. Контроль содержания: входы, инструменты и методы, выходы

Рис. 5-18. Контроль содержания: диаграмма потоков данных

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

Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего:

♦ План управления содержанием. Описан в разделе 5.1.3.1. Процесс управления содержанием документирует, каким образом содержание проекта и продукта будет контролироваться.

♦ План управления требованиями. Описан в разделе 5.1.3.2. План управления требованиями описывает, как осуществляется управление требованиями проекта.

♦ План управления изменениями. Описан в разделе 4.2.3.1. План управления изменениями определяет процесс управления изменениями проекта.

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

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

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

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

♦ Реестр извлеченных уроков. Описан в разделе 4.4.3.1. Уроки, извлеченные на более ранних стадиях проекта, могут применяться на его более поздних стадиях с целью улучшения контроля содержания.

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

♦ Матрицу отслеживания требований. Описана в разделе 5.2.3.2. Матрица отслеживания требований помогает выявить воздействие какого-либо изменения или отклонения от базового плана по содержанию на цели проекта. Она также предоставляет статус контролируемых требований.

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

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

♦ существующие формальные и неформальные политики, процедуры и руководящие указания, связанные с содержанием и контролем;

♦ используемые шаблоны и методы мониторинга и отчетности.

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

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

♦ Анализ тенденций. Описан в разделе 4.5.2.2. Анализ тенденций предполагает изучение данных об исполнении проекта с течением времени для определения того, улучшается или ухудшается исполнение проекта.

Важные аспекты контроля содержания проекта включают в себя определение причины и степени отклонения от базового плана по содержанию (раздел 5.4.3.1) и принятие решений о необходимости корректирующих или предупреждающих действий.

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

Описаны в разделе 4.3.3.4. Анализ исполнения проекта может привести к запросу на изменение базового плана по содержанию, базового расписания или других компонентов плана управления проектом. Запросы на изменения проходят проверку и направление в соответствии с процессом интегрированного контроля изменений (см. раздел 4.6).

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

♦ План управления содержанием. Описан в разделе 5.1.3.1. План управления содержанием может обновляться для отражения изменений порядка управления содержанием.

♦ Базовый план по содержанию. Описан в разделе 5.4.3.1. В связи с одобренными изменениями содержания, описания содержания, ИСР или словаря ИСР в базовый план по содержанию вносятся соответствующие изменения. В некоторых случаях отклонения по содержанию могут быть настолько существенными, что для создания реалистичной основы для измерения исполнения базовый план по содержанию должен быть пересмотрен.

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

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

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

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

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

♦ Документацию по требованиям. Описана в разделе 5.2.3.1. Документация по требованиям может обновляться путем внесения в нее дополнительных или измененных требований.

♦ Матрицу отслеживания требований. Описана в разделе 5.2.3.2. Матрица отслеживания требований может обновляться с целью отражения обновлений, внесенных в документацию по требованиям.

6. Управление расписанием проекта

Управление расписанием проекта включает в себя процессы, необходимые для управления своевременным выполнением проекта. Управление расписанием проекта включает в себя следующие процессы:

6.1. Планирование управления расписанием – это процесс, устанавливающий политики, процедуры и документацию по планированию, разработке, управлению, исполнению и контролю за расписанием проекта.

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

6.3. Определение последовательности операций – это процесс определения и документирования связей между операциями проекта.

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

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

6.6. Контроль расписания – это процесс мониторинга статуса проекта для актуализации расписания проекта и управления изменениями базового расписания.

На рис. 6–1 представлена общая схема процессов управления расписанием проекта. Процессы управления расписанием проекта представляются в виде дискретных процессов с определенными границами, хотя на практике они накладываются и взаимодействуют такими способами, которые не могут быть в полной мере детализированы в Руководстве PMBOK®.

Рис. 6–1. Общая схема управления расписанием проекта

КЛЮЧЕВЫЕ КОНЦЕПЦИИ УПРАВЛЕНИЯ РАСПИСАНИЕМ ПРОЕКТА

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

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

В небольших проектах определение операций, определение последовательности операций, оценка длительности операций и разработка модели расписания настолько тесно связаны, что их рассматривают как единый процесс, который может быть выполнен человеком за сравнительно короткий период времени. Здесь эти процессы представлены как дискретные элементы, потому что инструменты и методы каждого процесса различны. Некоторые из этих процессов более подробно описаны в Практическом стандарте разработки расписания (Practice Standard for Scheduling) [2].

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

Рис. 6–2. Общая схема составления расписания

ТЕНДЕНЦИИ И ВНОВЬ ПОЯВЛЯЮЩИЕСЯ ПРАКТИКИ В ОБЛАСТИ УПРАВЛЕНИЯ РАСПИСАНИЕМ ПРОЕКТА

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

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

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

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

СООБРАЖЕНИЯ ПО АДАПТАЦИИ

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

♦ Подход к жизненному циклу проекта. Какой подход к жизненному циклу будет наиболее целесообразным, чтобы можно было составить более подробное расписание?

♦ Доступность ресурсов. Какие факторы оказывают влияние на длительности (например, взаимосвязь между имеющимся ресурсом и его производительностью)?

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

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

Для получения более подробной информации относительно составления расписания см. документ «Практический стандарт разработки расписания» (Practice Standard for Scheduling) [16].

СООБРАЖЕНИЯ ДЛЯ ГИБКИХ/АДАПТИВНЫХ СРЕД

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

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

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