Руководство pmbok ® Шестое издание
Yüklə 12,83 Mb. Pdf görüntüsü
|
|
Часть 2 - Стандарт
1.6 ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ ПРОЕКТА Заинтересованная сторона — это лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта. Заинтересованные стороны могут быть внешними или внутренними по отношению к проекту, могут участвовать в нем активно, неактивно или вообще о нем не знать. Заинтересованные стороны могут оказывать положительное или отрицательное воздействие на проект, или подвергаться положительному или отрицательному воздействию от проекта. Ниже приводятся примеры заинтересованных сторон (перечень не является исчерпывающим): u u Внутренние заинтересованные стороны: u n спонсор, u n руководитель ресурсов, u n офис управления проектами (ОУП), u n управляющий комитет портфеля, u n руководитель программы, u n руководители других проектов, u n члены команды. u u Внешние заинтересованные стороны: u n заказчики, u n конечные пользователи, u n поставщики, u n акционеры, u n регулирующие органы, u n конкуренты. 551 Рис. 1-4. Примеры заинтересованных сторон проекта На рис. 1-4 показаны примеры заинтересованных сторон проекта. Вовлеченность заинтересованных сторон может осуществляться в различных формах — от эпизодического участия в опросах и работе фокус-групп до полного спонсорства проекта, которое включает в себя предоставление финансовой, политической и других типов поддержки. Вид и уровень участия в проекте могут меняться на протяжении жизненного цикла проекта. Таким образом, успешная идентификация , анализ и вовлечение заинтересованных сторон, а также результативное управление их ожиданиями от проекта и участием на протяжении всего жизненного цикла проекта имеет важнейшее значение для его успеха.
Команда проекта Руководители публично- частных партнерств Руководители ресурсов Спонсоры
Органы управления Управляющие комитеты ОУПы Заинтересованные стороны Поставщики Заказчики Конечные пользователи
552 Часть 2 - Стандарт 1.7 РОЛЬ РУКОВОДИТЕЛЯ ПРОЕКТА Руководитель проекта — это лицо, назначенное исполняющей организацией руководить командой, ответственной за достижение целей проекта. Отношения подчиненности руководителя проекта зависят от организационной структурыи руководства проектом. Помимо конкретных технических навыков и общего уровня подготовки руководителя, необходимых для реализации проекта, руководители проектов должны обладать как минимум следующими качествами: u u
необходимой для результативного управления проектом; u u навыки, необходимые для результативного управления командой проекта, координации работ, взаимодействия с заинтересованными сторонами, разрешения проблем и принятия решений; u u
планами, презентациями и отчетностью; u u другие качества, необходимые для успешного управления проектом, такие как характер, отношение к работе, моральные качества и лидерство. Руководители проектов выполняют работу с помощью команды проекта и других заинтересованных сторон. Руководители проекта используют в работе навыки межличностных отношений, включая, среди прочего, следующие: u u
u u укрепление команды, u u мотивация, u u общение, u u влияние, u u принятие решений, u u политическая и культурная осведомленность, u u ведение переговоров, u u фасилитация (организация групповой работы), u u умение разрешать конфликты, u u коучинг. Руководителя проекта можно считать успешным, когда были достигнуты цели проекта. Еще одним критерием успеха является удовлетворенность заинтересованных сторон. Руководитель проекта должен принимать в расчет их потребности, затруднения и ожидания, чтобы добиться удовлетворенности соответствующих заинтересованных сторон. Для достижения успеха руководитель проекта должен так адаптировать подход к проекту, его жизненный цикл и процессы управления проектом, чтобы выполнить требования к проекту и продукту.
553 1.8 ОБЛАСТИ ЗНАНИЙ УПРАВЛЕНИЯ ПРОЕКТОМ Области знаний управления проектом — это области или сферы специализации, которые обычно применяются при управлении проектами. Область знаний — это набор процессов, связанных с определенной темой в управлении проектом. Эти 10 областей знаний применимы в большинстве проектов в большинстве случаев. Для нужд некоторых проектов могут потребоваться дополнительные области знаний. 10 областей знаний включают в себя: u u Управление интеграцией проекта. Управление интеграцией проекта включает в себя процессы и операции, необходимые для идентификации, определения, комбинирования, объединения и координации различных процессов и операций по управлению проектом в рамках групп процессов управления проектом. u u Управление содержанием проекта. Управление содержанием проекта включает в себя процессы, требуемые для обеспечения того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. u u Управление расписанием проекта. Управление расписанием проекта включает в себя процессы, необходимые для управления своевременным выполнением проекта. u u
для планирования, оценки, разработки бюджета, привлечения финансирования, финансирования, управления и контроля стоимости, обеспечивающие выполнение проекта в рамках одобренного бюджета. u u
применения политики организации в области качества относительно планирования, управления и контроля проекта, а также требований к качеству продукта с целью удовлетворения ожиданий заинтересованных сторон. u u
идентификации, приобретения и управления ресурсами, необходимыми для успешного выполнения проекта. u u Управление коммуникациями проекта. Управление коммуникациями проекта включает в себя процессы, необходимые для обеспечения своевременного и надлежащего планирования, сбора, создания, распространения, хранения, извлечения, управления, контроля, мониторинга и, в конечном счете, архивирования/утилизации проектной информации. u u
с осуществлением планирования управления рисками, идентификацией, анализом, планированием реагирования, осуществлением реагирования, а также с мониторингом рисков в проекте. u u Управление закупками проекта. Управление закупками проекта включает в себя процессы покупки или приобретения необходимых для осуществления проекта продуктов, услуг или результатов вне команды проекта. u u
включает в себя процессы, необходимые для выявления людей, групп и организаций, которые могут оказывать или на которых может оказывать воздействие проект, для анализа ожиданий заинтересованных сторон и их воздействия на проект, а также для разработки соответствующих стратегий управления для эффективного вовлечения заинтересованных сторон в принятие решений и исполнение проекта. 554 Часть 2 - Стандарт 1.9 ГРУППЫ ПРОЦЕССОВ УПРАВЛЕНИЯ ПРОЕКТОМ Данный Стандарт описывает процессы управления проектом, применяемые для достижения целей проекта. Процессы управления проектом сгруппированы в пять групп процессов управления проектом: u u Группа процессов инициации. Процесс (-ы), выполняемый (-е) для определения нового проекта или новой фазы существующего проекта путем получения авторизации на начало проекта или фазы. Процессы инициации описаны в разделе 2. u u Группа процессов планирования. Процесс (-ы), требуемый (-е) для установления содержания проекта, уточнения целей и определения направления действий, требуемых для достижения целей проекта. Процессы планирования описаны в разделе 3. u u Группа процессов исполнения. Процесс (-ы), выполняемый (-е) для исполнения работ, указанных в плане управления проектом, с целью соответствия требованиям проекта. Процессы исполнения описаны в разделе 4. u u
регулирования исполнения проекта; выявления областей, требующих внесения изменений в план; и инициирования соответствующих изменений. Процессы мониторинга и контроля описаны в разделе 5. u u
проекта, фазы или договора. Процессы закрытия описаны в разделе 6. Эти пять групп процессов не зависят от прикладных областей (таких как маркетинг, информационные услуги или бухгалтерский учет) или конкретных отраслей применения (таких как строительство, авиационно-космическая отрасль, телекоммуникации). Отдельные процессы в группах процессов часто повторяются вплоть до окончания фазы или проекта в целом. Повторение процессов и их взаимодействие варьируется в зависимости от потребностей проекта. В целом, процессы попадают в одну из трех категорий: u u
примеров можно указать разработку устава проекта и закрытие проекта или его фазы. u u Процессы, которые выполняются периодически, по мере необходимости. Приобретение ресурсов производится тогда, когда в них возникает необходимость. Проведение закупок осуществляется до возникновения потребности в использовании предмета закупки. u u Процессы, которые реализуются постоянно на всем протяжении проекта. Определение операций может происходить на протяжении всего жизненного цикла проекта, особенно в тех случаях, когда в проекте применяется планирование методом набегающей волны или метод адаптивного подхода к разработке. Многие процессы мониторинга и контроля выполняются постоянно с момента начала проекта до его закрытия. 555 Выход одного процесса, как правило, становится входом для другого процесса или является поставляемым результатом проекта или фазы проекта. Например, план управления проектом и документы проекта (то есть реестр рисков, матрица ответственности и т. д.), создаваемые группой процессов планирования, предоставляются в группу процессов исполнения по мере внесения в них изменений. На рис. 1-4 показан пример того, как группы процессов могут накладываться друг на друга в проекте или его фазе. Группы процессов не являются фазами проекта. Если проект разделен на фазы, то процессы в группах процессов взаимодействуют в рамках каждой фазы. Есть вероятность, что все группы процессов могут оказаться представлены внутри фазы, как показано на рис. 1-5. Поскольку проекты разделяются на отдельные фазы, такие как разработка концепции, анализ целесообразности, проектирование, изготовление прототипа, строительство, тестирование и т. п., процессы в каждой группе процессов повторяются по мере необходимости внутри каждой фазы, пока не будут выполнены критерии завершения данной фазы. Рис. 1-5. Пример взаимодействия группы процессов в рамках проекта или фазы В таблице 1-1 показано место 49 процессов относительно групп процессов и областей знаний. Группа процессов планирования Группа
процессов инициации Группа процессов исполнения Группа
процессов мониторинга и контроля Группа
процессов закрытия
Старт Финиш
Время Уровень трудозатрат 556 Часть 2 - Стандарт Таблица 1-1. Разделение по группам процессов управления проектом и областям знаний 4.1 Разработка устава проекта 4.2 Разработка плана управления проектом
4.3 Руководство и управление работами проекта 4.4 Управление знаниями проекта 4.5 Мониторинг и контроль работ проекта
4.6 Интегрирован- ный контроль изменений 4.7 Закрытие проекта или фазы
13.1 Идентификация заинтересованных сторон
13.2 Планирование вовлечения заинтересованных сторон
13.3 Управление вовлечением заинтересован- ных сторон 13.4 Мониторинг вовлечения заинтересован- ных сторон 12.1 Планирование управления закупками 12.2 Проведение закупок 12.3 Контроль закупок 11.1 Планирование управления рисками
11.2 Идентификация рисков
11.3 Качественный 11.4 Количествен- ный анализ рисков 11.5 Планирование реагирования на риски 11.6 Осуществле- ние реагирования на риски
11.7 Мониторинг рисков
10.1 Планирование управления коммуникациями 10.2 Управление коммуникациями 10.3 Мониторинг коммуникаций 9.1 Планирование управления ресурсами 9.2 Оценка ресурсов операций 9.3 Приобретение ресурсов 9.4 Развитие команды проекта 9.5 Управление командой проекта 9.6 Контроль ресурсов 8.1 Планирование управления качеством 8.2 Управление качеством 8.3 Контроль качества
7.1 Планирование управления стоимостью 7.2 Оценка стоимости 7.3 Определение бюджета 7.4 Контроль стоимости 6.1 Планирование управления расписанием 6.2 Определение операций
6.3 Определение последователь- ности операций 6.4 Оценка длительности операций
6.5 Разработка расписания 6.6 Контроль расписания 5.1 Планирование управления содержанием 5.2 Сбор требований 5.3 Определение содержания 5.4 Создание ИСР 5.5 Подтверждение содержания 5.6 Контроль содержания 557 1.10 ФАКТОРЫ СРЕДЫ ПРЕДПРИЯТИЯ И АКТИВЫ ПРОЦЕССОВ ОРГАНИЗАЦИИ Проекты существуют и осуществляются в среде, которая может влиять на них. Данные влияния может оказывать благоприятное или неблагоприятное воздействие на проект. Две главных категории влияний — это факторы среды предприятия (ФСП) и активы процессов организации (АПО). Источником ФСП является внешняя по отношению к проекту и часто внешняя по отношению к предприятию среда. Эти факторы являются условиями, которые не находятся под непосредственным контролем команды проекта и оказывают влияние на проект, ограничивают или направляют его. ФСП могут оказать воздействие на уровне предприятия, портфеля, программы или проекта. (Дополнительную информацию по ФСП смотрите в разделе 2.2 Руководства PMBOK®) Одной из групп таких факторов является внутренняя организационная культура, структура и руководство. Примеры в этой области включают в себя, среди прочего: видение, миссию, ценности, убеждения, культурные нормы, иерархию и систему взаимосвязей полномочий. АПО являются внутренними по отношению к предприятию. Они могут происходить от самого предприятия, портфеля, программы, другого проекта или их сочетания. АПО — это планы, процессы, политики, процедуры и базы знаний, специфичные для исполняющей организации и используемые ею. Эти активы оказывают влияние на управление проектом. Примеры в этой области включают в себя, среди прочего: процедуры контроля изменений, шаблоны, информацию по итогам прошлых проектов и репозитории извлеченных уроков. (Дополнительную информацию по АПО смотрите в разделе 2.3 Руководства PMBOK®)
558 Часть 2 - Стандарт 1.11 АДАПТАЦИЯ АРТЕФАКТОВ ПРОЕКТА Понятие «артефакт» в настоящем контексте включает в себя процессы управления проектом, входы, инструменты, методы, выходы, ФСП и АПО. Руководитель проекта и команда управления проектом выбирают и приспосабливают соответствующие артефакты для использования в их конкретном проекте. Этот процесс «выбора» и «приспособления» обычно называют «адаптацией». Адаптация необходима, поскольку каждый проект является уникальным, и вследствие чего не всякий процесс, вход, инструмент, метод или выход требуется для каждого проекта. План управления проектом является наиболее распространенным артефактом. Он имеет много компонентов, таких как вспомогательные планы управления, базовые планы и описание жизненного цикла проекта. Вспомогательные планы управления — это планы, связанные с конкретным аспектом или областью знаний проекта, например план управления расписанием, план управления рисками и план управления изменениями. Частью адаптации является определение компонентов плана управления проектом, необходимых для данного проекта. План управления проектом — это вход, а обновления плана управления проектом — это выход многих процессов в настоящем Стандарте. Чтобы не перечислять отдельные компоненты плана управления проектом в сводной таблице входов/выходов, примеры компонентов, которые
Перечень возможных компонентов приводится только для примера. Эти входы и выходы не являются обязательными и не являются единственными входами и обновлениями в план управления проектом, которые руководитель проекта может использовать в данном конкретном процессе. План управления проектом является одним из основных артефактов проекта, однако имеются и другие документы, которые не входят в состав плана управления проектом, но используются для управления проектом. Указанные «другие документы» называются документами проекта. Как и компоненты плана управления проектом, перечень необходимых для того или иного процесса документов проекта зависит от особенностей конкретного проекта. За выбор необходимых для того или иного процесса документов проекта, а также документов проекта, которые будут обновлены на выходе процесса, отвечает руководитель проекта. Документы проекта, перечисленные под таблицами входа/выхода далее в этом Стандарте, являются возможными примерами документов проекта, и их перечень не является исчерпывающим. В таблице 1-2 представлен типичный список компонентов плана управления проектом и документов проекта. Это не исчерпывающий список, но в нем приведены типичные виды документов, которые часто используются при управлении проектом. 559 Таблица 1-2. План управления проектом и документы проекта Бизнес-документы — это документы, которые обычно формируются вне проекта и используются в качестве входов для проекта. В качестве примеров бизнес-документов можно назвать бизнес-кейс и план управления выгодами. Использование бизнес-документов зависит от корпоративной культуры и процесса инициации проекта. Факторы среды предприятия, которые влияют на проект, и активы процессов организации, имеющиеся в распоряжении проекта, зависят от характера и среды проекта, и их перечень в настоящем Стандарте не приводится. 1. План управления содержанием 2. План управления требованиями 3. План управления расписанием 4. План управления стоимостью 5. План управления качеством 6. План управления ресурсами 7. План управления коммуникациями 8. План управления рисками 9. План управления закупками 10. План вовлечения заинтересованных сторон 11. План управления изменениями 12. План управления конфигурацией 13. Базовый план по содержанию 14. Базовое расписание 15. Базовый план по стоимости 16. Базовый план исполнения 17. Описание жизненного цикла проекта 18. Подход к разработке 1. Параметры операций 2. Список операций 3. Журнал допущений 4. Основа для оценок 5. Журнал изменений 6. Оценки стоимости 7. Прогнозы стоимости 8. Оценки длительности 9. Журнал проблем 10. Реестр извлеченных уроков 11. Список контрольных событий 12. Выделение материальных ресурсов 13. Календари проекта 14. Коммуникации проекта 15. Расписание проекта 16. Диаграмма сети расписания проекта 17. Описание содержания проекта 18. Распределение обязанностей членов команды проекта 19. Результаты измерений в контроле качества
20. Метрики качества 21. Отчет о качестве 22. Документация по требованиям 23. Матрица отслеживания требований 24. Иерархическая структура ресурсов 25. Календари ресурсов 26. Требования к ресурсам 27. Реестр рисков 28. Отчет по рискам 29. Данные расписания 30. Прогнозы в отношении расписания 31. Реестр заинтересованных сторон 32. Устав команды 33. Документы тестирования и оценки Документы проекта План управления проектом 560 561 2 ГРУППА ПРОЦЕССОВ ИНИЦИАЦИИ Группа процессов инициации состоит из процессов, выполняемых для определения нового проекта или новой фазы существующего проекта путем получения авторизации на начало проекта или фазы. Цель группы процессов инициации — привести в соответствие ожидания заинтересованных сторон и цель проекта, проинформировать заинтересованные стороны о содержании проекта и его целях, а также обсудить с ними, каким образом их участие в проекте и связанных с ним фазах может помочь обеспечить удовлетворение их ожиданий. В рамках процессов инициации определяется изначальное содержание и выделяются изначальные финансовые ресурсы. Идентификация заинтересованных сторон, которые будут взаимодействовать и влиять на общий результат проекта. Выбирается руководитель проекта, если он еще не назначен. Данная информация закрепляется в уставе проекта и в реестре заинтересованных сторон. После одобрения устава проекта проект считается официально авторизованным, и руководитель проекта получает полномочия использовать ресурсы организации для операций проекта. Ключевые выгоды от данной группы процессов состоят в том, что авторизуются только проекты, которые согласованы со стратегическими целями организации, а также в том, что с самого начала проекта учитываются бизнес-кейс, выгоды и заинтересованные стороны. В некоторых организациях руководитель проекта привлекается к разработке бизнес- кейса и определению выгод. В таких организациях руководитель проекта обычно участвует в подготовке устава проекта, а в других организациях предпроектную работу выполняет спонсор проекта, офис управления проектами (ОУП), управляющий комитет портфеля или другая группа заинтересованных сторон. Данный Стандарт предполагает, что проект был одобрен спонсором или другим руководящим органом, и что они изучили бизнес-документы, прежде чем авторизовать проект. Бизнес-документы — это документы, которые обычно формируются вне проекта и используются в качестве входов для проекта. В качестве примеров бизнес-документов можно назвать бизнес-кейс и план управления выгодами. На рис. 2-1 показано место спонсора и бизнес-документов в процессах инициации. |