Немного теории об управлении рисками

Вводная информация по управлению рисками

К теме управления рисками я решил обратиться по нескольким причинам:

• недавно я разрабатывал методику и процедуру по управлению рисками в компании, где я работаю (разработка ПО под заказ, аутсорсинг) – соответственно, было перерыто и изучено очень много материалов, информация из которых потом была структурирована и оформлена в отдельный документ, который сейчас используется
• само по себе управление рисками является одной из ключевых активностей на проекте: на мой взгляд одной из самых сложных, но в то же время интересных (из каждого риска и события можно извлечь выгоду)
• как показывает опыт работы в компаниях-разработчиках ПО, управлению рисками выделяется либо очень мало времени, либо ими начинают управлять только тогда, когда они становятся проблемами (что, согласитесь, довольно поздно). Надеюсь, что информация, собранная здесь, подтолкнет интересующихся к дальнейшему изучению темы и внедрению соответствующих практик в работе

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

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

Определение риска

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

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)

Приглашаю все заинтересованные стороны к общению на данную интересную тему ;)

Полезные ссылки

MSF Risk Management Discipline v.1.1 — www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942&displaylang=en (http://www.microsoft.com/Rus/Download.aspx?file=/Msdn/Msf/MSF_risks_mngt_rus.doc)

‘Continuous Risk Management at NASA’ — satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html
PMBok — www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00100035801

Risk Management @ SEI — www.sei.cmu.edu/risk

SWEBOK (Guide to the SoftWare Engineering Body Of Knowledge) 2004 (Iron Man) — www.swebok.org

Просто интересные скетчи по управлению проектами — jchyip.blogspot.com/2008/12/lean-it-in-sketches.html