авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 14 |

«РУКОВОДСТВО К СВОДУ ЗНАНИЙ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ РУКОВОДСТВО PMBOK® Четвертое издание Project Management Institute Руководство к своду знаний по ...»

-- [ Страница 4 ] --

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

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

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

• результаты адаптации, полученные от команды управления проектом, а именно:

процессы управления проектом, выбранные командой управления проектом;

уровень реализации каждого выбранного процесса;

описания инструментов и методов, которые будут использованы для выполнения данных процессов;

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

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

• план управления изменениями, документирующий порядок мониторинга и контроля изменений;

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та • лан управления конфигурацией, документирующий порядок управления конфигурацией;

п • орядок поддержания целостности базовых планов исполнения;

п • отребности в коммуникации между заинтересованными сторонами проекта и методы ее п реализации;

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

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

Базовые планы проекта включают в себя, среди прочего:

• базовое расписание;

• базовый план выполнения стоимости;

• базовый план по содержанию.

Вспомогательные планы включают в себя, среди прочего:

• план управления содержанием (введение к главе 5);

• план управления требованиями (раздел 5.1.3.2);

• план управления расписанием (введение к главе 6);

• план управления стоимостью (введение к главе 7);

• план управления качеством (раздел 8.1.3.1);

• план усовершенствования процессов (раздел 8.1.3.4);

• план управления человеческими ресурсами (раздел 9.1.3.1);

• план управления коммуникациями (раздел 10.2.3.1);

• план управления рисками (раздел 11.1.3.1);

• план управления закупками (раздел 12.1.3.1).

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та 4.3 Руководство и управление исполнением проекта Руководство и управление исполнением проекта – это процесс исполнения работ, определенных в плане управления проектом, для достижения целей проекта. Данные действия включают в себя, среди прочего:

• существление действий для выполнения требований проекта;

о • оздание результатов проекта;

с • одбор, подготовка и управление членами команды, назначенными на проект;

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

• рименение запланированных методов и стандартов;

п • алаживание и управление каналами коммуникаций проекта, как внешними, так и внутренними по н отношению к команде проекта;

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

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

• правление рисками и выполнение действий по реагированию на риски;

у • правление продавцами и поставщиками;

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

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

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

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

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

• исправление дефекта. Формально документированное выявление дефекта в элементе проекта, содержащее рекомендации либо об исправлении дефекта, либо о полной замене элемента.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та На рис. 4-6 показаны входы, инструменты и методы, а также выходы для данного процесса, а на рис. 4- представлена блок-схема данных.

Входы Инструменты и методы Выходы.1 План управления проектом.1 Экспертные оценки.1 Результаты.2 Одобренные запросы на.2 Информационная система.2 Информация об изменение управления проектами исполнении работ.3 Ф акторы среды.3 Запросы на изменение предприятия.4.4 Обновления плана Активы процессов управления проектом организации.5 Обновления документов проекта Рис. 4-6. Руководство и управление исполнением проекта: входы, инструменты, методы и выходы Управление интеграцией проекта 4. 4. Осуществление Разработка плана общего управления управления проектом изменениями • Одобренные запросы на изменение Предприятие / • Обновления Документы организация плана управления проекта • Запросы на проектом изменение • Активы процессов • План управления организации проектом 4. • Факторы среды Руководство и 8. предприятия управление • Обновления документов Контроль исполнением проекта качества проекта • Результаты • Информация об исполнении работ 10. Подготовка отчетов об исполнении 11. Мониторинг и управление рисками 12. 5.5 6.6 7.3 8.2 Управление Управление Управление Управление Обеспечение закупочной содержанием расписанием стоимостью качества деятельностью Рис. 4-7. блок-схема данных при руководстве и управлении исполнением проекта ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та 4.3.1 Руководство и управление исполнением проекта: входы.1 план управления проектом Описан в разделе 4.2.3.1.

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

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

• культуру и структуру организации, компании или заказчика;

• инфраструктуру (например, существующие сооружения и капитальное оборудование);

• управление персоналом (например, директивы по найму и увольнению, оценки эффективности работы сотрудников и документы об обучении);

• готовность заинтересованных сторон проекта принимать риски;

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та.4 активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс руководства и управления исполнением проекта, включают в себя, среди прочего:

• типовые руководящие указания и рабочие инструкции;

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

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

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

• архивы по предыдущим проектам (например, базовые планы по содержанию, стоимости, расписанию и измерению исполнения, календари проектов, сетевые диаграммы проекта, реестры рисков, запланированные ответные действия и определенные последствия рисков);

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

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

• другие подразделения в рамках организации;

• консультанты;

• заинтересованные стороны проекта, в том числе заказчики или спонсоры;

• профессиональные и технические ассоциации.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та.2 информационная система управления проектами Информационная система управления проектами, будучи одним из факторов среды предприятия, предоставляет доступ к автоматизированным средствам, таким как программное обеспечение для управления расписанием, система управления конфигурацией, система сбора и распространения информации или веб-интерфейсы прочих автоматизированных систем, работающих в режиме онлайн, используемых во время работ по руководству и управлению исполнением проекта.

4.3.3 Руководство и управление исполнением проекта: выходы.1 Результаты Одобренный результат – это любой уникальный и поддающийся проверке продукт, результат или способность осуществить услугу, который (ая) должен (на) быть произведен (на) для завершения процесса, фазы или проекта.

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

• статус результата;

• ход выполнения расписания;

• понесенные затраты.

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

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

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

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та • исправление дефекта. Формально документированное выявление дефекта в элементе проекта, содержащее рекомендации либо об исправлении дефекта, либо о полной замене элемента.

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

.4 обновления плана управления проектом Элементы плана управления проектом, которые могут быть обновлены, включают в себя, среди прочего:

• план управления требованиями;

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

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

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

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

• план управления коммуникациями;

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

• план управления закупками;

• базовые планы проекта.

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

• документацию по требованиям;

• журналы проекта (проблем, предположений и т. д.);

• реестр рисков;

• Реестр заинтересованных сторон проекта.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та 4.4 мониторинг и управление работами проекта Мониторинг и управление работами проекта – это процесс отслеживания, проверки и регулирования исполнения для достижения целей исполнения, определенных в плане управления проектом. Мониторинг – это аспект управления проектом, осуществляемый на протяжении всего проекта. Мониторинг включает в себя сбор, измерение и распространение информации об исполнении, а также оценку измерений и тенденций для оказания влияния на улучшение процесса. Постоянный мониторинг дает команде управления проектом возможность понимать общее состояние проекта и определять, на какие области следует обратить особое внимание. Управление включает в себя определение корректирующих или предупреждающих действий, либо повторное планирование и отслеживание планов с целью определить, удалось ли решить проблему с помощью предпринятых действий. Процесс мониторинга и управления работами проекта направлен на следующее:

• равнение фактического исполнения проекта с планом управления проектом;

с • ценка исполнения, чтобы определить, требуются ли какие-либо корректирующие или о предупреждающие действия, с последующей рекомендацией данных действий, при необходимости;

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

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

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

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

• ониторинг реализации одобренных изменений по мере их появления.

м На рис. 4-8 показаны входы, инструменты и методы, а также выходы для данного процесса, а на рис. 4- представлена блок-схема данных.

Входы Инструменты и методы Выходы.1 План управления проектом..1 Экспертные оценки.1 Запросы на изменение 2 Отчеты об исполнении.2 Обновления плана.3 Факторы среды предприятия управления проектом.4 Активы процессов.3 Обновления документов организации проекта Рис. 4-8. мониторинг и управление работами проекта: входы, инструменты, методы и выходы ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та Управление интеграцией проекта 4. Разработка плана управления проектом 10.5 • Обновления плана Документы Подготовка отчетов управления проектом проекта об исполнении • План управления проектом • Обновления документов 4.4 проекта • Отчеты об исполнении Мониторинг и управление работами проекта • Запросы на изменение • Активы процессов организации 4. • Факторы среды предприятия Осуществление общего управления Предприятие / изменениями организация Рис. 4-9. блок-схема данных при мониторинге и управлении работами проекта 4.4.1 мониторинг и управление работами проекта: входы.1 план управления проектом Описан в разделе 4.2.3.1.

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

• текущий статус;

• существенные достижения за указанный период времени;

• внесенные в расписание операции;

• прогнозы;

• проблемы.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та.3 Факторы среды предприятия Факторы среды предприятия, которые могут оказывать влияние на процесс мониторинга и управления работами проекта, включают в себя, среди прочего:

• государственные и промышленные стандарты (например, предписания контролирующих органов, стандарты на продукцию, стандарты качества и стандарты изготовления);

• корпоративную систему санкционирования выполнения работ;

• готовность заинтересованных сторон проекта принимать риски;

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

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

• требования организации к обмену информацией;

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

• процедуры разрешения проблем и устранения дефектов;

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

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

• базу накопленных знаний.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та 4.4.2 мониторинг и управление работами проекта: инструменты и методы.1 Экспертные оценки Экспертные оценки используются командой управления проекта для интерпретации информации, получаемой в результате процессов мониторинга и управления. Менеджер проекта совместно с командой определяет действия, необходимые для обеспечения того, чтобы исполнение проекта соответствовало ожиданиям.

4.4.3 мониторинг и управление работами проекта: выходы.1 запросы на изменение В результате сравнения запланированных результатов с фактическими могут выпускаться запросы на изменение, которые могут расширить, скорректировать или сократить проект или содержание продукта.

Изменения могут оказывать влияние на план управления проектом, документы или результаты проекта.

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

• корректирующее воздействие. Документированное указание для исполнения работ по проекту для приведения ожидаемого будущего исполнения работ по проекту в соответствие с планом управления проектом.

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

• исправление дефекта. Формально документированное выявление дефекта в элементе проекта, содержащее рекомендации либо об исправлении дефекта, либо о полной замене элемента.

.2 обновления плана управления проектом Элементы плана управления проектом, которые могут быть обновлены, включают в себя, среди прочего:

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

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

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

• базовый план по содержанию;

• базовое расписание;

• базовый план выполнения стоимости.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та.3 обновления документов проекта Документы проекта, которые могут быть обновлены, включают в себя, среди прочего:

• прогнозы;

• отчеты об исполнении;

• журнал проблем.

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

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

• казание влияния на факторы, которые могут «обойти» общее управление изменениями, с тем, чтобы о приводились в исполнение только одобренные изменения;

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

• правление одобренными изменениями;

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

• нализ, одобрение или отклонение всех рекомендованных корректирующих и предупреждающих а действий;

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

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

д ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та Запрос на изменение может подать любая заинтересованная сторона, вовлеченная в проект. Хотя изменения могут быть инициированы устно, они обязательно должны быть зарегистрированы в письменной форме и переданы в систему управления изменениями и/или управления конфигурацией. Запросы на изменения подвержены процессам, указанным в системах управления изменениями и управления конфигурацией. Эти процессы, связанные с запросами на изменение, могут требовать информацию об ожидаемом воздействии на сроки и на стоимость.

Каждый задокументированный запрос на изменение либо одобряется, либо отклоняется каким-либо уполномоченным лицом из команды управления проектом или сторонней организации. Во многих проектах менеджер проекта наделен полномочиями одобрять определенные виды запросов на изменение, что указано в документах о ролях и обязанностях в рамках проекта. При необходимости процесс осуществления общего управления изменениями включает в себя совет по управлению изменениями (change control board, CCB), отвечающий за одобрение или отклонение запросов на изменение. Роли и обязанности таких советов четко определяются в рамках процедур управления конфигурацией и управления изменениями и согласуются с соответствующими заинтересованными сторонами проекта. Многие крупные организации разрабатывают многоуровневые структуры, разделяющие обязанности между советами. Если проект реализуется по контракту, то некоторые предложенные изменения могут требовать одобрения заказчиком, что указывается в контракте.

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

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

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

• предоставляет возможности для постоянного подтверждения и улучшения проекта путем рассмотрения воздействий каждого изменения;

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та Ниже приведены некоторые действия по управлению конфигурацией, входящие в процесс осуществления общего управления изменениями:

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

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

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

На рис. 4-10 показаны входы, инструменты и методы, а также выходы для данного процесса, а на рис. 4- представлена блок-схема данных.

Входы Инструменты и методы Выходы.1 План управления проектом.1 Экспертные оценки.1 Обновления статусов.2 Информация об исполнении.2 Собрания по управлению запросов на изменение работ изменениями.2 Обновления плана.3 Запросы на изменение управления проектом.4 Ф акторы среды.3 Обновления документов предприятия.5 проекта Активы процессов организации Рис. 4-10. осуществление общего управления изменениями: входы, инструменты, методы и выходы ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та 5. Подтверждение содержания 5. Управление содержанием 6. Управление расписанием 7. Управление Управление интеграцией проекта стоимостью 8. 4.4 4. Обеспечение Мониторинг и Разработка плана качества управление управления работами проекта проектом 8.3 • План управления Контроль качества проектом Документы проекта • Обновления плана управления проектом 9. Управление • Запросы на изменение 4. командой проекта Осуществление общего • Обновления документов управления 10.4 проекта изменениями Управление ожиданиями 8. заинтересованных • Информация об Контроль качества • Обновления статусов сторон проекта исполнении работ запросов на изменение 10. Подготовка отчетов 4. исполнении 12. Руководство и Управление управление закупочной проектом 11.6 деятельностью Мониторинг и управление рисками 12. Планирование закупок 12. Осуществление закупок 12. Управление закупочной деятельностью • Активы процессов организации • Факторы среды предприятия Предприятие / организация Рис. 4-11. блок-схема данных в процессе осуществления общего управления изменениями ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 у пРав л ение интеГ РаЦи ей пР оек та 4.5.1 осуществление общего управления изменениями: входы.1 план управления проектом Описан в разделе 4.2.3.1.

.2 информация о выполненных работах Описана в разделе 4.3.3.2.

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

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

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

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

• процедуры одобрения и выдачи разрешений на внесение изменений;

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та • архивы проекта (например, базовые планы по содержанию, стоимости, расписанию и измерению исполнения, календари проекта, сетевые диаграммы проекта, реестры рисков, запланированные ответные действия и определенные последствия рисков);

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

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

• консультанты;

• заинтересованные стороны проекта, в том числе заказчики или спонсоры;

• профессиональные и технические ассоциации;

• отраслевые объединения;

• эксперты по отдельным вопросам;

• офис управления проектами (Project management office, PMO).

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

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 упРав л ение интеГ РаЦией пР оек та.1 обновления статусов запросов на изменение Запросы на изменение обрабатываются менеджером проекта или назначенным членом команды в соответствии с системой управления изменениями. Одобренные запросы на изменение реализуются процессом Руководства и управления исполнением проекта. Статус всех изменений, как одобренных, так и не одобренных, обновляется в журнале запросов на изменение как часть обновлений документов проекта.

.2 обновления плана управления проектом Элементы плана управления проектом, которые могут быть обновлены, включают в себя, среди прочего:

• любые вспомогательные планы управления;

• базовые планы, подверженные процессу формального управления изменениями.

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

Исполнение в прошлом не может быть изменено. Это защищает целостность базовых планов и исторические сведения об исполнении в прошлом.

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

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та Это включает в себя все действия, необходимые для административного завершения проекта или фазы, включая пошаговые методики, направленные на:

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

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

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

На рис. 4-12 показаны входы, инструменты и методы, а также выходы для данного процесса, а на рис. 4- представлена блок-схема данных.

Входы Инструменты и методы Выходы.1 План управления проектом.1 Экспертные оценки.1 Передача конечного.2 Принятые результаты продукта, услуги или.3 Активы процессов результата организации.2 Обновления активов процессов организации Рис. 4-12. завершение проекта или фазы: входы, инструменты, методы и выходы Управление интеграцией проекта 5. Подтверждение содержания 4. Разработка плана управления • План управления проектом • Принятые результаты проектом 4. Завершение • Активы процессов Заказчик организации проекта • Передача конечного или фазы продукта, услуги или результата • Обновления активов Организация процессов организации Рис. 4-13. блок-схема данных при завершении проекта или фазы ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 4 упРав л ение интеГ РаЦи ей пР оек та 4.6.1 завершение проекта или фазы: входы.1 план управления проектом Описан в разделе 4.2.3.1.

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

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

• руководящие указания или требования к закрытию проекта или фазы (например, проверки проекта, оценки проекта и критерии передачи);

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

4.6.2 завершение проекта или фазы: инструменты и методы.1 Экспертные оценки Экспертные оценки применяются при проведении действий по административному закрытию. Эти эксперты подтверждают, что закрытие проекта или фазы производится в соответствии с необходимыми стандартами.

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 4 Гла ва 4 упРа в ление интеГРа Цией пР оек та.2 обновления активов процессов организации Активы процессов организации, которые обновляются в результате процесса завершения проекта или фазы, включают в себя, среди прочего:

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

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

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Глава упРавление содеРжанием пРоекта Управление содержанием проекта включает в себя процессы, обеспечивающие включение в проект тех и только тех работ, которые необходимы для успешного завершения проекта. Управление содержанием проекта непосредственно связано с определением и контролем того, что включено и что не включено в проект. На рис. 5- представлена общая схема процессов управления содержанием проекта, которые включают в себя следующее:

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

5.2 определение содержания – процесс разработки подробного описания проекта и продукта.

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

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

5.5 управление содержанием – процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию.

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

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

• содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат;

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

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

Одобренное подробное описание содержания проекта вместе с ИСР и словарем ИСР представляют собой базовый план проекта по содержанию. Далее содержание, оформленное в базовом плане, отслеживается, подтверждается и контролируется на всем протяжении жизненного цикла проекта.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та Работе, связанной с осуществлением пяти процессов управления содержанием проекта, предшествуют действия команды управления проектом по планированию, хотя они и не представлены здесь в виде дискретного процесса. Работы по планированию являются частью процесса разработки плана управления проектом (раздел 4.2), в результате которого создается план управления содержанием, предоставляющий указания относительно того, как содержание проекта будет определяться, документироваться, подтверждаться, управляться и контролироваться. План управления содержанием может быть формальным и неформальным, детализированным, или задавать лишь общие рамки в зависимости от потребностей проекта.

Управление содержанием проекта 5.2 Определение 5.3 Создание ИСР 5.1 Сбор требований содержания.1 Входы.1 Входы.1 Входы.1 Устав проекта.1 Устав проекта.1 Описание содержания проекта.2 Реестр заинтересованных.2 Документация по требованиям.2 Документация по требованиям сторон проекта.3 Активы процессов организации.3 Активы процессов организации.2 Инструменты и методы.2 Инструменты и методы.2 Инструменты и методы.1 Интервью.1 Экспертная оценка.1 Декомпозиция.2 Целевые группы.2 Анализ продукта.3 Выходы.3 Семинары с участием координатора.3 Поиск альтернатив.1 ИСР.4 Групповые творческие методы.4 Семинары с участием.2 Словарь ИСР.5 Методы группового принятия координатора.3 Базовый план по содержанию решения.4 Обновления документов проекта.6 Анкеты и опросы.3 Выходы.7 Наблюдения.1 Описание содержания проекта.8 Прототипы.2 Обновления документов проекта.3 Выходы 5.5 Управление.1 Документация по требованиям содержанием.2 План управления требованиями.3 Матрица отслеживания требований.1 Входы.1 План управления проектом 5.4 Подтверждение.2 Информация об исполнении работ содержания.3 Документация по требованиям.4 Матрица отслеживания требований.1 Входы.5 Активы процессов организации.1 План управления проектом.2 Документация по требованиям.2 Инструменты и методы.3 Матрица отслеживания.1 Анализ отклонений требований.4 Подтвержденные результаты.3 Выходы.1 Результаты измерения.2 Инструменты и методы исполнения работ.1 Инспекция.2 Обновления активов процессов.3 Выходы организации.1 Принятые результаты.3 Запросы на изменение.2 Запросы на изменение.4 Обновления плана управления.3 Обновления документов проекта проектом.5 Обновления документов проекта Рис. 5-1. управление содержанием проекта: входы, инструменты и методы, выходы ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 у пРав л ение сод еРж ани ем пР оек та Выполнение содержания проекта измеряется относительно плана управления проектом (раздел 4.2.3.1).

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

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

Планирование стоимости, расписания и качества строится на основе этих требований. Разработка требований начинается с анализа информации, содержащейся в Уставе проекта (раздел 4.1.3.1) и в Реестре заинтересованных сторон проекта (раздел 10.1.3.1).


Многие организации разделяют требования на категории «требования к проекту» и «требования к продукту».

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

На рис. 5-2 показаны входы, инструменты и методы и выходы процесса сбора требований, а на рис. 5- представлена общая схема основных связей и взаимодействий в рамках данного процесса.

Входы Инструменты и методы Выходы.1 Устав проекта.1 Интервью.1 Документация по.2 Реестр заинтересованных.2 Целевые группы требованиям сторон проекта.3 Семинары с участием.2 План управления координатора требованиями.4 Групповые творческие.3 Матрица отслеживания методы требований.5 Методы группового принятия решений.6 Анкеты и опросы.7 Наблюдения.8 Прототипы Рис. 5-2. сбор требований: входы, инструменты и методы, выходы ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та Управление содержанием проекта 4. • Документация по 4.1 требованиям Разработка плана Разработка управления Устава проекта • План управления проектом требованиями • Устав проекта 5.1 • Документация по требованиям 12. Сбор Планирование требований • Реестр закупок • Матрица заинтересованных отслеживания сторон проекта требований • Документация по требованиям 10. Определение заинтересованных сторон проекта 5.2 5. Определение Подтверждение содержания содержания 5. 5. Управление Создание ИСР содержанием Рис. 5-3. блок-схема данных при сборе требований 5.1.1 сбор требований: входы.1 устав проекта Устав проекта используется для предоставления требований к проекту высокого уровня и описания продукта высокого уровня, позволяющих разработать подробные требования к продукту. Устав проекта описан в разделе 4.1.

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

Реестр заинтересованных сторон проекта описан в разделе 10.1.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 упРав л ение сод еРж ани ем пР оек та 5.1.2 сбор требований: инструменты и методы.1 интервью Интервью представляют собой формальный или неформальный способ получения информации от заинтересованных сторон проекта путем непосредственного общения с ними. Обычно в ходе интервью задают подготовленные и неподготовленные вопросы и записывают ответы. Интервью часто проводятся «один на один», но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых.

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

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

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

Например, в области разработки программного обеспечения используются семинары с участием модератора под названием «Совместная разработка (или проектирование) приложений» (Joint Application Development (or Design), JAD). Такие собрания с участием модератора направлены на предоставление пользователям возможности встретиться с командой разработчиков для улучшения процесса разработки программного продукта. В производственных отраслях существует «Развертывание функции качества»

(Quality Function Deployment, QFD) – это еще один пример семинара с участием модератора, который помогает определить критически важные характеристики для продвижения нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (Voice of the Customer, VOC). Затем эти потребности объективно сортируются, и между ними расставляются приоритеты, а также устанавливаются цели для их достижения.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та.4 Групповые творческие методы Для выявления требований к проекту и продукту могут организовываться различные групповые мероприятия. Ниже представлено несколько групповых творческих методов:

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

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

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

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

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

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

Существует множество методов принятия группового решения, например:

• единогласие. Все соглашаются с определенным направлением действий.

• большинство голосов. Поддержка со стороны более 50 % членов группы.

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

• диктатура. Один человек принимает решение за всю группу.

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 упРав л ение сод еРж ани ем пР оек та.6 анкеты и опросы Анкеты и опросы представляют собой наборы вопросов в письменной форме, предназначенные для быстрого получения информации от большого числа респондентов. Опросы и/или анкеты лучше всего подходят для работы с широкими аудиториями, когда требуется быстрый сбор информации, и где допускается применение статистического анализа.

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

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

.8 прототипы Создание прототипов представляет собой метод раннего получения обратной связи по требованиям путем создания рабочей модели ожидаемого продукта до его фактического производства.

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

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


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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та Элементы документов по требованиям могут включать в себя, среди прочего:

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

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

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

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

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

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

• бизнес-правила, описывающие руководящие принципы организации;

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

• влияние на другие органы внутри и за пределами исполняющей организации;

• требования к технической поддержке и обучению;

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

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

• орядок планирования, отслеживания и составления отчетов о действиях в отношении п требований;

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 упРав л ение сод еРж ани ем пР оек та • процесс расстановки приоритетов требований;

• используемые показатели продукта и обоснование их использования;

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

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

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

• требования к бизнес-потребностям, возможностям, задачам и целям;

• требования к целям проекта;

• требования к содержанию проекта / результатам ИСР;

• требования к проектированию продукта;

• требования к разработке продукта;

• требования к стратегии и сценариям проверки;

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

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

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

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та 5.2 определение содержания Определение содержания – процесс разработки подробного описания проекта и продукта. Подготовка подробного описания содержания проекта чрезвычайно важна для успеха проекта и основывается на основных результатах, допущениях и ограничениях, задокументированных во время инициации проекта. Содержание проекта определяется во время планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты;

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

Входы Инструменты и методы Выходы.1 Устав проекта.1 Экспертная оценка.1 Описание содержания проекта.2 Документация по.2 Анализ продукта.2 Обновления документов требованиям.3 Поиск альтернатив проекта.3 Активы процессов.4 Семинары с участием организации модератора Рис. 5-4. определение содержания: входы, инструменты и методы, выходы ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 у пРав л ение сод еРж ани ем пР оек та 5.2.1 определение содержания: входы.1 устав проекта Устав проекта предоставляет описание проекта высокого уровня и характеристики продукта.

Кроме того, он содержит требования к одобрению проекта. Устав проекта описан в разделе 4.1.3.1.

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

.2 документы по требованиям Описаны в разделе 5.1.3.1.

Управление содержанием проекта 5. Сбор требований 4. Документы Разработка проекта • Документация Устава проекта по требованиям • Обновления документов проекта • Устав проекта 4. 5.2 Разработка Определение • Описание содержания плана содержания проекта управления проектом • Активы процессов организации 6. Определение 5. Предприятие/ последовательности Создание ИСР организация операций 6. Оценка длительности операций 6. Разработка расписания 11. 11.3 Планирование Качественный управления анализ рисков рисками Рис. 5-5. блок-схема данных при определении содержания ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та.3 активы процессов организации Примеры активов процессов организации, которые могут оказывать влияние на процесс определения содержания, включают в себя, среди прочего:

• правила, процедуры и шаблоны описания содержания проекта;

• проектные архивы из предыдущих проектов;

• знания, накопленные в предыдущих фазах или проектах.

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

• другие подразделения в рамках организации;

• консультанты;

• заинтересованные стороны проекта, в том числе заказчики или спонсоры;

• профессиональные и технические ассоциации;

• промышленные группы;

• эксперты по отдельным вопросам.

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

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 упРав л ение сод еРж ани ем пР оек та.4 семинары с участием модератора Описаны в разделе 5.1.2.3.

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

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

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

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

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

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

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

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та • допущения проекта. Перечисляются и описываются конкретные допущения проекта, связанные с содержанием проекта, и потенциальное влияние данных допущений в случае, если они окажутся ошибочными. Команды проектов часто выявляют, документируют и подтверждают допущения в рамках проводимого ими процесса планирования. Информация о допущениях может быть указана в описании содержания проекта или в отдельном журнале.

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

• Реестр заинтересованных сторон проекта;

• документы по требованиям;

• матрицу отслеживания требований.

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

на каждом более низком уровне ИСР представляет все более детальное описание работ по проекту. ИСР организует и определяет общее содержание проекта и представляет работы, указанные в текущем одобренном описании содержания проекта (см. рис. 5-6 и 5-7).

Запланированные работы содержатся в элементах ИСР самого нижнего уровня, которые называются «пакетами работ». Для пакетов работ могут составляться расписания, оцениваться стоимость, может проводиться их мониторинг и управление. В контексте ИСР «работа» означает продукты или результаты работ, являющиеся результатами действий, но не сами действия. В таблице 5-4 показаны входы, инструменты и методы, выходы процесса создания ИСР, а на рис. 5-3 представлена общая схема основных связей и взаимодействий в рамках данного процесса.

Для получения дополнительной информации по иерархическим структурам работ обратитесь к документу the Practice Standard for Work Breakdown Structures – Second Edition [1]1.

Входы Инструменты и методы Выходы.1 Описание содержания.1 Декомпозиция.1 ИСР проекта.2 С ловарь ИСР.2 Документация по.3 Базовый план по содержанию требованиям.4 Обновления документов.3 Активы процессов проекта организации Рис. 5-6. создание исР: входы, инструменты и методы, выходы Полужирные цифры в квадратных скобках обозначают ссылки на список литературы в конце данного стандарта.

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 у пРав л ение сод еРж ани ем пР оек та Документы Управление содержанием проекта проекта 5.1 5. Сбор Определение требований содержания 4. Разработка плана управления проектом • Документация по • Описание требованиям содержания проекта Предприятие/ 6. организация • Обновления Определение документов проекта операций 5. Создание ИСР • Активы процессов • Базовый план по 7. организации содержанию Оценка стоимости 7. Определение бюджета 8. Планирование качества 11. Идентификация рисков 12. Планирование закупок Рис. 5-7. блок-схема данных при создании исР 5.3.1 создание исР: входы.1 описание содержания проекта Описано в разделе 5.2.3.1.

.2 документы по требованиям Описаны в разделе 5.1.3.1.

.3 активы процессов организации ©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание 5 Гла ва 5 упРа в ление содеРж а нием пР оек та Активы процессов организации, которые могут оказывать влияние на процесс создания ИСР, включают в себя, среди прочего:

• правила, процедуры и шаблоны для ИСР;

• проектные архивы из предыдущих проектов;

• знания, накопленные в предыдущих проектах.

5.3.2 создание исР: инструменты и методы.1 декомпозиция Декомпозиция – это разделение результатов проекта на более мелкие и легко управляемые элементы;

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

Декомпозиция всей совокупности работ по проекту до пакетов работ обычно включает в себя следующие действия:

• определение и анализ результатов и соответствующих работ;

• структурирование и организация ИСР;

• разбиение верхних уровней ИСР на детализированные элементы более низких уровней;

• разработку и присвоение идентификационных кодов элементам ИСР;

• проверку необходимости и достаточности степени декомпозиции.

На рис. 5-8 показана часть ИСР с некоторыми ответвлениями ИСР, декомпозированными до уровня пакетов работ.

Структура ИСР может быть создана в различных формах, например:

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

• в качестве первого уровня декомпозиции используются основные результаты, как показано на рис. 5-10;

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

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание Гл а в а 5 у пРав л ение сод еРж ани ем пР оек та Проект Фаза 1 Фаза 2 Результат 3 Подпроект 4 Подпроект n Результат 2.1 Результат 2.2 Результат 2.3 Результат 4.1 Результат 4.m Результат 2.2.1 Результат 2.2.2 Результат 4.1.1 Результат 4.1.2 Результат 4.1.x Пакет работ Пакет работ 2.2.2.1 Пакет работ Пакет работ 2.2.1. 3.1 4.1.2. Подпроект 2.2.2. Пакет работ Пакет работ Пакет работ 3.2 4.1.2. 2.2.1. Пакет работ Пакет работ Пакет работ 3.3 4.1.2. Пакет работ 2.2.2.2. 2.2.1. Пакет работ Пакет работ 3. 2.2.2.2. Рис. 5-8. образец иерархической структуры работ с некоторыми ответвлениями, декомпозированными до уровня пакетов работ Выпуск программного продукта 5. Управление Требования Рабочий Интеграция Конструирование проектом к продукту проект и тестирование Программное Программное Программное Программное Планирование обеспечение обеспечение обеспечение обеспечение Документация Документация Документация Документация Собрания пользователя пользователя пользователя пользователя Материалы Материалы Материалы Материалы Администрирование программ обучения программ обучения программ обучения программ обучения Данная ИСР носит исключительно пояснительный характер. Она не предназначена для представления полного содержания какого-либо конкретного проекта и не подразумевает, что это единственно возможный способ организации ИСР для данного типа проекта.



Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 14 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.