Руководство к Своду знаний по управлению проектами (Руководство PMBOK) читать онлайн - Коллектив авторов

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

Коллектив авторов

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

Является Американским национальным стандартом. В настоящее время в пользовании находятся более 2 миллионов экземпляров Руководства PMBOK.C момента выхода четвертого издания Институт управления проектами получил тысячи ценных разъяснений и рекомендаций по улучшению от мирового сообщества руководителей проектов.

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

© 2013 Project Management Institute, Inc. Все права защищены.

Уведомление

Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.

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

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

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

1

Введение

В Руководстве к Своду знаний по управлению проектами (Руководство PMBOK®) – Пятом издании приведены руководящие указания по управлению отдельными проектами и определены концепции, связанные с управлением проектами. Здесь также описан жизненный цикл управления проектом и связанных с ним процессов, а также жизненный цикл проекта.

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

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

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

1.1 Цель Руководства PMBOK®

1.2 Что такое проект?

1.3 Что такое управление проектом?

1.4 Связи между управлением портфелем, управлением программой, управлением проектом и организационным управлением проектами

1.5 Связь между управлением проектами, управлением операционной деятельностью и организационной стратегией

1.6 Бизнес-ценность

1.7 Роль руководителя проекта

1.8 Свод знаний по управлению проектами

1.1. Цель Руководства PMBOK®

Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для успеха проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация и/или команда управления проектом самостоятельно определяет

применимость этих знаний к тому или иному проекту.

Руководство PMBOK® также предоставляет и содействует применению общего словаря терминов в профессии управления проектами для употребления и применения понятий управления проектами. Общий словарь является существенным элементом любой профессиональной дисциплины. Словарь терминов управления проектами PMI (PMI Lexicon of Project Management Terms) [1][1 - Цифры в скобках относятся к списку литературы в конце этого стандарта.] представляет собой основной профессиональный словарь, который могут постоянно использовать руководители проектов, программ и портфелей и другие заинтересованные стороны.

Приложение A1 является основным справочным материалом для программ PMI по профессиональному развитию в области управления проектами. Приложение A1 продолжает развиваться вместе с профессией и, таким образом, не является всеобъемлющим; данный стандарт – скорее руководство, а не специфическая методология. Для применения его структуры и рекомендаций могут использоваться различные методологии и инструменты, такие как гибкие (agile) методы, водопадная (waterfall) модель, PRINCE2.

В дополнение к стандартам, формулирующим руководящие указания в отношении процессов управления проектами, специалисты-практики в области управления проектами руководствуются Кодексом профессиональной этики и поведения, разработанным Институтом управления проектами (Project Management Institute Code of Ethics and Professional Conduct) [2] описывающим требования, выполнения которых специалисты-практики ожидают от себя и от других. Кодекс профессиональной этики и поведения, разработанный Институтом управления проектами, устанавливает конкретные нормы ответственности, уважения, справедливости и добропорядочности. Данный кодекс требует от специалистов-практиков по управлению проектами вести себя в соответствии с этическими и профессиональными нормами. В нем указана необходимость соответствия законодательным нормам и правилам, а также политикам организаций и нормам профессионального поведения. Специалисты-практики по управлению проектами заняты в различных областях деятельности и являются представителями различных культур, при этом Кодекс профессиональной этики и поведения применим во всем мире. Специалисты-практики по управлению проектами должны соблюдать принципы добропорядочности, уважения и справедливости при взаимодействии с любой заинтересованной стороной проекта. Принятие кодекса крайне важно для руководителей проектов и необходимо для сдачи следующих экзаменов PMI®:

• Сертифицированный специалист по управлению проектами (Certified Associate in Project Management, CAPM®),

• Профессионал в управлении проектами (Project Management Professional, PMP®),

• Профессионал в управлении программами (Program Management Professional, Pomp®),

• Сертифицированный специалист-практик PMI по методам Agile (PMI Agile Certified Practitioner, PMI-ACP®),

• Профессионал PMI в области управления рисками (PMI Risk Management Professional, PMI-RMP®),

• Профессионал PMI в области календарного планирования (PMI Scheduling Professional, PMI-SP®).

1.2. Что такое проект?

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

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

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

Проект может создать:

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

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

• улучшение существующей линейки продуктов или услуг (например, проект по методике «шести сигм» (Six Sigma), предпринятый для уменьшения дефектов);

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

Примерами проектов могут служить, среди прочего:

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

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

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

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

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

• внедрение, улучшение или усовершенствование существующих бизнес-процессов и процедур.

1.2.1. Связи между портфелями, программами и проектами

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

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

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

Рис. 1–1. Связи между управлением портфелями, управлением программами и управлением проектами

1.3. Что такое управление проектом?

Управление проектом – это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных 47 процессов управления проектом, объединенных в 5 групп процессов. Эти 5 групп процессов следующие:

• инициация,

• планирование,

• исполнение,

• мониторинг и контроль,

• закрытие.

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

• определение требований;

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

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

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

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

– содержание,

– качество,

– расписание,

– бюджет,

– ресурсы,

– риски.

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

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

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

1.4. Связи между управлением портфелем, управлением программой, управлением проектом и организационным управлением проектами

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

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

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

Таблица 1–1. Сравнительный обзор управления проектом, программой и портфелем

1.4.1. Управление программой

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

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

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

проектов, а не программой.

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

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

• приведение в соответствие с организационным/стратегическим направлением, затрагивающим цели и задачи проекта и программы;

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

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

1.4.2. Управление портфелем

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

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

1.4.3. Проекты и стратегическое планирование

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

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

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

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

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

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

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

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

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

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

1.4.4. Офис управления проектами

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

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

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

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

• Руководящий. Руководящие ОУП контролируют проекты путем непосредственного управления данными проектами. Степень контроля со стороны ОУП высокая.

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

сбалансированная система показателей).

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

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

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

• управление общими ресурсами всех проектов, администрируемых ОУП;

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

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

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

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

• координация коммуникаций между проектами.

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

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

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

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

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

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

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

1.5.1. Управление операционной деятельностью и управление проектами

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

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

• в каждой завершающей фазе;

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

• при улучшении операционной деятельности или процесса разработки продукта;

• до завершения жизненного цикла продукта.

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

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

1.5.1.1. Управление операционной деятельностью

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

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

1.5.1.2. Операционные заинтересованные стороны в управлении проектами

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

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

Следующий список представляет собой пример операционных заинтересованных сторон (в зависимости от вида деятельности):

• операторы промышленных предприятий,

• руководители производственных линий,

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

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

• представитель отдела обслуживания клиентов,

• сотрудники отдела продаж,

• обслуживающий персонал,

• сотрудники отдела телемаркетинга,

• сотрудники call-центра,

• сотрудники отдела розничных продаж,

• руководители структурных подразделений,

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

1.5.2. Организации и управление

проектами

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

1.5.2.1. Организации, основанные на проектах

Организации, основанные на проектах (project-based organizations, PBOs), – разнообразные формы организаций, которые занимаются созданием временных систем для исполнения работ. PBOs могут создаваться различными видами организаций (т. е. функциональными, матричными или проектными (см. 2.1.3)). Использование PBOs может привести к ослаблению иерархии и бюрократии внутри организации, так как успех работы определяется конечным результатом, а не должностью или политикой.

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

1.5.2.2. Связь между управлением проектами и организационным руководством

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

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

1.5.2.3. Связь между управлением проектами и организационной стратегией

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

1.6. Бизнес-ценность

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

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

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

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

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

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

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

1.7. Роль руководителя проекта

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

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

1.7.1. Сферы ответственности и компетенции руководителя проекта

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

• Компетенции в знаниях – то, что руководитель знает об управлении проектом.

• Компетенции в исполнении – то, что руководитель проекта способен сделать или достичь, применяя свои знания об управлении проектом.

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

1.7.2. Навыки межличностного общения руководителя проекта

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

• лидерство,

• укрепление командой,

• мотивация,

• коммуникация,

• влияние,

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

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

• переговоры,

• построение доверительных отношений,

• урегулирование конфликтов,

• коучинг.

1.8. Свод знаний по управлению проектами

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

Данный стандарт уникален для сферы управления проектами и имеет отношение к другим дисциплинам управления проектами, таким как управление программой и управление портфелем.

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

• Стандарт управления программой (The Standard for Program Management) [3] – относится к управлению программами,

• Стандарт управления портфелем (The Standard for Portfolio Management) [4] – относится к управлению портфелями,

• Модель зрелости организационного управления проектами (Organizational Project Management Maturity Model, OPM3®) [5] – изучает возможности процессов управления проектами в рамках предприятия.

2

Влияние организации и жизненный цикл проекта

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

2.1 Влияние организации на управление проектами

2.2 Заинтересованные стороны и руководство проектом

2.3 Команда проекта

2.4 Жизненный цикл проекта

2.1. Влияние организации на управление проектами

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

2.1.1. Организационные культуры и стили

Организации – это систематические

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

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

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

• нормы, политики, методы и процедуры;

• системы мотивации и вознаграждений;

• толерантность к риску;

• взгляд на лидерство, иерархию и взаимоотношения руководства;

• кодекс поведения, рабочую этику и часы работы;

• бизнес-окружение.

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

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

2.1.2. Организационные коммуникации

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

2.1.3. Организационные структуры

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

Таблица 2–1. Влияние организационных структур на проекты

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

Рис. 2–1. Функциональная организация

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

Рис. 2–2. Слабая матричная организация

Рис. 2–3. Сбалансированная матричная организация

Рис. 2–4. Сильная матричная организация

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

Рис. 2–5. Проектная организация

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

Рис. 2–6. Комбинированная организация

Многие организационные

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

• стратегическое значение проекта,

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

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

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

• организационные коммуникации.

Данное взаимодействие определяет характеристики проекта, такие как:

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

• доступность и управление ресурсами,

• сторона, контролирующая бюджет проекта,

• роль руководителя проекта,

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

2.1.4. Активы процессов организации

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

2.1.4.1. Процессы и процедуры

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

• Инициация и планирование:

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

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

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

• Исполнение, мониторинг и контроль:

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

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

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

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

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

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

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

• Закрытие:

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

2.1.4.2. Корпоративная база знаний

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

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

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

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

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

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

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

2.1.5. Факторы среды предприятия

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

Факторы среды предприятия широко различаются по типу или характеру. Факторы среды предприятия включают в себя, среди прочего:

• организационную культуру, структуру и руководство;

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

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

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

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

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

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

• ситуация на рынке;

• толерантность к риску заинтересованных сторон;

• политический климат;

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

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

рисков);

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

2.2. Заинтересованные стороны и руководство проектом

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

2.2.1. Заинтересованные стороны проекта

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

Рис. 2–7. Взаимосвязь между заинтересованными сторонами и проектом

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

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

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

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

Ниже представлены некоторые примеры заинтересованных сторон проекта:

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

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

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

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

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

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

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

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

Заинтересованные стороны проекта и вовлечение заинтересованных сторон определены далее в разделе 13, посвященном управлению заинтересованными сторонами проекта.

2.2.2. Руководство проектом

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

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

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

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

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

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

• процессы и процедуры для сообщения информации;

• процессы принятия решений по проекту;

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

• подход к жизненному циклу проекта;

• процесс для шлюза стадии или анализа фазы;

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

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

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

2.2.3. Успех проекта

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

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

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

2.3. Команда проекта

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

Члены команды проекта выполняют следующие роли:

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

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

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

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

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

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

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

2.3.1. Состав команд проектов

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

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

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

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

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

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

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

2.4. Жизненный цикл проекта

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

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

2.4.1. Характеристики жизненного цикла проекта

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

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

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

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

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

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

Рис. 2–8. Типовые уровни стоимости и обеспечения персоналом в обобщенной структуре жизненного цикла проекта

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

• Стоимость и обеспечение персоналом невелики в начале, достигают пикового значения по мере выполнения работ и стремительно падают на этапе завершения проекта. Рис. 2–8 отображает данный типовой пример.

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

• Риск и неопределенность (как показано на рис. 2–9) имеют наибольшие значения в начале проекта. Эти факторы уменьшаются по ходу проекта по мере принятия решений и приемки поставляемых результатов.

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

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

Рис. 2–9. Воздействие переменной в зависимости от срока проекта

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

2.4.2. Фазы проекта

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

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

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

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

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

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

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

Рис. 2-10. Пример однофазного проекта

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

2.4.2.1. Связи между фазами

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

Существует два основных типа взаимосвязей между фазами:

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

Рис. 2-11. Пример трехфазного проекта

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

Рис. 2-12. Пример проекта с перекрывающимися фазами

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

2.4.2.2. Предиктивные жизненные циклы

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

Рис. 2-13. Пример предиктивного жизненного цикла

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

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

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

2.4.2.3. Итеративные и инкрементные жизненные циклы

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

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

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

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

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

2.4.2.4. Адаптивные жизненные циклы

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

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

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

3

Процессы управления проектом

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

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

Для того чтобы проект оказался успешным, его команда должна:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство PMBOK® описывает суть процессов управления проектом в рамках интеграции процессов, их взаимодействия и целей, которым они служат. Процессы управления проектом разделяются на пять категорий, известных как группы процессов управления проектом (или группы процессов):

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

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

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

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

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

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

3.1 Общие взаимодействия процессов управления проектом

3.2 Группы процессов управления проектом

3.3 Группа процессов инициации

3.4 Группа процессов планирования

3.5 Группа процессов исполнения

3.6 Группа процессов мониторинга и контроля

3.7 Группа процессов закрытия

3.8 Информация проекта

3.9 Роль областей знаний

3.1. Общие взаимодействия процессов управления проектом

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

Интегративный характер управления проектом требует, чтобы группа процессов мониторинга и контроля взаимодействовала с другими группами процессов, как показано на рис. 3–1. Процессы мониторинга и контроля осуществляются в то же самое время, что и процессы, входящие в другие группы процессов. Таким образом, на рис. 3–1 процесс мониторинга и контроля изображен как «фоновая» группа процессов для других четырех групп.

Рис. 3–1. Группы процессов управления проектом

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

Рис. 3–2. Взаимодействие групп процессов в рамках фазы или проекта

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

3.2. Группы процессов управления проектом

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

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

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

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

Рис. 3–3. Взаимодействия процессов управления проектом

3.3. Группа процессов инициации

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

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

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

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

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

3.4. Группа процессов планирования

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

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

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

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

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

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

3.5. Группа процессов исполнения

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

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

3.6. Группа процессов мониторинга и контроля

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

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

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

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

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

3.7. Группа процессов закрытия

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

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

При закрытии проекта или фазы может происходить следующее:

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

• проведение анализа после окончания проекта или фазы,

• документирование последствий адаптации любого процесса,

• документирование извлеченных уроков,

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

• архивация всех значимых документов проекта в информационной системе управления проектами (project management information system, PMIS) для использования в качестве исторических данных,

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

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

3.8. Информация проекта

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

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

терминологию:

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

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

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

На рис. 3–5 показан поток информации проекта в рамках различных процессов, используемых для управления проектом.

Рис. 3–5. Поток данных, информации и отчетов проекта

3.9. Роль областей знаний

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

Руководство PMBOK® определяет важные аспекты каждой области знаний и их взаимодействия с пятью группами процессов. В качестве вспомогательных элементов, области знаний предоставляют подробное описание входов и выходов процессов, а также подробное объяснение инструментов и методов, которые наиболее часто используются в рамках процессов управления проектом, чтобы создать каждый выход. Диаграммы потоков данных приводятся в каждой области знаний (разделы с 4 по 13). Диаграмма потоков данных представляет собой обобщающую схему входов и выходов, проходящих через все процессы, относящиеся к определенной области знаний (обозначения, представленные на диаграммах потоков данных, см. на рис. 3–6). Хотя процессы представлены здесь в виде дискретных элементов с четко определенными границами, на практике они являются итеративными, могут накладываться друг на друга и взаимодействовать между собой способами, не описанными здесь.

Таблица 3–1 отражает отнесение 47 процессов управления проектом к 5 группам процессов управления проектом и 10 областям знаний по управлению проектом.

Рис. 3–6. Обозначения на диаграммах потоков данных

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

4

Управление интеграцией проекта

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

На рис. 4–1 представлена общая схема следующих процессов управления интеграцией проекта, а именно:

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

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

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

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

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

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

Данные процессы взаимодействуют друг с другом и с процессами из других областей знаний (подробное описание см. в разделе 3 и Приложении А1).

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

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

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

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

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

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

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

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

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

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

4.1. Разработка устава проекта

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

Рис. 4–2. Разработка устава проекта: входы, инструменты и методы, а также выходы

Рис. 4–3. Диаграмма потоков данных разработки устава проекта

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

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

4.1.1. Разработка устава проекта: входы

4.1.1.1. Описание работ проекта

Описание работ (statement of work, SOW) проекта – это словесное описание продуктов, услуг или результатов, которые должен произвести проект. Для внутренних проектов инициатор или спонсор проекта предоставляет описание работ на основании бизнес-потребностей, требований к продукту или услуге. Для внешних проектов описание работ может быть получено от заказчика как часть документации по предложениям (например, запроса предложения, запроса информации, запроса заявок) или как часть договора. SOW отражает:

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

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

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

4.1.1.2. Бизнес-кейс

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

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

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

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

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

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

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

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

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

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

4.1.1.3. Соглашения

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

4.1.1.4. Факторы среды предприятия

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

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

• организационную культуру и структуру;

• ситуацию на рынке.

4.1.1.5. Активы процессов организации

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

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

• шаблоны (например, шаблон устава проекта);

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

4.1.2. Разработка устава проекта: инструменты и методы

4.1.2.1. Экспертная оценка

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

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

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

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

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

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

• эксперты по предметной области (subject matter experts, SME);

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

4.1.2.2. Методы организации групповой работы

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

4.1.3. Разработка устава проекта: выходы

4.1.3.1. Устав проекта

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

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

• измеримые цели проекта и соответствующие критерии успеха;

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

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

• высокоуровневые описание и границы проекта;

• высокоуровневые риски;

• укрупненное расписание контрольных событий;

• укрупненный бюджет;

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

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

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

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

4.2. Разработка плана управления проектом

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

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

Рис. 4–5. Диаграмма потоков данных разработки плана управления проектом

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

процесса является план управления проектом, который последовательно уточняется путем внесения обновлений, а также контролируется и утверждается в процессе интегрированного контроля изменений (раздел 4.5). В ходе проектов, существующих в рамках программы, необходимо создание плана управления проектом, который соответствует плану управления программой. Например, если план управления программой требует проведения советом по контролю изменений (change control board, CCB) оценки всех изменений, превысивших установленную стоимость, в плане управления проектом должен быть определен данный процесс и оговорен порог по стоимости.

4.2.1. Разработка плана управления проектом: входы

4.2.1.1. Устав проекта

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

4.2.1.2. Выходы других процессов

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

4.2.1.3. Факторы среды предприятия

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

• государственные и промышленные стандарты;

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

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

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

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

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

4.2.1.4. Активы процессов организации

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

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

• шаблон плана управления проектом, включая:

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

– руководящие указания или требования к закрытию проекта, например критерии подтверждения и приемки продуктов;

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

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

• историческую информацию и базу накопленных знаний;

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

4.2.2. Разработка плана управления проектом: инструменты и методы

4.2.2.1. Экспертная оценка

При разработке плана управления проектом экспертная оценка используется для:

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

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

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

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

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

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

4.2.2.2. Методы организации групповой работы

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

4.2.3. Разработка плана управления проектом: выходы

4.2.3.1. План управления проектом

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

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

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

• базовое расписание (раздел 6.6.3.1);

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

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

• план управления содержанием (раздел 5.1.3.1);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

изменений;

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

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

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

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

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

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

Таблица 4–1. Отличия плана управления проектом и документов проекта

4.3. Руководство и управление работами проекта

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

Рис. 4–6. Руководство и управление работами проекта: входы, инструменты и методы, а также выходы

Рис. 4–7. Диаграмма потоков данных руководства и управления работами проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3.1. Руководство и управление работами проекта: входы

4.3.1.1. План управления проектом

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

• план управления содержанием (раздел 5.1.3.1);

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

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

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

• план управления заинтересованными сторонами (раздел 13.2.3.1).

4.3.1.2. Одобренные запросы на изменения

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

4.3.1.3. Факторы среды предприятия

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

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

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

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

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

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

режиме онлайн).

4.3.1.4. Активы процессов организации

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

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

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

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

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

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

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

4.3.2. Руководство и управление работами проекта: инструменты и методы

4.3.2.1. Экспертная оценка

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

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

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

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

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

4.3.2.2. Информационная система управления проектами

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

4.3.2.3. Совещания

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

• обмен информацией;

• мозговой штурм, оценка вариантов или проектирование;

• принятие решений.

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

4.3.3. Руководство и управление работами проекта: выходы

4.3.3.1. Поставляемые результаты

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

4.3.3.2. Данные об исполнении работ

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

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

4.3.3.3. Запросы на изменения

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

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

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

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

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

4.3.3.4. Обновления плана управления проектом

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

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

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

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

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

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

• план совершенствования

процессов;

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

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

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

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

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

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

4.3.3.5. Обновления документов проекта

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

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

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

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

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

4.4. Мониторинг и контроль работ проекта

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

Рис. 4–8. Мониторинг и контроль работ проекта: входы, инструменты и методы, а также выходы

Рис. 4–9. Диаграмма потоков данных мониторинга и контроля работ проекта

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

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

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

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

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

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

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

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

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

4.4.1. Мониторинг и контроль работ проекта: входы

4.4.1.1. План управления проектом

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

• план управления содержанием (раздел 5.1.3.1);

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

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

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

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

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

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

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

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

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

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

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

• базовое расписание (раздел 6.6.3.1);

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

4.4.1.2. Прогнозы в отношении расписания

Описаны в разделе 6.7.3.2. Прогнозы в отношении расписания составляются с учетом прогресса относительно базового расписания и расчетного времени прогноза до завершения (ПДЗ). Они обычно выражаются в виде отклонения по срокам (ОСР) и индекса выполнения сроков (ИВСР). Для проектов, которые не используют управление освоенным объемом, указываются отклонения от запланированных и прогнозируемых дат финиша.

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

4.4.1.3. Прогнозы в отношении стоимости

Описаны в разделе 7.4.3.2. Прогнозы в отношении стоимости составляются с учетом прогресса относительно базового плана по стоимости и расчетного прогноза до завершения (ПДЗ). Они обычно выражаются в виде отклонения по стоимости (ОСТ) и индекса выполнения стоимости (ИВСТ). Прогноз по завершении (ППЗ) можно сравнить с бюджетом по завершении (БПЗ), чтобы определить, находится ли проект в области допустимых значений, или необходимо составление запросов на изменения. Для проектов, которые не используют управление освоенным объемом, указываются отклонения от запланированных и фактических расходов, а также прогнозируемая окончательная стоимость.

4.4.1.4. Подтвержденные изменения

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

4.4.1.5. Информация об исполнении работ

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

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

4.4.1.6. Факторы среды предприятия

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

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

• системы авторизации работ организации;

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

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

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

4.4.1.7. Активы процессов организации

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

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

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

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

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

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

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

• базу извлеченных уроков.

4.4.2. Мониторинг и контроль работ проекта: инструменты и методы

4.4.2.1. Экспертная оценка

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

4.4.2.2. Аналитические методы

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

• регрессионный анализ;

• методы группировки;

• причинный анализ;

• анализ первопричины;

• методы прогнозирования (например, динамические ряды, создание сценариев, имитация и т. д.);

• анализ характера и последствий отказов (failure mode and effect analysis, FMEA);

• анализ дерева решений (fault tree analysis, FTA);

• анализ резервов;

• анализ тенденций;

• управление освоенным объемом;

• анализ отклонений.

4.4.2.3. Информационная система управления проектами

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

4.4.2.4. Совещания

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

4.4.3. Мониторинг и контроль работ проекта: выходы

4.4.3.1. Запросы на изменения

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

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

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

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

4.4.3.2. Отчеты об исполнении работ

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

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

4.4.3.3. Обновления плана управления проектом

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

• план управления содержанием (раздел 5.1.3.1);

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

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

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

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

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

• базовое расписание (раздел 6.6.3.1);

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

4.4.3.4. Обновления документов проекта

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

• прогнозы в отношении расписания и стоимости;

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

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

4.5. Интегрированный контроль изменений

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

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

Рис. 4-10. Интегрированный контроль изменений: входы, инструменты и методы, а также выходы

Рис. 4-11. Диаграмма потоков данных интегрированного контроля изменений

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

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

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

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

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

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

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

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

4.5.1. Интегрированный контроль изменений: входы

4.5.1.1. План управления проектом

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

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

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

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

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

4.5.1.2. Отчеты об исполнении работ

Описаны в разделе 4.4.3.2. Отчеты об исполнении работ, относящиеся к процессу интегрированного контроля изменений, включают в себя доступность ресурсов, данные по расписанию и стоимости и отчеты по управлению освоенным объемом (earned value management, EVM), диаграммы сгорания задач (burnup/burndown chart).

4.5.1.3. Запросы на изменения

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

4.5.1.4. Факторы среды предприятия

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

4.5.1.5. Активы процессов организации

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

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

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

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

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

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

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

4.5.2. Интегрированный контроль изменений: инструменты и методы

4.5.2.1. Экспертная оценка

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

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

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

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

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

• эксперты по предметной области (SME);

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

4.5.2.2. Совещания

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

4.5.2.3. Инструменты контроля изменений

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

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

4.5.3. Интегрированный контроль изменений: выходы

4.5.3.1. Одобренные запросы на изменения

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

4.5.3.2. Журнал изменений

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

4.5.3.3. Обновления плана управления проектом

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

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

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

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

4.5.3.4. Обновления документов проекта

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

4.6. Закрытие проекта или фазы

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

Рис. 4-12. Закрытие проекта или фазы: входы, инструменты и методы, а также выходы

Рис. 4-13. Диаграмма потоков данных закрытия проекта или фазы

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

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

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

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

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

4.6.1. Закрытие проекта или фазы: входы

4.6.1.1. План управления проектом

Описан в разделе 4.2.3.1. План управления проектом становится соглашением между руководителем проекта и спонсором проекта, определяющим, что именно составляет завершение проекта.

4.6.1.2. Принятые поставляемые результаты

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

4.6.1.3. Активы процессов организации

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

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

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

4.6.2. Закрытие проекта или фазы: инструменты и методы

4.6.2.1. Экспертная оценка

Экспертная оценка применяется при

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

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

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

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

4.6.2.2. Аналитические методы

Описаны в разделе 4.4.2.2. Примеры аналитических методов, используемых при закрытии проекта:

• регрессионный анализ;

• анализ тенденций.

4.6.2.3. Совещания

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

4.6.3. Закрытие проекта или фазы: выходы

4.6.3.1. Передача конечного продукта, услуги или результата

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

4.6.3.2. Обновления активов процессов организации

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

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

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

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

5

Управление содержанием проекта

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

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

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

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

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

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

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

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

Данные процессы взаимодействуют друг с другом и с процессами из других областей знаний (подробное описание см. в разделе 3 и Приложении А1).

В контексте проекта термин «содержание» может обозначать:

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

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

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

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

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

5.1. Планирование управления содержанием

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

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

Рис. 5–3. Диаграмма потоков данных планирования управления содержанием

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

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

5.1.1. Планирование управления содержанием: входы

5.1.1.1. План управления проектом

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

5.1.1.2. Устав проекта

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

5.1.1.3. Факторы среды предприятия

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

• организационную культуру,

• инфраструктуру,

• управление персоналом,

• ситуацию на рынке.

5.1.1.4. Активы процессов организации

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

• политики и процедуры,

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

5.1.2. Планирование управления содержанием: инструменты и методы

5.1.2.1. Экспертная оценка

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

5.1.2.2. Совещания

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

5.1.3. Планирование управления содержанием: выходы

5.1.3.1. План управления содержанием

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

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

• процесс, который позволяет создавать ИСР из подробного описания содержания проекта;

• процесс, который определяет, как ИСР будет поддерживаться и одобряться;

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

• процесс контроля обработки запросов на изменения в отношении подробного описания содержания проекта. Этот процесс напрямую связан с процессом интегрированного контроля изменений (раздел 4.5).

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

5.1.3.2. План управления требованиями

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

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

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

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

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

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

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

5.2. Сбор требований

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

Рис. 5–4. Сбор требований: входы, инструменты и методы, а также выходы

Рис. 5–5. Диаграмма потоков данных сбора требований

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

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

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

• Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных

сторон.

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

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

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

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

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

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

5.2.1. Сбор требований: входы

5.2.1.1. План управления содержанием

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

5.2.1.2. План управления требованиями

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

5.2.1.3. План управления заинтересованными сторонами

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

5.2.1.4. Устав проекта

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

5.2.1.5. Реестр заинтересованных сторон

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

5.2.2. Сбор требований: инструменты и методы

5.2.2.1. Интервью

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

5.2.2.2. Фокус-группы

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

5.2.2.3. Семинары с участием модератора

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

Например, в области разработки программного обеспечения используются семинары с участием модератора под названием «Совместная разработка/проектирование приложений» (joint application development/design, JAD). Данные обсуждения с участием модератора сконцентрированы на том, чтобы собрать вместе бизнес-экспертов по предметной области и команду разработчиков для улучшения процесса разработки программного продукта. В производственных отраслях существует «Развертывание функций качества» (quality function deployment, QFD) – это еще один пример семинара с участием модератора, который помогает определить критически важные характеристики для разработки нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC). Затем данные потребности объективно сортируются и приоритезируются, а также устанавливаются цели для их достижения. Во время семинаров по требованиям зачастую разрабатываются пользовательские истории – краткие текстовые описания требуемой функциональности. Пользовательские истории описывают заинтересованную сторону, которая получает пользу от свойства продукта (роль), что заинтересованной стороне необходимо достичь (цель) и пользу для заинтересованной стороны (мотивацию). Пользовательские истории широко используются в рамках гибких (agile) методов.

5.2.2.4. Методы группового творчества

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

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

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

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

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

• Анализ решений на основе множества критериев. Метод,

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

5.2.2.5. Методы группового принятия решения

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

Существуют различные методы принятия группового решения, например:

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

• Большинство. Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного количества голосов.

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

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

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

5.2.2.6. Анкеты и опросы

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

5.2.2.7. Наблюдения

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

5.2.2.8. Прототипы

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

5.2.2.9. Бенчмаркинг

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

5.2.2.10. Контекстные диаграммы

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

5.2.2.11. Анализ документов

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

5.2.3. Сбор требований: выходы

5.2.3.1. Документация по требованиям

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

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

• Бизнес-требования, включая:

– цели организации и проекта для возможности отслеживания;

– бизнес-правила для исполняющей организации;

– руководящие принципы организации.

• Требования заинтересованных сторон, включая:

– воздействие на другие области

организации;

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

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

• Требования к решению, включая:

– функциональные и нефункциональные требования;

– требования соответствия технологиям и стандартам;

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

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

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

• Требования к проекту, такие как:

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

• Требования к переходу.

• Допущения, зависимости и ограничения в отношении требований.

5.2.3.2. Матрица отслеживания требований

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

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

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

• цели проекта;

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

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

• разработка продукта;

• стратегия и сценарии тестирования;

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

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

Рис. 5–6. Пример матрицы отслеживания требований

5.3. Определение содержания

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

Рис. 5–7. Определение содержания: входы, инструменты и методы, а также выходы

Рис. 5–8. Диаграмма потоков данных определения содержания

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

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

5.3.1. Определение содержания: входы

5.3.1.1. План управления содержанием

Описан в разделе 5.1.3.1. План управления содержанием – это компонент плана управления проектом, задающий действия по разработке, мониторингу и контролю содержания проекта.

5.3.1.2. Устав проекта

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

5.3.1.3. Документация по требованиям

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

5.3.1.4. Активы процессов организации

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

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

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

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

5.3.2. Определение содержания: инструменты и методы

5.3.2.1. Экспертная оценка

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

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

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

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

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

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

• эксперты по предметной области.

5.3.2.2. Анализ продукта

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

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

5.3.2.3. Формирование альтернатив

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

5.3.2.4. Семинары с участием модератора

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

5.3.3. Определение содержания: выходы

5.3.3.1. Описание содержания проекта

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

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

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

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

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

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

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

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

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

Таблица 5–1. Элементы устава проекта и описания содержания проекта

5.3.3.2. Обновления документов проекта

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

• реестр заинтересованных сторон,

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

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

5.4. Создание ИСР

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

Рис. 5–9. Создание ИСР: входы, инструменты и методы, а также выходы

Рис. 5-10. Диаграмма потоков данных создания ИСР

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

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

5.4.1. Создание ИСР: входы

5.4.1.1. План управления содержанием

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

5.4.1.2. Описание содержания проекта

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

5.4.1.3. Документация по требованиям

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

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

5.4.1.4. Факторы среды предприятия

Описаны в разделе 2.1.5. Отраслевые стандарты ИСР, имеющие отношение к характеру проекта, могут использоваться в качестве внешних справочных материалов в ходе создания ИСР. Например, в инженерных проектах можно использовать стандарт ISO/IEC 15288 «Системная инженерия. Процессы жизненного цикла систем» [6], чтобы создать ИСР для нового проекта.

5.4.1.5. Активы процессов организации

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

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

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

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

5.4.2. Создание ИСР: инструменты и методы

5.4.2.1. Декомпозиция

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

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

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

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

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

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

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

5.4.2.2. Экспертная оценка

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

Рис. 5-11. Пример декомпозиции ИСР до пакетов работ

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

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

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

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

Рис. 5-12. Пример ИСР, организованной по фазам

Рис. 5-13. Пример ИСР по основным поставляемым результатам

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

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

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

Для получения дополнительной информации по ИСР обратитесь к Практическому стандарту по иерархическим структурам работ – Второму изданию (Practice Standard for Work Breakdown Structures – Second Edition) [7]. Этот стандарт содержит конкретные отраслевые примеры шаблонов ИСР, которые могут быть адаптированы к конкретным проектам в определенных прикладных областях.

5.4.3. Создание ИСР: выходы

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

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

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

ограничений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3.2. Обновления документов проекта

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

5.5. Подтверждение содержания

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

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию (http://www.litres.ru/pages/biblio_book/?art=21239983&lfrom=931425718) на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

notes

Примечания

1

Цифры в скобках относятся к списку литературы в конце этого стандарта.