- •Расшифровки и толкования аббревиатуры
- •Цели создания и задачи
- •Состав и структура
- •Подсистемы
- •[Компоненты и обеспечение
- •Управление проектами - основные понятия и методы
- •Разработка плана управления проектом (pmBoK 4d)
- •4.2.1 Разработка плана управления проектом: входы
- •4.2.2 Разработка плана управления проектом: инструменты и методы
- •4.2.3 Разработка плана управления проектом: выходы
- •Создание Иерархической структуры работ проекта Иерархическая структура работ
- •Определение операций (pmBoK 4ed)
- •6.1.1 Определение операций: входы
- •6.1.2 Определение операций: инструменты и методы
- •6.1.3 Определение операций: выходы
- •Оценка ресурсов операций (pmBoK 4ed)
- •6.3.1 Оценка ресурсов операций: входы
- •6.3.2 Оценка ресурсов операций: инструменты и методы
- •6.3.3 Оценка ресурсов операций: выходы
- •Планирование качества проекта
- •Этапы управления человеческими ресурсами
- •Планирование коммуникаций (pmBoK 4ed)
- •10.2.1 Планирование коммуникаций: входы
- •10.2.2 Планирование коммуникаций: инструменты и методы
- •10.2.3 Планирование коммуникаций: выходы
- •Управление рисками проекта
- •Планирование управления рисками
- •Часть 3. Качественный анализ рисков
- •Шаг 1. Выбор владельца риска
- •Шаг 2. Анализ всех допущений и определение погрешности данных
- •Шаг 3. Выбор шкал степени воздействия и оценка вероятности возникновения риска
- •Шаг 4. Сортировка рисков
- •Шаг 5. Ранжирование и выбор значимых рисков
- •Шаг 6. Общий риск проекта
- •Шаг 7. Документирование незначимых рисков
- •Шаг 8. Количественный анализ или rrp?
- •Количественный анализ рисков
- •Количественный анализ рисков: входы
- •Количественный анализ рисков: инструменты и методы
- •Результаты количественного анализа рисков
- •Планирование реагирования на риски
- •Входы процесса планирования реагирования на риски
- •Инструменты и методы процесса планирования реагирования на риски
- •Планирование реагирования на риски: выходы
- •Мониторинг и управление рисками
- •Исходные данные для процесса мониторинга
- •Мониторинг и управление рисками: инструменты и методы
- •Мониторинг и управление рисками: выходы
- •Планирование закупок
Часть 3. Качественный анализ рисков
В этой части цикла, посвященного управлению рисками, мы подробно остановимся на одном из важнейших этапов - качественном анализе найденных рисков, их сортировке и выбору особенно влияющих на проект, а потому значимых рисков для последующей работы с ними.
Следующие два этапа процесса управления рисками - это качественный и количественный анализ рисков. Задача качественного и количественного анализа состоит в том, чтобы определить какие идентифицированные на предыдущей стадии риски потребуют специфических действий. Каждый ли риск в имеющемся списке потребует специфических мер или же есть риски с низкой вероятностью или риски с низкой степенью воздействия на проект, работу над которыми можно опустить?
Задачи этапа 4 - качественного анализа рисков - состоят в том, чтобы субъективно оценить вероятность воздействия каждого риска, создать более короткий список рисков, определить критические риски, которые уже будут пропущены через количественный анализ и для которых будут планироваться ответные действия. Кроме того, на стадии качественного анализа принимается решение о судьбе проекта: продолжать проект или закрывать.
В целом этап качественного анализа рисков разбивается на восемь шагов.
Шаг 1. Выбор владельца риска
Так называемые владельцы рисков (risk owners) - это сотрудники, которым руководитель проекта поручает наблюдать за триггерами некоторого определенного риска, а также управлять ответными процедурами в случае возникновения данного риска. Сотрудники становятся владельцами рисков в силу специфических экспертных знаний относительно той или иной проблемы или в связи с тем, что они обладают определенным контролем над специфическим риском. Прежде всего надо решить, будут ли владельцы рисков использованы с самого начала процесса качественного анализа рисков или позже, в процессе работы над рисками. Обычно чем раньше в процесс управления рисками вводится владелец риска, тем лучше.
Шаг 2. Анализ всех допущений и определение погрешности данных
Следующий шаг - анализ допущений (assumption testing), которые были сделаны в процессе идентификации рисков. Это надо сделать, прежде чем непосредственно переходить к качественному и количественному анализу рисков. Слишком много неизвестных делают данные еще более рискованными. Если допущения оказываются ложными, степень риска проекта существенно увеличивается. Поэтому PMBOK считает необходимым проанализировать стабильность каждого сделанного в проекте допущения, а также последствий, если допущение окажется ложным. Анализ допущений осуществляется, как правило, в формате, показанном в таблице 1.
Таблица 1. Анализ допущений при идентификации рисков
Допущение |
Стабильность допущения (1--10) |
Последствия, если допущение ложно (1--10) |
Работа над проектом не будет мешать ежедневной работе сотрудника А |
2 |
8 |
Примечание: Стабильность допущения в рамках от 5 до10 означает, что допущение более-менее верно. Последствия допущения в рамках от 5 до10 означает, что влияние на проект может быть существенным |
После анализа допущений необходимо провести определение погрешности данных. Данная процедура показывает, достаточно ли хорошо понятны определенные риски, достаточно ли данных, необходимых для определения последствия рисков, доступно, а также насколько эти данные надежны. Кто именно будет проводить процедуру, зависит от понимания проекта и профессионального опыта. Возможно, руководитель проекта посчитает нужным пройти этот шаг самостоятельно. Важно учесть: чем выше приоритет проекта, тем точнее должен быть проведен анализ погрешности данных. Результаты определения погрешности данных должны быть собраны в таблицу 2. Возможно, на этом шаге понадобится дополнительный раунд интервью, однако необходимо провести всю эту работу, прежде чем можно будет начать полноценный качественный анализ.
Таблица 2. Результаты определения погрешности данных
Риск |
Степень понимания риска |
Количество данных, |
Надежность данных |
Система Х инсталлируется с опозданием, приводя к двухнедельному срыву сроков внедрения системы Y |
9 |
7 |
2 |
ПО Z не будет полноценно интегрировано с ПО W через встроенные инструменты, что приведет к необходимости дополнительного программирования |
2 |
2 |
9 |