Текст книги "Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство"

Жизненный цикл проекта – это набор фаз, через которые проходит проект с момента его начала до момента завершения. Фаза проекта – совокупность логически связанных операций проекта, завершающихся достижением одного или ряда поставляемых результатов. Фазы проекта могут быть последовательными, итеративными или накладывающимися друг на друга. Названия, количество и продолжительность фаз проекта определяются в зависимости от потребностей в управлении и контроле организации(ий), вовлеченных в проект, характера самого проекта и его прикладной области. Фазы ограничены по времени и имеют начальную и конечную или контрольную точку (которую иногда называют «обзор фазы», «ворота фазы», «ворота контроля» или иным подобным термином). В контрольной точке устав проекта и бизнес-документы проходят повторное рассмотрение с учетом текущей ситуации. В это время исполнение проекта сравнивается с планом управления проектом с целью определить следующее: требуется ли внести изменения в проект, прекратить его или продолжить его реализацию в соответствии с планом.

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

Хотя проекты отличаются размером и степенью сложности своего состава, структуру жизненного цикла типичного проекта можно представить в следующем виде (см. рис. 1–2):

♦ начало проекта;

♦ организация и подготовка;

♦ выполнение работ;

♦ завершение проекта.

Рис. 1–2. Общее представление жизненного цикла проекта

Обобщенная структура жизненного цикла обычно отображает следующие характеристики:

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

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

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

Рис. 1–3. Влияние переменных с течением времени

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

♦ Внутренние заинтересованные стороны:

• спонсор,

• руководитель ресурсов,

• офис управления проектами (ОУП),

• управляющий комитет портфеля,

• руководитель программы,

• руководители других проектов,

• члены команды.

♦ Внешние заинтересованные стороны:

• заказчики,

• конечные пользователи,

• поставщики,

• акционеры,

• регулирующие органы,

• конкуренты.

Рис. 1–4. Примеры заинтересованных сторон проекта

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

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

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

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

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

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

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

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

♦ лидерство,

♦ укрепление команды,

♦ мотивация,

♦ общение,

♦ влияние,

♦ принятие решений,

♦ политическая и культурная осведомленность,

♦ ведение переговоров,

♦ фасилитация (организация групповой работы),

♦ умение разрешать конфликты,

♦ коучинг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♦ Группа процессов исполнения. Процесс (-ы), выполняемый (-е) для исполнения работ, указанных в плане управления проектом, с целью соответствия требованиям проекта. Процессы исполнения описаны в разделе 4.

♦ Группа процессов мониторинга и контроля. Процесс (-ы), требуемый (-е) для отслеживания, анализа, а также регулирования исполнения проекта; выявления областей, требующих внесения изменений в план; и инициирования соответствующих изменений. Процессы мониторинга и контроля описаны в разделе 5.

♦ Группа процессов закрытия. Процесс (-ы), выполняемый (-ые) для формального завершения или закрытия проекта, фазы или договора. Процессы закрытия описаны в разделе 6.

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

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

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

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

Выход одного процесса, как правило, становится входом для другого процесса или является поставляемым результатом проекта или фазы проекта. Например, план управления проектом и документы проекта (то есть реестр рисков, матрица ответственности и т. д.), создаваемые группой процессов планирования, предоставляются в группу процессов исполнения по мере внесения в них изменений. На рис. 1–4 показан пример того, как группы процессов могут накладываться друг на друга в проекте или его фазе.

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

Рис. 1–5. Пример взаимодействия группы процессов в рамках проекта или фазы

В таблице 1–1 показано место 49 процессов относительно групп процессов и областей знаний.

Таблица 1–1. Разделение по группам процессов управления проектом и областям знаний

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

Источником ФСП является внешняя по отношению к проекту и часто внешняя по отношению к предприятию среда. Эти факторы являются условиями, которые не находятся под непосредственным контролем команды проекта и оказывают влияние на проект, ограничивают или направляют его. ФСП могут оказать воздействие на уровне предприятия, портфеля, программы или проекта. (Дополнительную информацию по ФСП смотрите в разделе 2.2 Руководства PMBOK®) Одной из групп таких факторов является внутренняя организационная культура, структура и руководство. Примеры в этой области включают в себя, среди прочего: видение, миссию, ценности, убеждения, культурные нормы, иерархию и систему взаимосвязей полномочий.

АПО являются внутренними по отношению к предприятию. Они могут происходить от самого предприятия, портфеля, программы, другого проекта или их сочетания. АПО – это планы, процессы, политики, процедуры и базы знаний, специфичные для исполняющей организации и используемые ею. Эти активы оказывают влияние на управление проектом. Примеры в этой области включают в себя, среди прочего: процедуры контроля изменений, шаблоны, информацию по итогам прошлых проектов и репозитории извлеченных уроков. (Дополнительную информацию по АПО смотрите в разделе 2.3 Руководства PMBOK®)

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

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

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

В таблице 1–2 представлен типичный список компонентов плана управления проектом и документов проекта. Это не исчерпывающий список, но в нем приведены типичные виды документов, которые часто используются при управлении проектом.

Таблица 1–2. План управления проектом и документы проекта

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

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

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

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

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

Рис. 2–1. Границы проекта

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

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

В состав группы процессов инициации входят процессы управления проектом, которые определены в разделах 2.1 и 2.2.

Рис. 2–2. Группа процессов инициации