Управление рисками проекта: основные моменты (Часть 2)

Продолжаем публикацию статей по Управлению рисками проекта. В настоящей статье касаемся некоторых следующих этапов управления рисками: количественный и качественный анализ, мониторинг и контроль. 

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

 Качественный анализ рисков

В целом этап качественного анализа рисков разбивается на восемь шагов.

Шаг 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

Шаг 3. Выбор шкал степени воздействия и оценка вероятности возникновения риска

После завершения работы с погрешностью данных необходимо определить степень воздействия на проект каждого риска. Для этого необходимо понять, какие шкалы степени воздействия рисков будут использованы и какие методы качественного анализа могут применяться. Шкалы представляют собой определенные наборы степеней воздействия рисков на проект в целом. На данном шаге шкала воздействия определяется субъективно. Если в организации шкалы степени воздействия тех или иных рисков не были стандартизированы, можно принять одну из предлагаемых в таблице 3. Можно построить и свои шкалы.

Таблица 3. Шкалы степени воздействия рисков

Шкала	Степени воздействия на проект
1	Очень низкая		Низкая		Средняя		Высокая		Очень высокая
2	0,05		0,1		0,2		0,4		0,8
3	0,1		0,3		0,5		0,7		0,9
4	1	2	3	4	5	6	7	8	9	10
Примечание:  Степени воздействия, измеряемые в пределах от 1 до 10, интерпретируются в стандартном случае следующим образом. 10 - проект провален; 9 - превышение бюджета на 40% или срыв сроков на 40%; 8 - превышение бюджета на 30% или срыв сроков на 30%; 7 - превышение бюджета на 20% или срыв сроков на 20%; 6 - превышение бюджета на 10% или срыв сроков на 10%; 5 - слегка превышен бюджет проекта; 4 - существенное использование резервного времени или фонда резервных затрат проекта, но в пределах бюджета; 3 - среднее использование резервного времени или фонда резервных затрат проекта; 2 - незначительное использование резервного времени или фонда резервных затрат проекта;  1 - никакого реального воздействия на проект.

Многие компании ошибочно используют трехуровневые шкалы воздействия рисков типа "высокая-средняя-низкая". Проблема состоит в том, что такой подход сделает распределение рисков при их сортировке на стадии качественного анализа слишком плотным. Придется еще долго разбираться со всеми рисками, которые попадут в графу "высокая вероятность - сильное воздействие". Будет сложно понять, какие риски окажутся приоритетными.

Кроме степени влияния, необходимо определить вероятность возникновения риска. На этом шаге вероятность также определяется субъективно. Необходимо помнить тот факт, что риск не может быть вероятен на 100% или даже на 80%. Такая вероятность выводит проблему из разряда рисков и переводит в разряд фактов, а потому должна быть учтена в плане проекта.

Шаг 4. Сортировка рисков

Далее риски необходимо отсортировать. Разберем реальную технику сортировки большого количества рисков, которая зарекомендовала себя на примере не одной сотни компаний. Она активно используется и пропагандируется подразделением Risk Management Special Interest Group (RMSIG) из Project Management Institute.

Суть метода состоит в том, чтобы распределить риски по специальной карте (другое ее название - PI-матрица). Карта должны выглядеть так, как показано в таблице 4. Обычно все идентифицированные риски распределяются между сотрудниками группы по работе с рисками. За риск, как правило, отвечает тот, кто идентифицировал данный риск (источник указан на RMC-карте). Риски, определенные теми, кто не присутствует при данной процедуре, делятся поровну между всеми остальными участниками. Затем участники распределяют имеющиеся у них риски по определенным квадратам, то есть ранжируют вероятности и степени влияния данных рисков.

Таблица 4. Карта сортировки рисков

Вероятность	10
	9
	8
	7
	6
	5
	4
	3
	2
	1	1	2	3	4	5	6	7	8	9	10
	Степень воздействия

Некоторые специалисты из RMSIG рекомендуют проводить эту процедуру в реальности, то есть физически начертить карту размером 2х2 метра, раздать участникам RMC-карты созданные ранее и разложить их по квадратам. Бывает необходимо повысить качество индивидуальных решений о вероятности и степени влияния рисков - такие решения могут быть недостаточно аккуратны. Рекомендуется раздать членам команды фломастеры разных цветов и предложить, просмотрев все риски, промаркировать те, с которыми они не согласны и которые, по их мнению, необходимо обсудить отдельно. После этого маркированные риски обсуждаются, и делаются соответствующие изменения.

По окончании данного шага вероятность и степень воздействия каждого риска на проект считается установленной, и в RMC-карты вносятся вероятность данного риска и степень влияния.

Шаг 5. Ранжирование и выбор значимых рисков

Кроме процедуры сортировки рисков необходимо проранжировать риски - определить RR (risk ranking) для каждого риска. Формула для определения RR такова:

RR = Вероятность риска х Степень воздействия риска

Отчасти этот шаг повторяет сортировку рисков по карте, однако специалисты советуют проводить его, так как это понадобится в дальнейшем. Потом уже можно определить, какие риски будут запущены в процесс управления рисками. Список рисков согласно значению RR позволяет отсортировать их. Таким образом, риски, которые возникают с очень низкой вероятностью или будут оказывать очень незначительное воздействие на проект, могут быть удалены из дальнейшего анализа.

Самое важное на этом шаге - принять решение по поводу пороговых величин рисков, которые будут участвовать в дальнейшем рассмотрении. Это сложный вопрос, по которому трудно дать конкретные рекомендации. Огромную роль здесь играет опыт руководителя проекта, а также уровни рисков, которые приняты как пороговые в компании. Если в компании принят максимальный уровень риска проектов 77 (степени влияния по шкале 4 и вероятности от 1 до 10), то все риски, имеющие RR выше 45-50, должны быть признаны значимыми. Все риски, имеющие RR ниже 45-50, документируются, но в работу по управлению рисками не запускаются.

Еще один совет состоит в том, чтобы проанализировать риски на предмет их принадлежности к определенной задаче. Это делается сортировкой RMC-карт. Если среднее число рисков для различных задач проекта равно 3, а для некоторой задачи было идентифицировано 10 рисков, со значениями RR, колеблющимися от 10 до 50, то такие риски также стоит признать значимыми и вносить в план по управлению рисками.

Следует проанализировать и причины рисков. В формате идентификации рисков, который мы обсуждали в предыдущей статье - Cause-Risk-Effect (CRE), - есть дополнительное преимущество: можно отсортировать данный список по причинам. Здесь важно отметить, что при определении риска в CRE-форме очень важно грамотно описать причину риска, а не ограничиваться общими словами. В таблице 5 мы приводим примеры правильно и неправильно описанного риска. Именно это позволяет грамотно сортировать риски по причинам. Часто такая сортировка показывает, что какая-то причина, сотрудник или событие вызывает более чем один риск. Таким образом, претендентами на дальнейшее участие в процессе управления рисками являются риски с высоким рангом, задачи с количеством рисков, сильно отклоняющимся от среднего по задаче, и часто встречающиеся причины рисков.

Таблица 5. Неправильное и правильное определение риска

Причина	Риск	Эффект
Неправильно определенный риск
Есть проблемы с системой backup\recovery	Может привести к потере важных данных	?
Риск, определенный согласно стандарту
Было три случая, когда система backup\recovery не срабатывала. Хотя и были предприняты попытки определить и устранить причину сбоев, однако на момент старта данного проекта ничего так и не было сделано.	Означает, что backup\recovery опять может дать сбой	Что может привести к потере важных данных и результатов тестирования в рамках проекта

Шаг 6. Общий риск проекта

Следующий шаг - определить общий риск, с которым компания еще способна смириться, чтобы запустить проект в работу. Как правило, данная шкала допустимости в компании предопределена. Общий риск проекта (risk score, RS) определяется как среднее арифметическое всех значимых рисков проекта:

RS = ? RR / N, где 

RR = Вероятность риска x Степень воздействия риска

N = общее количество рисков данного проекта

Обычно возникают разные мнения по поводу того, где установить порог для проекта. Это тоже сложный вопрос, и трудно дать конкретные рекомендации. Топ-менеджменту компании порог, как правило, видится несколько иначе, чем функциональным заказчикам проекта, и иначе, чем руководителю проекта. В компаниях, которые ввели управление рисками проектов в повседневную практику, это порог установлен. В этом случае появляются возможности взаимодействия с топ-менеджментом компании на новом уровне. Например: "Мы были необыкновенно заинтересованы в работе над данным проектом, однако в результате подготовительной работы было установлено, что риск проекта превышает отметку 77, допустимую в компании. К сожалению, нам придется отказаться от выполнения данного проекта в связи с неоправданностью риска для данного проекта". Или: "Риск данного проекта находится на уровне 75. Топ-менеджмент компании согласен инвестировать в проект дополнительно 100 тыс. долларов, если удастся снизить показатель риска до 60". Именно на этом шаге принимается решение о продолжении или сворачивании проекта.

Шаг 7. Документирование незначимых рисков

Что делать с рисками, которые были "признаны легковесными" и не включены в дальнейшее планирование управления рисками? Разумный подход к решению этого вопроса - принять во внимание следующее: невозможно до начала проекта спрогнозировать проект на 100%, поэтому по мере выполнения проекта и обретения лучшего понимания его составляющих рейтинги рисков будут меняться. Значит, риски, не вошедшие в дальнейшее управление рисками, должны быть задокументированы, чтобы можно было по мере выполнения проекта быстро понять, как ведет себя данный риск. Удобным форматом документирования является форма NTR (Non-top risk), показанная в таблице 6.

Таблица 6. NTR-форма

Риск	Задача	Вероятность	Степень воздействия	RR (Risk Ranking)

Шаг 8. Количественный анализ или RRP?

После качественного анализа рисков необходимо перейти либо к количественному анализу, либо напрямую к процедуре RRP (Risk Response Planning). Как определить, необходимо ли переходить к количественному анализу или к RRP?

На самом деле опыт показывает, что количественный анализ рисков не так уж важен, как большинство почему-то склонно считать. Поэтому очень многие проекты ограничиваются этапом субъективного качественного анализа рисков.

В общем случае переходить к количественному анализу имеет смысл, если:

• есть инструменты количественного анализа рисков;
• количественный анализ стоит затрат времени и средств потраченных на него;
• приоритет проекта очень высокий или же проект находится в центре внимания руководства по другим причинам;
• проект практически не допускает дополнительных затрат и нарушений расписания проекта.

Непосредственно к процедуре Risk Response Planning стоит переходить, если:

• проект краткосрочный или малобюджетный;
• у вас еще недостаточно опыта в управлении рисками, и количественный анализ пока является проблемой.

Количественный анализ рисков

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

Итак, в предыдущей статье мы остановились на моменте, когда риски корректно идентифицированы и проведен их качественный анализ, после чего можно переходить либо сразу к этапу RRP (Risk Response Planning), либо к количественному анализу рисков (QRA, Quantitative Risk Analysis).

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

Проведение количественного анализа рисков требует времени. Задача менеджера проекта состоит в том, чтобы грамотно сбалансировать необходимость количественного анализа с требованиями проекта. Сколько времени и сил потратить на количественный анализ, должен решать сам менеджер, но, как правило, чем важнее проект, тем больше времени затрачивается на QRA. Другая проблема состоит в том, что очень часто менеджмент компании состоит из людей, которые не любят иметь дело с вероятностями и, боже упаси, с распределением вероятностей. Если руководитель проекта не понимает этого, то своим количественным анализом он скорее всего добьется прямо противоположного результата, а именно - отвернет управление компании от той части проекта, которая как раз требует внимания. Тут важно чувствовать баланс между представлением на рассмотрение существенных вопросов и их количественной поддержкой.

Способы получения оценок

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

С точки зрения оптимизации времени проработки данных важно понять, что все принимаемые решения будут находиться в промежутке между двумя полюсами: на 100% объективные данные, которые достигаются за счет полного понимания ситуации и наличия всех необходимых данных с одной стороны и на 100% субъективные данные, основанные только на интуиции и предположениях без какой-либо фактической поддержки. Первое недостижимо, поэтому лучшая стратегия руководителя проекта состоит в том, чтобы уделить соответствующее количество времени и усилий, чтобы собрать максимально аккуратные данные.

Наиболее распространенные способы получения количественной оценки рисков:

• субъективное предположение о процентной вероятности, финансовых затратах и времени;
• прямой подсчет реальной стоимости или временных затрат;
• использование исторических данных: какие были вероятности, временные или финансовые затраты для рисков на предыдущих аналогичных проектах;
• дельфи-техника (см. Часть 1);
• интервью с экспертом.

Очевидно, что эти способы получения цифр количественной оценки рисков аналогичны качественному анализу и это не должно удивлять. Согласно инструкциям PMI RMSIG угадывать цифры вероятности и степени воздействия является допустимым. Например, "полагаю, такой-то риск увеличит работу надо проектом на две недели, или будет стоить дополнительных 34 тыс. долларов". Или "я работал над похожими проектами раньше и полагаю, что вероятность риска порядка 20%". Руководитель проекта скорее всего столкнется с тем, что погрешность таких суждений слишком велика, чтобы базировать на них какое-то решение, однако снижения погрешности можно добиться выставляя на оценку небольшие части проекта, а также предоставляя как можно больше деталей тому кто будет проводить оценку. Чтобы количественно оценить риски, интервьюируя людей, необходимо провести довольно много различных интервью с различными специалистами.

Важные этапы проведения количественного анализа рисков: 1. Определить, какие методы количественного анализа будут применены, кто и как будет осуществлять эти оценки. 2. Определить цифры вероятностей и степени влияния рисков, если они не определены на стадии качественного анализа рисков. 3. Определить, какие риски требуют мероприятий RRP. 4. Определить, какие задачи требуют мероприятий RRP. 5. Определить ожидаемую величину стоимости риска проекта в целом. 6. Определить стоимость и продолжительность проекта в том случае, если никакие дальнейшие действия не будут предприняты. 7. Определить вероятность того, что проект будет окончен в рамках расписания и бюджета.

Ожидаемая величина риска

Количественной оценки риска можно добиться, используя понятие "ожидаемой величины стоимости риска" (expected value of the cost). Данная величина просчитывается так:

Ожидаемая величина стоимости риска = Вероятность риска х оценку стоимости влияния риска

Например, вероятность возникновения риска составляет 30%. Если дополнительные затраты в случае возникновения данного риска составляют 66 тыс. долларов, ожидаемое значение стоимости будет 0,3 * 66 000 = 19 800 долларов. Такой подход позволяет достаточно легко решить, сколько и каких рисков должны быть запущены в работу управления рисками. В работу запускаются риски, ожидаемое значение которых находится выше определенного порогового значения, по поводу которого вынесено решение компании. Например, менеджмент компании решает, что любые риски с ожидаемой величины стоимости 2500 долл. и выше будут запущены в работу. Эта политика становится руководствующей в отношении отбора рисков для дальнейшей отработки в русле управления рисками. Заметим, что, как и при качественном анализе, в дальнейшую работу берутся не только риски с превышающим пороговый показателями, но также и задачи, для которых определено большое количество рисков.

Если теперь просуммировать эти стоимости для всех идентифицированных рисков, будет получена цифра ожидаемого значения для проекта. Рассмотрим пример. Вы планируете проект внедрения ИТ-системы. Результаты оценки показывают, что проект обходится в 600 тыс. долл. Однако:

А. Есть 5%-ные вероятности задержки получения определенных комплектующих, что выльется в дополнительные затраты в 75 тыс. долл.

Б. Есть 55%-ные вероятности того, что аппаратное обеспечение обойдется на 60 тыс. долл. дешевле, чем ожидается.

В. Есть 75%-ные вероятности того, что будут проблемы с совместимостью определенных элементов, и это приведет к дополнительным затратам в 100 тыс. долл.

Г. Есть 5%-ная вероятность того, что стечение обстоятельств позволит внедрению пройти легче, чем ожидается, и это даст экономию в 25 тыс. долл.

Д. Есть 15%-ная вероятность определенных архитектурных недочетов, которые потребуют доработок стоимостью 8 тыс. долл.

Все это надо свести в таблицу (таблица 1). Таким образом, общая стоимость ожидаемых рисков по данному проекту с учетом всех возможностей составит 45 700 долл.

Таблица 1. Ожидаемая величина стоимости риска проекта

Риск	Расчеты	Ожидаемая величина стоимости риска
А.	0,05 * $75 000	$3750
Б.	0,55 * $60 000	-$33 000
В.	0,75 * $100 000	$75 000
Г.	0,05 * $25 000	-$1250
Д.	0,15 * $8000	$1200
Итого		$45 700

На этом процесс не заканчивается. Необходимо еще подсчитать следующие параметры (таблица 2):

1. Стоимость проекта при самом оптимальном стечении обстоятельств.
2. Стоимость проекта, ожидаемая управлением компании (цифра без какой либо поправки на риски).
3. Наиболее вероятная стоимость проекта с учетом стоимости ожидаемых рисков
4. Наихудший вариант стоимости проекта (WCC, worst case cost)

Таблица 2. Параметры стоимости проекта.

№	Позиция	Расчеты	Результат
1	Стоимость проекта при самом оптимальном стечении обстоятельств	600 000 - (60 000 + 25 000)	515 000
2	Стоимость проекта, ожидаемая управлением компании		600 000
3	Наиболее вероятная стоимость проекта с учетом стоимости ожидаемых рисков	600 000 + 45 700	645 700
4	Наихудший вариант стоимости проекта	600 000 + 75 000 + 100 000 + 8000	783 000

В реальности оценки проекта не ставятся жестко, они всегда находятся в определенном коридоре, заданном неопределенностями проекта. Следовательно, если мы примем во внимание неопределенности проекта, вероятно, что проектная стоимость окажется где-то между 515 тыс. и 783 тыс. Если такой разброс выходит за допустимые пределы в этом случае необходимо осуществить процедуру RRP (risk response planning) для того чтобы упразднить определенные риски. После чего делается повторная калькуляция и переопределяется разброс вероятной стоимости проекта.

Данные расчеты вскрывают один из важнейших моментов процесса управления проектами. Методология управления рисками позволяет показать, что сроки или стоимость проекта, установленные менеджментом, нереальными. Допустим, что в нашем примере менеджмент компании требует, чтобы данный проект не превышал 620 тыс. долл. Расчеты показывают, что это вряд ли возможно при существующем уровне рисков проекта. Либо должны быть уменьшены риски, либо увеличен бюджет. Менеджменту компании это может не понравиться, но ведь известно, что проект, у которого наиболее вероятная стоимость проекта с учетом стоимости ожидаемых рисков - 645 700 долл., не может быть гарантированно закончен за 620 000 долл.

По окончании этапа количественного анализа на руках руководителя проекта должны быть следующие документы: список количественно обработанных рисков, расписанный по приоритетам; прогноз потенциального времени выполнения и затрат по данному проекту (методом Монте-Карло или аналогичными расчетами); вероятность достижения планируемого времени выполнения проекта, масштаба работ, уровня удовлетворенности заказчиков, стоимости и качества проекта; тенденций, выявленных на данном этапе (главным образом для того, чтобы знать, где потребуется повторное выполнение процедур QRA); задокументированный список некритических рисков.

Метод Монте-Карло

Многие менеджеры проектов ошибочно полагают, что метод Монте-Карло и является самим процессом управления рисками. Это неправильно. Метод Монте-Карло позволяет спрогнозировать наиболее вероятную стоимость проекта и время необходимое для завершения проекта посредством оценки влияния неопределенностей на проект в целом. Чтобы метод Монте-Карло можно было применять, необходимо уже иметь на руках списки идентификационных рисков, оценки их вероятности и степени влияния. Понимание механизма, лежащего в основе данного метода, позволит менеджеру проекта не только обрести важное понимание природы прогнозирования, но и придаст уверенности в общении с менеджментом компании.

Рассмотрим пример. Допустим, ИТ-директор запрашивает определенный отдел, сколько времени потребуется на выполнение той или иной задачи. Отдел отвечает конкретно - 33 часа. Если задача более сложная и количество неопределенных моментов больше, отдел скорее всего ответит неопределенно, чаще всего, например, так: от 30 до 41 часа, скорее всего часа 33. Здесь 30 означает самую оптимистичную оценку, а 41 подразумевает случай, когда все, что можно, пойдет не так. Если бы ИТ-директор запросил наиболее оптимистичную, наиболее вероятную и пессимистичную оценки, то ответ был бы скорее всего: 30-33-41. Это можно представить графически (рис. 1). В данном случае три величины задают распределение вероятностей, что и является ответом. Очевидно, чем более широким является разброс, тем больше неопределенности таится в проекте.

Метод Монте-Карло используется именно в таких ситуациях, когда есть разброс вероятностей.

Метод Монте-Карло состоит в нахождении случайной выборки вероятностных значений и вычислении конечной стоимости и сроков выполнения проекта для этой выборки. Время и стоимость проекта пересчитываются исходя из различных допущений по времени и затратам для отдельных задач от 500 до нескольких тысяч раз на основании случайной выборки из возможных оценок. В результате строится график вероятности завершения проекта в определенное время или в пределах определенного бюджета (рис. 2). Понятно, что этот подсчет можно осуществить и вручную, однако количество вычислений, которое при этом надо будет проделать, трудноописуемо. Поэтому ПО для симуляций Монте-Карло и получило такое широкое распространение. (Здесь важно не дать себя запугать: ПО не говорит, что надо делать по ходу управления рисками, а только делает расчеты и дает представление о прогнозируемых сроках и затратах.)

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

Например, менеджмент компании спускает директиву о том, что проект должен быть закончен к 28 января с бюджетом 47,5 тыс. долларов. Из графика (см. выше) следует, что есть только 55% вероятности окончания проекта к этому сроку. Руководителю проекта необходимо сообщить об этом, а также дать показать, что наиболее вероятно окончить проект в конце февраля. (Здесь можно сказать, что большинство компаний в Америке считают допустимым ориентироваться на 90%-ную вероятность в планировании сроков окончания проекта.) Если же, что возможно, дата 28 января все-таки не может быть изменена, необходимо будет провести мероприятия RRP для снижения вероятности определенных рисков, идентифицированных ранее, после чего Монте-Карло осуществляется еще раз. Таким образом, стадия количественного анализа создает мощный фундамент для работы по управлению проектами.

Планирование минимизации рисков

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

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. Действия желательно планировать таким образом, чтобы каждое мероприятие работало на снижение вероятности или упразднение более чем одного риска.