Документирование рисков проекта
В прошлой статье был оформлен бюджет проекта, а теперь мы разберёмся, как документировать риски проекта, т.е. все его неопределённости и непредвиденные ситуации. Для этого нам понадобятся все уже созданные планы проекта.
Подписывайтесь на группу PMDoc в Facebook, и обсуждайте с коллегами вопросы документирования проектов |
Меня зовут Анатолий Савин. Я продолжаю цикл статей и видео-уроков по управленческому документированию проектов. Перед тобой шестая статья из этого цикла – «Документирование рисков проекта». |
Документирование рисков проекта – это частный случай планирования подходов к управлению рисками и различных действий по реагированию на риски. Напомню, что общее управление проектами я стараюсь выносить за рамки этого цикла статей, и описываю только состав и правила заполнения документов для управления проектами.
Выдумай риски
Первое с чего стоит начать документирование рисков – это с банального придумывания их. Собери всех, кого можешь собрать – представителей заказчика, спонсора, команду проекта, топ-менеджеров, будущих пользователей продукта проекта, экспертов по рискам, технических специалистов, и попроси их пофантазировать про риски, которые могут произойти в проекте. Именно “пофантазировать”, потому что риск – это просто вероятностное событие, которое может произойти, а может и нет. Чистой воды гадание!
Поэтому придумываем и записываем любые риски, которые могут и не могут произойти. Даже риск, что на День Независимости прилетят инопланетяне, а американцы не смогут, как обычно, спасти весь мир… Шутка! Но в каждой шутке есть только доля шутки… Главное во время придумывания рисков не критиковать, не анализировать, а фантазировать и фонтанировать мыслью. Тогда группа сможет обнаружить даже те риски, которые далеко не очевидны в начале проекта и за которые уже потом себя ругаешь – “знал бы где соломку подстелить…”.
Для того, чтоб легче придумывались риски, можно использовать Иерархическую структуру рисков, наподобие этой:
Это позволит пробежаться по всем типам рисков и не упустить из виду ничего важного.
Все придуманные риски аккуратненько записываем в табличку Реестра рисков, пока заполняя только колонку “Название риска”, ну и возможно “Краткое описание”.
Шаблоны документов для идентификации рисков проекта:
|
Если вы с коллегами по проектному цеху выдумали таким образом риски, то их может быть очень много, а денег, ресурсов и времени на управление всеми этими рисками в проекте, понятное дело, нет. Поэтому нужно решить, с какими рисками мы будет работать, а с какими нет.
Выдели только важное
Первое, что нужно сделать со всем полученным списком рисков – это проставить основные параметры рисков (и заполнить соответствующие колонки Реестра рисков):
- Категория риска из Иерархической структуры (рисунок выше).
- Причина возникновения риска или его источник.
- На каком этапе проекта этот риск может произойти (желательно с привязкой к WBS).
- Вероятность возникновения риска.
- Последствия для проекта, если риск произойдёт.
Два последних пункта самые важные для дальнейшего отбора рисков. Как рассчитывать вероятность и последствия? Всё зависит от степени зрелости системы управления рисками в твоей компании, но раз уж ты читаешь эту книгу, то своя формальная процедура документирования рисков проекта у вас в компании, скорее всего, отсутствует. Поэтому предлагаю, для начала, упростить до элементарного.
Итак, берём тех же экспертов и вместе с ними проставляем вероятность, как относительную величину из списка: очень высокая (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%) |
По каждой из характеристик выбираешь воздействие (сверху в таблице указан % влияния каждой характеристики в колонке), высчитываешь среднее арифметическое и получаешь уровень воздействия произошедшего риска на проект. Затем по матрице воздействия определяем приоритет для риска:
Если риска попадает в красную зону – для него нужно обязательно вырабатывать противорисковое мероприятие. На зелёные риски можно не тратить время, ресурсы и бюджет проекта. С жёлтыми рисками – на усмотрение команды проекта. Если есть возможности – работаем с рисками, нет – просто мониторим без каких-либо затратных действий.
Шаблоны документов для анализа рисков проекта те же:
|
Ну, и теперь полностью раскрываем секрет оружия под названием “риск-менеджмент”.
Дополни график противорисковыми мероприятиями
Для рисков красной зоны и некоторых рисков жёлтой зоны команда проекта должна разработать планы мероприятий по следующим возможным направлениям:
- Исключить риск, т.е. переделать график и технологию исполнения проекта так, чтоб риск вообще не мог произойти. Например, если есть риск того, что самолёт упадёт – мы не летим самолётом и исключаем этот риск.
- Передать риск, т.е. отдать риск сторонней компании. Например, застраховать или передать подрядчику по контракту. Таким образом мы несём дополнительные затраты, а сторонняя компания берёт на себя наш риск.
- Уменьшить риск. И тут возникает два направления:
- Уменьшить вероятность риска. Например, если мы знаем, что в октябре могут быть дожди, мы переноси отпуск на сентябрь. Дожди не исключены, но вероятность меньше.
- Уменьшить влияние риска. Например, если мы знаем, что в обед может пойти дождь, мы берём с собой зонт. Мы всё равно промокнем, но не так сильно, как без зонта.
Все придуманные мероприятия аккуратно заносим в график проекта, привязываем к соответствующим этапам и работам, назначаем ответственных и отправляем им в виде конкретных задач.
Вот таким нехитрым способом мы переходим от понимания, что в проекте есть риски, к конкретным (задокументированным в графике) задачам, для конкретных людей, в определённые сроки.
Шаблоны документов для планирования противорисковых мероприятий проекта:
|
Итого
С точки зрения документирования, итог планирования управления рисками проекта выглядит следующим образом:
- Реестр рисков дающий нам понимание, какие риски могут произойти в проекте, их основные характеристики и приоритет рисков друг относительно друга.
- Расписание проекта, которое объединяет операций проекта, длительности, зависимости и другую информацию о планировании, а так же включает все задачи по управлению рисками проекта.
- Шаблоны всех этих и других документов по управлению рисками проекта можно получить/полистать здесь:
- ОСУП.Риски.Комплект по PMBOK (5th edition).
- ИСО21500:Риски по ISO 21500:2012.
- Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
- Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект
- Все примеры и шаблоны документов портала PMDoc, связанные с управлением рисками различных проектов, можно получить здесь: Риски проекта.
В следующей статье я расскажу, как документировать качество проекта.
Оставить ответ
Хотите присоединиться к дискуссии?Не стесняйтесь вносить свой вклад!