Risk Management: предотвращение проблем vs. ведение регистра рисков

Странно, но факт

• Абсолютно все стандарты управления проектами и компаниями говорят о необходимости управления рисками. Предлагаются различные модели, инструменты и термины. Каждый ПМ понимает, что это важно. И проходят тренинги. И даже пытаются выполнять такую практику (или процесс) как Risk Management. Но не все (большинство) видят в этом смысл и пользу на практике. В лучшем случае заводят регистры рисков (про которые скоро забывают), в худшем говорят, что управление рисками происходит в ходе ежедневной коммуникации (непонятно, правда, что имеется ввиду под рисками и управлением.
• При наличии на проектах Risk register-а менеджмент компании считает что есть недостаток в про-активном управлении проекта и в коммуникациях с заказчиком, который регулярно жалуется на неожиданные проблемы на проекте.
• Проджект менеджеры и Проектные команды жалуются на большие затраты времени на работу с рисками (и, очевидно, отсутствием эффекта, а то бы не жаловались.

Эти и многие подобные наблюдения были сделаны мной в ходе внедрения системы управления качеством и проведения аудитов процессов в IT компании. В частности, процессов управления проектом. Как и любое нововведение, внедрение правил работы должно сопровождаться обоснованием зачем это нужно. Для этого, в дополненение к навыкам убеждения, необходимы знание теории и практических примеров — как негативных, так и позитивных. На них и основаны мои выводы о секретах эффективного Управления Рисками.

Риски, источники рисков, категории рисков

Анализ причин неэффективности или отсутствия управления рисками на проектах, показывает, что народ не правильно определяет риски и формулирует план реагирования (response actions).
Вот примеры типичных рисков, которые я в основном встречала в проектных регистрах рисков (обобщенные формулировки):

• «клиент может долго не отвечать»
• «сотрудник может внезапно отсутствовать на работе»
• «контракт подписан без тщательного изучения требований»
• «могут возникнуть проблемы с Интернет»

Господа, это же факты! Для борьбы с этими фактами существуют стандарты управления качеством (ISO), методологии управления проектами (например SCRUM), фрэмворки для организации работы (PMBOK, CMMI) и пр. В них собран опыт поколений менеджеров и разной степени успешности проектов. В них говорится о том, что нужно до подписания контракта оговорить обязательства сторон (commitments), заботиться о человеконезависимости процесса, создавать артефакты работы (документацию и данные, полученные в результате мониторинга) и пр. Заранее обдумывать вопросы непрерывности бизнеса, одним словом. Но это слишком «бюрократично» и «несовременно», по мнению многих менеджеров (особенно «оменеджерившихся» программистов, не в обиду будет сказано). Мы предпочитаем изобретать велосипед на каждом отдельном проекте, тушить пожары, в общем геройствовать. Подобные «риски» должны предотвращаться на этапе предварительного планирования проекта, желательно до подписания контракта.

В ходе проекта такие нерешенные заранее проблемы становятся уже источниками рисков. По поводу источников: типичные источники рисков, задокументированные в регистрах рисков, которые я наблюдала — «Клиент», «Команда», «environment», и т.д. Никто не задумывается над тем, что источник потенциальной проблемы это не обобщенное понятие, а определенная ситуация чаще всего негативная)!
«Клиент», «Команда», «environment» – это категории, через которые мы смотрим на ситуацию на проекте и можем найти негативные факты или ситуации, которые вызывают сомнения в достижении целей проекта.
Определенная негативная ситуация (чаще всего это отклонение от контракта, от стандартов работы, вызванные как ошибкой, так и сознательным решением) может повлечь за собой отклонения от желаемых (и запланированных) результатов работы, то есть целей проекта. Вот это уже проектный риск!

Оценка риска

Последствия (Impact) этого риска определяеюся тем, насколько большим будет отклонение от проектных целей, и тем, насколько большие отклонения мы можем себе позволить в отношении данной цели.
Пора, наверное, привести пример. Не полезнее ли вместо типичного
"Source": Команда
"Risk": Человек может заболеть
"Impact:" не сделаем вовремя
иметь следующую информацию:
"Source": У человека (А), выполняющего задачи на критическом пути, беременная жена, которая должна родить в период выполнения человеком (А) своих задач (это факт)
“Risk": вышеуказанный факт может повлечь отсутствие человека (А) более 3-х рабочих дней (риск)
"Impact: «возможно отклонение от расписания на 20%.
Отклонение от расписания на 20% может быть мелочью для одного проекта (где 20% это 4 рабочих часа и разница во времени с клиентом 8 часов в нашу пользу), но реальной трагедией для другого проекта (где 20% это 2 дня и у клиента назначена презентация с важными stakeholders на заранее определенное число). Учитывая все подобные реалии, оценивается серьезность риска (например, от 1 до 9, как в нашей компании).

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

Серьезность риска – в классике – определяется произведением последствия на вероятность. В первую очередь, задача менеджера работать с самыми серьезными рисками. Это понимает каждый. Все так же знают и основные стратегии ответа на риск. Проблемы начинаются тогда, когда нужно продумать о планах ответа на риск.

Планы ответа на риск

Вот типичные примеры плана ответа на риск, которые я встречаю:

• »поговорить с клиентом"
• «не отпускать в отпуск»
• «проводить митинги»

Можем ли мы сказать, насколько будет снижен риск при применении этих планов? То есть насколько эффективны наши действия по Risk Management: насколько снизится вероятность? Насколько снизится ущерб?

План ответа на риск – это действие, которое должно полностью или частично убирать потенциальную проблему, но не констатация намерения ее предотвратить.
Действия также имеют свою стоимость (влияние на достижение целей проекта: например, человекочасы).
Только в том случае, когда есть 2 и более альтернативных сценария, с указанием их стоимости для проекта (например, один – реактивный, т.е. после срабатывания риска, а второй – превентивный, если план ответа на риск включается в план проекта изначально и выполняется), тогда мы можем принимать решение, что из этого делать. Или предоставить возможность руководству или клиенту принимать решение. Только в этом случае мы управляем (или принимаем участие в управлении) проектом, оправдывая звание Project Manager. Кстати, это неплохой способ заслужить уважение в глазах клиента, что ведет к снижению давления с его стороны.

Например, в риске с человеком (А), ответ может быть такой:
"Сделать возможным выполнение задачи другим человеком: ежедневный митинг по knowledge sharing со вторым человеком (1 час в день у основного действующего лица и 1 час в день у «бэкапа»)".
Стоимость ответа на риск=10 человекочасов в неделю, что в перерасчете на расписание будет N% отставания.
Сравниваем с возможным отклонением, если риск случится, учитываем вероятность риска, и идем с этим всем к тому, кто принимает решение. Возможным результатом будет уменьшение объема работ или принятие клиентом одного из отклонений.

Количество Рисков

Один из интересных вопросов – сколько может быть рисков на проекте?
Логический ответ – сколько угодно, и чем менее организована система и слабее запланирован проект – тем больше.
Более конкретно вопрос должен звучать так: «Сколько рисков нам нужно контролировать (документировать, следить за изменениями)».
На практике есть случаи:

• В регистре несколько (больше 2-3) десятков рисков, разной степени детализации. У менеджера уходит много времени на пересмотр их, на них в конечном итоге «забивают».
• В регистре рисков около 5-7 рисков, каждый их них глобален и отражает не столько возможные проблемы на проекте, сколько проблемы индустрии: технологий, управления персоналом и т.д. При этом, для них уже указаны степень серьезности, стратегия и план ответа. На них периодически смотрят с целью «не открыть ли риск». Проблемы тут как минимум две:
  
  • Неспецифичный риск ведет к неспецифичным ответным планам, невозможности эффективно оценить влияние риска на цели проекта
  • Причины переоткрытий могут быть разными, потенциальный ущерб тоже разный, соответственно, и ответные действия должны быть разными при каждом переоткрытии. Т.о. эти 5 «рисков» по сути – источники рисков.
  
  
• Нет регистра рисков. Риски не документируются. В лучшем случае риски обсуждаются, оцениваются и предлагают ответные действия, возможно, даже с оценкой ответных действий. В этом случае проблемы следующие:
  
  • можно забыть сделать анализ того, а были ли ответные действия эффективными
  • потерять важные уроки, которые можно было бы применить еще раз, как инструмент для «укрощения» клиента.
  
  

Количество рисков, за которыми нужно следить, должно быть таким, какое возможно переварить тем, кто отвечает за мониторинг и ответ на риски. Т.е. записать можно (а иногда и нужно) все проидентифицированные риски, а вот планировать ответные действия — только для тех, чье влияние на цели проекта действительно значимо.
При этом, если у Вас 10 рисков на этой неделе и 10 было на прошлой, но это скорее всего будут хотя бы частично другие риски: ведь ситуация изменилась появились новые обстоятельства, отпали старые. А вот источники этих рисков могут быть теми же.

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

Итог

• Применение практик управления рисками – не самоцель, а инструмент для:
  
  • упрощения жизни проектной команды
  • эффективной коммуникации с заказчиком и менеджментом компании (то есть инструмент, применяемый на регулярной, ежедневной основе) для достижения бизнес целей (целей проекта).
  
  
• Для того, чтобы извлечь наибольшую пользу при наименьших «лишних» затратах времени, рекомендуется начать не с Регистра рисков, а со следующих шагов:
  
  • Четко и корректно сформулируйте (запросите) цели проекта (доступные и понимаемые тем человеком, который занимается управлением рисками на проекте, например:
    «такие-то пользователи должны иметь возможность делать такие-то действия / получать такие-то данные с нашим приложением через 120 дней. Ошибки в таких-то запросах недопустимы».
  • Сформулируйте специфический и конечный (SMART) Риск для достижения ранее сформулированных целей. Для этого определитесь с:
    
    • его Источником (фактом, который – в отличие от риска — может быть актуальным на протяжение всего проекта).
    • Источники ищите в Категории рисков, которые актуальны для нескольких проектов, организации и индустрии в целом (например: управление человеческими ресурсами, определенная технология, национальная культура заказчика и пр.)
    
    
• Работая с рисками, помните следующее:
  
  • Цель оценки риска – измеримое потенциальное воздействие риска на цели проекта; цель ответа на риск – изменить (измеримо) потенциальное воздействие на цели проекта.
  • Эффективность Риск менеджмента определяется измеримыми показателями того, насколько удалось предотвратить потенциальные отклонения от целей проекта.
• И последнее. Часто приходится слышать, что – по разным причинам – «на этом проекте управлять рисками невозможно». Но Вы же Менеджер!
  • Project Manager отличается от Project Coordinator-а тем, что принимает участие в выработке наиболее оптимальных путей достижения целей проекта, в том числе и путем своевременного нахождения потенциальных проблем (рисков) и предложения альтернативных вариантов их решения.