10 - проект провален;
9 - превышение бюджета на 40% или срыв сроков на 40%;
8 - превышение бюджета на 30% или срыв сроков на 30%;
7 - превышение бюджета на 20% или срыв сроков на 20%;
6 - превышение бюджета на 10% или срыв сроков на 10%;
5 - слегка превышен бюджет проекта;
4 - существенное использование резервного времени или фонда резервных затрат проекта, но в пределах бюджета;
3 - среднее использование резервного времени или фонда резервных затрат проекта;
2 - незначительное использование резервного времени или фонда резервных затрат проекта;
1 - никакого реального воздействия на проект[21].
Многие компании ошибочно используют трехуровневые шкалы воздействия рисков типа "высокая-средняя-низкая". Проблема состоит в том, что такой подход сделает распределение рисков при их сортировке на стадии качественного анализа слишком плотным. Придется еще долго разбираться со всеми рисками, которые попадут в графу "высокая вероятность - сильное воздействие". Будет сложно понять, какие риски окажутся приоритетными[22].
Кроме степени влияния, необходимо определить вероятность возникновения риска. На этом шаге вероятность также определяется субъективно. Необходимо помнить тот факт, что риск не может быть вероятен на 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-карты вносятся вероятность данного риска и степень влияния[23].
Шаг 5. Ранжирование и выбор значимых рисков
Кроме процедуры сортировки рисков необходимо проранжировать риски - определить RR (risk ranking) для каждого риска. Формула для определения RR такова:
RR = Вероятность риска х Степень воздействия риска
Отчасти этот шаг повторяет сортировку рисков по карте, однако специалисты советуют проводить его, так как это понадобится в дальнейшем. Потом уже можно определить, какие риски будут запущены в процесс управления рисками. Список рисков согласно значению RR позволяет отсортировать их. Таким образом, риски, которые возникают с очень низкой вероятностью или будут оказывать очень незначительное воздействие на проект, могут быть удалены из дальнейшего анализа.
Самое важное на этом шаге - принять решение по поводу пороговых величин рисков, которые будут участвовать в дальнейшем рассмотрении. Это сложный вопрос, по которому трудно дать конкретные рекомендации. Огромную роль здесь играет опыт руководителя проекта, а также уровни рисков, которые приняты как пороговые в компании. Если в компании принят максимальный уровень риска проектов 77 (степени влияния по шкале 4 и вероятности от 1 до 10), то все риски, имеющие RR выше 45-50, должны быть признаны значимыми. Все риски, имеющие RR ниже 45-50, документируются, но в работу по управлению рисками не запускаются[24].
Еще один совет состоит в том, чтобы проанализировать риски на предмет их принадлежности к определенной задаче. Это делается сортировкой RMC-карт. Если среднее число рисков для различных задач проекта равно 3, а для некоторой задачи было идентифицировано 10 рисков, со значениями RR, колеблющимися от 10 до 50, то такие риски также стоит признать значимыми и вносить в план по управлению рисками.
Следует проанализировать и причины рисков. В формате идентификации рисков, который мы обсуждали в предыдущей статье - Cause-Risk-Effect (CRE), - есть дополнительное преимущество: можно отсортировать данный список по причинам. Здесь важно отметить, что при определении риска в CRE-форме очень важно грамотно описать причину риска, а не ограничиваться общими словами. В таблице 5 мы приводим примеры правильно и неправильно описанного риска. Именно это позволяет грамотно сортировать риски по причинам. Часто такая сортировка показывает, что какая-то причина, сотрудник или событие вызывает более чем один риск[25]. Таким образом, претендентами на дальнейшее участие в процессе управления рисками являются риски с высоким рангом, задачи с количеством рисков, сильно отклоняющимся от среднего по задаче, и часто встречающиеся причины рисков.
Таблица 5
Неправильное и правильное определение риска
| Причина | Риск | Эффект |
| Неправильно определенный риск | ||
| Есть проблемы с системой backup\recovery | Может привести к потере важных данных | ? |
| Риск, определенный согласно стандарту | ||
| Было три случая, когда система backup\recovery не срабатывала. Хотя и были предприняты попытки определить и устранить причину сбоев, однако на момент старта данного проекта ничего так и не было сделано. | Означает, что backup\recovery опять может дать сбой | Что может привести к потере важных данных и результатов тестирования в рамках проекта |
Шаг 6. Общий риск проекта
Следующий шаг - определить общий риск, с которым компания еще способна смириться, чтобы запустить проект в работу. Как правило, данная шкала допустимости в компании предопределена. Общий риск проекта (risk score, RS) определяется как среднее арифметическое всех значимых рисков проекта:
RS = ? RR / N,
где
RR = Вероятность риска
x Степень воздействия риска
N = общее количество рисков данного проекта[26]
Обычно возникают разные мнения по поводу того, где установить порог для проекта. Это тоже сложный вопрос, и трудно дать конкретные рекомендации. Топ-менеджменту компании порог, как правило, видится несколько иначе, чем функциональным заказчикам проекта, и иначе, чем руководителю проекта. В компаниях, которые ввели управление рисками проектов в повседневную практику, это порог установлен. В этом случае появляются возможности взаимодействия с топ-менеджментом компании на новом уровне. Например: "Мы были необыкновенно заинтересованы в работе над данным проектом, однако в результате подготовительной работы было установлено, что риск проекта превышает отметку 77, допустимую в компании. К сожалению, нам придется отказаться от выполнения данного проекта в связи с неоправданностью риска для данного проекта". Или: "Риск данного проекта находится на уровне 75. Топ-менеджмент компании согласен инвестировать в проект дополнительно 100 тыс. долларов, если удастся снизить показатель риска до 60". Именно на этом шаге принимается решение о продолжении или сворачивании проекта[27].
Шаг 7. Документирование незначимых рисков
Что делать с рисками, которые были "признаны легковесными" и не включены в дальнейшее планирование управления рисками? Разумный подход к решению этого вопроса - принять во внимание следующее: невозможно до начала проекта спрогнозировать проект на 100%, поэтому по мере выполнения проекта и обретения лучшего понимания его составляющих рейтинги рисков будут меняться. Значит, риски, не вошедшие в дальнейшее управление рисками, должны быть задокументированы, чтобы можно было по мере выполнения проекта быстро понять, как ведет себя данный риск. Удобным форматом документирования является форма NTR (Non-top risk), показанная в таблице 6.
Таблица 6
NTR-форма
| Риск | Задача | Вероятность | Степень воздействия | RR (Risk Ranking) |
Шаг 8. Количественный анализ или RRP?
После качественного анализа рисков необходимо перейти либо к количественному анализу, либо напрямую к процедуре RRP (Risk Response Planning). Как определить, необходимо ли переходить к количественному анализу или к RRP?
На самом деле опыт показывает, что количественный анализ рисков не так уж важен, как большинство почему-то склонно считать. Поэтому очень многие проекты ограничиваются этапом субъективного качественного анализа рисков.