Risk Response Planning
Итак, мы подошли к предпоследнему, этапу процесса управления рисками. Теперь менеджеру проекта необходимо разработать меры, противодействующие появлению рисков или снижающие их величину. Этот этап носит название Risk Response Planning (RRP). В целом, любая из принимаемых ИТ-менеджером мер будет вписываться в следующие три вида:
1. Профилактические меры. Меры, принимаемые до возникновения риска и нацеленные на упразднение возможности появления риска или снижение вероятности его возникновения.
2. Меры по устранению риска (contingency plan). Меры, принимаемые в случае возникновения риска.
3. Резервный план (fallback plan). Меры, принимаемые в случае, если меры по устранению риска (contingency plan) оказываются неэффективными.
Основные принципы работы с последствиями рисков обычно разбиваются на четыре направления.
1. Избежать риска. Устранение, где это возможно, причин возникновения риска.
2. Снизить величину риска. Снижение ожидаемой величины риска за счет снижения вероятности возникновения самого риска или влияния риска.
3. Принять риск. Это активное принятие последствий риска и разработка мер по устранению риска.
4. Передать риск. Страхование от определенного риска или передача управления каким-либо риском третьей стороне.
При работе с каждым из существенных рисков, как правило, разрабатываются действия и процедуры во всех четырех направлениях, а потом делается выбор относительно того, какой тактики необходимо придерживаться. Все эти действия удобно заносить в RRP-форму, которая показана в таблице.
Таблица. Форма, используемая для планирования противодействия рискам
Risk Response Planning | ||||||
Наибольшие риски | Как избежать риска | Как снизить вероятность возникновения риска | Как снизить степень влияния риска на проект | Какие меры надо принять при возникновении риска | Возможно ли застраховаться от риска или передать его третьей стороне | Выбор |
Практика выделения резервов проекта1. Резерв проекта - 10%Распространенный прием создания резервов проекта - добавление 10% ко времени выполнения и стоимости проекта в качестве резервного как для известных неустранимых, так и для неизвестных рисков. Величина 10% возникла на основании средних величин резервов различных проектов. Данный способ усредненный и не является предпочтительным, так как не принимает во внимание риски конкретного проекта. Эти резервы ни на чем конкретном не основаны, а управляющему комитету проекта необходимо обоснование выделенных резервов. Тем не менее такое "угадывание" необходимого количества резервного времени и средств допустимо. Этот способ угадывания позволяет также отклоняться от цифры 10%, если менеджер проекта видит в этом необходимость. Резерв, созданный таким способом, лучше, чем отсутствие резервов вообще. 2. Ожидаемое значение для резерва проекта Если риски анализировались количественно, для вычисления величины резервов необходимо взять общую стоимость всех задач проекта и ожидаемую величину всех рисков. Эта сумма и будет величиной резервов для всех известных рисков (contingency reserve). Затем следует добавить 5% от общей стоимости проекта для неизвестных рисков (management reserve). В сумме получится стоимость резервов. Этот метод является самым предпочтительным и, как правило, не вызывает у управляющего комитета проекта никаких проблем. |
Как планировать противодействие рискам
Обычно, чтобы спланировать действия в соответствии с любым из рисков, ИТ-менеджеру необходимо следовать следующей достаточно очевидной процедуре.
Шаг 1. Попытаться избежать риска. На этом шаге ИТ-менеджер детально прорабатывает план проекта с целью устранения различных рисков.
Шаг 2. Попытаться снизить величину риска. На этом шаге план проекта прорабатывается с целью снижения вероятности и влияния рисков. Как правило, снижение вероятностей и степени влияния рисков связано с общими затратами на проект или временем выполнения проекта.
Шаг 3. Определить неустранимые риски. На этом шаге ИТ-менеджер определяет риски, не поддающиеся упразднению residual risks). Обо всех неустранимых рисках следует сообщить управляющему комитету проекта.
Шаг 4. Определить владельца риска (risk owner). Для каждого неустранимого риска необходимо назначить владельца риска. Это назначение позволяет существенно снизить время выполнения проекта в том случае, если риск все-таки проявится. Владелец риска ответственен за управление процедурами, связанными с этим риском. Наличие владельца риска позволит избежать собраний и совещаний, если риск возникает.
Необходимо принять во внимание важную деталь: владелец риска отличается от владельца задачи (task owner). Владелец задачи ответственен как за выполнение, так и за невыполнение задачи. Владелец риска не несет ответственности за возникновение риска, но ответственен за управление риском в случае его возникновения, эффективность данного управления, а также за отчетность по полученным результатам. Более того, выполнение задачи может быть связано с несколькими рисками, которые могут быть приписаны к нескольким владельцам риска.
Шаг 5. Создать план на случай возникновения риска (contingency plan) и резервный план (fallback plan) для всех неустранимых рисков. Хороший план - такой, при котором не только владелец риска точно знает, что необходимо делать, но продуманы и подготовлены и все необходимые вспомогательные элементы ответных действий, подписаны необходимые контракты с третьими сторонами и третья сторона находится в курсе того, что и как надо делать в случае необходимости. Резервный план создается на тот случай, если основной план не сработает. Часто резервный план может предполагать определенные дополнительные расходы. Здесь нужно убедиться, что затраты на основной и резервный планы меньше, чем величина риска. Очевидно, что планируемые действия не должны превышать потери, которые придется понести, если риск возникнет.
Как правило, эти планы создаются вместе с выведением триггеров. Триггеры обычно выводятся на основании трех вопросов:
- что случится прямо перед возникновением риска;
- есть ли измеримые показатели, с помощью которых можно понять, что риск вот-вот должен возникнуть;
- есть ли способ немедленно распознать, когда произойдет риск.
Шаг 6. Определить вторичные риски и создать основной и резервный планы для них. Под вторичными рисками понимаются риски, создаваемые плановыми действиями в ответ на первичный риск. Влияние вторичного риска не должно превышать масштабы первичного риска.
Шаг 7. Свести все риски в RRP-форму. Там же должны быть перечислены владельцы рисков, основной и резервный планы. Все триггеры также в обязательном порядке перечисляются в RRP.
Шаг 8. Создать резервы для каждого неустранимого риска. Резервы представляют собой запас времени и бюджета, добавляемые к проекту для эффективной работы с рисками. Резервы, которые запасаются для неустранимых рисков, называются contingency reserve. Резервы - необходимое условие управления и планирования. Правильный расчет резервов является обязанностью менеджера проекта.
Приведем примеры рисков, для устранения которых должны быть зарезервированы ресурсы:
- в связи с уходом ИТ-персонала создание критических компонент проекта было задержано;
- в связи с некорректными источниками данных требуется дополнительная работа по очистке данных, что приведет к общей задержке проекта;
- в связи с новой технологией и необходимостью в новых навыках возникла потребность в дополнительном персонале, что увеличивает стоимость проекта.
Если проводился количественный анализ рисков, из которого понятно, что проект не вписывается в плановые сроки и бюджеты, необходимо изменить показатели резервов для удержания проекта в планируемых рамках.
Шаг 9. Создать резервы для неизвестных рисков. Кроме резервов, предназначенных для работы с идентифицированными и известными рисками, необходимо создать резервы для неизвестных рисков, не идентифицированных в процессе создания. Они носят название management reserve. Резервы, оставляемые на случай появления неизвестных рисков, как правило, составляют от 2 до 15% от общей стоимости проекта в зависимости от размера резервов на идентифицированные риски.
Шаг 10. Обсудить результаты данной стадии управления рисками на управляющем комитете проекта. Кроме того, принять решение о продолжении или прекращении проекта, опираясь на результаты всего процесса управления рисками.
Обходные путиКроме обычных и резервных планов по устранению последствий каждого риска ИТ-менеджерам приходится использовать так называемые «обходные пути». Обходные пути — это незапланированные ответы на незапланированные риски. По сути, обходные пути представляют собой способ немедленного реагирования на возникшие непредвиденные ситуации. Однако не стоит возлагать на эти спонтанные действия серьезные надежды. По природе своей управление проектами должно быть профилактическим. Время менеджера проектами должно уходить на выполнение обычных и резервных планов, а не на то, чтобы изобретать обходные пути. Чем больше обходных путей требуется, тем ниже профессионализм управляющего проектами. |
Мониторинг и контроль рисков
Управление рисками не является одномоментным событием, а осуществляется периодически, по мере того как изменения произошли или проблемы обнаружены. Поэтому на протяжении всего проекта руководителю проекта необходимо проводить контроль рисков проекта. Стандартные задачи стадии мониторинга и контроля - приведение плана противодействия рискам в соответствие с текущим состоянием проекта, количественные и качественные анализы рисков, дополнительные идентификации рисков в ходе проекта.
Здесь необходимо ввести понятие аудита работы с рисками (risk response audit, RRA). RRA связан с анализом уже случившегося и того, как происходило управление рисками. Он никак не связан с планированием того, что только должно произойти. Аудит работы с рисками включает в себя проверку таких моментов: был ли приписан риску правильный владелец риска, является ли данный владелец риска достаточно эффективным, какова эффективность разработанных планов по устранению последствий рисков и расходования резервов проекта.
При работе с данными методиками важно помнить следующие аксиомы:
1. Уровень риска и предпринимаемые меры должны соответствовать друг другу. Как ни странно, но часто происходит так, что меры по предотвращению риска приводят к большим затратам, чем сам риск, если он возникает. 2. Действия желательно планировать таким образом, чтобы каждое мероприятие работало на снижение вероятности или упразднение более чем одного риска. |