WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 || 3 | 4 |   ...   | 8 |

«Руководство к Своду знаний по управлению проектами Третье издание (Руководство PMBOK®) Американский национальный стандарт ANSI/PMI 99-001-2004 ISBN: 1-930699-77-8 (обложка - издание на русском ...»

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

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

Группа процессов инициации (рис. 3-6) служит началом проекта (фазы проекта), а выход определяет цели и ставит задачи проекта, а также служит менеджеру проекта авторизацией для начала проекта.

Рисунок 3-6. Группа процессов инициации Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 44 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США В группу процессов инициации входят следующие процессы управления проектами:

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

Таблица 3-1. Разработка Устава проекта: входы и выходы.2 Разработка предварительного описания содержания проекта Это процесс, необходимый для предварительного общего описания проекта с использованием Устава проекта и других входов процессов инициации. Этот процесс направляет и документирует требования к проекту и результатам поставки, требования к продукту, границы проекта, методы приемки и общее управление содержанием. В многофазных проектах этот процесс оценивает или уточняет содержание проекта для каждой фазы.

Таблица 3-2. Разработка предварительного содержания проекта: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом 3.2.2 Группа процессов планирования Команда управления проектом использует группу процессов планирования и составляющие ее процессы и взаимодействия для планирования и управления успешным проектом в интересах организации. Цель группы процессов планирования – собрать информацию из нескольких источников, различных по уровню полноты и доверия. Процессы планирования разрабатывают план управления проектом. Эти процессы также обнаруживают, определяют и дорабатывают содержание и стоимость проекта и составляют расписание для операций проекта, которые будут предприняты в рамках проекта. По мере того как появляется новая информация по проекту, будут выявляться или исчезать дополнительные зависимости, требования, риски, возможности, допущения и ограничения. Из-за присущей управлению проектами многомерности в ходе проекта неоднократно возникает необходимость в дополнительном анализе, а значит и в возвращении к уже утвержденным процессам. По мере того как выявляются и осознаются новые характеристики и информация, касающиеся проекта, могут возникнуть необходимость в доработках. Значительные изменения, происходящие во время жизненного цикла проекта, приводят к необходимости пересмотреть один или несколько процессов планирования и, возможно, некоторые из процессов инициации.

Это затрагивает также и частоту итераций процессов планирования.

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

Обновления плана управления проектом обеспечивают большую точность по отношению требований к расписанию, затратам и ресурсам для достижения заданного содержания проекта в целом. Обновления могут ограничиваться операциями и проблемами, связанными с выполнением отдельной фазы. Такую постепенную детализацию плана управления проектом часто называют "планированием методом набегающей волны", подчеркивая этим, что планирование в этом случае представляет собой итеративный и непрерывный процесс (см. рис. 3-7).

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 46 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Примечание: На диаграмме показаны не все взаимодействия между процессами и не все потоки данных между процессами.

Рисунок 3-7. Группа процессов планирования Группа процессов планирования способствует планированию проекта путем нескольких процессов. В нижеприведенном списке указываются процессы, к которым команда проекта должна обратиться, чтобы решить нужно ли их выполнять, и если да, то кем. В группу процессов планирования входят следующие процессы управления проектами:

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом.1 Разработка плана управления проектом Это процесс, необходимый для определения, подготовки, координации и интеграции всех вспомогательных планов в план управления проектом. План управления проектом становится первичным источником информации по планированию, исполнению, мониторингу и управлению, а также закрытию проекта.

Таблица 3-3. Разработка плана управления проектом: входы и выходы.2 Планирование содержания Это процесс, необходимый для создания плана управления содержанием проекта, который описывает, как будет определяться, проверяться и управляться содержание проекта и как будет создана и определена иерархическая структура работ.

Таблица 3-4. Планирование содержания: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 48 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.3 Определение содержания Это процесс, необходимый для разработки подробного описания содержания проекта, на основании которого будут впоследствии приниматься решения по проекту.

Таблица 3-5. Определение содержания: входы и выходы.4 Создание иерархической структуры работ (ИСР) Это процесс, необходимый для разделения основных результатов поставки проекта и работ проекта на меньшие элементы, которыми легче управлять.

Таблица 3-6. Создание иерархической структуры работ (ИСР): входы и выходы.5 Определение состава операций Это процесс, необходимый для идентификации конкретных операций, которые следует выполнить для получения различных результатов поставки проекта.

Таблица 3-7. Определение состава операций: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом.6 Определение взаимосвязей операций Это процесс, необходимый для определения и документирования взаимосвязей между операциями.

Таблица 3-8. Определение взаимосвязей операций: входы и выходы.7 Оценка ресурсов операций Это процесс, необходимый для оценки типа и количества ресурсов, необходимых для выполнения каждой плановой операции.

Таблица 3-9. Оценка ресурсов операций: входы и выходы.8 Оценка длительности операций Это процесс, необходимый для оценки количества рабочих периодов, которые потребуются для завершения отдельных плановых операций.

Таблица 3-10. Оценка длительности операции: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 50 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.9 Разработка расписания Это процесс, необходимый для анализа последовательности операций, длительности операций, требований к ресурсам и ограничений на сроки с целью создания расписания проекта.

Таблица 3-11. Разработка расписания: входы и выходы.10 Стоимостная оценка Это процесс, необходимый для разработки приблизительных значений стоимости ресурсов, необходимых для выполнения операций проекта.

Таблица 3-12. Стоимостная оценка: входы и выходы.11 Разработка бюджета расходов Это процесс, необходимый для суммирования оценок стоимости отдельных операций или пакетов работ для оценки базового плана по стоимости.

Таблица 3-13. Разработка бюджета расходов: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом.12 Планирование качества Это процесс, необходимый для определения стандартов качества, которые соответствуют проекту, и средств достижения этих стандартов.

Таблица 3-14. Планирование качества: входы и выходы.13 Планирование человеческих ресурсов Это процесс, необходимый для определения и документирования ролей в проекте, ответственности и отчетности, а также создания плана управления обеспечением проекта персоналом.

Таблица 3-15. Планирование человеческих ресурсов: входы и выходы.14 Планирование коммуникаций Это процесс, необходимый для определения потребностей участников проекта в информации и коммуникациях.

Таблица 3-16. Планирование коммуникаций: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 52 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.15 Планирование управления рисками Это процесс, необходимый для определения подходов к планированию и выполнению операций по управлению рисками проекта.

Таблица 3-17. Планирование управления рисками: входы и выходы.16 Идентификация рисков Это процесс, необходимый для определения того, какие именно риски могут повлиять на проект, а также для документирования их характеристик.

Таблица 3-18. Идентификация рисков: входы и выходы.17 Качественный анализ рисков Это процесс, необходимый для установления приоритетов рисков с целью их дальнейшего анализа или действий путем оценки и совмещения их вероятности и воздействия.

Таблица 3-19. Качественный анализ рисков: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом.18 Количественный анализ рисков Это процесс, необходимый для количественного анализа воздействия определенного риска на общие цели проекта.

Таблица 3-20. Количественный анализ рисков: входы и выходы.19 Планирование реагирования на риски Это процесс, необходимый для разработки вариантов и операций для повышения возможностей и снижения угроз целям проекта.

Таблица 3-21. Планирование реагирования на риски: входы и выходы.20 Планирование покупок Это процесс, необходимый для определения, что, как и когда следует приобрести.

Таблица 3-22. Планирование покупок: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 54 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.21 Планирование контрактов Это процесс, необходимый для документирования требований к продуктам, услугам и результатам, а также для поиска потенциальных продавцов.

Таблица 3-23. Планирование контрактов: входы и выходы 3.2.3 Группа процессов исполнения Группа процессов исполнения состоит из процессов, используемых для осуществления работ, означенных в плане управления проектом для выполнения требований проекта. Команда проекта должна определить, какие из процессов нужны для конкретного проекта команды. Данная группа процессов включает в себя координацию людей и ресурсов, а также интеграцию и исполнение операций проекта в соответствии с планом управления проектом.

Кроме того, в ходе этой группы процессов идет работа с содержанием проекта, определенным в описании содержания проекта, и в него вносятся одобренные изменения (см. рис. 3-8).

Примечание: На диаграмме показаны не все взаимодействия между процессами и не все потоки данных между процессами.

Рисунок 3-8. Группа процессов исполнения Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом Обычно при исполнении имеют место отклонения, приводящие к корректировке планов. Эти отклонения могут затрагивать длительность операций, наличие и эффективность ресурсов, а также непредусмотренные риски. Независимо от того, повлияют такие отклонения на план управления проектом или нет, они могут потребовать анализа. Результаты этого анализа могут повлечь за собой запрос на изменение. Если этот запрос будет одобрен, то это может привести к изменению плана управления проектом и, возможно, утверждению нового базового плана. Подавляющая часть бюджета проекта пойдет на выполнение группы процессов исполнения. В группу процессов исполнения входят следующие процессы управления проектами:

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

Таблица 3-24. Руководство и управление исполнением проекта: входы и выходы.2 Процесс обеспечения качества Это процесс, необходимый для применения плановых систематических операций по проверке качества например аудит или независимая экспертиза, чтобы удостовериться, что в проекте используются все необходимые процессы для выполнения требований.

Таблица 3-25. Процесс обеспечения качества: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 56 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.3 Набор команды проекта Это процесс, необходимый для получения человеческих ресурсов, нужных для выполнения проекта.

Таблица 3-26. Набор команды проекта: входы и выходы.4 Развитие команды проекта Это процесс, необходимый для повышения компетенции и взаимодействия членов команды для улучшения исполнения проекта.

Таблица 3-27. Развитие команды проекта: входы и выходы.5 Распространение информации Это процесс, необходимый для обеспечения своевременного доступа участников проекта к нужной им информации.

Таблица 3-28. Распространение информации: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом.6 Запрос информации у продавцов Это процесс, необходимый для получения информации, расценок или предложений.

Таблица 3-29. Запрос информации у продавцов: входы и выходы.7 Выбор продавцов Это процесс, необходимый для изучения предложений, выбора из потенциальных продавцов и заключения письменного контракта с продавцом.

Таблица 3-30. Выбор продавцов: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 58 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 3.2.4 Группа процессов мониторинга и управления Группа процессов мониторинга и управления состоит из процессов, выполняемых для правильного исполнения проекта, так чтобы возможные проблемы были обнаружены вовремя и, в случае необходимости, могли быть предприняты корректирующие действия для управления исполнением проекта.

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом Примечание: На диаграмме показаны не все взаимодействия между процессами и не все потоки данных между процессами.

Рисунок 3-9. Группа процессов мониторинга и управления В группу процессов мониторинга и управления входят следующие процессы:

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 60 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 1 Мониторинг и управление работами проекта Это процесс, необходимый для сбора, измерения и распространения информации об исполнении проекта и оценки измерений и тенденций для влияния на улучшение процессов. Этот процесс включает в себя мониторинг рисков, что позволяет обеспечить выявление рисков на ранних стадиях, после чего составляется отчет об их состоянии и приводятся в исполнение соответствующие планы реагирования на риски. Мониторинг включает в себя отчеты о текущем состоянии, оценку прогресса и прогнозирование. Отчеты об исполнении предоставляют информацию об исполнении проекта по таким показателям, как содержание, расписание, стоимость, ресурсы, качество и риски.

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

Таблица 3-32. Общее управление изменениями: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом.3 Подтверждение содержания Это процесс, необходимый для формализации приемки завершенных результатов поставки проекта.

Таблица 3-33. Подтверждение содержания: входы и выходы.4 Управление содержанием Это процесс, необходимый для управления изменениями в содержании проекта.

Таблица 3-34. Управление содержанием: входы и выходы.5 Управление расписанием Это процесс, необходимый для управления изменениями в расписании проекта.

Таблица 3-35. Управление расписанием: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 62 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.6 Управление стоимостью Процесс влияния на факторы, создающие отклонения, и управление изменениями бюджета проекта.

Таблица 3-36. Управление стоимостью: входы и выходы.7 Процесс контроля качества Это процесс, необходимый для мониторинга определенных результатов проекта с целью определения их соответствия принятым стандартам качества и выработки путей устранения причин неудовлетворительного исполнения.

Таблица 3-37. Процесс контроля качества: входы и выходы.8 Управление командой проекта Это процесс, необходимый для отслеживания деятельности членов команды, обеспечения обратной связи, решения проблем и координации изменений с целью улучшения исполнения проекта.

Таблица 3-38. Управление командой проекта: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом.9 Отчетность по исполнению Это процесс, необходимый для сбора и распространения информации об исполнении. Эта информация включает в себя отчеты о текущем состоянии, оценку прогресса, а также прогнозирование.

Таблица 3-39. Отчетность по исполнению: входы и выходы.10 Управление участниками проекта Это процесс, необходимый для управления коммуникациями с целью удовлетворения требований участников проекта и решения вместе с ними возникающих проблем.

Таблица 3-40. Управление участниками проекта: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 64 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.11 Наблюдение и управление рисками Это процесс, необходимый для отслеживания выявленных рисков, мониторинга остаточных рисков, выявления новых рисков, выполнения планов реагирования на риски и оценки их эффективности в течение жизненного цикла проекта.

Таблица 3-41. Мониторинг и управление рисками: входы и выходы.12 Администрирование контрактов Это процесс, необходимый для управления контрактом и взаимоотношениями между продавцом и покупателем, для изучения и документирования действий продавца и, в соответствующих случаях, для управления контрактными отношениями с внешним покупателем проекта.

Таблица 3-42. Администрирование контрактов: входы и выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом 3.2.5 Группа завершающих процессов В группу завершающих процессов входят процессы, используемый для формального завершения всех операций проекта или фазы проекта, передачи завершенного продукта другим лицам или закрытия остановленного проекта.

Когда эта группа процессов выполнена, она подтверждает, что во всех группах процессов должным образом совершены определенные процессы для закрытия проекта или фазы проекта, и формально устанавливает, что проект или фаза проекта окончены. См. рис. 3-10.

Рисунок 3-10. Группа завершающих процессов Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 66 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США В группу завершающих процессов входят следующие процессы управления проектами:

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

Таблица 3-43. Закрытие проекта: входы и выходы.2 Закрытие контрактов Это процесс, необходимый для завершения и урегулирования каждого контракта, в том числе завершение действующих контрактов и закрытия каждого контракта, затрагивающего проект или фазу проекта.

Таблица 3-44. Закрытие контрактов: входы и выходы 3.3 Взаимодействия процессов Группы процессов управления проектом связаны целями, которые перед ними поставлены. Выход одного процесса обычно является входом для другого процесса или является результатом поставки проекта. Группа процессов планирования предоставляет группе процессов исполнения документированный план управления проектом и описание содержания проекта, а также часто вносит изменения в план управления проектом по ходу проекта. Необходимо также отметить, что группы процессов редко являются дискретными или однократными событиями;

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом Рисунок 3-11. Взаимодействие групп процессов в проекте Результаты процессов связаны с другими группами процессов и воздействуют на них. Например, для завершения фазы проектирования необходима приемка проекта заказчиком. После этого проектный документ определяет описание продукта для последующей группы процессов исполнения. Когда процесс разделяется на фазы, группы процессов обычно связаны с каждой фазой на протяжении существования проекта, чтобы способствовать успешному завершению проекта. Группы процессов и их отношения показаны на рис. 3-12.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 68 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Рисунок 3-12. Треугольник групп процессов управления проектом Однако не все процессы могут понадобиться в каждом конкретном выполняемом проекте или его фазе, и не все взаимодействия могут быть к ним применимы. Например:

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

• Некоторые входы процессов заранее определены как ограничения.

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

3.4 Графическое отображения процесса управления проектом На таблице 3-45 показано распределение 44 процессов управления проектами на пять групп процессов управления проектом и девять областей знаний по управлению проектами. Каждый из необходимых процессов управления проектами помещен в ту группу процессов, в которой проходит большая часть его операций. Например, когда процесс, обычно проводящийся во время планирования, пересматривается или обновляется во время исполнения, это все тот же процесс, который был выполнен при планировании, а не новый процесс.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 3 - Процессы управления проектом Таблица 3-45. Соответствие между процессами управления проектами и группами процессов управления проектом и областями знаний Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 70 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Часть III Области знаний по управлению проектами Часть III Введение Глава 4 Управление интеграцией проекта Глава 5 Управление содержанием проекта Глава 6 Управление сроками проекта Глава 7 Управление стоимостью проекта Глава 8 Управление качеством проекта Глава 9 Управление человеческими ресурсами проекта Глава 10 Управление коммуникациями проекта Глава 11 Управление рисками проекта Глава 12 Управление поставками проекта ЧАСТЬ III Введение Диаграммы зависимостей процессов Диаграмма зависимостей процессов приводится в каждой главе, посвященной отдельной области знаний (главы с 4 по 12). Диаграмма зависимостей процессов представляет собой общую схему входов процесса и выходов процесса, которые используются во всех процессах в данной области знаний. Хотя процессы представлены как дискретные элементы с четко определенными интерфейсами, но на практике они могут быть итеративными, накладываться друг на друга и взаимодействовать между собой;

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

Рисунок III-1. Обозначения на диаграммах зависимостей процессов Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Часть III - Введение Условные знаки, используемые в диаграммах зависимостей процессов, объяснены на рис. III-1. На них показывается три разных вида информации:

1. Процессы в данной области знаний, их взаимодействие с другими процессами из той же области знаний и их выходы для процессов интеграции (описаны в главе 4).

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

3. Активы организационного процесса и факторы внешней среды предприятия показываются как входы для первого процесса.

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 74 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Рисунок III-2. Три основных документа проекта и составляющие их элементы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Часть III - Введение Основные документы проекта В Руководстве PMBOK® описываются три основных документа, каждый из которых имеет определенное назначение:

• Устав проекта. Является официальной авторизацией проекта.

• Описание содержания проекта. Содержит описание работы, которую предстоит выполнить, и результатов поставки, которые надлежит произвести.

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

На рис. III-2 показаны эти три документа и входящие в их состав элементы.

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 76 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США ГЛАВА Управление интеграцией проекта Область знаний об управлении интеграцией проекта включает в себя процессы и операции, необходимые для выявления, определения, объединения, унификации и координации различных процессов и операций управления проектами в рамках групп процессов управления проектами. В контексте управления проектами интеграция включает в себя такие характеристики, как унификация, консолидация, артикуляция и интегративные действия, являющиеся ключевыми для завершения проекта, успешного удовлетворения требований заказчика и других участников проекта, а также управления ожиданиями. В контексте управления проектом интеграция – это принятие решений о том, где концентрировать ресурсы на каждую конкретную дату, предугадывание потенциальных проблем, и их решение до того, как эти проблемы станут критическими, и хорошая координация работы проекта в целом. Интеграция также подразумевает нахождение компромиссов между пересекающимися целями и альтернативами. Процессы управления проектами обычно представляются в виде дискретных элементов с хорошо разработанными интерфейсами, в то время как на практике они накладываются друг на друга и взаимодействуют между собой такими путями, которые не могут быть достаточно подробно описаны в Руководстве PMBOK®.

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта Интегративный характер проектов и управления проектами можно лучше понять, если представить себе другие операции, выполняемые при реализации проекта. Вот какими, к примеру, могут быть операции, выполняемые командой управления проектом:

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

• Задокументировать конкретные критерии требований к продукту.

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

• Создать иерархическую структуру работ.

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

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

• Анализировать риски проекта.

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

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

Цель интеграции – это прежде всего эффективное интегрирование процессов в группах процессов управления проектами, необходимых для достижения целей проекта в рамках определенных процедур, принятых в организации. На рис. 4-1 представлена общая схема интегративных процессов управления проектом. На рис. 4-2 показана диаграмма зависимостей процессов для этих процессов, их входы, выходы и другие релевантные процессы в области знаний. Интегративные процессы управления проектами включают в себя следующие элементы:

4.1 Разработка Устава проекта – разработка Устава проекта, формально авторизующего проект или фазу проекта.

4.2 Разработка предварительного описания содержания проекта – разработка предварительного описания содержания проекта, включающего в себя самое общее изложение содержания.

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

4.4 Руководство и управление исполнением проекта – выполнение работы, определенной в Плане управления проектом для выполнения требований, определенных в описании содержания проекта.

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 78 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 4.6 Общее управление изменениями – обработка всех запросов на изменения, утверждение этих изменений и управление ими для оптимизации результатов поставки и активов организационного процесса.

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

Рисунок 4-1. Общая схема управления интеграцией проекта Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта Примечание: Показаны не все взаимодействия процессов и не все потоки данных между процессами.

Рисунок 4-2. Диаграмма зависимостей процессов для управления интеграцией проекта Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 80 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 4.1 Разработка Устава проекта Устав проекта является документом, формально авторизующим проект. Устав проекта наделяет менеджера проекта полномочиями задействовать ресурсы организации на операциях проекта. Менеджер проекта определяется и назначается как можно раньше. Менеджера проекта необходимо всегда назначать до начала планирования и желательно на этапе разработки Устава проекта.

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

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

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

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

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

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта • Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта • Производственная необходимость, самое общее описание проекта или требования к продукту, который является предметом проекта • Цель или обоснование проекта • Информацию о назначенном менеджере проекта и уровне его полномочий • Расписание контрольных событий • Отношения между участниками проекта • Функциональные организации и их участие • Допущения относительно организации и окружения, а также внешние допущения • Ограничения относительно организации и окружения, а также внешние ограничения • Реальная бизнес-ситуация, служащая обоснованием проекта с данными о прибыли на инвестиции • Бюджет проекта.

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

Рисунок 4-3. Разработка Устава проекта: входы, инструменты и методы, выходы 4.1.1 Разработка Устава проекта: входы.1 Контракт (если применимо) Входом является контракт приобретающей организации заказчика, если проект выполняется для стороннего заказчика.

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 82 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США • Производственная необходимость – практическая необходимость организации может основываться на необходимости обучения, рыночном спросе, техническом прогрессе, юридических требованиях или государственном стандарте.

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

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

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

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

• Организационная или корпоративная культура и структура • Государственные или промышленные стандарты (например, предписания контролирующих органов, стандарты на продукцию, стандарты качества, стандарты изготовления) • Инфраструктура (например, существующие сооружения и капитальное оборудование) • Существующие человеческие ресурсы (навыки, знания, специализации, такие как проектирование, разработки, юридические вопросы, заключение контрактов, закупки) • Управление персоналом (например, правила приема и увольнения, оценка эффективности работы и обучение персонала) • Корпоративная система авторизации работ • Ситуация на рынке • Толерантность к риску участников проекта • Коммерческие базы данных (например, стандартизированные сметные данные, данные изучения промышленных рисков и базы данных рисков) • Информационные системы управления проектами (например, автоматизированные системы, такие как программное обеспечение для управления расписанием, система управления конфигурацией, система сбора и распределения информации и веб-интерфейсы к другим автоматизированным системам, работающим в режиме online).

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта.4 Активы организационного процесса При разработке Устава проекта и последующей документации по проекту все активы, используемые для влияния на успех проекта могут быть взяты из активов организационного процесса. У всех и каждой из вовлеченных в проект организаций могут быть свои формальные и неформальные кодексы поведения, процедуры, планы и регламенты, влияние которых необходимо учитывать.

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

например, завершенные расписания, данные о рисках и освоенных объемах. Активы организационного процесса могут быть организованы по-разному, в зависимости от отрасли, организации и области приложения. Например, активы организационного процесса можно сгруппировать в две категории:

• Процессы и процедуры организации для проведения работ:

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 84 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США • Корпоративная база знаний для хранения и извлечения информации:

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

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

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

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

4.1.2 Разработка Устава проекта: инструменты и методы.1 Методы выбора проекта Методы выбора проекта используются для определения того, какой проект выберет организация. Обычно эти методы попадают в одну из двух крупных категорий:

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

• Математические модели на основе линейных, нелинейных, динамических, многоцелевых алгоритмов и алгоритмов целых чисел.

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта.3 Информационная система управления проектами Информационная система управления проектами (ИСУП) представляет собой стандартизированный набор имеющихся в организации автоматизированных инструментов, интегрированных в систему. ИСУП используется командой управления проектом для подготовки Устава проекта, обеспечения обратной связи на этапе его доработки, управления вносимыми в Устав изменениями и издания утвержденного документа.

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

источники в таких случаях могут быть разными:

• другие отделы данной организации;

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

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

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

• отраслевые группы.

4.1.3 Разработка Устава проекта: выходы.1 Устав проекта Описан в предисловии к разделу 4.1.

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

• Цели проекта и продукта • Требования к продукту или услуге и их характеристики • Критерии приемки продукта • Границы проекта • Требования и результаты поставки проекта • Ограничения проекта • Допущения проекта • Первоначальная организация проекта • Первоначально сформулированные риски • Контрольные события расписания • Первоначальная иерархическая структура работ (ИСР) • Смета расходов с указанием порядка величин • Требования к управлению конфигурацией проекта • Требования к одобрению.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 86 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Предварительное описание содержания проекта разрабатывается на основе информации, предоставляемой инициатором или спонсором проекта. Команда управления проектом в рамках процесса определения содержания проекта производит дальнейшую доработку предварительного описания содержания проекта до получения окончательного варианта описания содержания проекта.

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

Рисунок 4-4. Разработка предварительного описания содержания проекта: входы, инструменты и методы, выходы 4.2.1 Разработка предварительного описания содержания проекта: входы.1 Устав проекта Описан в разделе 4.1.

.2 Содержание работы по проекту Описано в разделе 4.1.1.2.

.3 Факторы внешней среды предприятия Описаны в разделе 4.1.1.3.

.4 Активы организационного процесса Описаны в разделе 4.1.1.4.

4.2.2 Разработка предварительного описания содержания проекта: Инструменты и Методы.1 Методология управления проектами Методология управления проектами определяет процесс, помогающий команде управления проектом разработать и контролировать изменения к предварительному описанию содержания проекта.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта.2 Информационная система управления проектами Информационная система управления проектами, автоматизированная система, используется командой управления проектом для подготовки предварительного описания содержания проекта, обеспечения обратной связи на этапе доработки документа, управления изменениями к описанию содержания проекта и выпуска утвержденного документа.

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

4.2.3 Разработка предварительного описания содержания проекта: Выходы.1 Предварительное описание содержания проекта Описано в предисловии к разделу 4.2.

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 88 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и прочих элементов. Каждый из вспомогательных планов и элементов описывается настолько подробно, насколько того требует конкретный проект.

Вспомогательные планы включают в себя (список не исчерпывающий):

• План управления содержанием проекта (раздел 5.1.3.1) • План управления расписанием (глава 6, вводная часть) • План управления стоимостью (глава 7, вводная часть) • План управления качеством (раздел 8.1.3.1) • План совершенствования процессов (раздел 8.1.3.4) • План управления обеспечением проекта персоналом (раздел 9.1.3.3) • План управления коммуникациями (раздел 10.1.3.1) • План управления рисками (раздел 11.1.3.1) • План управления поставками (раздел 12.1.3.1.) Прочие элементы включают в себя (перечень не исчерпывающий):

• Перечень контрольных событий (раздел 6.1.3.3).

• Календарь ресурсов (раздел 6.3.3.4).

• Базовый план расписания (раздел 6.5.3.3).

• Базовый план по стоимости (раздел 7.2.3.1).

• Базовый план по качеству (раздел 8.1.3.5).

• Реестр рисков (раздел 11.2.3.1).

Рисунок 4-5. Разработка плана управления проектом: входы, инструменты и методы, выходы 4.3.1 Разработка плана управления проектом: входы.1 Предварительное описание содержания проекта Описано в разделе 4.2.

.2 Процессы управления проектами Описаны в главах с 5 по 12.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта.3 Факторы внешней среды предприятия Описано в разделе 4.1.1.3.

.4 Активы организационного процесса Описано в разделе 4.1.1.4.

4.3.2 Разработка плана управления проектом: Инструменты и Методы.1 Методология управления проектами Методология управления проектами определяет процесс, помогающий команде управления проектом в разработке и контролировании изменений к плану управления проектом.

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

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

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

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

.3 Экспертная оценка Экспертная оценка применяется ко всем техническим и организационным деталям, входящим в план управления проектом.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 90 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 4.3.3 Разработка плана управления проектом: выходы.1 План управления проектом Описан в предисловии к разделу 4.3.

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

Вот некоторые из этих действий:

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта Для руководства и управления исполнением проекта требуется также следующее:

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

Рисунок 4-6. Руководство и управление исполнением проекта: входы, инструменты и методы, выходы 4.4.1 Руководство и управление исполнением проекта: входы.1 План управления проектом Описано в предисловии к разделу 4.3.

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

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

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

Временные рамки обработки одобренных запросов на изменение устанавливаются командой проекта.

.5 Одобренное исправление дефекта Одобренное исправление дефекта представляет собой документированный, авторизованный запрос на исправление дефекта продукта, выявленного в ходе проверки или аудита качества.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 92 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.6 Санкционированное исправление дефекта Уведомление о приемке / выбраковке осмотренных отремонтированных элементов.

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

4.4.2 Руководство и управление исполнением проекта:

инструменты и методы.1 Методология управления проектами Методология управления проектами определяет процесс, помогающий команде проекта в исполнении плана управления проектом.

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

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

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

.3 Реализованные запросы на изменение Одобренные запросы на изменение, реализованные командой управления проектом в ходе выполнения проекта.

.4 Реализованные корректирующие действия Одобренные корректирующие действия, реализованные командой управления проектом для приведения ожидаемой эффективности проекта с планом управления проектом.

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта.6 Реализованное исправление дефекта В ходе выполнения проекта команда управления проектом реализовала одобренные исправления дефектов.

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

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

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

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

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

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

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 94 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Рисунок 4-7. Мониторинг и управление работами проекта: входы, инструменты и методы, выходы 4.5.1 Мониторинг и управление работами проекта: входы.1 План управления проектом Описан в предисловии к разделу 4.3.

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

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

4.5.2 Мониторинг и управление работами проекта: инструменты и методы.1 Методология управления проектами Методология управления проектами определяет процесс, помогающий команде управления проектом наблюдать и контролировать проектную работу, выполняемую в соответствии с планом управления проектом.

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

.3 Метод освоенного объема Метод освоенного объема предназначен для измерения эффективности проекта от его инициации вплоть до его закрытия. Методология управления освоенным объемом служит также средством прогнозирования эффективности на основе измеренной ранее.

.4 Экспертная оценка Экспертная оценка используется командой управления проектом для мониторинга и управления работами проекта.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта 4.5.3 Мониторинг и управление работами проекта: выходы.1 Рекомендуемые корректирующие действия Корректирующие действия – это документированные рекомендации, необходимые для приведения ожидаемого хода исполнения проекта в соответствие с планом управления проектом.

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

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

например, прогноз по завершении и прогноз до завершения.

.4 Рекомендуемое исправление дефекта Некоторые дефекты, выявленные в ходе проверки и аудита качества, рекомендуются к исправлению.

.5 Запрошенные изменения Описано в разделе 4.4.3.2.

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

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

• Идентификация необходимости появления изменения или факта его появления.

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

• Рассмотрение и одобрение запрошенных изменений.

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

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

• Проверка и одобрение всех рекомендованных корректирующих и предупреждающих действий.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 96 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США • Контроль и обновление содержания, стоимости, бюджета, расписания проекта и требований к качеству на основе одобренных изменений путем координирования изменений по всему проекту. Например, предлагаемое изменение расписания часто оказывает влияние на стоимость, риск, качество и расстановку персонала.

• Документирование в полном объеме корректировок, вызванных запрошенными изменениями.

• Санкционирование исправлений дефектов. • Контроль качества проекта по стандартам на основе отчетов о качестве.

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

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

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

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

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта Каждое задокументированное запрошенное изменение должно быть принято или отклонено лицом с соответствующими полномочиями из команды управления проектом или из сторонней организации, представляющей инициатора, спонсора или заказчика. Зачастую в процессе общего управления изменениями задействован Совет управления изменениями, который отвечает за одобрение и отклонение запрошенных изменений. Роли и обязанности этих Советов четко определяются в рамках процедур управления конфигурацией и управления изменениями и согласуются спонсором, заказчиком и другими участниками проекта. Во многих крупных организациях Советы управления изменениями имеют многоуровневые структуры с разделением обязанностей.

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

Рисунок 4-8. Общее управление изменениями: входы, инструменты и методы, выходы 4.6.1 Общее управление изменениями: входы.1 План управления проектом Описан в предисловии к разделу 4.3.

.2 Запрошенные изменения Описаны в разделе 4.4.3.2.

.3 Информация об исполнении работ Описана в разделе 4.4.3.7.

.4 Рекомендуемые предупреждающие действия Описаны в разделе 4.5.3.2.

.5 Рекомендуемые корректирующие действия Описаны в разделе 4.5.3.1.

.6 Рекомендуемые исправления дефектов Описаны в разделе 4.5.3.4.

.7 Результаты поставки Описаны в разделе 4.4.3.1.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 98 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 4.6.2 Общее управление изменениями: инструменты и методы.1 Методология управления проектами Методология управления проектами определяет процесс, помогающий команде управления проектом в реализации общего управления изменениями в рамках проекта.

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

.3 Экспертная оценка Команда управления проектом использует экспертную оценку Совета управления изменениями и участников проекта для контроля и одобрения всех запрошенных изменений по любому аспекту проекта.

4.6.3 Общее управление изменениями: Выходы.1 Одобренные запросы на изменение Описаны в разделе 4.4.1.4.

.2 Отклоненные запросы на изменение Описаны в разделе 4.5.1.3.

.3 План управления проектом (обновления) Описан в предисловии к разделу 4.3.

.4 Описание содержания проекта (обновления) Описано в разделе 5.3.3.1.

.5 Одобренные корректирующие действия Описаны в разделе 4.4.1.2.

.6 Одобренные предупреждающие действия Описаны в разделе 4.4.1.3.

.7 Одобренные исправления дефектов Описаны в разделе 4.4.1.5.

.8 Санкционированные исправления дефектов Описано в разделе 4.4.1.6.

.9 Результаты поставки Описаны в разделе 4.4.3.1 и одобрены в рамках процесса общего управления изменениями (раздел 4.6).

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта 4.7 Закрытие проекта Процесс закрытия проекта включает в себя выполнение плана управления проекта в части закрытия проекта. В многофазных проектах процесс закрытия проекта закрывает часть содержания проекта и операций, относящихся к данной фазе. Этот процесс включает в себя завершение всех выполненных операций во всех группах процессов управления проектом для формального закрытия проекта или проектной фазы и передачи завершенного или остановленного проекта. Процесс закрытия проекта также определяет процедуры координации операций, необходимых для проверки и документирования результатов поставки проекта, координации и формализации приемки этих результатов поставки заказчиком или спонсором и исследования и документирования причин предпринятых действий при закрытии проекта до его завершения. Для обеспечения необходимого взаимодействия при выполнении операций закрытия всего проекта или фазы проекта разрабатываются две процедуры:

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

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

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

Рисунок 4-9. Закрытие проекта: входы, инструменты и методы, выходы Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 100 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 4.7.1 Закрытие проекта: входы.1 План управления проектом Описан в предисловии к разделу 4.3.

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

.3 Факторы внешней среды предприятия Описаны в разделе 4.1.1.3.

.4 Активы организационного процесса Описаны в разделе 4.1.1.4.

.5 Информация об исполнении работ Описано в разделе 4.4.3.7.

.6 Результаты поставки Описаны в разделе 4.4.3.1 и одобрены в рамках процесса общего управления изменениями (раздел 4.6).

4.7.2 Закрытие проекта: инструменты и методы.1 Методология управления проектами Методология управления проектами определяет процесс, помогающий команде управления проектом в выполнении процедур административного закрытия проекта и закрытия контрактов.

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 4 - Управление интеграцией проекта • Действия и операции для определения требований участников проекта к одобрению изменений и результатов поставки всех уровней • Действия и операции, необходимые для подтверждения того, что в проекте выполнены все требования спонсоров, заказчиков и других участников проекта, проверки выдачи и приемки всех результатов поставки и выполнения критериев завершения и выхода • Действия и операции, необходимые для удовлетворения критериев завершения и выхода для данного проекта.

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

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

.4 Активы организационного процесса (обновления) Закрытие будет включать в себя разработку каталога и определение места для документации по проекту с использованием системы управления конфигурацией (раздел 4.3).

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

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 102 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США ГЛАВА Управление содержанием проекта Управление содержанием проекта включает в себя процессы, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта. Оно непосредственно связано с определением и контролем того, что включено или не включено в проект. На рис. 5- приведена общая схема процессов управления содержанием проекта, а на рис. 5-2 – диаграмма зависимостей для этих процессов с их входами, выходами и прочими процессами в области знаний.

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

5.2 Определение содержания – разработка подробного описания содержания проекта в качестве основы для принятия будущих решений по проекту.

5.3 Создание ИСР – разбиение крупных результатов поставки проекта и проектных работ на более мелкие, более управляемые элементы.

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

5.5. Управление содержанием – управление изменениями содержания проекта.

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

Взаимодействие процессов подробно рассматривается в главе 3.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта В контексте управления проектами термин "содержание" может относиться к следующим понятиям:

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

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

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

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

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

Реализация содержания проекта сравнивается с планом управления проектом (раздел 4.3), описанием содержания проекта с ИСР и словарем ИСР, но реализация содержания продукта сравнивается с требованиями к продукту.

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 104 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Рисунок 5-1. Общая схема управления содержанием проекта Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта Примечание: Показаны не все взаимодействия процессов и не все потоки данных между процессами.

Рисунок 5-2. Диаграмма зависимостей процессов для управления содержанием проекта Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 106 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 5.1 Планирование содержания Определение содержания проекта и управление им оказывает влияние на общую успешность проекта. Для каждого проекта требуется тщательно сбалансированная совокупность инструментов, источников данных, методологий, процессов и процедур и других факторов, обеспечивающая соразмерность трудозатрат на операции по управлению содержанием проекта размеру, сложности и важности проекта. Например, для проекта особой важности будут оправданы формализованные, детализированные и трудоемкие операции по управлению содержанием, а для обычного проекта потребуется значительно меньше документации и проверок. Команда управления проектом документирует эти решения по управлению содержанием в плане управления содержанием проекта. План управления содержанием проекта является инструментом планирования, описывающим, как проектная команда будет формулировать содержание проекта, разрабатывать подробное описание содержания проекта, определять и разрабатывать иерархическую структуру работ, проверять и контролировать содержание проекта. Разработка плана управления содержанием проекта и детализация содержания проекта начинаются с анализа информации, содержащейся в Уставе проекта (раздел 4.1), предварительном описании содержания проекта (раздел 4.2), последней одобренной редакции плана управления проектом (раздел 4.3), исторической информации, содержащейся в активах организационного процесса (раздел 4.1.1.4), и любых релевантных факторов внешней среды предприятия (раздел 4.1.1.3).

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта • Корпоративные правила для различных сфер деятельности организации в части, относящейся к планированию и управлению содержанием проекта • Организационные процедуры, относящиеся к планированию и управлению содержанием проекта • Историческая информация о предыдущих проектах, которая может быть помещена в базу накопленных знаний.

.3 Устав проекта Описан в разделе 4.1.

.4 Предварительное описание содержания проекта Описано в разделе 4.2.

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

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

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 108 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 5.2 Определение содержания Подготовка подробного описания содержания проекта – это ключевая составляющая успеха проекта;

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

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

Рисунок 5-4. Определение содержания: входы, инструменты и методы, выходы 5.2.1 Определение содержания: входы.1 Активы организационного процесса Описаны в разделе 4.1.1.4.

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта 5.2.2 Определение содержания: инструменты и методы.1 Анализ продукта В каждой области приложения есть один или несколько общепринятых методов преобразования целей проекта в материальные результаты поставки и требования. Анализ проекта включает в себя такие методы, как иерархическая структура продукта, системный анализ, системный инжиниринг, метод оптимизации выгод, анализ стоимости и функциональный анализ.

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

наибольшей популярностью пользуются метод мозгового штурма и всестороннее рассмотрение вопроса.

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

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

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

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

5.2.3 Определение содержания: выходы.1 Описание содержания проекта Описание содержания проекта подробно описывает результаты поставки проекта и работы, необходимые для создания этих результатов поставки.

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 110 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США • Цели проекта. Цели проекта включают в себя измеримые критерии его успешности. Проекты могут иметь широкий спектр целей – связанных с бизнесом, стоимостью и расписанием проекта, а также технических и качественных целей. Цели проекта могут также включать в себя плановые показатели стоимости, расписания и качества проекта. У каждой цели проекта есть атрибуты (например, стоимость), единица измерения (например, доллар США) и абсолютное или относительное значение (например, не более 1,5 млн. долларов).

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

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

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

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

• Критерии приемки продукта. Определяют порядок и критерии приемки готового продукта.

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта • Первоначальная организация проекта. На этом этапе определяются члены команды проекта и участники проекта, а также документально фиксируется организация проекта.

• Изначально сформулированные риски. Перечисляются известные риски.

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

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

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

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

• Спецификации проекта. Определяют спецификации, которым должен соответствовать проект.

• Требования к одобрению. Определяют требования к одобрению, применяющиеся к таким элементам, как цели проекта, результаты поставки проекта, документы и работа.

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

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

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

В ИСР включаются работы, указанные в текущем одобренном описании содержания проекта. Составные элементы ИСР облегчают участникам проекта обзор результатов поставки проекта (раздел 4.4.3.1).

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 112 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Рисунок 5-5. Создание ИСР: входы, инструменты и методы, выходы 5.3.1 Создание ИСР: входы.1 Активы организационного процесса Описаны в разделе 4.1.1.4.

.2 Описание содержания проекта Приведено в разделе 5.2.3.1.

.3 План управления содержанием проекта Описан в разделе 5.2.1.4.

.4 Одобренные запросы на изменение Описаны в разделе 4.4.1.4.

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

свои стандартные шаблоны есть и во многих исполняющих организациях.

Стандарт Института управления проектами (PMI) для иерархической структуры работ содержит руководство по созданию, доработке и применению иерархических структур работ. В это руководство включены взятые из некоторых отраслей примеры шаблонов ИСР, которые можно адаптировать под конкретные проекты в конкретной области приложения. На рис. 5-6 показана часть примера ИСР с несколькими ответвлениями, разбитыми до уровня пакет работ.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта Рисунок 5-6. Пример иерархической структуры работ с несколькими ответвлениями, разбитыми до уровня пакетов работ.2 Декомпозиция Декомпозиция – это разделение результатов поставки проекта на более мелкие и более управляемые элементы;

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

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

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

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 114 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Декомпозиция всей совокупности проектных работ обычно включает в себя следующие операции:

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

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

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

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

• Использование подпроектов, как показано на рис. 5-6, где подпроекты могут разрабатываться сторонними организациями. Например, в некоторых областях приложения может быть определена и разработана ИСР проекта, состоящая из нескольких частей (например, сводная ИСР проекта с несколькими подпроектами в рамках ИСР, на которые могут быть заключены контракты со сторонними организациями). В таких случаях продавец разрабатывает вспомогательную иерархическую структуру работ по контракту в рамках работ, включенных в условия контракта.

• Использование фаз жизненного цикла проекта в качестве первого уровня декомпозиции, а результатов поставки проекта – в качестве второго уровня, как показано на рис. 5-7.

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

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта При проверке корректности декомпозиции определяется, являются ли элементы ИСР нижнего уровня необходимыми и достаточными для достижения соответствующих результатов поставки на более высоких уровнях.

Рисунок 5-7. Пример иерархической структуры работ, организованной по фазам Рисунок 5-8. Пример иерархической структуры работ для элементов оборонного комплекса Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 116 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США 5.3.3 Создание ИСР: выходы.1 Описание содержания проекта (обновления) Если одобренные запросы на изменение являются результатом создания ИСР, то в описание содержания проекта включаются эти одобренные изменения.

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

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

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

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

• Иерархическая структура рисков. Иерархически выстроенное представление идентифицированных рисков проекта по категориям.

• Иерархическая структура ресурсов. Иерархически выстроенное представление ресурсов по их типам.

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

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

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

.4 Базовый план по содержанию Одобренное подробное описание содержания проекта (раздел 5.2.3.1) вместе с ИСР и словарем ИСР представляют собой базовый план по содержанию проекта.

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США Глава 5 - Управление содержанием проекта.5 План управления содержанием проекта (обновления) Если одобренные запросы на изменения являются результатом создания ИСР, то может потребоваться включить эти одобренные изменения в план управления содержанием проекта.

.6 Запрошенные изменения Запрошенные изменения описания содержания проекта и его элементов могут появляться в процессе создания ИСР и рассматриваются в рамках процесса общего управления изменениями.

5.4 Подтверждение содержания Подтверждение содержания – это формальное принятие участником проекта завершенного содержания проекта и относящихся к нему результатов поставки.

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

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

Рисунок 5-9. Подтверждение содержания: входы, инструменты и методы, выходы 5.4.1 Подтверждение содержания: входы.1 Описание содержания проекта Описание содержания проекта включает в себя определение содержания продукта, в котором дается описание продукта и критерии его приемки.

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

Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) Третье издание 118 ©2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США.3 План управления содержанием проекта Описан в разделе 5.1.3.1.

.4 Результаты поставки Результаты поставки – это полностью или частично достигнутые результаты проекта. Они являются выходом процесса руководства и управления исполнением проекта (раздел 4.4).

5.4.2 Подтверждение содержания: Инструменты и Методы.1 Инспекция Инспекция включает в себя такие операции, как измерение, изучение и проверка и служит для определения соответствия работ и результатов поставки требованиям и критериям приемки продукта. Инспекции называются различными терминами: "проверка", "проверка продукта", "аудит" и "сквозной контроль" В некоторых областях приложения эти термины имеют более узкий или специфический смысл.

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

.2 Запрошенные изменения Запрошенные изменения могут появиться в ходе процесса подтверждения содержания и рассматриваются в ходе процесса общего управления изменениями.

.3 Рекомендуемые корректирующие действия Описаны в разделе 4.5.3.1.

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

Управление содержанием проекта используется также для управления текущими изменениями по мере их появления;

Pages:     | 1 || 3 | 4 |   ...   | 8 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

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