Определение риска
Определений рисков огромное множество и все они, в принципе, общеизвестны и интуитивно понятны. Приведу тут лишь несколько запомнившихся мне цитат.
Risks are schedule delays and cost overruns waiting to happen (by Peter Kulik)
Risk is the possibility of suffering loss (SEI, Dorofee 96)
Также следует понимать основное отличие понятия риска от понятия проблемы:
- риск это некоторое событие, которое может случиться в будущем и может привести к определенным потерям (снижение качества продукта, перерасходование бюджета, задержка сроков либо полной неудачи проекта)
- проблема же – это событие, которое уже случилось. Риски превращаются в проблемы, если с ними не работать
Некоторые термины и определения
- Риск – некоторое событие или условие, которое может позитивно либо негативно повлиять на результат проекта (план, качество, стоимость, объем реализованной функциональности)
- Вероятность риска (Likelihood) – вероятность того, что риск сработает. Является одним из атрибутов риска и может измеряться целыми числами от 1 до 4 (где 1 – очень низкая вероятность, 4 – высокая вероятность)
- Влияние риска (Impact) – обозначает величину позитивных или негативных последствий для проекта, если риск срабатывает. Является одним из атрибутов риска и может измеряться целыми числами от 1 до 4 (где 1 –малое влияние, 4 – блокирующее влияние). Может также носить название «потери»
- Величина риска (Risk Exposure) – произведение вероятности на влияние риска (Risk Exposure = Likelihood x Impact)
- Mitigate (к сожалению, не смог адекватно перевести) – разрабатывать стратегии и план действия для снижения вероятности и/или влияния риска до какого-либо приемлемого уровня (к примеру, можно использовать матрицу величины риска, речь о которой пойдет позже)
- Mitigation strategy – план действий, направленный на снижение вероятности и/или влияния риска до какого-либо приемлемого уровня (план митигации рисков)
- Contingency – подход, направленный на минимизацию влияния риска после того, как он сработал
- Contingency plan – план, направленный на снижения влияния риска (последствий риска) после того, как риск сработал
Следует различать понятия Mitigation и Contingency – первый относится к рискам, второй – к проблемам. Реализовывать mitigation plan – снижать или вероятность или влияние риска когда/если он наступит; реализовывать contingency plan – снижать последствия уже наступившего риска.
Для одного и того же риска могут разрабатываться оба плана, но в большинстве случаев – только один (тут уже надо решить что важнее – не допустить срабатывания риска, или же минимизировать потери при его срабатывании). Также при разработке mitigation plan часто руководствуются либо только стратегией снижения влияния или только стратегией снижения вероятности риска (что позволяет экономить – зачем направлять усилия на снижение влияния риска, если одновременно снижается и его вероятность).
Процесс управления рисками
Ниже перечислены шаги, которые я обычно выделяю в процессе управления рисками.
- идентификация рисков
- анализ рисков
- планирование рисков
- разрешение рисков
- отслеживание и модификация данных по рискам (параметров и/или планов и стратегий)
С чего начать?
С чего начинается процесс управления рисками на проекте? Согласно теории – с идентификации риска(ов). Необходимо составить список рисков, которые бы наиболее полно отражали картину рисков и потенциальных проблем на проекте. Следует помнить, однако, что даже самый большой список никогда не будет полным – что-то всегда будет упущено. 😉
Анализ
Результатом этого этапа является качественная и количественная оценка риска, которая может проводиться по следующим направлениям:
- оценка риска – определение значений атрибутов Вероятность риска (Likelihood) и Влияние риска (Impact)
- классификация риска – группировка рисков, основанная на каких-либо характеристиках (например, по типу рисков их можно разделить на «Quality», «Management», «Hardware», «Software» и тд)
- приоритизация риска – расставление приоритетов. Практически приоритизация делается на основе матрицы величины риска, о которой я говорил выше
Likelihood\Impact | Small =1 | Medium=2 | Critical=3 | Blocking=4 |
Very likely=4 | 4 | 8 | 12 | 16 |
High =3 | 3 | 6 | 9 | 12 |
Medium =2 | 2 | 4 | 6 | 8 |
Very low probability =1 | 1 | 2 | 3 | 4 |
При таком определении величина риска является простейшим способом определить количественную характеристику риска. Практически имеет смысл отслеживать и управлять рисками, которые находятся на главной диагонали данной матрицы или выше ее (то есть со значениями величины риска большими или равными 4 или 6).
После анализа риска мы можем составить топ10 рисков (Top 10 Risk List), выстроив риски по убыванию значения величины риска и выбрав первые десять. Следует помнить, что выбор большего числа рисков может превратить управление рисками в очень тяжелый процесс, который будет слишком дорог и неэффективен.
Планирование
Основной задачей планирования является ответ на вопрос, как мы будем обрабатывать каждый из рисков. Тут возможны следующие варианты:
- исследование риска (research) – проведение дальнейшего исследования риска для его детализации и более аккуратного планирования
- принятие риска (accept) – мы принимаем риск и готовы жить с его последствиями
- избежание риска (avoid) – мы предполагаем, что риск никогда не станет реальностью
- передача риска (transfer) – передача риска и ответственности за него в другую команду, другому менеджеру (возможно и руководству компании), другому лицу
Непосредственно для управления рисками должны быть разработаны mitigation strategy (действия, которые мы предпринимаем для снижения вероятности и/или влияния риска до какого-либо приемлемого уровня, если мы выбрали эту стратегию) и contigency plan (план действий на случай, если риск сработал).
Разрешение рисков
На данном этапе фактически происходит разрешение риска после того, как он сработал. То есть выполняется соотвуетствующий contingency plan. Задача этапа – выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о данном риске для следующего этапа.
Отслеживание и модификация данных по рискам
В данном этапе преследуются следующие цели:
- мониторинг статуса рисков
- мониторинг статуса mitigation strategy и contingency plan
- мониторинг проектных метрик, которые связаны с планами действий
- определять и извещать все заинтересованные стороны о том, что сработал триггер того или иного плана действий
Так как ситуация на проекте постоянно меняется, то необходимо постоянно отслеживать изменения параметров рисков, корректируя «Top 10 Risk List»:
- идентификация новых рисков, которые не учитывались до этого
- изменение количественных оценок на риски (возврат к этапу анализа, Top 10 Risk List может значительно измениться)
- определение, явилось ли изменение количественных оценок (если таковые есть) результатом выполнения тех или иных планов действий (mitigation strategy или contingency plan). Если величина риска снижается, то, скорее всего, mitigation strategy реализуется успешно, однако не стоит сильно обольщаться на этот счет
- определение методов и способов коррекции планов действий с учетом определенных изменений, переход к планированию
Заключение
Ключевым моментом процесса управления рисками должно быть периодическое повторение данных процессов, желательно согласованное с длительностью циклов разработки и рабочих процессов. Можно порекомендовать проводить оценку рисков один раз в 1-2 недели в зависимости от размера проекта (в некоторых особо крупных проектах периодичность может быть увеличена до месяца, однако больше я бы делать не стал).
Также хочу порекомендовать сохранять историю изменений списка рисков и их параметров (хотя бы Top 10 Risk List) – в будущем это даст нам необходимые статистические данные.
Постскриптум
Хочется отметить, что информация, приведенная выше, является выжимкой из большой, официальной и предельно формализованной процедуры по менеджменту рисков, которую я создал для компании, в которой работаю. Опущены некоторые формальные этапы (например, планирование управления рисками, контроль), для приведенных этапов дано описание их сути, что помогает понять их, но оставляет определенную свободу выбора и гибкость при применении на различных проектах.
Однако, можно обозначить пути для дальнейшего развития статьи
детализация этапов (входные и выходные документы, ключевые активности и ответственности исполнителей)
предложения по формату документов, которые могут использоваться в процессе
обсуждение наиболее общих рисков и стратегий по их разрешению (так называемый Risk Assessment document)
P.S. Mitigate — смягчать (риски), Risk mitigation- смягчение рисков
contingency — непредвиденное обстоятельство