Руководство по проектному менеджменту это

From Wikipedia, the free encyclopedia

ISO 21500, Guidance on Project Management, is an international standard developed by the International Organization for Standardization, or ISO starting in 2007 and released in 2012. It was intended to provide generic guidance, explain core principles and what constitutes good practice in project management.^[1] The ISO technical committee dealing with project management, ISO/PC 236 was held by the American National Standards Institute (ANSI) which had approved four standards that used Project Management Institute (PMI) materials, one of which was ANSI/PMI 99-001-2008, A Guide to the Project Management Body of Knowledge — 4th Edition (PMI BoK® Guide — 4th Edition).^[2]

ISO plans for this standard (21500) to be the first in a family of project management standards. ISO also designed this standard to align with other, related standards such as ISO 10005:2005 Quality management systems − Guidelines for quality plans, ISO 10006:2003 Quality management systems − Guidelines for quality management in projects, ISO 10007:2003 Quality management systems − Guidelines for configuration management, ISO 31000:2009 Risk management – Principles and guidelines.^[3]

Background[edit]

The process approach to project management developed in the 1980s, largely in Europe.^[4] The main focus of this approach is the use of structured processes throughout project execution in order to achieve its objectives.^[4] Project management then is a structured process about converting a vision into reality and the major emphasis was on developing and defining processes in order to meet project objectives.^[4] Research has demonstrated that organizational effectiveness is a direct function of the decision-making criteria and goal-centered activities embedded in processes^[5] and implicitly, a process-based approach to project management.

Project life cycles come out of this process approach to project management. In fact, several core concepts in the Project Management Body of Knowledge are based upon the process based to project management, particularly, project management processes, integration management, and the management of quality and risk.^[4]

Overview[edit]

ISO 21500 was developed to offer guidance on the concepts and processes of project management with the goal of implementing processes and best practices to improve project management performance.^[6]
While the standard describes important concepts and processes of project management it does not provide detailed guidance and general management topics are limited to relevant aspects of project management.^[7] The standard as developed by the ISO was modeled on the Project Management Institute’s Body of Knowledge (PMBoK), although there are some key differences.^[8]

The ISO project management standard is only 47 pages long and is limited to the introduction of the processes, their inputs, and their outputs.^[9] The PMI standard is more than 450 pages in length and describes processes, inputs, outputs and associated tools and techniques.^[9] Both organizations use the concept of process as an integral part of project management. ISO and PMI segregate project processes into five process groups with some minor variances in labeling.^[8] The differences between the two standards is minimal with respect to process groups and subjects/knowledge areas.^[7] The substantive difference in the two standards is with the detail and description of tools and techniques, because ISO 21500:2012 do not provide it.^[7][8] Another major change is the introduction of a new subject by ISO, namely, «stakeholder management».^[9]

Criticism[edit]

One reviewer noted that the ISO 21500 project management processes were probably more useful in a cascade approach to scope definition as an alternative to using iterative approaches and therefore less attractive for project-oriented organizations.^[9] Similarly, for the PMBoK, the major development in this coordinated approach was the requirement that a knowledge area always starts with the associated management plan.^[9]

ISO 21500 certification[edit]

Since ISO 21500:2012 is a guidance document, it is not intended to be used for certification/registration purposes.

History[edit]

Year	Description
2012	ISO 21500 (1st Edition)
2020	ISO 21502 (Reissued as a 1st Edition when ISO 21500:2021 became «Project, programme and portfolio management — Context and concepts»)

See also[edit]

• ASCE Body of Knowledge project (or ASCE BoK)
• Project management

References[edit]

Sources

• Turner, J. R. (1999). The handbook of project based management (2nd ed.). London: McGraw-Hill.
• Turner, J. R. (2006). Editorial: Towards a theory of project management: The nature of project governance and project management. International Journal of Project Management, 24, 93–95.
• Turner, J. R. (2006). Editorial: Towards a theory of project management: The functions of project management. International Journal of Project Management, 24, 187–189.
• Turner, J. R. (2006). Editorial: Towards a theory of project management: The nature of the functions of project management. International Journal of Project Management, 24, 277–279.
• Winch, G. M., The construction firm and the construction project: A transaction cost approach, Construction Management and Economics, (1989) 7, 331–345.
• Winch, G. M. Managing construction projects: An information processing approach, Oxford, UK: Blackwell Science. (2002)
• Winch, G. M. Rethinking project management: Project organizations as information processing systems? Proceedings of PMI Research Conference, 2002: Frontiers of Project Management Research and Application [CD]. Newtown Square, PA: Project Management Institute.

External links[edit]

ISO 21500:2021 Project, programme and portfolio management — Context and concepts

Перевод ISO 21500 на русский язык выполнен с общедоступного черновика ISO 21500. В настоящем переводе опущены рисунки и приложение А.

Введение

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

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

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

Данный международный стандарт не предназначен для:

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

1 Область действия

Данный международный стандарт (ISO 21500 — прим. переводчика) обеспечивает всеобъемлющее руководство по проектному управлению.

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

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

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

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

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

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 Понятия проектного управления

3.1 Обзор

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

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

3.2 Проект (project)

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

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

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

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

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

3.4 Организационная стратегия и проекты

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

Цель проекта — это измеримый признак выбранных возможностей.

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

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

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

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

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

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

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

3.4.3. Осуществление преимуществ (benefits realisation)

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

3.5. Среда проекта

3.5.1. Общие замечания

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

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

3.5.2. Проекты в рамках организации (projects within the organizational boundary)

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

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

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

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

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

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

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

3.6 Руководство (правление) проектами (project governance)

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

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

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

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

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

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

3.8 Заинтересованные лица и организационная структура проекта (stakeholders and project organization)

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

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

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

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

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

Руководство (правление) проектом может включать в себя следующее:

• Инициатор проекта (project sponsor) – направляет, обосновывает, разрешает выделение ресурсов, содействует проекту и поддерживает его. Принимает управленческие решения, решает проблемы и разрешает противоречия, с которыми не может справиться руководитель проекта;
• Координационный комитет или совет (по выбору) – вносит свой вклад в проект, обеспечивая высший уровень руководства проектом;

На рис.4 также показаны некоторые дополнительные заинтересованные лица, например:

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

3.9 Профессиональные качества персонала проекта (competencies of project personnel)

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

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

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

• Технические профессиональные качества для выполнения проектов в структурированном виде, включая проектное управление;
• процессы, определённые в стандарте ISO 21500;
• поведенческие профессиональные качества, связанные с личными отношениями внутри определённых рамок проекта;
• контекстно-зависимые профессиональные качества, связанные с управлением проекта в обстановке организации.

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

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

Проекты обычно упорядочены по этапам, определённым потребностями внешнего руководства и управления.

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

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

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

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

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

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

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

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

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

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

3.12 Отношения между понятиями и процессами (relationship between concepts and processes)

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

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

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

Стандарт ISO 21500 исследует только процессы проектного управления. Тем не менее, следует заметить, что все вышеперечисленные процессы зачастую накладываются друг на друга и взаимодействуют в проекте.

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

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

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

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

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

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

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

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

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

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

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

4.2 Проектные группы и предметные группы (process groups and subject groups)

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

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

 Примечание: Эта таблица не выстроена в хронологическом порядке

4.2.1 Группы процессов (Process groups)

4.2.1.1 Общие замечания

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

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

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

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. Группы процессов редко являются или дискретными или одноразовыми в своём применении.

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

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

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

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

4.2.2.1 Общие замечания

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

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

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 Риски (Risk)

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

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

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

4.2.2.10 Закупки (Procurement)

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

4.2.2.11 Обмен информацией (Communication)

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

4.3 Процессы

4.3.1 Общие замечания

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

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

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

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

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

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

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

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

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

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

Основные входы	Основные выходы
Проектная заявка работы, контракт, экономическое обоснование или документы от предыдущего этапа	Устав проекта

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ: В оставшейся части этого документа «Планы проекта» приведены для всех планов в пункте 4.3.3.

4.3.4 Направление работы по проекту (Direct project work)

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

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

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

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

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

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

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

4.3.5 Управление работой по проекту (Control project work)

Назначение процесса «Управление работой по проекту» состоит в обеспечении того, что задачи проекта завершены комплексным способом в соответствии с планами по проекту.

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

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

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

Основные входы	Основные выходы
Планы по проекту Данные по ходу работ Показатели управления качеством Реестр рисков Журнал вопросов	Запросы на изменения Прогнозы Отчёты по ходу работ Отчёты по сдаче проекта

4.3.6 Управление изменениями (Control changes)

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

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

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

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

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

Таблица 6 — Управление изменениями: основные входы и выходы

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

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

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

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

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

Таблица 7 — Закрытие этапа проекта или проекта: основные входы и выходы

Основные входы	Основные выходы
Отчёты по ходу работ Документация по контракту Отчёты по передаче проекта Сертификат по передаче проекта	Завершённые контракты Отчёт о закрытии проекта или этапа Высвобожденные ресурсы

4.3.8 Сбор уроков на будущее (Collect lessons learned)

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

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

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

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

Таблица 8 — Сбор уроков на будущее: основные входы и выходы

Основные входы	Основные выходы
Планы по проекту Отчёты по ходу работ Одобренные изменения Уроки на будущее (оргвыводы) Журнал вопросов Реестр рисков	Документ «Уроки на будущее»

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

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

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

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

Таблица 9 — Определение заинтересованных лиц: основные входы и выходы

Основные входы	Основные выходы
Устав проекта Оргструктура организации-проектанта	Реестр заинтересованных лиц

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

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

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

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

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

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

Таблица 10 — Управление заинтересованными лицами: основные входы и выходы

Основные входы	Основные выходы
Реестр заинтересованных лиц Планы по проекту	Запросы на изменения

4.3.11 Определение области действия (Define scope)

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

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

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

Таблица 11 — Определение области действия: основные входы и выходы

Основные входы	Основные выходы
Устав проекта Одобренные изменения	Отчёт по области действия Требования

4.3.12 Создание структуры декомпозиции работ (Create work breakdown structure)

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

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

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

Таблица 12 — Создание структуры декомпозиции работ: основные входы и выходы

Основные входы	Основные выходы
Планы по проекту Требования Одобренные изменения	Структура декомпозиции работ Словарь структуры декомпозиции работ

4.3.13 Определение задач (Define activities)

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

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

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

Таблица 13 — Определение задач: основные входы и выходы

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

4.3.14 Управление областью действия (Control scope)

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

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

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

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

Таблица 14 — Управлять областью действия: основные входы и выходы

Основные входы	Основные выходы
Данные по ходу работ Отчёт по области действия Структура декомпозиции работ Список задач	Запросы на изменения

4.3.15 Создание команды проекта (Establish project team)

Назначение процесса «Создание команды проекта» состоит в получении трудовых ресурсов, необходимых для завершения проекта.

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

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

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

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

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

4.3.16 Оценка ресурсов (Estimate resources)

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

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

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

Основные входы	Основные выходы
Список задач Планы по проекту Одобренные изменения	Требования по ресурсам План по ресурсам

4.3.17 Определение организации проекта (Define project organization)

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

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

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

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

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

Основные входы	Основные выходы
Планы по проекту Структура декомпозиции работ Требования по ресурсам Реестр заинтересованных лиц Одобренные изменения	Описания ролей Оргструктура организации-проектанта

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

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

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

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

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

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

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

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

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

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

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

Основные входы	Основные выходы
Планы по проекту Кадровые назначения Доступность ресурсов Данные по ходу работ Требования по ресурсам	Запросы на изменения Меры по устранению несоответствий

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

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

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

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

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

Основные входы	Основные выходы
Планы по проекту Оргструктура организации-проектанта Описания ролей Данные по ходу работ	Работа персонала Оценка деятельности сотрудников Запросы на изменения Меры по устранению несоответствий

4.3.21 Выстраивание последовательности задач (Sequence activities)

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

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

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

Таблица 21 — Выстраивание последовательности задач: основные входы и выходы

Основные входы	Основные выходы
Список задач Одобренные изменения	Последовательность задач

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

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

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

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

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

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

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

4.3.23 Разработка графика (Develop schedule)

Назначение процесса «Разработка графика» состоит в расчёте времени начала и завершения задач проекта, а также в установлении исходного графика проекта от начала и до конца.

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

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

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

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

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

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

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

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

Назначение процесса «Управление графиком» заключается в отслеживании отклонений от графика и принятии соответствующих мер.

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

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

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

Основные входы	Основные выходы
График Данные по ходу работ Планы по проекту	Запросы на изменения Меры по устранению несоответствий

4.3.25 Оценка затрат (Estimate costs)

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

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

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

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

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

Основные входы	Основные выходы
Структура декомпозиции работ Планы по проекту Одобренные изменения	Смета затрат План по затратам

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

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

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

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

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

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

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

Основные входы	Основные выходы
Структура декомпозиции работ Смета затрат График Планы по проекту Одобренные изменения	Бюджет

4.3.27 Управление затратами (Control costs)

Назначение процесса «Управление затратами» состоит в отслеживании отклонений по затратам и принятии соответствующих мер.

Процесс «Управление затратами» должен быть сосредоточен на определении текущего состояния объёма затрат по проекту, сравнивая их с исходным объёмом затрат, чтобы определить любые отклонения, прогнозируя объём затрат по проекту при завершении, осуществляя соответствующие предупредительные меры или меры по устранению несоответствий, чтобы избежать неблагоприятных финансовых последствий. Все изменения в исходных затратах должны осуществляться посредством процесса «Управление затратами»; смотрите пункт 4.3.6. После того, как работа началась, накапливаются данные по выполнению, включая запланированные расходы, фактические расходы и ожидаемые расходы при завершении. Чтобы оценить освоенный объём затрат необходимо накопить данные по планированию, такие как достигнутые успехи в области запланированных задач, прогнозируемые даты завершения текущих и будущих задач. Отклонения могут возникать из-за плохого планирования, непредвиденных изменений области действий, технических проблем, сбоев оборудования или других внешних, экзогенных факторов, таких как затруднения у поставщиков. Независимо от причины, корректирующие действия требуют или изменения величины исходных затрат или разработки краткосрочного плана восстановления.

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

Таблица 27 — Управление затратами: основные входы и выходы

Основные входы	Основные выходы
Данные по ходу работы Планы по проекту Бюджет	Фактические затраты Прогнозируемые затраты Запросы на изменения Меры по устранению несоответствий

4.3.28 Выявление рисков (Identify risks)

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

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

Риски с возможным отрицательным влиянием на проект называются «угрозами», а риски с возможным положительным влиянием – «возможностями». По всем выявленным рискам следует принять меры согласно критериям, описанным в процессе «Обработка рисков»; смотрите пункт 4.3.30.

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

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

Таблица 28 — Выявление рисков: основные входы и выходы

Основные входы	Основные выходы
Планы по проекту	Реестр рисков

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

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

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

Оценка рисков – непрерывный процесс на протяжении всего проекта посредством процесса «Управление рисками»; смотрите пункт 4.3.31. Тенденции могут указать на необходимость для больших или меньших действий по управлению рисками.

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

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

Основные входы	Основные выходы
Реестр рисков Планы по проекту	Расставленные по приоритетам риски

4.3.30 Обработка рисков (Treat risks)

Назначение процесса «Обработка рисков» состоит в разработке вариантов и определении действий в целях расширения возможностей и снижения угроз для целей проекта

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

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

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

Таблица 30 — Обработка рисков: основные входы и выходы

Основные входы	Основные выходы
Реестр рисков Планы по проекту	Ответные действия на риски Запросы на изменения

4.3.31 Управление рисками (Control risks)

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

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

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

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

Основные входы	Основные выходы
Реестр рисков Данные по ходу проекта Планы по проекту Ответные действия на риски	Запросы на изменения Меры по устранению несоответствий

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

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

Процесс «Планирование качества» включает в себя:

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

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

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

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

Основные входы	Основные выходы
Планы по проекту Требования по качеству Одобренные изменения	План по качеству План по управлению качеству

4.3.33 Обеспечение качества (Quality assurance)

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

Процесс «Обеспечение качества» включает в себя:

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

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

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

Таблица 33 — Обеспечение качества: основные входы и выходы

Основные входы	Основные выходы
План по качеству План по управлению качеством	Запросы на изменения

4.3.34 Управление качеством (Perform quality control)

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

Процесс «Управление качеством» следует применять в течение всего жизненного цикла проекта и включает в себя:

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

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

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

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

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

Основные входы	Основные выходы
Данные по ходу работ Результаты План по качеству План по управлению качеством	Показатели управления качеством Проверенные результаты Отчёты по обследованиям Запросы на изменения

4.3.35 Планирование закупок (Plan procurement)

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

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

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

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

Основные входы	Основные выходы
Планы по проекту Свои мощности и возможности Существующие контракты Потребности в ресурсах Реестр рисков	План закупок Список предпочтительных поставщиков Список решений «Делать-самим-или-купить»

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

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

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

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

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

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

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

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

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

«Администрирование контракта» начинается с выпуска согласованной документации по контракту и заканчивается с закрытием контракта.

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

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

Основные входы	Основные выходы
Контракты или заказы на покупку Планы по проекту Утверждённые изменения Отчёты по проверке	Сертификаты контрактов Запросы на изменения Меры по устранению несоответствий

4.3.38 Планирование обмена информацией (Plan communications)

Назначение процесса «Планирование обмена информацией» состоит в определении информации и обмена информации, необходимых для потребностей заинтересованных лиц проекта.

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

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

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

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

Таблица 38 — Планирование обмена информацией: основные входы и выходы

Основные входы	Основные выходы
Планы по проекту Реестр заинтересованных лиц Описания ролей Утверждённые изменения	План обмена информацией

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

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

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

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

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

Основные входы	Основные выходы
План обмена информацией Доклады о ходе работы Прогнозы Неожиданные запросы	Распределяемая информация

4.3.40 Управление обменом информацией (Manage communication)

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

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

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

Таблица 40 — Управление обменом информацией: основные входы и выходы

Основные входы	Основные выходы
План обмена информацией Распределяемая информация	Точная и своевременная информация Меры по устранению несоответствий

Примечания переводчика

1. В данный русский перевод ISO 21500 не включены иллюстрации и приложения.

2. В декабре 2014 года появился ещё и официальный русский перевод ISO 21500 2012 от Росстандарта —  ГОСТ Р ИСО 21500 – 2014 «Руководство по проектному менеджменту».

3. Скачать ISO 21500 отдельным документом с данного сайта пока нельзя, но можно копировать и использовать с сайта http://MConLab.com

Перевод выполнен Д. М. Литовкой

________________________________________________________________________________________________

________________________________________________________________________________________________

Оглавление

1.      ВВЕДЕНИЕ

2.      ВЛИЯНИЕ ОРГАНИЗАЦИИ И ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА

3.      ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТОМ

4.      УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА

5.      УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

6.      УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА

7.      УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА

8.      УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА

9.      УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА

10.        УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ ПРОЕКТА

11.        УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА

12.        УПРАВЛЕНИЕ ЗАКУПКАМИ ПРОЕКТА

13.        УПРАВЛЕНИЕ ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ ПРОЕКТА

1.    ВВЕДЕНИЕ

Проект — это
временное предприятие, направленное на создание уникального продукта, услуги
или результата.

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

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

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

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

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

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

Эти 5 групп процессов следующие:

·       
инициация,

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

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

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

·       
закрытие.

Ограничений проекта:

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

·       
качество,

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

·       
бюджет,

·       
ресурсы,

·       
риски.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компетенции РП:

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

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

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

Навыки РП:

·       
лидерство,

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

·       
мотивация,

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

·       
влияние,

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

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

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

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

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

·       
коучинг.

2.    ВЛИЯНИЕ
ОРГАНИЗАЦИИ И ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА

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

·       
процессы и процедуры

·       
корпоративная база знаний

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все проекты могут иметь следующую структуру жизненного
цикла:

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

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

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

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

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

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

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

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

3.    ПРОЦЕССЫ
УПРАВЛЕНИЯ ПРОЕКТОМ

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

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

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

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

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

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

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

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

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

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

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

Группы процессов не
являются фазами жизненного цикла проекта!

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

Следующие руководящие указания сводят к минимуму
недопонимание и помогают команде проекта использовать надлежащую терминологию:

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

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

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

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

·       
управление интеграцией проекта,

·       
управление содержанием проекта,

·       
управление сроками проекта,

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

·       
управление качеством проекта,

·       
управление человеческими ресурсами проекта,

·       
управление коммуникациями проекта,

·       
управление рисками проекта,

·       
управление закупками проекта,

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

4.    УПРАВЛЕНИЕ
ИНТЕГРАЦИЕЙ ПРОЕКТА

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

Устав проекта содержит:

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

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

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

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

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

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

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

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

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

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

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

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

Описание работ
(statement of work, SOW) проекта — это словесное описание продуктов, услуг или
результатов, которые должен произвести проект.

SOW отражает:

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

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

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

Бизнес-кейс

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

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

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

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

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

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

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

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

Соглашения

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

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

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

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

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

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

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

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

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

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

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

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

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

·       
базовый план по содержанию;

·       
базовое расписание;

·       
базовый план по стоимости.

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

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

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

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

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

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

·       
план совершенствования процессов;

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

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

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

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

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

Среди прочего, план управления
проектом также может включать следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.    УПРАВЛЕНИЕ
СОДЕРЖАНИЕМ ПРОЕКТА

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

В контексте проекта
термин «содержание» может обозначать:

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

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

Классы требований:

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

·       
Требования
заинтересованных сторон, описывающие потребности заинтересованной стороны
или группы заинтересованных сторон.

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

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

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

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

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

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

6.    УПРАВЛЕНИЕ
СРОКАМИ ПРОЕКТА

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

Типы зависимости
операций:

·       
Финиш-старт (finish-start, FS). Логическая
связь, при которой старт последующей операции зависит от финиша предшествующей
операции. Пример: церемония награждения (последующая операция) не может быть
начата, пока не закончится гонка предшествующая операция).

·       
Финиш-финиш (finish-finish, FF). Логическая
связь, при которой финиш последующей операции зависит от финиша предшествующей
операции. Пример: создание документа (предшествующая операция) должно быть закончено
до завершения его правки (последующая операция).

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

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

Оценка по трем точкам

Точность оценок
длительности операций по одной точке может быть улучшена путем рассмотрения неопределенностей
оценок и рисков. Данная концепция происходит из метода оценки и анализа
программ (program evaluation and review technique, PERT). Для определения
приблизительного диапазона длительности операции PERT использует три оценки:

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

·       
Оптимистичная
(tO). Длительность операции основывается на анализе наиболее благоприятного
сценария для операции.

·       
Пессимистичная
(tP). Длительность операции основывается на анализе наиболее
неблагоприятного сценария для операции.

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

Формулы:

·       
Треугольное
распределение. tE = (tO + tM + tP) / 3

·       
Бета-распределение
(из традиционного метода PERT). tE = (tO + 4tM + tP) / 6

Метод критического пути

Метод критического пути
— метод, используемый для оценки минимальной длительности проекта и определения
степени гибкости расписания на логических путях в сети в рамках модели
расписания. Метод анализа сети расписания позволяет рассчитать даты раннего
старта и финиша, а также даты позднего старта и финиша для всех операций без
учета ресурсных ограничений путем проведения анализа прямого и обратного
прохода по сети проекта, как показано на рис. 6-18. В данном примере самый
длительный путь включает в себя операции A, C и D, и поэтому последовательность
A-C-D является критическим путем. Критический путь — это последовательность операций,
представляющая собой самый длительный путь в расписании проекта, который
определяет самую короткую возможную длительность проекта. Полученные даты
раннего старта и финиша не обязательно являются расписанием проекта; они скорее
указывают периоды времени, в рамках которых может быть выполнена операция,
используя параметры, введенные в модель расписания, связанные с длительностью
операций, логическими связями, опережениями, задержками и другими известными
ограничениями. Метод критического

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

Метод критической цепи

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

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

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

7.    УПРАВЛЕНИЕ
СТОИМОСТЬЮ ПРОЕКТА

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

Управление освоенным
объемом

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

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

·       
Плановый объем. Плановый объем (ПО) —
авторизованный бюджет, выделенный на запланированные работы. Это авторизованный
бюджет, выделенный для работы, которую необходимо выполнить в рамках операции
или компонента иерархической структуры работ, за исключением управленческого
резерва. Данный бюджет распределяется по фазам в жизненном цикле проекта, но в
определенный момент запланированный объем определяет физическую работу, которая
должна была быть выполнена. Совокупный ПО иногда называется базовым планом
исполнения (performance measurement baseline, PMB). Общая величина
планового объема проекта также известна как бюджет по завершении (БПЗ).

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

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

Также осуществляется мониторинг отклонений от
одобренного базового плана:

·       
Отклонение по срокам. Отклонение по
срокам (ОСР) — показатель исполнения расписания, выражаемый как разница между
освоенным объемом и плановым объемом. Количество времени, на которое проект
отстает от запланированной даты поставки или опережает ее в определенный момент
времени. Это измерение исполнения расписания проекта. Значение его равно
освоенному объему (ОО) за вычетом планового объема (ПО). Отклонение по срокам в
методе EVM представляет собой метрику, полезную тем, что она
демонстрирует, когда проект отстает по срокам от своего базового плана или
когда он опережает его. Отклонение по срокам в EVM в конечном итоге будет
равно нулю при завершении проекта, так как все плановые объемы к тому времени
должны быть освоены. Отклонение по срокам лучше всего использовать вместе с
составлением расписания по методу критического пути (CPM) и управлением
рисками. Формула: ОСР = ОО – ПО

·       
Отклонение по стоимости. Отклонение по
стоимости (ОСТ) — сумма дефицита или излишка бюджета в определенный момент
времени, выражаемая как разница между освоенным объемом и фактической стоимостью.
Это измерение эффективности выполнения проекта по стоимости. Оно равно
освоенному объему (ОО) за вычетом фактической стоимости (ФС). Отклонение по
стоимости в конце проекта будет равно разнице между бюджетом по завершении
(БПЗ) и фактически израсходованной суммой. ОСТ чрезвычайно важно, так как оно
демонстрирует связь между физическим исполнением и израсходованными средствами.
Отрицательное ОСТ зачастую невозместимо для проекта. Формула: ОСТ = ОО –
ФС.

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

·       
Индекс выполнения сроков. Индекс
выполнения сроков (ИВСР) — показатель эффективности расписания, выражаемый как
соотношение освоенного объема к плановому объему. С помощью него измеряется,
насколько эффективно команда проекта использует свое время. Иногда он
используется вместе с индексом выполнения стоимости (ИВСТ) для прогнозирования
окончательных оценок завершения проекта. Значение ИВСР меньше 1,0 указывает на
то, что выполнено меньше работ, чем было запланировано. Значение ИВСР больше
1,0 указывает на то, что выполнено больше работ, чем было запланировано. Так
как ИВСР измеряет все работы проекта, также необходимо проанализировать
исполнение на критическом пути, чтобы определить, будет проект завершен до или
после своей плановой даты финиша. ИВСР равен отношению ОО к ПО. Формула:
ИВСР = ОО/ПО

·       
Индекс выполнения стоимости. Индекс
выполнения стоимости (ИВСТ) — показатель эффективности ресурсов, включенных в
бюджет, по стоимости, выражаемый как соотношение освоенного объема к
фактической стоимости. Он считается наиболее важной метрикой EVM и
измеряет стоимостную эффективность выполненной работы. Значение ИВСТ меньше 1,0
указывает на перерасход средств для выполненной работы. Значение ИВСТ больше
1,0 указывает на недоосвоение средств при исполнении на конкретную дату. ИВСР
равен отношению ОО к ФС. Индексы полезны для определения статуса проекта, а
также предоставляют основу для оценки итоговых сроков и стоимости проекта. Формула:
ИВСТ = ОО/ФС

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

Прогнозирование

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

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

ППЗ обычно рассчитываются как фактическая стоимость,
учтенная для завершенных работ, плюс прогноз до завершения (ПДЗ) оставшихся
работ. На команду проекта возложена обязанность прогнозировать, с чем она может
столкнуться во время выполнения ПДЗ, на основании имеющегося в данный момент
опыта. Метод EVM хорошо работает вместе с прогнозами требуемого ППЗ,
разработанными вручную. Наиболее широко используемым подходом прогнозирования ППЗ
является ручное суммирование «снизу вверх», проводимое руководителем проекта и
командой проекта.

Метод ППЗ «снизу вверх», используемый руководителем
проекта, основан на учтенной фактической стоимости и опыте, полученном на
выполненных работах, и требует построения нового прогноза до завершения в
отношении оставшихся работ проекта. Формула: ППЗ = ФС + ПДЗ «снизу вверх».

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

·       
ППЗ для
работ ПДЗ, выполненных по заложенным в бюджет ставкам. Данный метод ППЗ
использует фактическое исполнение проекта на конкретную дату (благоприятное или
неблагоприятное), представленное фактической стоимостью, и предсказывает, что
все будущие работы ПДЗ будут выполнены по заложенным в бюджет ставкам. В тех
случаях, когда фактическое исполнение неблагоприятно, допущение, что будущее исполнение
улучшится, должно быть принято только в том случае, если это подтверждается
анализом рисков проекта. Формула: ППЗ = ФС + (БПЗ – ОО)

·       
ППЗ для работ
ПДЗ, выполненных с текущим ИВСТ. Этот метод допускает, что проект
продолжится в будущем так же, как он протекал до этого момента. Допускается,
что работы ПДЗ будут выполняться на том же уровне кумулятивного индекса
выполнения стоимости (ИВСТ), какой был достигнут в проекте к этому моменту. Формула:
ППЗ = БПЗ/ИВСТ

·       
ППЗ для
работ ПДЗ с учетом обоих факторов ИВСР и ИВСТ. В данном прогнозе работы ПДЗ
будут выполняться с эффективностью, которая учитывает индексы выполнения как
стоимости, так и сроков. Данный метод наиболее полезен в случае, когда одним из
факторов, влияющих на ПДЗ, является расписание проекта. Вариации данного метода
рассматривают ИВСТ и ИВСР в различных соотношениях (например, 80/20, 50/50 или
в других пропорциях), в соответствии с мнением руководителя проекта. Формула:
ППЗ = ФС + [(БПЗ – ОО)/(ИВСТ x ИВСР)]

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

Индекс
производительности до завершения (ИПДЗ)

Индекс производительности до завершения (ИПДЗ) —
расчетный показатель эффективности выполнения проекта по стоимости, который
необходимо достичь с оставшимися ресурсами, чтобы добиться установленного
управленческого показателя, выражаемого в виде отношения стоимости выполнения
оставшейся части работ к оставшемуся бюджету. ИПДЗ представляет собой
вычисляемый индекс выполнения стоимости, который необходимо обеспечить на
оставшихся работах для достижения определенной управленческой цели, такой как
БПЗ или ППЗ. Если становится очевидным, что БПЗ больше не является
реалистичным, руководитель проекта должен рассмотреть ППЗ. После одобрения ППЗ
может заменить БПЗ при расчете ИПДЗ. Формула для ИПДЗ, основанного на БПЗ: (БПЗ
– ОО)/(БПЗ – ФС). ИПДЗ концептуально представлен на рисунке ниже. Формула для
ИПДЗ показана в левом нижнем углу — оставшаяся работа (определена как БПЗ минус
ОО), деленная на оставшиеся средства (которые могут рассчитываться либо как БПЗ
минус ФС, либо как ППЗ минус ФС).

Если кумулятивный ИВСТ ниже базового плана (как
показано на рисунке ниже), все будущие работы по проекту немедленно должны
выполняться в соответствии с ИПДЗ (БПЗ) (что отражено в верхней линии рисунке
ниже), чтобы оставаться в рамках авторизованного БПЗ. Суждение о том, является
ли данный уровень исполнения достижимым, принимается на основе ряда соображений,
включая риски, расписание и техническое исполнение. Этот уровень исполнения
изображен в виде линии ИПДЗ (ППЗ). Формула для ИПДЗ, основанного на ППЗ: (БПЗ –
ОО)/(ППЗ – ФС). Формулы EVM представлены в таблице ниже.

Анализ
исполнения

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

·       
Анализ
отклонений. Анализ отклонений при использовании в EVM — это разъяснение
(причина, влияние и корректирующие воздействия) отклонений для стоимости (ОСТ =
ОО – ФС), расписания (ОСР = ОО – ПО) и отклонения по завершении (ОПЗ = БПЗ –
ППЗ). Наиболее часто анализируются отклонения по стоимости и по срокам. Для
проектов, в которых не применяется управление освоенным объемом, может быть
выполнен аналогичный анализ отклонений путем сравнения запланированной
стоимости операции с фактической стоимостью операции для определения отклонений
фактического исполнения проекта от базового плана по стоимости. Дальнейший
анализ может быть выполнен для определения причины и степени отклонения от базового
расписания и необходимых корректирующих воздействий или предупреждающих
действий. Измерения выполнения стоимости используются для оценки величины
отклонения от первоначального базового плана по стоимости. Важные аспекты
управления стоимостью проекта включают в себя определение причины и степени отклонения
относительно базового плана по стоимости и принятие решений о необходимости корректирующих
воздействий или предупреждающих действий. По мере выполнения все большего
объема работ процентный диапазон допустимых отклонений будет иметь тенденцию к
уменьшению.

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

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

8.    УПРАВЛЕНИЕ
КАЧЕСТВОМ ПРОЕКТА

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

Качество и сорт — это концептуально различные
понятия. Качество как поставляемый выход или результат — это «степень
соответствия совокупности присущих характеристик требованиям» (ISO 9000) [10].
Сорт как конструктивный замысел — это категория, присваиваемая поставляемым
результатам, имеющим одно и то же функциональное назначение, но различные
технические характеристики. Руководитель проекта и команда управления проектом
отвечают за достижение компромиссных решений в отношении обеспечения требуемых
уровней как качества, так и сорта. Уровень качества, который не отвечает требованиям к качеству, — это всегда
проблема, а низкий сорт может не быть проблемой.

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

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

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

·       
Постоянное
совершенствование. Цикл «планирование-выполнение-проверка-действие»
(plan-do-check-act, PDCA) — модель, описанная Шухартом и усовершенствованная
Демингом, — является основой для улучшения качества. Кроме того, инициативы по
улучшению качества, такие как всеобщее управление качеством (Total Quality
Management, TQM), методика «шести сигм» и совместное применение методики «шести
сигм» и бережливого производства (Lean Six Sigma), могут улучшить качество
управления проектом, а также качество продукта проекта. Среди моделей
совершенствования процессов можно привести модель качества Малкольма Болдриджа,
модель зрелости организационного управления проектами (Organizational Project
Management Maturity Model, OPM3®) и комплексную модель производительности и
зрелости (Capability Maturity Model Integrated, CMMI®).

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

·       
Стоимость
качества (cost of quality, COQ). Стоимость качества — это общая стоимость
работы над соответствием и работы над несоответствием требованиям, которая
должна быть выполнена в качестве компенсационного усилия, поскольку при первой
попытке выполнения этой работы существует потенциальная возможность, что
какая-то часть требуемого объема работ может быть выполнена или была выполнена
неправильно. Затраты на выполнение работ по обеспечению качества могут
возникать на протяжении всего жизненного цикла поставляемого результата.
Например, решения, принятые командой проекта, могут повлиять на операционные
затраты, связанные с использованием выполненного поставляемого результата.
Затраты, связанные с обеспечением качества после закрытия проекта, могут
возникать в результате возвратов продуктов, претензий по гарантии и кампаний по
отзыву продукции. Таким образом, вследствие временного характера проекта и
потенциальной выгоды, которая может быть получена в результате снижения
послепроектной стоимости качества, спонсирующие организации могут принять
решение об инвестировании средств в улучшение качества продукта. Данные
инвестиции, как правило, делаются в области работы над соответствием
требованиям с целью предотвращения дефектов или снижения стоимости дефектов
путем инспекции несоответствующих требованиям единиц продукции. Более того,
вопросы, связанные с постпроектной COQ, должны решаться в процессе управления
программой и управления портфелем, например офисы управления проектами,
программами и портфелями должны применять соответствующие методы анализа,
шаблоны и способы выделения финансовых средств для этой цели.

Семь основных
инструментов качества

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

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

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

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

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

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

·       
Контрольные
карты используются для определения того, является ли процесс стабильным или
нет и характеризуется ли он предсказуемым исполнением. Нижние и верхние
границы, заданные спецификацией, основаны на требованиях, закрепленных в
соглашении. Они отражают максимальные и минимальные допустимые значения. Могут
налагаться штрафы, связанные с выходом значений за границы, заданные спецификацией.
Верхняя и нижняя контрольные границы отличаются от границ, заданных
спецификацией. Контрольные границы устанавливаются с использованием стандартных
статистических расчетов и принципов с целью окончательного определения
естественной возможности стабилизации процесса. Руководитель проекта и
соответствующие заинтересованные стороны могут использовать статистически
рассчитанные контрольные границы для определения точек, в которых будут
предприниматься корректирующие воздействия с целью предотвращения
неестественного исполнения. Целью корректирующего воздействия, как правило,
является сохранение естественной устойчивости стабильного и действенного процесса.
Для повторяющихся процессов контрольные границы обычно составляют ± 3 сигмы от
среднего значения процесса, которое было установлено на 0. Процесс считается
вышедшим из-под контроля в том случае, если: (1) точка данных находится вне
контрольных границ; (2) семь последовательных точек находятся выше средней
линии; или (3) семь последовательных точек находятся ниже средней линии.
Контрольные карты могут быть использованы для контроля различных типов выходных
переменных. Хотя наиболее часто контрольные карты используются для отслеживания
повторяющихся операций, требуемых для производства промышленных изделий, они
также могут использоваться для контроля отклонений по стоимости и расписанию,
объема и частоты изменений содержания или иных управленческих результатов, что
помогает определить, находятся ли процессы управления проектом под контролем.

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

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

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

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

·       
Диаграммы
процесса осуществления программы (process decision program charts, PDPC).
Используются для понимания цели относительно действий, предпринимаемых для
достижения цели. PDPC — полезный метод для планирования с учетом возможных
потерь, так как он помогает командам предвидеть промежуточные шаги, которые
могут препятствовать достижению цели.

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

·       
Древовидные
диаграммы. Также известные как систематические диаграммы, которые могут
использоваться для отображения декомпозиции иерархий, таких как ИСР,
иерархическая структура рисков (risk breakdown structure, RBS) и организационная структура работ (organizational breakdown structure,
OBS). В процессе
управления проектом древовидные диаграммы полезны для визуализации отношений
типа «родитель – потомок» в любой иерархии декомпозиции, которая использует
систематический набор правил для определения отношений подчиненности.
Древовидные диаграммы могут быть горизонтальными (например, иерархическая
структура рисков) или вертикальными (например, иерархия команды или OBS).
Поскольку древовидные диаграммы делают возможным создание вложенных
ответвлений, которые заканчиваются в одной точке принятия решения, они полезны
в качестве деревьев решений для определения ожидаемой ценности ограниченного
числа родственных отношений, систематически представляемых в виде диаграммы.

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

·       
Диаграммы
сети операций. Ранее известные как стрелочные диаграммы. Они включают в
себя такие форматы диаграммы сети, как операции на дугах (activity on arrow,
AOA) и наиболее часто используемый формат операции в узлах (activity on node, AON). Диаграммы сети операций
используются с методами составления расписания проекта, такими как метод оценки
и анализа программ (PERT), метод критического пути (CPM) и метод диаграмм
предшествования (PDM).

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

9.    УПРАВЛЕНИЕ
ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА

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

Организационные
диаграммы и должностные инструкции

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

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

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

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

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

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

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

·       
Организационные диаграммы проекта.
Организационная диаграмма проекта — это графическое представление состава
команды проекта и отношений подотчетности между ее членами. В зависимости от
требований проекта она может быть формальной или неформальной, подробной или
обобщенной. Например, организационная диаграмма проекта для команды
реагирования на чрезвычайные ситуации, состоящей из 3 000 человек, будет
значительно более подробной, чем организационная диаграмма внутреннего проекта
с командой в 20 человек.

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

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

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

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

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

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

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

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

Одна из моделей, используемых для описания развития команды
— это Tuckman ladder (Tuckman, 1965; Tuckman & Jensen, 1977), которая
включает пять стадий развития, через которые должны пройти команды. Обычно эти
стадии наступают по порядку, но нередко команда может «застрять» на
определенной стадии или вернуться на более раннюю. В проектах, члены команд
которых ранее работали вместе, определенные стадии могут быть пропущены.

·       
Формирование.
На данной стадии команда собирается вместе и узнает о проекте и о своих
формальных ролях и сферах ответственности в нем. Члены команды на данной фазе,
как правило, независимы друг от друга и не особенно открыты.

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

·       
Урегулирование.
На стадии урегулирования члены команды начинают работать вместе и подстраивают
свои рабочие привычки и модели поведения так, чтобы содействовать командной
работе. Члены команды учатся доверять друг другу.

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

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

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

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

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

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

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

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

·       
Принуждение/указания.
Лоббирование чьей-либо точки зрения за счет других, предлагая только решения
«один выиграл — все проиграли», обычно со стороны позиции власти, чтобы
разрешить критическую ситуацию.

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

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

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

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

o  
способность убедительно и четко излагать точку
зрения и позицию;

o  
высокий уровень навыков активного и
результативного выслушивания;

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

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

·       
Результативное
принятие решений. Это подразумевает способность проведения переговоров и
оказания влияния на организацию и команду управления проектом. Ниже
представлены некоторые из рекомендаций в отношении принятия решений:

o  
необходимо сосредоточиться на целях, которые
предстоит достичь;

o  
необходимо придерживаться процедуры принятия
решений;

o  
необходимо изучать факторы среды;

o  
необходимо анализировать имеющуюся информацию;

o  
необходимо развивать личностные качества членов
команды;

o  
необходимо стимулировать творческий подход
команды к работе;

o  
необходимо управлять рисками.

10. УПРАВЛЕНИЕ
КОММУНИКАЦИЯМИ ПРОЕКТА

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

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

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

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

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

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

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

Базовая коммуникационная модель имеет следующую
последовательность шагов:

·       
Кодирование.
Преобразование (кодирование) мыслей или идей в кодовый язык отправителем.

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

·       
Декодирование.
Сообщение переводится получателем обратно в значимые мысли и идеи.

·       
Подтверждение.
После получения сообщения получатель может послать сигнал (подтверждение) о
получении сообщения, но это не обязательно означает согласие с сообщением или
понимание сообщения.

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

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

Данные методы
могут быть разделены на следующие большие группы:

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

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

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

Методы и аспекты эффективного управления коммуникациями
включают среди прочего:

·       
Модели
«отправитель-получатель». Внедрение циклов обратной связи с целью обеспечения
благоприятных возможностей для взаимодействия/участия и устранения барьеров
коммуникаций.

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

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

·       
Методы
управления совещаниями. Подготовка повестки и работа с конфликтами.

·       
Методы
презентаций. Осведомленность о воздействии языка тела и разработка
визуальных средств.

·       
Методы
организации групповой работы. Достижение консенсуса и преодоление
препятствий.

·       
Методы
слушания. Активное слушание (подтверждение, уточнение и проверка понимания)
и устранение барьеров, которые могут исказить понимание.

11. УПРАВЛЕНИЕ
РИСКАМИ ПРОЕКТА

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

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

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

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

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

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

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

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

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

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

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

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

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

Методы диаграмм

К методам диаграмм рисков относятся:

·       
Диаграммы
причинно-следственных связей. Эти диаграммы, также известные как диаграммы
Исикавы или диаграммы «рыбий скелет», используются для определения причин
возникновения рисков.

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

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

Анализ SWOT

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

Реестр рисков

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

·       
Список
идентифицированных рисков. Идентифицированные риски описываются с
достаточной степенью детализации. В данном списке может использоваться
определенная структура для описания рисков, например: может произойти СОБЫТИЕ,
которое окажет ВОЗДЕЙСТВИЕ, или если существует ПРИЧИНА, то может произойти
СОБЫТИЕ, которое будет иметь ПОСЛЕДСТВИЕ. Кроме того, при построении списка идентифицированных
рисков могут стать более очевидными первопричины данных рисков. Это
фундаментальные условия или события, которые способны вызвать наступление
одного или нескольких идентифицированных рисков. Они должны регистрироваться и
использоваться для поддержки идентификации рисков в будущем в рамках данного и
других проектов.

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

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

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

Методы сбора и
представления информации

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

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

Методы
количественного анализа и моделирования рисков

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

·       
Анализ
чувствительности. Анализ чувствительности помогает определить риски с
наибольшим возможным воздействием на проект. Он помогает понять, каким образом
вариации в целях проекта коррелируют с вариациями в различных
неопределенностях. С другой стороны, он устанавливает, в какой степени
неопределенность каждого элемента проекта влияет на изучаемую цель, в то время
как все другие неопределенные элементы находятся в своих базовых значениях.
Одним из типичных способов отображения анализа чувствительности является
диаграмма «торнадо» (рис. ниже), которая полезна при сравнении относительной
важности и воздействия переменных, обладающих высокой степенью
неопределенности, с другими, более стабильными переменными. Диаграмма «торнадо»
также полезна при анализе сценариев принятия рисков, применяемых при
определенных рисках, количественный анализ которых указывает на то, что
возможные выгоды больше, чем соответствующие идентифицированные отрицательные
воздействия. Диаграмма «торнадо» — особый вид линейчатой диаграммы,
используемый в анализе чувствительности для сравнения относительной важности
переменных. В диаграмме «торнадо» на оси Y располагается каждый тип неопределенности
в базовых значениях, а на оси X — разброс или корреляция неопределенности в
отношении изучаемого выхода. На этом рисунке каждая неопределенность содержит
горизонтальную полосу (линию), а по вертикали показаны неопределенности с
уменьшающимся разбросом от базовых значений

·       
Анализ
ожидаемого денежного значения. Анализ ожидаемого денежного значения
(expected monetary value, EMV) — это статистический метод, с помощью которого
вычисляется средний результат, когда в будущем имеются сценарии, которые могут
произойти или не произойти (т. е. анализ в условиях неопределенности). EMV
благоприятных возможностей, как правило, выражается в положительных величинах,
а угроз — в отрицательных. Для EMV требуется нейтральное по отношению к рискам
допущение — ни склонное к чрезмерному риску, ни, наоборот, полностью его
отвергающее. Чтобы рассчитать EMV для проекта, необходимо умножить значение
каждого возможного результата на вероятность его наступления, а затем сложить
вместе полученные значения. Обычно данный тип анализа используется в виде анализа
дерева решений.

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

Стратегии
реагирования на отрицательные риски (угрозы)

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

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

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

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

Стратегии
реагирования на положительные риски (благоприятные возможности)

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

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

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

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

12. УПРАВЛЕНИЕ
ЗАКУПКАМИ ПРОЕКТА

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

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

Типы договоров

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

o  
Договоры с
твердой фиксированной ценой (Firm Fixed Price Contracts, FFP). Наиболее
широко используемым типом договоров является FFP. Большинство
организаций-покупателей предпочитает именно этот тип договора, так как цена
товаров устанавливается в самом начале и не подвержена изменениям, если не
меняется содержание работ. Любое увеличение стоимости, вызванное негативным
исполнением, является ответственностью продавца, который обязан закончить
работу. В соответствии с FFP покупатель обязан точно определить приобретаемый
продукт или услуги, а любые изменения закупочной спецификации могут увеличить
затраты покупателя.

o  
Договоры с
фиксированной ценой и поощрительным вознаграждением (Fixed Price Incentive
Fee Contracts,FPIF). Данное соглашение с фиксированной ценой предоставляет
покупателю и продавцу некоторую гибкость, поскольку допускает отклонение от
исполнения и предусматривает финансовое поощрение за достижение оговоренных
метрик. Как правило, такие финансовые поощрения связаны с выполнением
стоимости, расписания или с техническим исполнением со стороны продавца.
Целевые значения показателей исполнения устанавливаются в начале, а конечная
цена договора определяется после завершения всех работ в зависимости от их
исполнения продавцом. В рамках FPIF устанавливается потолок цен, и
ответственность за все затраты выше потолка цен возлагается на продавца, который
обязан завершить работу.

o  
Договоры с
фиксированной ценой и оговоркой о возможной корректировке цены (Fixed Price
with Economics Price Adjustment Contracts,
FP-EPA). Данный тип договора используется в
том случае, если исполнение договора продавцом растягивается на значительный
период времени, к чему обычно стремятся при долгосрочных отношениях. Договор с
фиксированной ценой, но со специальным положением, позволяющим вносить
предопределенные окончательные корректировки в стоимость договора в связи с
изменившимися условиями, такими как инфляция или повышение (понижение) цен
определенных товаров. Оговорка о корректировке цены должна быть привязана к
достоверному финансовому индексу, используемому для точной корректировки
конечной цены. FP-EPA призван защищать как покупателя, так и продавца от
внешних условий, которые они не могут контролировать.

·       
Договоры
с возмещением затрат. Этот тип договора подразумевает оплату (возмещение)
продавцу всех законных фактических затрат, понесенных в результате исполнения
работы, плюс вознаграждение, составляющее его прибыль. В договоры с возмещением
затрат часто включаются пункты, предусматривающие поощрительные вознаграждения
за превышение или улучшение запланированных показателей проекта (например,
стоимости, расписания или технического исполнения). Тремя наиболее
распространенными типами договоров с возмещением затрат являются: договор с
возмещением затрат плюс фиксированное вознаграждение (Cost Plus Fixed Fee
Contract, CPFF), договор с возмещением затрат плюс поощрительное вознаграждение
(Cost Plus Incentive Fee Contract, CPIF), договор с возмещением затрат плюс
премиальное вознаграждение (Cost Plus Award Fee Contract, CPAF). Договор с
возмещением затрат обеспечивает гибкость проекта, позволяя изменять указания
для продавца в том случае, если содержание работ не может быть точно описано в
начале и нуждается в корректировке или существуют высокие риски во время
выполнения работ.

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

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

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

·       
Договоры «время и материалы» (Time and Material
Contracts, T&M). Договоры «время и материалы» являются смешанным
типом договорных соглашений, содержащим положения как договоров с возмещением затрат,
так и договоров с фиксированной ценой. Они часто используются при
дополнительном наборе персонала (staff augmentation), привлечении экспертов и
для любой сторонней поддержки в тех случаях, когда невозможно быстро создать
точное описание работ. Данные типы договоров напоминают договоры с возмещением
затрат тем, что они допускают поправки и увеличение стоимости для покупателя. В
момент заключения договора покупатель может не указывать общую стоимость по
договору и точное количество предметов, которые необходимо поставить. Таким
образом, стоимость договоров T&M может увеличиваться, как и в договорах с
возмещением затрат. Для предотвращения неограниченного роста стоимости многие
организации требуют включения во все договоры T&M предельных значений цены
и сроков. C другой стороны, договоры T&M также могут напоминать соглашения
с фиксированной ценой, когда в договоре указываются определенные параметры. Ставки
оплаты рабочих часов или стоимость материалов, в том числе прибыль продавца,
могут быть заранее установлены покупателем и продавцом, если обе стороны
достигли соглашения по поводу стоимости определенных категорий ресурсов,
например определенной ставки почасовой оплаты труда главных инженеров или
определенной цены за единицу материала.

13. УПРАВЛЕНИЕ
ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ ПРОЕКТА

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

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

·       
матрица
власти/интересов, группирующая заинтересованные стороны на основе их уровня
полномочий («власть») и уровня заинтересованности («интерес») в отношении
результатов проекта;

·       
матрица
власти/влияния, группирующая заинтересованные стороны на основе их уровня
полномочий («власть») и активного вовлечения («влияние») в проект;

·       
матрица
влияния/воздействия, группирующая заинтересованные стороны на основе их
активного вовлечения («влияние») в проект и их возможности приводить к
изменениям в планировании или исполнении проекта («воздействие»);

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

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

·       
Неосведомленный. Заинтересованная сторона
не осведомлена о проекте и потенциальных воздействиях.

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

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

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

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

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

·       
Идентификационную
информацию: Ф.И.О., должность в организации, местоположение, роль в
проекте, контактная информация.

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

·       
Классификацию
заинтересованной стороны: внутренняя/внешняя,
поддерживает/нейтральна/сопротивляется и т. д.

В дополнение к данным из реестра заинтересованных сторон
план управления заинтересованными сторонами зачастую также содержит:

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

·       
объем и воздействие изменения на
заинтересованные стороны;

·       
выявленные взаимосвязи и потенциальное
пересечение заинтересованных сторон;

·       
требования заинтересованных сторон к
коммуникациям на текущей фазе проекта;

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

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

·       
время и периодичность распространения требуемой
информации заинтересованным сторонам;

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

Автор: PM Angel