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-а тем, что принимает участие в выработке наиболее оптимальных путей достижения целей проекта, в том числе и путем своевременного нахождения потенциальных проблем (рисков) и предложения альтернативных вариантов их решения.
Поделиться публикацией

Комментарии 18

    +1
    Прекрасно. Спасибо за хорошие примеры.
      0
      Мне понравилось. Но вот скажите, что делать в подобной ситуации:
      фрилансеру или маленькой фирме нужны новые проекты. Они хотят делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ. Чтобы минимизировать риски невыполнения проекта или несоответствия тому, что напридумывал заказчик.
      И тут приходит один, второй, пятый заказчик и все говорят, почесав затылок:
      — Хочу, сайт, чтобы деньги зарабатывать, ну, например, партнёкру для веб-мастеров
      — Не вопрос. Давайте ТЗ — отвечаете ему вы
      -Вот, пожалуйста, — выдает он ссылку.
      А в ссылке сумбур типа «конпки квадартные, можно логиниться, вебмастера размещают ссылки, а вы им деньги». Да к тому же таких партнёрок вы не делали ещё, нюансов не знаете
      — Не, так не пойдёт. Это не ТЗ. Здесь ни чего не ясно и нужно разбираться: бизнес-модель изучить, юз-кейсы составить, над архитектурой подумать (хотя бы самой простой).
      — Да что тут непонятно. Там же всё просто!
      А потом ещё выясняется, что у него на все про всё есть 600$, а нет, то он к другому Васе пойдёт, который ему напел про 200$ за сайт с админкой.

      И тут сидишь ты и думаешь… ну ведь я же качество ему предлагаю! Он доволен будет в итоге. Ведь я и так 10 баксов в час прошу всего…

      А поезд ту-туууу. И что делать — не понятно. А ведь каждый 2ой проект, который я видел на фрилансе примерно так и выглядит: нет ТЗ, денег тоже почти нет, а вот требований к качеству и срокам — хоть отбавляй.

        +2
        «Не вопрос. Давайте ТЗ» — вот тут косяк. Проектировать надо самому, задавая правильные вопросы.
          +6
          О да, знакомо. Только Вася ему не сделает качество, которое он хочет. И в итоге он будет недоволен. Хотя, если Вася умный мужик, то он сделает то, что может и убедит, что именно это и нужно было :). А потом будет выманивать по баксу за каждый дополнительный чих.

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

          И еще, не надо говорить с ним терминами ТЗ, архитектура, безопасность и пр. Ему надо показать, сколько он сохранит, заработает или потеряет пользователей, траффика и пр. (читай: «денег») при добавлении-отключении тех или иных «фишек».

          А в целом, чтобы «делать всё качественно, по стандартам, с анализом требований, составлением юзкейсов и ТЗ» нужно выходить на другой уровень фрилансерства. А для этого нужно постигать хитрости продаж и бизнесс анализа.
            0
            Дело в том, что ваш клиент интуитивно чувствует (или уже проходил и знает), что подробное ТЗ — это та бумажка, в которую вы будете тыкать его носом, когда вы возьмете его $600 и сделаете совсем не то, что ему на самом деле надо.

            Клиент знает, что вероятность получить «не то» одинакова — что за $200, что за $600.

            Поэтому клиент, идет к Васе за $200. Когда Вася сделает «не то», клиент дает ему еще $200 и просит переделать. А потом еще $200. В итоге за свои $600 он получает «более или менее то».
            0
            Тема хорошая. Только, как и большинство материалов по этой теме, статья получилась какая-то наукообразная. Нет ощущения, что советы испробованы на практике. Я ни разу не видел, чтобы кто-то управлял рисками в IT-компаниях на регулярной основе. Хотя готов поверить, что где-то это происходит.

            Хотелось бы узнать, что у Вас получилось. Если, конечно, после аудита что-то последовало :). Ведёте реестр из 10 (3, 5, 20) наиболее неприятных рисков, мониторите его регулярно (раз в неделю, в день)? Или каким-то другим способом осуществляете управление рисками? Это удалось делать с начала и до конца проекта? Интересно было бы видеть примеры реальных (а не книжных) рисков. Реальных планов их преодоления.

            Заранее благодарен.
              +1
              Хочется верить, что автор топика практик, который делает все то, что тут написано.
              Так и рассказал бы об этом.

              А для чего писать весь этот академический булшит — не понятно. Все это и так уже 100 раз пережевано в куче публикаций и книг.

              Например, я хотел бы услышать такие реальные истории
              • «Мы практикуем формальное управление рисками (с реестром, оценками и т.п.). А если бы мы этого не сделали, то реально могли бы прошляпить вот этот риск» (типа, просто так, интуитивно, без реестра — ну точно бы прошляпили)
              • «Пришел риск, а у нас был план. А если бы не было плана — пришел бы песец»

                0
                > А для чего писать весь этот академический булшит — не понятно. Все это и так уже 100 раз пережевано в куче публикаций и книг.

                Лишнее напоминание никак не повредит. Тем более, что несмотря на то что всё 100 раз пережёвано (как вы говорите), многие (если верить автору) всё-равно управляют рисками только на бумаге, но никак не на деле.

                >Например, я хотел бы услышать такие реальные истории
                Я б тоже предпочёл реальные истории, хотя бы в виде примеров. Надеюсь что такие будут в продолжении. =)
                0
                Управление рисками — не самоцель, это инструмент для про-активных действий, для предотвращения возможных проблем, вместо тушния пожаров. Это инструмент коммуникации с руководством компании и клиентом.
                В статье я привожу примеры того, с чем я сталкивалась. И они не радужные. Они как раз свидетельствуют о наличии ненужной борократической процедуры — наличия регистра рисков с банальными проблемами.
                Сейчас передо нами (в нашей компании) стоит задача — устранить ненужную бюрокаратию и минимизировать «пожары» за счет «проактивного» менеджмента.
                За аудитом последовало исследование, тренинг и workshop-ы, изменились (стали жесче и конкретнее) требования к процессу управления проектами и определены точки контроля корректирующих действий.
                Эта статья как раз и является обобщением наших ресёрчей и брейнстормингов. Сейчас мы пытаемся внедрить те рекомендации, которые я описываю. Последующий контроль корректирующих действий покажет есть ли эффект.
                Обязательно поделюсь результатами.
                0
                Отлично написано! В продолжение хотелось бы увидеть краткую сводку по итогу.
                  0
                  Не совсем поняла пожелание.
                  +1
                  Мне кажется, в большинстве проектов (по крайней мере, имеющих отношение к Хабру) единственный «риск», которым имеет смысл управлять — это изменение scope. Вот все силы и бросают на разборки с постоянно меняющимся скоупом. А на риски не забивают, просто с ними никто не возится формально.
                  Повторюсь, это лишь гипотеза :)
                    0
                    Меня тоже смущает всеобщее убеждение, что к Хабру имеют отношение только веб-проекты. Как же быть внедрятелям АСУ с бюджетами проектов от миллиона зелени? Куда сливать мысли и где делиться опытом? Пафосные «корпоративные» форумы — тоска зеленая и бесконечная фаллометрия. Мы же тоже люди и тоже хотим живого общения! :)
                    0
                    Хорошая статья, упущен только один момент — классификация и упорядочение рисков по степени влияния их на реализацию заданной цели.
                    Соответственно от этого отличается и проработка планов мероприятий по компенсации рисков с резервированием запаса ресурсов на эти случаи.

                    Ну и так, смысловое замечание — «менеджер» это девочка в ларьке торгующая сотками. А проектами управляют «руководители».
                      +1
                      Да хоть горшком назовите :)
                        0
                        Хм, это верно только для ларька и сопоставимых с ним по размеру компаний.

                        А в более-менее крупных компаниях это приводит к путанице кто чем реально руководит\несет ответственность.
                        Правильное наименование сущностей — основа качественного управления.
                        Это примерно тоже самое, что все функции в программе назвать Manage_...(). Как потом разбираться? -)
                      0
                      Уловил следующие темы:
                      1. Думать заранее.
                      Получается не всегда, а в реальности вообще никогда. Контракт приносят с мутным ТЗ и еще более мутными ожиданиями. Это не область контроля ПМ, да и вообще сфера банно-винных отношений. В госсекторе уж точно. Так что риск все равно придется заносить.
                      2. План управления рисками.
                      Ну план на то и план, что должен содержать мероприятия, ответственных, сроки и критерии достижения. Сами же писали про SMART.
                      3. Ранжирование и оценка рисков.
                      Если вы знакомы с теми книжками, которые перечисляли (а поводов сомневаться у меня нет), то там про ранжирование все очень хорошо написано. Продолжить мысль и понять количество рисков, которыми можно практически управлять несложно. Если бы большинство корпоративных андроидов не действовало по принципу «смотрю в книгу — вижу фигу», то мир вокруг был бы гораздо лучше.

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

                      Довелось поучаствовать в вытягивании одного высокобюджетного проекта при помощи 7-ми ключей IBM с участием консультантов. Могу сказать, что когда действует настоящий профи, все получается и кажется, что все элементарно. Не забывайте об этом признаке мастерства — простота и банальность. Но простота, о которой никто до сих пор не подозревал.
                        0
                        Спасибо за статью! Продолжайте писать, у вас хорошо получается. =)

                        По духу, ваша статья очень напомнила отличную книгу «Вальсируя с медведями». Собственно, это лучшая книга по управлению рисками в IT, которую я читал.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое