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

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

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

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

Шаг 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 стоит переходить, если:

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