какие риски выделяет в проектном менеджменте стандарт pmi pmbok
Управление рисками проекта по PMBoK
В соответствии с PMI PMBoK область знаний «Управление рисками проекта» включает в себя процессы планирования управления рисками, идентификации и анализа рисков, реагирования на риски, а также контроля и управления рисками в рамках проекта.
Выделяют две основные цели управления рисками проекта:
Рисунок 1. Схема управления рисками проекта.
Схема процессов управления рисками проекта (рисунок 1) в соответствии с PMI PMBoK 5th Edition включает следующие процессы.
Планирование управления рисками
Этот процесс определения порядка осуществления действий по управлению рисками в рамках проекта. Тщательное и подробное планирование повышает вероятность успеха пяти остальных процессов управления рисками. Процессы планирования управления рисками важны для обеспечения того, чтобы степень, тип и возможность визуального контроля над управлением рисками соответствовали как рискам, так и важности проекта для организации.
Также планирование важно и для выделения достаточных ресурсов и времени для выполнения действий по управлению рисками, а также для формирования предварительно согласованной базы для оценки рисков. Процесс планирования управления рисками должен начинаться, как только появляется замысел проекта, и должен быть завершен на ранних стадиях планирования проекта.
Идентификация рисков
Процесс «Идентификации рисков» направлен на выявление рисков, способных повлиять на проект, а также документирования их характеристик. В действиях по идентификации рисков могут принимать участие:
Хотя эти сотрудники зачастую являются ключевыми участниками идентификации рисков, необходимо побуждать к идентификации рисков весь персонал проекта.
Результатом процесса идентификации рисков является одобренный командой управления проектом Реестр рисков проекта, содержащий список выявленных рисков. Реестр рисков должен быть доступен всем участникам проекта и постоянно актуализироваться. Все новые риски должны заноситься в реестр.
Качественный анализ рисков
Это процесс расстановки приоритетов между рисками для дальнейшего анализа или действия с помощью оценки и суммирования вероятности их возникновения и воздействия. Организации могут существенно улучшить исполнение проекта, сосредоточив усилия на рисках, обладающих наивысшим приоритетом.
При качественном анализе рисков определяются приоритеты идентифицированных рисков на основании вероятности или возможности их наступления, их воздействие на достижение целей проекта в случае наступления, а также с учетом ряда других факторов (например, временных рамок реагирования и готовности организации принимать риски, заложенной в ограничениях проекта по стоимости, срокам, содержанию и качеству).
Такие оценки отражают отношение команды проекта и других заинтересованных сторон проекта к риску. Таким образом, эффективная оценка требует четкого определения и управления отношением к рискам со стороны ключевых участников процесса качественного анализа рисков. Когда данные отношения к рискам вносят необъективность в оценку определенных рисков, необходимо обратить внимание на оценку необъективности и ее корректировку.
Количественный анализ рисков
В процессе количественного анализа рисков проводится численный анализ воздействия выявленных рисков на общие цели проекта. Количественный анализ рисков производится в отношении тех рисков, которые в результате процесса качественного анализа рисков были классифицированы как потенциально и существенным образом влияющие на противостоящие требования проекта.
В процессе количественного анализа рисков оценивается воздействие данных рисков в случае их наступления. Он может использоваться для присвоения числового рейтинга отдельно для каждого из этих рисков или для оценки совместного влияния всех рисков на проект. Данный анализ также предоставляет количественный подход к принятию решений в условиях неопределенности.
Планирование реагирования на риски
Это процесс разработки вариантов и действий по расширению возможностей и снижению угроз для целей проекта. Данный процесс следует за процессами качественного и количественного анализа рисков. Он включает в себя определение и назначение ответственного за реагирование на риски, который должен взять на себя ответственность за каждую согласованную и подкрепленную бюджетом реакцию на риск.
При планировании реагирования на риски рассматриваются риски в порядке их приоритетности. При необходимости, новые соответствующие ресурсы и операции добавляются в бюджет, расписание и план управления проектом.
Мониторинг и управление рисками
Процесс применения планов реагирования на риски, слежения за выявленными рисками, контроля остаточных рисков, идентификации новых рисков и оценки эффективности процесса регулирования рисков на протяжении проекта.
Методология, фреймворк или стандарт проектного управления
В продолжение статьи о классическом PRINCE2 по запросу из комментариев попробовала сравнить ключевые методики управления проектами. Надеюсь, что получилось что-то полезное и при выборе подхода управления у читающих часть вопросов будут снята.
Краткие вводные:
PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.
PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.
Как можно заметить, первое главное отличие – собственное позиционирование в проектном управлении. Остальные основные отличия с некоторыми субъективными выводами приведены в таблице.
PRINCE2
PMBoK (6 издание, 2017г.)
ISO 21500:20112
Определение проекта
Временная организация, которая создается с целью предоставления одного или нескольких бизнес-продуктов в соответствии с утвержденным экономическим обоснованием проекта.
Временное предприятие, направленное на создание уникального продукта, услуги или результата.
Уникальная совокупность процессов, состоящая из контролируемых и управляемых видов деятельностей с датами начала и завершения, предназначенная для достижения определенных целей.
Процессы
7 процессов: Начало проекта, руководство проектом, инициация проекта, контроль стадии, управление границами стадии, управление созданием продукта, закрытие проекта.
49 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие.
39 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, управление, завершение.
Предметные темы / группы (курсивом отмечены различающиеся темы)
7 тем:
1. Экономическое обоснование,
3. Управление качеством,
5. Анализ и управление рисками,
6. Управление изменениями содержания,
7. Принятие решений.
10 областей знаний:
1. Управление интеграцией проекта,
2. Управление содержанием,
3. Управление сроками,
4. Управление стоимостью,
5. Управление качеством,
6. Управление человеческими ресурсами,
7. Управление коммуникациями,
8. Управления рисками,
10. Управление заинтересованными сторонами.
10 предметных групп:
2. Заинтересованные стороны,
Жизненный цикл проекта
Структура стадий проекта:
1. Стадия инициации,
2. Последующие стадии (создание продуктов, соответствующих требованием),
3. Финальная стадия (приемка результатов, подведение итогов проекта).
Минимальное количество стадий в проекте – 2 (инициация и финальная).
Все проекты могут иметь следующую структуру жизненного цикла:
2. организация и подготовка;
3. выполнение работ проекта;
4. завершение проекта.
В стандарте отсутствуют четкие требования/пояснения по стадиям проекта, стандарт определяет, что проект должен подразделяться на фазы, состав и содержание которых должно определяться потребностями управления и контроля.
Принципы
7 принципов (универсальны и не требуют обоснования):
1. Постоянная оценка целесообразности,
2. Учет предыдущего опыта,
3. Определенные роли и обязанности,
4. Управление по стадиям,
5. Управление по исключениям,
6. Фокус на продукте,
7. Адаптация к внешним условиям.
Шестое издание PMBoK основано на процессной составляющей с четкими входами, выходами и инструментарием.
Ожидается, что новое седьмое издание будет ориентировано на принципы.
ISO 21500 по аналогии с PMBoK основан на процессной составляющей.
Ответственность за результат проекта
Ответственный руководитель (куратор/спонсор проекта) полностью отвечает за успех проекта.
Менеджер проекта управляет проектом на ежедневной основе в рамках полномочий, делегированных Управляющим советом.
Руководитель проекта = единый ответственный за результат.
Руководитель проекта обеспечивает общее руководство и управление работами проекта и отвечает за получение результатов проекта.
Инструменты управления
В методологии отсутствуют примеры инструментов, данная область отдается на откуп Руководителю проектов.
Предоставляет расширенный список инструментов и методов по каждому процессу управления проектом.
Стандарт не описывает конкретных инструментов для реализации процессов управления.
Возможность гибкого применения
Допускает использование минимального количества документов с минимальным требуемым содержанием, гибкое использование метода с соблюдением всех 7 принципов позволяет подготавливать упрощенную отчетность и минимизировать процессы управления (с учетом целей и задач, которые соответствуют процессам PRINCE2).
Так как PMBoK является не методологией или стандартом, а фреймворком, его создатели рекомендуют использовать PMBoK для создания собственной методологии управления проектами в компании. При этом созданная методология должна учитывать особенности каждого отдельного проекта и позволять руководителю проектов изменять процессы управления в определенных пределах.
Описанные в стандарте процессы не должны применяться без изменений ко всем проектам или фазам жизненного цикла проекта. Руководитель проекта должен корректировать состав процессов управления конкретным проектом или фазой, отбирая подходящие процессы и условия их реализации. Такая адаптация должна выполняться в соответствии с существующими политиками организации.
Возможность использования в программе проектов
Возможность использования в портфеле проектов
P2M, или управление проектами по-японски
Стандарт управления — это набор рекомендаций и советов, на которые опираются команды при работе над проектами.
В США при работе над проектами используется PMBOK, а в Японии — P2M.
P2M, или Program and Project Management for Enterprise Innovation — это стандарт управления инновационными проектами, который поддерживает и развивает Японская ассоциация PMAJ.
Кроме P2M, который концентрируется на ценностях проекта, есть и другие стандарты управления, например, PMBOK отвечает за процессы, а ICB — за компетенции руководителя проектов.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
Что важно знать о стандарте P2M
P2M — свод знаний, который основан на культурных традициях, философии Японии и опыте японских предприятий в области управления проектами. Вот что важно знать, если вы используете его в работе.
Миссия и ценности
Обычно перед началом проекта нужно определить его цель и ответить на вопрос «зачем». В P2M на этом этапе выясняют миссию проекта для компании, а потом определяют цели и задачи. Для этого задают вопрос: что получит компания при успешном завершении проекта?
Цели проекта по P2M — создавать ценности, инновации и выполнять миссию компании. То есть мало просто создать продукт или услугу, нужно еще проверить, как результат повлияет на компанию.
По ходу проекта менеджер и команда следят за тем, что получается. Для этого задают себе вопрос: соответствует ли настоящий результат изначальным ценностям и миссии проекта? Если да — продолжают работать по плану. Если нет — выясняют, в чем расхождения и как это исправить.
Команда проекта
Для стандарта P2M важно единство команды. Менеджер должен создать единое ментальное пространство, по-японски — «Ба», чтобы сотрудники опирались на единые ценности и цели и вместе работали над улучшением процессов.
Команда, которая работает по стандарту P2M: концентрируется на создании ценности, постоянно улучшает процессы и ищет нестандартные решения проблем, использует полученный опыт для развития.
Области знаний и компетенции менеджера
Управление проектом по стандарту P2M делится на области знаний, как и в PMBOK, а менеджер контролирует эти направления.
Как и у PMBOK, у P2M есть своя система сертификации в несколько уровней, где специалистов оценивают по разным критериям. Экзамены проводит центр сертификации — Project Management Professionals Certification Center (PMCC).
Согласно P2M, менеджер проекта не просто создает команду, распределяет ресурсы и организует работу, а обладает следующими компетенциями.
Менеджер проекта по стандарту P2M
Заключение
Мы рассказали про основы, которые нужно знать о стандарте управления P2M. Можно остановиться на этом или продолжить вникать в тему, чтобы использовать его в работе. Прочитайте книгу о P2M и официальный гид.
Управление проектами по PmBok
Руководство PMI PMBoK® – это стандарт для управления проектами. Данный стандарт описывает процессы управления проектами, инструменты и методы, используемые для управления проектом в целях достижения успешного результата.
PMI PMBOK был разработан и поддерживается Институтом управления проектами (PMI®, Project Management Institute) — это ведущая международная некоммерческая ассоциация профессионалов в управлении проектами, объединяющая более 200 000 членов в 125 странах. Получить степень PMP можно здесь.
Разберем свод правил по этой книге с помощью методологии Ивана Селиховкина.
ЧАСТЬ 1.СТРУКТУРА PMBOK
10 областей знаний:
Области знаний разбиты на группы и состоят из 47 процессов управления проектом, объединенных в 5 групп:
Процесс — это задача, к примеру, создать расписание.
Пример: область знаний «управление сроками» на этапах «ПЛАНИРОВАНИЕ» и «МОНИТОРИНГ»:
Исключение: процессы из областей знания «интеграция» и «управление HR»:
Примечание. Область знаний «Управление интеграцией» — в книге эта глава первая, но никогда не стоит начинать чтение книги с этой главы, потому что она абстрактна и не даем применимых знаний.
ЧАСТЬ 2.
ПРИНЦИПЫ ПРОЕКТНОГО УПРАВЛЕНИЯ
Фундаментальные принципы PMI :
Разберем каждый принцип подробнее.
1. Принцип яйца
«Скорлупа яйца» — Устав проекта, который пишется в начале проекта
«Внутреннее содержимое яйца»:
2. Принцип удава
Жизненный цикл проекта:
Начало проекта — «инициация» > Середина проекта — «цикл Деминга» > Конец проекта — «закрытие»
Если представить этапы в виде удава, то получается следующая картинка (этого в книге нет, это разработал И.Селиховкин):
3. Принцип командности и проактивности
ЧАСТЬ 3. ОБЛАСТИ ЗНАНИЙ
1. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА
ROI-return of investment — (возврат инвестиций)
internal rate of return — (внутренняя ставка возврата)
discounted cash flow — (дисконтированный денежный поток)
net present value — (чистый дисконтированный доход)
4.1. Разработка устава проекта
Устав фиксирует цели и ограничения проекта
Должен быть неизменным
4.2. Разработка плана управления проектом
Как будем измерять выполнение планов, как закрывать проект.
4.3. Мониторинг и контроль работ проекта
Проверка хода проекта относительно всех планов: нужно сверить «план» и «факт» (укладываем в сроки?, укладываемся в бюджет? и т.п.)
4.4. Интегрированный контроль изменений
4.5. Руководство и управление работами проекта
Это координация команды, действия по планам, работа с отчета и т.п.
4.6. Закрытие фазы или проекта
Все проекты и фазы должны быть закрыты все зависимости завершился он триумфом или провалом.
2. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА
Определить, какие работы необходимы, а потом что только они выполняются. 
5.1. Планирование управлением содержанием
Связать все планы воедино
5.2. Сбор требований
Сбор требований происходит посредством опроса заинтересонных лиц — интервью, анкеты и т.п.
5.3. Определение содержания
Делаем концепцию (техническое задание): детальное описание продукта и проекта
Определяем: что делаем и чего НЕ делаем в ходе проекта
5.4. Создание иерархической структуры работ
Разделяй и властвуй!
Перед тем как представить иерархическую структуру работ желательно представить иерархическую структуру продукта
Иерархическая структура продукта (PBS — Product Breakdown Structure):
Иерархическая структура работ (WBS — Work Breakdown Structure):
Существенным является не способ представления, а иерархичность: декомпозиция любого результата на его составляющие.
От сложного – к простому.
5.5. Контроль содержания
Если понимаем, что не учли какой-то элемент, то вносим изменения в планы
5.6. Подтверждение содержания
3. УПРАВЛЕНИЕ ВРЕМЕНЕМ (СРОКАМИ) ПРОЕКТА
Вот как это выглядит на «Карте процессов»: 
6.1. Управление расписанием
Как создать расписание и сопоставление содержания с расписанием
6.2. Определение операций
Декомпозиция технического задания в ДЕЙСТВИЯ!
Берем иерархическую структуру работ и переводим ее в «глаголы» — как добьем результата обозначенного в ИСР.
6.3. Определение последовательности операций
Перестраиваем ИСР в Сетевую диаграмму (PDM — Precedence Diagramming Method, Метод «операции в узлах» (метод предшествования).
Сетевая диаграмма проекта показывает набор операций и логику их последовательностей – кто за кем. Заметьте, что в этой диаграмме нет никаких характеристик самих операций, например, сроков или длительностей – только логика: что и в какой последовательности должно делаться в проекте. Эта диаграмма является важнейшим промежуточным шагом на пути к значимой цели – расписание проекта
6.4. Оценка ресурсов операций
Ресурсы делятся на:
6.5. Оценка длительности операций
Способ оценки по аналогии с предыдущей похожей деятельностью.
Пример такой оценки: мы уже исполняли подобные работы и по опыту знаем, что на исполнение требуется 5 дней. Или не исполняли подобного, но погуглили или опросили экспертов.
Среди аналоговых методов оценки есть один метод, который люди используют чаще всего – оценка из своего опыта. Это предполагает простой алгоритм:
опытный человек чешет затылок и сообщает: — ну, я это не раз делал, понадобится столько-то деньков.
Такой оценки имеет существенную особенность – оценки получаются заниженными, то есть оптимистичными.
Это оценка такого типа:
я не знаю, сколько понадобится времени на эту операцию, но могу сказать, что если все пойдет хорошо, то уложимся в 5 дней (оптимистичная оценка), в худшем варианте понадобится 10 дней (пессимистичная оценка), а скорее всего, потребуется 7 дней (наиболее вероятная оценка).
В результате нужно усреднить способом «оценка PERT» (PERT – Program Evaluation and Review Technique):
Ожидаемая оценка = (Оптимистичная + 4 * Наиболее вероятная + Пессимистичная) / 6
Обращаю внимание, что делим на 6 потому, что взяли 4 наиболее вероятных оценок и по одной оптимистичной и пессимистичной – всего шесть оценок.
Пример: Оценка по трем точкам.
Некоторая работа исполнялась 10 раз. Статистика длительностей:
Посчитаем разные средние значения:
Средняя (арифм) = (4 * 2 + 5 * 7 + 9 * 1) / 10 = 5,2 дней
Ожидаемая (PERT) = (4 + 4 * 5 + 9) / 6 = 5,5 дней
6.6. Разработка расписания
Используйте программное обеспечение — диаграммы Ганта и т.п.
Метод критического пути для составления расписания
Метод критического пути является основным способом расчета расписания проекта.
Операции могут иметь резервы, вызванные наличием параллельных цепочек:
Резерв (Float, Total Float, Slack) – время, на которое операция может быть задержана, без увеличения длительности проекта:
Свободный резерв (Free Float) – время, на которое операция может быть задержана, не влияя на раннее начало любой последующей операции
В прямом проходе, от начала к концу проекта, рассчитываются ранние даты операций. А в обратном проходе, от конца проекта к началу, все наоборот – рассчитываются поздние даты каждой операции.
Результатом расчета является таблица с ранними датами и резевами каждой операции:. 
Операции без резервов являются основным фокусом внимания менеджера и команды проекта:
Критический путь — все работы, у которых нет резервов. Критический путь определяет длительность проекта.
6.7. Контроль расписания
Делаем прогнозы отклонений и отслеживаем укладываемся ли в в график.
4. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА
7.1. Планирование управлением стоимостью
Как будем держать под контролем наш план
7.2. Оценка стоимости
Считаем себестоимость на основе временных зарат.
Стоимость проекта = стоимость всех работ проекта
Стоимость работы = стоимость израсходованных ресурсов.
Стоимость проекта = Сумма стоимостей израсходованных ресурсов.
7.3. Определение бюджета
Бюджет проекта – это распределение стоимости проекта по времени.
Базовый план стоимости (cost baseline)= себестоимость работ + резервы работ + резервы пакетов работ
Бюджет проекта (project budget) = Базовый план стоимости + управленческие резервы
Управленческие резервы — это деньги, который спонсор проекта отложил на «всякий случай»
«План по стоимости» — это бюджет проекта.
Стоимости делят на две важные группы:
«Резерв управления» – это превышение бюджета, вызванное выявленными рисками.
7.4. Контроль стоимости
Собираем все вместе и контролируем календарный план проекта (MS Project):
7. УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ
Заинтересованные стороны проекта – это лица и организации, например заказчики, спонсоры, исполняющая организация и общественность, которые активно участвуют в проекте, или интересы которых могут быть затронуты как положительно, так и отрицательно в ходе исполнения или в результате завершения проекта. Они также могут оказывать влияние на проект или на его результаты. Заинтересованные стороны проекта могут находиться на различных уровнях внутри организации и иметь разные уровни полномочий либо могут являться внешними по отношению к исполняющей организации проекта.
В процессе планирования коммуникаций определяются информация и взаимодействия, необходимые заинтересованным сторонам проекта, например: каким лицам какая информация нужна, когда она им понадобится, кто и каким образом должен им эту информацию предоставить.
Это процесс предоставления необходимой информации заинтересованным сторонам проекта в соответствии с планом.
Это процесс общения и работы с заинтересованными сторонами проекта для удовлетворения их потребностей и решения возникающих проблем.
Это процесс сбора и распространения информации об исполнении, включая отчеты о состоянии, результаты измерения исполнения и прогнозы. Процесс подготовки отчетов об исполнении включает периодический сбор фактических данных и их сопоставление с базовым планом для оценки продвижения проекта и его исполнения, передачи данной информации, а также прогнозирования результатов проекта.