Документирование рисков проекта

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

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

Меня зовут Анатолий Савин. Я продолжаю цикл статей и видео-уроков по управленческому документированию проектов. Перед тобой шестая статья из этого цикла – «Документирование рисков проекта».

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

Выдумай риски

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

Поэтому придумываем и записываем любые риски, которые могут и не могут произойти. Даже риск, что на День Независимости прилетят инопланетяне, а американцы не смогут, как обычно, спасти весь мир… Шутка! Но в каждой шутке есть только доля шутки… Главное во время придумывания рисков не критиковать, не анализировать, а фантазировать и фонтанировать мыслью. Тогда группа сможет обнаружить даже те риски, которые далеко не очевидны в начале проекта и за которые уже потом себя ругаешь — «знал бы где соломку подстелить…».

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

RiskBS

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

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

Шаблоны документов для идентификации рисков проекта:

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

Выдели только важное

Первое, что нужно сделать со всем полученным списком рисков — это проставить основные параметры рисков (и заполнить соответствующие колонки Реестра рисков):

  1. Категория риска из Иерархической структуры (рисунок выше).
  2. Причина возникновения риска или его источник.
  3. На каком этапе проекта этот риск может произойти (желательно с привязкой к WBS).
  4. Вероятность возникновения риска.
  5. Последствия для проекта, если риск произойдёт.

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

Итак, берём тех же экспертов и вместе с ними проставляем вероятность, как относительную величину из списка: очень высокая (90%); высокая (70%); средняя (50%); низкая (30%); очень низкая (10%).

Для последствий нужны относительные влияния риска (если он вдруг произойдёт) на разные характеристики проекта: объемы работ, сроки, стоимость и качество. Хорошую таблицу таких относительных влияний приводит PMBOK:

Выбрать, какое влияние на характеристики проекта оказывает риск
% 5% 10% 20% 40% 80%
Содержание Изменение содержания едва заметно Воздействию подвержены незначительные области содержания Воздействию подвержены значительные области содержания Сокращение содержание неприемлемо для спонсора/заказчика Конечный результат практически бесполезен
Сроки Незначительное увеличение сроков Увеличение сроков <5% Увеличение сроков на 5-10% Увеличение сроков на 10-20% Увеличение сроков >20%
Стоимость Незначительное увеличение стоимости Увеличение стоимости <10% Увеличение стоимости на 10-20% Увеличение стоимости на 20-40% Увеличение стоимости >40%
Качество Ухудшение качества едва заметно Воздействию подвержены только самые требовательные области применения Снижение качества требует одобрения спонсора/заказчика Снижение качества неприемлемо для спонсора/заказчика Конечный результат практически бесполезен
Итого: Очень низкое
(5-7%)
Низкое
(7-15%)
Среднее
(15-30%)
Высокое
(30-60%)
Очень высокое
(60-80%)

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

risk_priority

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

Шаблоны документов для анализа рисков проекта те же:

Ну, и теперь полностью раскрываем секрет оружия под названием «риск-менеджмент».

Дополни график противорисковыми мероприятиями

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

  1. Исключить риск, т.е. переделать график и технологию исполнения проекта так, чтоб риск вообще не мог произойти. Например, если есть риск того, что самолёт упадёт — мы не летим самолётом и исключаем этот риск.
  2. Передать риск, т.е. отдать риск сторонней компании. Например, застраховать или передать подрядчику по контракту. Таким образом мы несём дополнительные затраты, а сторонняя компания берёт на себя наш риск.
  3. Уменьшить риск. И тут возникает два направления:
    • Уменьшить вероятность риска. Например, если мы знаем, что в октябре могут быть дожди, мы переноси отпуск на сентябрь. Дожди не исключены, но вероятность меньше.
    • Уменьшить влияние риска. Например, если мы знаем, что в обед может пойти дождь, мы берём с собой зонт. Мы всё равно промокнем, но не так сильно, как без зонта.

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

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

Шаблоны документов для планирования противорисковых мероприятий проекта:

Итого

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

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

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

Добавить комментарий