Iso 21500 2012 руководство по управлению проектами скачать

ГОСТ Р ИСО 21500-2014. Национальный стандарт Российской Федерации. Руководство по проектному менеджменту

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

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

ISO 21500 2014 скачать

Перевод 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 — Разработка планов проекта: основные входы и выходы

ПРИМЕЧАНИЕ: В оставшейся части этого документа «Планы проекта» приведены для всех планов в пункте 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

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

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

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

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

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

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

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

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

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

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

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

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

[см.
также комментарии об приоритете
использования ISO 21500 над ГОСТ и PMBOK в
Российской Федерации согласно Статье
7 ГК РФ]

Введение
(Introduction)

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

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

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

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

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

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

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

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

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

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

[см.
также комментарии к терминам и определениям
в стандарте]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.10
Лаг ( lag)

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

2.11
Лид (lead)

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

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

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

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

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

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

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

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

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

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

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

2.17
Тендер (tender)

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

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

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

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

3.1
Обзор
(Overview)

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

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

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

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

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

3.2
Проект (Project)

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

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

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

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

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

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

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

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

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

Рисунок
2 — Управление портфелем проектом от
стратегии до получения преимуществ
(см.
также комментарии)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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]

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