Международный Стандарт по Управлению Проектами ISO 21500:2012

Международный Стандарт по Управлению Проектами ISO 21500:2012

Утвержден Россией, США и Евросоюзом

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

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ISO/IEC (Часть 2).

Основной задачей технических комитетов является подготовка Международных стандартов. Проекты международных стандартов, принятые техническими комитетами, рассылаются организациям-членам на голосование. Для их опубликования в качестве международных стандартов требуется одобрение по меньшей мере, 75% организаций-членов, участвующих в голосовании [данный стандарт утвержден единогласно Россией, США и Евросоюзом].

Некоторые элементы этого документа могут быть объектом патентных прав. ISO не несет ответственность за идентификацию какого-либо или всех таких патентных прав.

ISO 21500 был подготовлен Проектным комитетом ISO/PC 236, управление проектами.

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

Цели стандарта ISO 21500:

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

– обеспечить руководителей проектов и членов команды проекта эталоном для сравнения с актуальными стандартами и практиками.

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

Введение (Introduction)

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

Целевой аудиторией для этого стандарта являются:

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

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

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

Общие положения

Этот международный стандарт (ISO 21500) описывает лучшие практики по управлению проектами.

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

Этот международный стандарт (ISO 21500) рассматривает проекты в контексте программ и портфелей проектов. Не представляет собой детальное руководство по управлению программами и портфелями. Разделы имеющие отношение к общему менеджменту представлены только в из связи с управлением проектами

Термины и определения

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

2.1 операция (activity)

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

2.2 область применения (application area)

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

2.3 исходные данные (baseline)

относительная основа по сравнению с которой проект осуществляется мониторинг проекта и контроль

2.4 запрос на изменения (change request)

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

2.5 конфигурационный менеджмент (configuration management)

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

2.6 контроль (control)

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

2.7 корректирующие воздействие (corrective action)

Направление по изменению направления реализации работ для возврата к запланированному

2.8 критический путь (critical path)

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

2.9 групповая динамика (group dynamics)

Описывает как группа индивидуумов взаимодействует при принятии решений или организуется для реализации задач

2.10 Лаг ( lag)

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

2.11 Лид (lead)

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

2.12 Кривая обучения (learning curve)

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

2.13 Жизненный цикл проекта (project life cycle)

установленная последовательность фаз от начала до завершения проекта.

2.14 Руководитель проекта (project manager)

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

2.15 Реестр рисков (risk register)

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

2.16 Заинтересованный участник (stakeholder)

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

2.17 Тендер (tender)

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

2.18 Словарь иерархической структуры работ (work breakdown structure dictionary)

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

3 Концепция управления проектами (Project management concepts)

3.1 Обзор (Overview)

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

 

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

Легенда: • Блоки представляют понятия управления проектами, введенные в следующих разделах

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

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

3.2 Проект (Project)

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

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

У любого проекта есть установленное начало и завершение. Обычно проект реализуется через ряд фаз. Проект начинается и завершается в соответствии с разделом 4.3.1.

3.3 Управление проектом (Project management)

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

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

3.4 Стратегия организации и проекты (Organizational strategy and projects)

3.4.1 Стратегия организации (Organizational strategy)

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

Рисунок 2 – Управление портфелем проектом от стратегии до получения преимуществ 

3.4.2 Определение возможностей и инициация проектов (Opportunity identification and project initiation)

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

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

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

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

[Данные положения ISO 21500 связаны с типовых сценарием управления портфелем проектов, описывая стыковку с будущим стандартом ISO по Портфелям проектов. ]

3.4.3 Реализация преимуществ (Benefits realisation)

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

3.5 Среда проекта (Project environment)

3.5.1 Общие положения (General)

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

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

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

3.5.2 Проекты в материнской организации (Projects within the organizational boundary)

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

Рисунок 3 – Проекты, программы и портфели проектов

3.5.2.1 Управление портфелем проектов (Project portfolio management)

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

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

3.5.2.2 Управление программой (Programme management)

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

3.6 Внешнее Руководство проектом (Project governance)

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

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

3.7 Проекты и операционная деятельность (Projects and operations)

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

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

3.8 Заинтересованные стороны и оргструктура проекта (Stakeholders and Project Organization)

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

 

Рисунок 4 – Заинтересованные стороны проекта (Project Stakeholders)

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

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

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

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

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

Внешнее управление проектом Заказчиком (Project governance) может включать в себя следующих лиц:

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

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

Рисунок 4 включает в себя следующих дополнительных заинтересованных лиц:

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

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

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

3.9 Компетенции участников проекта (Competencies of project personnel)

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

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

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

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

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

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

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

3.10 Жизненный цикл проекта (Project life cycle)

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

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

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

3.11 Ограничения проекта (Project constraints)

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

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

Некоторые ограничения могут быть такими:

• Продолжительность или целевая дата для осуществления проекта;

• Наличие бюджета проекта;

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

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

• Уровень приемлемого риска;

• Потенциальные социальные или экологические последствия проекта;

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

3.12 Взаимосвязь между концепцией и процессами (Relationship between concepts and processes)

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

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

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

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

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

4. Процессы управления проектами (Project management processes)

4.1 Применение процессов управления проектом (Project management process application)

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

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

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

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

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

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

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

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

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

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

4.2 Группы процессов и предметные группы (Process groups and subject groups)

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

Таблица 1 – Соответствие процессов управления проектами группам процессов и предметным группам

Предметные группы	Группы процессов
	Инициирование	Планирование	Исполнение	Управление	Завершение
Интеграция	4.3.2 Разработка устава проекта	4.3.3 Разработка планов проектов	4.3.4 Непосредственная работа по проекту	4.3.5 Управление проектными работами	4.3.7 Закрытие отдельной фазы или проекта
				4.3.6 Управление изменениями	4.3.8 Извлеченные уроки
Заинтересованные стороны	4.3.9 Определение заинтересованных сторон		4.3.10 Управление заинтересованными сторонами
Содержание		4.3.11 Определение содержания проекта		4.3.14 Управление содержанием проекта
		4.3.12 Создание структуры декомпозиции работ
		4.3.13 Определение состава работ
Ресурсы	4.3.15 Создание команды проекта	4.3.16 Оценка ресурсов	4.3.18 Развитие команды проекта	4.3.19 Управление ресурсами
		4.3.17 Определение организационной структуры проекта		4.3.20 Управление командой проекта
Время		4.3.21 Последовательность работ		4.3.24 Управление расписанием
		4.3.22 Оценка длительности работ
		4.3.23 Разработать расписания
Стоимость		4.3.25 Оценка затрат		4.3.27 Управление затратами
		4.3.26 Разработка бюджета
Риски		4.3.28 Определение рисков	4.3.30 Отношение к рискам	4.3.31 Управление рисками
		4.3.29 Оценка рисков
Качество		4.3.32 Плана по качеству	4.3.33 Обеспечение требований качества	4.3.34 Управление качеством
Поставки		4.3.35 Плана поставок	4.3.36 Выбор поставщиков	4.3.37 Администрирование контрактов
Коммуникации		4.3.38 План коммуникаций	4.3.39 Распространение информации	4.3.40 Управление коммуникациями

4.2.1.1 Общие положения (General)

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

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

4.2.1.2 Группа процессов инициации (Initiating process group)

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

4.2.1.3 Группа процессов планирования (Planning process group)

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

4.2.1.4 Группа процессов исполнения (Implementing process group)

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

4.2.1.5 Группа процессов контроля (Controlling process group)

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

4.2.1.6 Группа процессов завершения (Closing process group)

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

4.2.1.7 Взаимосвязи и взаимодействия групп процессов управление проектами (Project management process group interrelationships and interactions)

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

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

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

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

 

Рисунок 6 – Взаимодействие групп процессов с указанными основными входами и выходами

4.2.2 Предметные группы (Subject groups)

4.2.2.1 Основные положения (General)

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

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

4.2.2.2 Интеграция (Integration)

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

4.2.2.3 Стейкхолдеры (Stakeholder)

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

4.2.2.4 Содержание (Scope)

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

4.2.2.5 Ресурсы (Resource)

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

4.2.2.6 Сроки (Time)

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

4.2.2.7 Стоимость(Cost)

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

4.2.2.8 Риски (Risks)

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

4.2.2.9 Качество (Quality)

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

4.2.2.10 Закупки (Procurement)

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

4.2.2.11 Коммуникации (Communication)

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

4.3 Процессы (Processes)

4.3.1 Общие понятия (General)

Этот подраздел описывает каждый из процессов управления проектами в терминах цели, описания, основных входов и основных выходов. Заметьте, что в Таблицах 2 вплоть до 40, только общие основные входы и выходы, показаны без индикации их важности или последствий. Результаты (“артефакты”) инициализируют процессы, в тоже время процессы создают новые результаты для других процессов.

Некоторые относящиеся к проектам процессы могут быть завершены внешними к проектным границам как показано на Рисунке 6, через организационную политику, программы, портфели или другими подобными способами. Примеры включают подготовку предварительного технико-экономического обоснования, разработку бизнес кэйсов (бизнес планов), процесс отбора проектов до начала реальных проектных работ и усвоенные уроки из предыдущих проектов. Хотя включение или невключение этих типов процессов в проектные границы является свободным выбором для каждой организаций, для целей данного Международного Стандарта сделаны следующие предположения:

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

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

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

4.3.2 Разработка устава проекта (Develop project charter)

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

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

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

Tаблица 2 — Разработка устава проекта: основные входы и выходы

Основные Входы	Основные Выходы
Техническое задание, контракт экономическое обоснование или документы предыдущей фазы	Устав проекта

Основные входы и выходы показаны в Таблице 2.

4.3.3 Разработка планов проекта (Develop project plans)

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

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

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

Основные входы и выходы показаны в Таблице 3.

Tаблица 3 — Разработать планы проекта: основные входы и выходы

Основные Входы	Основные Выходы
Устав проекта Вспомогательные планы Усвоенные уроки с предыдущих проектов Экономическое обоснование Одобренные изменения	Проектный план (Project management plan)   Вспомогательные планы

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

4.3.4 Управление работами проекта (Direct project work)

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

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

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

Основные входы и выходы приведены в таблице 4.

Таблица 4 – Непосредственная работа по проекту: основные входы и выходы

Основные входы	Основные выходы
Планы проекта Одобренные изменения	Данные о ходе выполнения Журнал  вопросов (проблем) Извлеченные уроки

4.3.5 Контроль работ проекта (Control project work)

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

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

Основные входы и выходы приведены в таблице 5.

Таблица 5 – Управление работами по проекту: основные входы и выходы

Основные входы	Основные выходы
– Планы проекта (Project plans) – Данные о ходе выполнения (Progress data) – Измерители контроля качества (Quality control measurements) – Реестр рисков (Risk register) – Журнал вопросов (Issues log)	– Запросы на изменение (Change requests) – Прогнозы (Forecasts) – Отчеты о ходе работы (Progress reports) – Отчеты о завершении проекта (Project handover reports)

4.3.6 Контроль изменений (Control changes)

Цель Контроля изменениями – контролировать все изменения в проекте и в его результатах для формального принятия или отклонения этих изменений перед их последующим введением в силу.

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

Основные входы и выходы приведены в таблице 6.

Основные входы	Основные выходы
– Планы проекта (Project Plans) – Запросы на изменение (Change requests)	– Утвержденные изменения (Approved changes) – Журнал регистрации изменений (Change register)

4.3.7 Закрытие проекта или фазы проекта (Close project phase or project)

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

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

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

Основные входы и выходы приведены в таблице 7.

Основные входы	Основные выходы
– Отчеты о ходе выполнения работ (Progress reports) – Документация по контрактам (Contract documentation) – Акты приема–передачи (Project handover reports) – Акт выполненных работ (Project handover certificate)	– Выполненные закупки (Completed contracts) – Отчет о завершении проекта или фазы проекта (Project or phase closure report) – Высвобожденные ресурсы (Released resources)

4.3.8 Сбор извлеченных уроков (Collect lessons learned)

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

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

Основные входы и выходы приведены в таблице 8.

Основные входы	Основные выходы
– Планы проекта (Project plans) – Отчеты о выполнении работ (Progress reports) – Утвержденные изменения (Approved changes) – Извлеченные знания (Lessons learned) – Журнал проблем (Issues log) – Реестр рисков (Risk register)	– Извлеченные уроки (Lessons learned document)

4.3.9 Определение заинтересованных сторон (Identify stakeholders)

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

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

Основные входы и выходы приведены в таблице 9.

Основные входы	Основные выходы
– Устав проекта (Project charter) – Оргструктура проекта (Project organization chart)	– Реестр заинтересованных лиц (Stakeholder register)

4.3.10 Управления заинтересованными сторонами (Manage stakeholders)

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

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

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

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

Основные входы и выходы приведены в таблице 10.

Основные входы	Основные выходы
– Реестр заинтересованных сторон (Stakeholder register) – Планы проекта (Project plans)	– Запросы на изменения (Change requests)

4.3.11 Определение содержания проекта (Define scope)

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

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

Основные входы и выходы приведены в таблице 11.

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Устав проекта (Project charter) – Утвержденные изменения (Approved changes)	– Описание содержания (Scope statement) – Требования (Requirements)

4.3.12 Разработка ИСР (Create work breakdown structure)

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

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

Основные входы и выходы приведены в таблице 12.

Таблица 12 – Создание иерархической структура работ: основные входы и выходы

Основные входы	Основные выходы
– Планы проекта (Project plans) – Требования (Requirements) – Утвержденные изменения (Approved changes)	– Иерархическая структура работ (Work breakdown structure) – Словарь иерархической структуры работ (Work breakdown structure dictionary)

4.3.13 Определение работ (Define activities)

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

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

Основные входы и выходы приведены в таблице 13.

Таблица 13 – Определение работ: основные входы и выходы

Основные входы	Основные выходы
– Иерархическая структура работ (Work breakdown structure) – Словарь иерархической структуры работ (Work breakdown structure dictionary) – Планы проекта (Project plans) – Утвержденные изменения (Approved changes)	– Перечень работ (Activity list)

4.3.14 Контроль содержания (Control scope)

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

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

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

Основные входы и выходы приведены в таблице 14

Таблица 14 – Контроль содержания: основные входы и выходы

Основные входы	Основные выходы
– Данные о ходе выполнения (Progress data) – Описание содержания (Scope statement) – Иерархическая структура работа (Work breakdown structure) – Перечень работ (Activity list)	– Запросы на изменения (Change requests)

4.3.15 Утверждение команды проекта (Establish project team)

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

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

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

Основные входы и выходы приведены в таблице 15.

Таблица 15 – Создание команды проекта основные входы и выходы

Основные входы	Основные выходы
– Потребности в ресурсах (Resource requirements) – Оргструктура проекта (Project organization chart) – Наличие ресурсов (Resource availability) – Планы проекта (Project plans) – Описания ролей (Role descriptions)	– Назначения персонала (Staff assignments) – Контракты с персоналом (Staff contracts)

4.3.16 Оценка необходимых ресурсов (Estimate resources)

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

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

Основные входы и выходы приведены в таблице 16.

Таблица 16 – Оценка ресурсов: основные входы и выходы

Основные входы	Основные выходы
– Перечень работ (Activity list) – Планы проекта (Project plans) – Утвержденные изменения (Approved changes)	– Потребности в ресурсах (Resource requirements) – План ресурсов (Resource plan)

4.3.17 Определение оргструктуры проекта (Define project organization)

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

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

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

Основные входы и выходы приведены в таблице 17.

Таблица 17 – Определение оргструктуры проекта: основные входы и выходы

Основные входы	Основные выходы
– Планы проекта (Project plans) – Иерархическая структура работ (Work breakdown structure) – Потребности в ресурсах (Resource requirements) – Реестр заинтересованных сторон (Stakeholder register) – Утвержденные изменения (Approved changes)	– Описания ролей (Role descriptions) – Оргструктура проекта (Project organization chart)

4.3.18 Развитие команды проекта (Develop project team)

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

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

Основные входы и выходы приведены в таблице 18.

Таблица 18 – Разработка группы проекта: основные входы и выходы

Основные входы	Основные выходы
– Назначение персонала (Staff assignments) – Наличие ресурсов (Resource availability) – План по ресурсам (Resource plan) – Описание ролей (Role descriptions)	– Производительность команды (Team performance) – Оценки команды (Team appraisals)

4.3.19 Управление Ресурсами (Control resources)

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

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

Основные входы и выходы приведены в таблице 19.

Таблица 19 – Управление ресурсами: основные входы и выходы

Основные входы	Основные выходы
– Планы проекта (Project plans) – Назначение персонала (Staff assignments) – Наличие ресурсов (Resource availability) – Данные о ходе выполнения (Progress data) – Требования ресурсов (Resource requirements)	– Потребности в ресурсах (Change requests) – Запросы на изменение (Corrective actions) – Корректирующие действия

4.3.20 Управление командой проекта (Manage project team)

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

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

Основные входы и выходы приведены в таблице 20.

Таблица 20 – Управление группой проекта: основные входы и выходы

Основные входы	Основные выходы
– Планы проекта(Project plans) – Организация работы(Project organization chart) – Описания ролей(Role descriptions) – Данные о ходе выполнения(Progress data)	– Производительность труда сотрудников(Staff performance) – Оценки персонала(Staff appraisals) – Запросы на изменение(Change requests) – Корректирующие действия(Corrective actions)

4.3.21 Определение последовательности работ (Sequence activities)

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

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

Основные входы и выходы приведены в таблице 21.

Таблица 21 – Определение последовательности операций: основные входы и выходы

Основные входы	Основные выходы
Список операций (Activity list) Утвержденные изменения (Approved changes)	Последовательность операций (Activity sequence)

4.3.22 Оценка длительности работ (Estimate activity durations)

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

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

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

Основные входы и выходы приведены в таблице 22.

Таблица 22 – Оценка продолжительности деятельности: основные входы и выходы

Основные входы	Основные выходы
Список операций (Activity list) Потребности в ресурсах (Resource requirements) Исторические данные (Historical data) Отраслевые стандарты (Industry standards) Утвержденные изменения (Approved changes)	Оценка продолжительности операций (Activity duration estimates)

4.3.23 Разработка расписания проекта (Develop schedule)

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

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

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

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

Основные входы и выходы приведены в таблице 23.

Таблица 23 – Разработка графика: основные входы и выходы

Основные входы	Основные выходы
Последовательность операций (Activity sequence) Оценка продолжительности операций (Activity duration estimates) Ограничения расписания (Schedule constraints) Реестр рисков (Risk register) Утвержденные изменения (Approved changes)	Расписание (Schedule)

4.3.24 Управление расписанием проекта (Control schedule)

Целью управления расписанием является мониторинг отклонений от плана и принятие соответствующих мер.

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

Основные входы и выходы приведены в таблице 24.

Таблица 24 – Управление расписанием: основные входы и выходы

Основные входы	Основные выходы
– Расписание Schedule – Данные о ходе проекта Progress data – Планы проекта Project plans	– Запросы на изменение Change requests – Корректирующие действия Corrective actions

4.3.25 Оценка стоимости проекта (Estimate costs)

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

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

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

Основные входы и выходы приведены в таблице 25.

Таблица 25 – Оценка затрат: основные входы и выходы

Основные входы	Основные выходы
– Иерархическая структура работ (Work breakdown structure) – Список операций – Планы проекта (Project plans) – Утвержденные изменения (Approved changes)	– Смета расходов (Cost estimates) – План затрат (Cost plan)

4.3.26 Разработка бюджета проекта (Develop budget)

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

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

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

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

Основные входы и выходы приведены в таблице 26.

Таблица 26 – Разработка бюджета: основные входы и выходы

Основные входы	Основные выходы
– Иерархическая структура работ Work breakdown structure – Смета расходов Cost estimates – Расписание Schedule – Планы проекта Project plans – Утвержденные изменения Approved changes	– Бюджет Budget

4.3.27 Управление стоимостью проекта (Control costs)

Целью управления стоимостью проекта является мониторинг отклонений по стоимости и принятие соответствующих мер.

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

Основные входы и выходы приведены в таблице 27.

Таблица 27 – Контроль затрат: основные входы и выходы

Основные входы	Основные выходы
– Данные о ходе выполнения Progress data – Планы проекта Project plans – Бюджет Budget	– Фактические расходы Actual costs – Прогнозные расходы Forecasted costs – Запросы на изменение Change requests – Корректирующие действия Corrective actions

4.3.28 Идентификация рисков (Identify risks)

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

Это повторяющийся процесс, потому что новые риски могут стать известны или риски могут меняться в процессе прохождения проекта через его жизненный цикл. Риски с потенциальным негативным влиянием на проект называются «угрозами», в то время как риски с потенциальным положительным влияние на проект, называются “возможностями”. Все выявленные риски должны быть рассмотрены в соответствии с 4.3.30.

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

Основные входы и выходы приведены в таблице 28.

Таблица 28 – Определение рисков: основные входы и выходы

Основные входы	Основные выходы )
– Планы проекта Project plans	– Реестр рисков (Risk register

4.3.29 Оценка рисков (Assess risks)

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

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

Основные входы и выходы приведены в таблице 29.

Таблица 29 – Оценка рисков: основные входы и выходы

Основные входы	Основные выходы
– Реестр рисков Risk register – Планы проекта Project plans	– Риски, упорядоченные по приоритету Prioritised risks

4.3.30 Разработка антирисковых мероприятий (Treat risks)

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

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

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

Основные входы и выходы приведены в таблице 30.

Таблица 30 – Реагирование на риски: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Реестр рисков Risk register – Планы проекта Project plans	– Реагирование на риски Risk responses – Запросы на изменение Change requests

4.3.31 Контроль рисков (Control risks)

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

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

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

Основные входы и выходы приведены в таблице 31.

Таблица 31 – Управление рисками: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Реестр рисков Risk register – Данные о ходе выполнения Progress data – Планы проекта Project plans – Реагирование на риск Risk responses	– Запросы на изменение Change requests – Корректирующие действия Corrective actions

4.3.32 План качества (Plan quality)

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

Этот процесс включает в себя следующее:

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

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

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

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

• Объединение всей информации о качестве в плане по качеству.

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

Основные входы и выходы приведены в таблице 32.

Таблица 32 – Планирование качества: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Планы проекта Project plans – Требования к качеству Quality requirements – Утвержденные изменения Approved changes	– План по качеству Quality plan – План управления качеством Quality management plan

4.3.33 Выполнение обеспечения качества (Perform quality assurance)

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

Этот процесс включает в себя следующее:

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

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

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

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

Основные входы и выходы приведены в таблице 33.

Таблица 33 – Выполнение гарантии качества: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– План по качеству Quality plan План управления качеством Quality management plan	– Запросы на изменение Change requests

4.3.34 Выполнение контроля качества (Perform quality control)

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

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

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

• Анализ возможных причин дефектов;

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

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

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

Основные входы и выходы приведены в таблице 34.

Таблица 34 – Контроль качества: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Данные о ходе выполнения Progress data – Результаты Deliverables – План по качеству Quality plan Quality management plan	– Измерители контроля качества Quality control measurements – Верифицированные результаты Verified deliverables – Инспекционные отчеты Inspection reports – Запросы на изменение Change requests

4.3.35 План поставок (Plan procurement)

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

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

Основные входы и выходы приведены в таблице 35.

Таблица 35 – План закупок: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Планы проекта Project plans – Собственный потенциал и возможности In-house capacity and capability – Существующие контракты Existing contracts – Потребности в ресурсах Resource requirements – Реестр рисков Risk register	– План закупок Procurement plan – Список предпочитаемых поставщиков Preferred suppliers list – Решение о «производстве или покупке» Make-or-buy decision list

4.3.36 Выбор поставщиков (Select suppliers)

Целью выбора поставщиков является следующее:

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

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

• выбор поставщиков

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

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

Основные входы и выходы приведены в таблице 36.

Таблица 36 – Выбор поставщиков: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– План закупок Procurement plan – Список предпочитаемых поставщиков Preferred suppliers list – Тендеры поставщика Supplier’s tenders – Список решений «производить или покупать» Make-or-buy decision list	– Запрос на информацию, заявку, ценовое предложение, оферту или стоимость Request for information, proposal, or quotation – Контракты или заказы на поставку Contracts or purchase orders – Список выбранных поставщиков Selected suppliers list

4.3.37 Администрирование контрактов (Administer contracts)

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

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

Основные входы и выходы приведены в таблице 37.

Таблица 37 – Управление администрированием контрактов: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Контракты или заказы на поставку (Contracts or purchase orders) – Планы проекта (Project plans) – Утвержденные изменения (Approved changes) – Инспекционные отчеты (Inspection reports)	– Сертификаты (Contract certificates) – Запросы на изменение (Change requests) – Корректирующие действия (Corrective actions)

4.3.38 План коммуникаций (Plan communications)

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

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

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

Таблица 38 – План коммуникаций: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– Планы проекта(Project plans) – Реестр стейкхолдеров (Stakeholder register) – Описания ролей (Role descriptions) – Утвержденные изменения (Approved changes)	– План коммуникаций (Communication plan)

4.3.39 Распределение информации (Distribute information)

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

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

Основные входы и выходы приведены в таблице 39.

Таблица 39 – Распространение информации: основные входы и выходы

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– План коммуникаций (Communication plan) – Отчеты о ходе работы (Progress reports) – Прогнозы (Forecasts) – Неожиданные запросы (Unexpected requests)	– Распределенная информация (Distributed information)

4.3.40 Управление коммуникациями (Manage communication)

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

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

Основные входы и выходы приведены в Таблице 40

Таблица 40 – Управление коммуникациями: основные входы и выходы 

Основные входы (Primary Inputs)	Основные выходы (Primary Outputs)
– План коммуникаций (Communication plan) – Распределенная информация (Distributed information)	– Точная и своевременная информация (Accurate and timely information) – Корректирующие действия (Corrective actions)