Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Показать все разделы библиотеки управления

Если задать Google строку поиска «почему проваливаются проекты», вы получите несколько страниц статей и ресурсов, включая нашу статью «Пять причин, почему не выполняются проектные планы и как их избежать». Многие причины носят процедурный характер и касаются, например, определения области действия, методологии и коммуникации, но есть и общая тема: отсутствие процесса выявления рисков.

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

Что такое жизненный цикл и процесс идентификации риска?

Первый шаг процесса управления рисками — идентификация рисков. Вот как этот шаг описан в нашем руководстве «Оценка рисков проекта»: «Составьте список всех возможных рисков и возможностей, которые только могут прийти вам в голову. Если вы будете сосредоточены на одних лишь угрозах, вы можете упустить шанс предложить заказчику неожиданную ценность».

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

Как же выявляют риски? Для этого существуют различные концепции, и вы должны выбрать ту, которая лучше всего соответствует практике работы и ресурсам вашей организации. Институт управления проектами (Project Management Institute, PMI), например, опубликовал исчерпывающее руководство, в котором подробно объясняется его модель выявления рисков.

Жизненный цикл идентификации рисков работает, как подпроект, и представляет собой процесс, который обеспечивает ключевые элементы общего плана управления рисками. Процесс идентификации рисков имеет определенную структуру и состоит из шести этапов:

  • Внешняя перекрестная проверка
  • Внутренняя перекрестная проверка

Что такое управление рисками?

Управление рисками — это процесс выявления, отслеживания и обработки потенциальных рисков, которые могут повлиять на общее состояние бизнеса и его репутацию. Британская Ассоциация управления проектами (Association for Project Management, APM) описывает это так: «Анализ рисков и управление ими — это процесс, который позволяет видеть как отдельные рисковые события, так и общий риск, и проактивно ими управлять, достигая успеха путем снижения угроз, реализации возможностей и получения наилучших результатов».

Проект, который не поддерживается руководством, в который не вовлечены стейкхолдеры и для которого не практикуется строгий подход к выявлению рисков и управлению, имеет повышенный риск неудачи.

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

Управление рисками — это не просто процесс, это культура. Том Уилсон (Tom Wilson), директор по управлению рисками компании Allianz, напоминает: «Управление рисками — это культура, а не культ. И работает она только тогда, когда ее практикуют все, а не только лишь несколько первопроходцев».

С другой стороны, существуют риски, которые могут пойти на пользу проекту. Например, изменение правил организации может устранить бюрократию и сэкономить ваше время. Такие позитивные риски называют «возможностями», в отличие от негативных рисков — «угроз». Подробнее об этом написано в нашем посте «Что такое позитивные риски в управлении проектами?»

Что такое риски

Прежде чем понять, как работать с рисками, давайте проговорим, что это такое и какие они бывают.

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

Если негативное событие произойдет в любом случае — это не риск, а задача. Например, проджект знает, что новому QA-инженеру нужно в два раза больше времени на тестирование продукта. Его задача — учесть факт и заложить достаточно времени на этот этап.

Риски можно делить на внешние и внутренние.

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

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

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

Также можно категоризировать риски по этапам проекта.

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

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

Чем раньше проджект выявит и проработает риск, тем дешевле и проще будет его компенсация или предотвращение. Если детально изучить требования и обсудить непонятные моменты, то на этапе тестирования будет меньше проблем.

В статье вы встретитесь с терминами, которые могут быть вам незнакомы. Их использует в своей работе Анастасия Борисюк в Актион Технологии. Давайте введем определения, чтобы говорить на одном языке.

ДОДинг, от Defenition of Done — это встреча между заказчиком, проджектом и тимлидом. Цель встречи — договориться, что будет сделано в фиче, для кого она, какую проблему решает. Это нужно, чтобы можно было грубо оценить, приоритизировать и запланировать работу.

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

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

Чтобы грамотно управлять угрозами для бизнеса, мы решили использовать метод фреймворка PMBoK от PMI. Разработчики предлагают поделить процесс управления на 6 этапов:

  • Планирование управления
  • Идентификация факторов
  • Качественная оценка
  • Количественная оценка
  • Планирование реакции
  • Мониторинг и контроль

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

Такую схему из 6 этапов предлагает PMBoK.

Планирование управления

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

Вот такую проектную схему предлагают разработчики PMBoK.

Диаграмма потоков данных планирования управления рисками в PMBoK.

3 главных аспекта правильного планирования:

  • формирование благоприятной среды управления — гармонизация отношений внутри команды
  • использование заранее заготовленных схем и шаблонов процессов управления
  • создание описательной части и плана управления угрозами

Основной процессный инструмент — совещание. В нем принимают участники все члены команды, а иногда и инвесторы, когда речь идет про угрозы для инвестиционного проекта. Результат их работы — создание плана управления. Это полноценный регламент, которым команда руководствуется при противодействии угрозам.

Обычно в плане управления указывают:

  • методы и инструменты управления
  • роли участников при возникновении рисковых ситуация
  • допустимые значения и диапазоны угроз
  • принципы и правила внесения изменений в работу
  • форматы отчетности и документации по проектным угрозам
  • способы мониторинга и ответственные

Идентификация

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

Чтобы увеличить вероятность идентификации, есть смысл использовать грамотную классификацию рисковых событий. Например, мы в Oko используем классификацию по степени по степени контролируемости.

Классификация рисковых событий по степени их контролируемости.

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

Пример классификации рисковых событий в зависимости от их источника.

При формулировании угрозы важно использовать двух составные понятия: с указанием на источник события и саму угрозу. Например, «угроза срыва сроков реализации из-за отсутствия определенности с функционалом» или «риск отсутствия финансирования из-за нестабильной ситуации с бюджетом у компании-заказчика». Результат — создание реестра возможных рисковых ситуаций.

Фрагмент реестра рисковых ситуаций.

Анализ и оценка рисков проекта

Здесь мы совмещаем качественную и количественную оценку.

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

  • перечень рисковых событий, сгруппированный по приоритету
  • перечень событий, которые нужно дополнительно проанализировать
  • комплексную оценку угрозы для команды в целом
Читать также:  Государственные программы на урале

При анализе экспертные оценки делят на две категории: оценки вероятности наступления рисковых событий и оценки их влияния. Для их корректного анализа создают специальную матрицу с оценками. Например, вот такую матрицу предлагают разработчики PMBoK.

Матрица вероятности/воздействия угроз и благоприятных возможностей из PMBoK.

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

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

Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень рисковой угрозы.

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

Количественная оценка помогает проанализировать:

  • вероятность достижения конечной цели
  • степень воздействия угроз на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться
  • события, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на результат
  • фактические расходы, предполагаемые сроки окончания

Обычно для количественного анализа используют такие методологии:

Вероятностный анализ — оценка на основе статистики по прошлым проекта с учетом вероятностной погрешности.

Анализ чувствительности — оценка влияния основных параметров финансовой модели на результирующий показатель в целях выявления наиболее существенных переменных для проекта.

Имитационное моделирование — оценка, сделанная на основе многократных опытов с моделью.

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

Планирование реакции

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

В своей практике мы выработали 4 варианта реакций, которые помогают нам ликвидировать или хотя бы минимизировать последствия от возможных проблем. Вот какие стратегии можно использовать.

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

Передача. Перекладываем ответственность за негатив на третью сторону. Например, заключаем договор страхования, берем предоплату, предусматриваем в договоре с заказчиком неустойку. Иногда на это потребуются дополнительные деньги.

Снижение. Формируем предупредительные меры по снижению вероятности наступления негативных событий или последствий их наступления. Например, при формировании команды включаем в нее возможных дублеров — на случай, если разработчик заболеет, а дизайнер-фрилансер решит пропасть на неделю без предупреждения.

Использование. Превращаем негатив в позитив. Пример риска проекта: квалификация тестировщика вызывает у руководителя группы вопросы, есть вероятность срыва сроков и снижения качества продукта. Думаем, что делать — в качестве дублера привлекаем более опытного тестировщика. Мы увеличим бюджет, но сократим сроки на выполнение важных для нас процессов с гарантией их качества.

На основании выбранного варианта реагирования предпринимаются дальнейшие действия. Например, в PMBoK рекомендуют вносить изменения в документацию или план проекта.

Диаграмма потоков данных планирования реакции на угрозы из PMBoK.

Мониторинг и управление

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

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

Важный момент: проектный менеджер не может быть владельцем всех угроз и отвечать за всех одновременно. Поэтому есть смысл назначить ответственного по каждому риску отдельно.

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

Анализ, оценка и стратегии управления

Эту статью мы написали вместе с Анастасией Борисюк, руководителем проектной группы в Актион Технологии. Вот ее телеграм-канал.

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

  • Какие бывают источники рисков
  • Шаблон реестра рисков
  • Как выбрать стратегию управления рисками

Изучите профессию проджект-менеджераЗа 3 месяца интенсивного обучения в симуляторе skillsetter вы получите ключевые навыки для карьерного роста

Начать учиться бесплатно

Как работать с рисками

Рабочая неделя начинается с проверки Google-календаря. На сегодня у вас стоит созвон с Оливией — опытным проджектом, которая давно работает в компании и будет вашим ментором.

Вы заходите в Google Meet

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Привет! Как настрой на неделю?

Да, понимаю. Мне тоже было страшно выполнять новые задачи. Но я уверена, что ты быстро освоишься.

Здорово, спасибо за поддержку. Как будем работать?

Первое время я буду отдавать тебе часть своих задач — объяснять, как это делается, и проверять, все ли правильно. Так ты поймешь, как все устроено, и сможешь брать на себя больше ответственности за проект.

Я сейчас работаю над приложением SportLife — это сервис для внедрения привычки заниматься спортом каждый день. Нужно проработать все возможные риски, поможешь мне в этом?

Ты уже знаешь, что такое риски и какие они бывают?

Да, знаю. Но мне еще не приходилось с ними работать. Это делается на протяжении всего проекта?

Конечно. Риски нельзя описать и забыть, ведь проект живет. С течением времени могут появиться новые риски, а старые — измениться.

Обычно проджект начинает работу с рисками на этапе планирования и продолжает вплоть до релиза.

В начале работы он выявляет риски на ДОДинге, когда обсуждается фича, объем работ и сроки, а также на предоценке и встрече с заказчиком. Периодически он возвращается к рискам, чтобы проверить, ничего ли не изменилось.

А команда участвует в обсуждении рисков?

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

На дейли стендапах нужно спрашивать разработчиков, что может помешать достичь  целей спринта, а на ретро — анализировать причины неудач, потому что они могут возникнуть снова.

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Ну как, пока все понятно?

Отлично, тогда перейдем к делу. Я отправлю тебе на почту документ, в котором описан весь процесс работы с рисками проекта.

Разберись подробнее в теме и распиши риски для одного этапа. Я проверю, все ли ок, и ты пойдешь работать дальше.

Какой именно этап разобрать?

Давай возьмем этап оценки.

Хорошо, вернусь к тебе, как доделаю задачу.

Удачи! Если будут вопросы, спрашивай 😎

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

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Рассмотрим подробнее каждый этап.

Гайд по лучшим статьям skillsetterВ нашем блоге уже больше 150 статей про рост продуктов и карьеру в IT. Для удобной навигации мы объединили их в тематические подборки. Выбрать подборку

Как выявлять проблемы

Анализ рисков начинается с выявления проблем. Для этого можно использовать три способа: вспомнить старые проблемы, обсудить проект с командой, опросить экспертов, продактов и представителей бизнеса.

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

Читать также:  Консульский отдел Посольства Российской Федерации в Республике Казахстан

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

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

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

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

Как определять причины проблем

Чтобы предотвратить проблемы, нужно определить их триггеры — причины  возникновения. Для этого можно воспользоваться методом “5 почему”.

Метод “5 почему” заключается в том, чтобы постепенно отвечать на вопрос “Почему это произошло?” Вопросов не обязательно должно быть пять — их может быть как больше, так и меньше. Главная задача — добраться до корневой причины.

Например, проблема в том, что команда не попала в оценку:

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

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

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

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

Как систематизировать причины

Причины, полученные с помощью метода “5 почему”, следует включить в реестр рисков — документ, в котором собраны все риски. Чем масштабнее, длительнее и сложнее становятся проекты, тем труднее контролировать ситуацию. Без централизованного мониторинга рисков вы можете что-то забыть или упустить.

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

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Задание

Как вы думаете, какие риски относятся к этапу “Разработка”?

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

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Вы вносите в реестр риски и их триггеры.

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Как заполнять документ дальше пока непонятно, поэтому вы переходите к следующему блоку документации. Там говорится о том, как оценивать риски и управлять ими.

Как оценивать риски

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

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Риски принято делить на три группы: высокий, средний и низкий:

  • К низкой группе относятся риски с низкой вероятностью и степенью влияния.
  • К высокой — с высокой вероятностью и степенью влияния.
  • Если у риска высокая вероятность, но низкое влияние, или наоборот, то он относится к средней группе.

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Высокие риски нужно прорабатывать в первую очередь, так как они представляют наибольшую опасность для проекта. С рисками из средней группы можно работать двумя способами:1. Снизить их влияние и переместить в низкие2. Переместить в высокие и составить план их отработкиРисками из низкой группы можно пренебречь и мониторить их состояние. Их вероятность и влияние на проект не такие существенные. Оценка рисков обычно субъективна, на нее влияет контекст проекта. Одни и те же риски в двух проектах с разной вероятностью становятся реальной проблемой и по-разному влияют на результат. Например, для одной команды увеличение бюджета на $10 000 повлечет полную перестройку плана, а для другой эта сумма — стоимость всего одного дня работы команды. У вас пока нет опыта в оценке рисков, но вы понимаете, что неизвестная технология с большей вероятностью может стать проблемой и сильно повлияет на результаты работы. Предоценка без декомпозиции или с высокоуровневой декомпозицией скорее всего не так критичны. Вы расставляете в реестре рисков вероятности и степень влияния.

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Осталось разобраться с тем, как работать с этими рисками.

Читайте лучшие статьи о запуске и росте продуктовРаз в неделю будем отправлять свежий дайджест вам на почту. Наc читает 25000 человек 🚀

Как управлять рисками

Когда мы выявляем риск, то понимаем, какую он несет угрозу проекту: срокам, качеству, бюджету, целям. Но этого недостаточно. После анализа и оценки рисков нужно придумать план, как превратить их из неопределенности в управляемые элементы. Для этого нужно:

  • Составить план действий, чтобы риск не произошел.
  • Определить, что делать, если риск станет проблемой.

Чтобы понять, что делать с риском, надо выбрать одну из четырех стратегий:

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Далее рассмотрим каждую стратегию подробнее — что она значит, как ее применять и в каких случаях рекомендуется использовать.

Стратегия «Принять риск»

Суть стратегии. При использовании данной стратегии проджект-менеджер принимает то, что риск станет проблемой, и сразу планирует ее решение.

Когда используется. Эта стратегия подходит для рисков, когда вероятность негативного события низкая или последствия на проект незначительные. Например, переход на удаленную работу, небольшие доработки в проект, новые баги.

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

Как вы думаете, какой риск можно принять?

Стратегия «Уклониться от риска»

Суть стратегии. При использовании стратегии уклонения проджект предпринимает действия, чтобы событие не произошло. Для этого он старается ограничить влияние внешних факторов и взять под контроль внутренние.

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

Пример. Есть риск, что приемка фичи у заказчика затянется. Значит, следует поставить четкий срок по приемке. В этом случае цель фича будет выполнена вовремя, так как проджект ограничил влияние внешних факторов.

Стратегия «Снизить влияние»

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

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

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

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

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

Стратегия «Передать другому»

Суть стратегии. Эта стратегия подразумевает передачу задачи и связанные с ней риски заказчику или другим исполнителям.

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

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

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

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

Проработка рисков для SportLife

После чашки кофе вы приступаете к выбору стратегии управления выявленными рисками.

❌ Стратегия «Принять риск». Все ваши риски на этапе оценки достаточно значимы. Вы не можете просто принять их.

❌ Стратегия «Передать другому». Передать задачу другому тоже не получится — по договору все задачи по проекту лежат на вашей проектной команде.

✅ Стратегия «Уклониться от риска». От рисков, связанных с декомпозицией задач, можно уклониться. Они предсказуемые, и вы можете сделать так, чтобы риск не стал проблемой.

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

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

✅ Стратегия «Снизить влияние». Для управления риском неправильной оценки из-за неизвестной технологии можно использовать стратегию снижения влияния. Для этого нужно заранее провести рисерч, чтобы лучше разобраться, какие работы потребуется провести в проекте. На ретро нужно обсудить, вписывается ли команда в оценку. Если окажется, что команда выбивается из сроков, нужно заложить дополнительное время на разработку и правки.

Вы вносите план действий в реестр рисков и спешите показать Оливии результат.

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

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

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

Отлично. Слушай, я сегодня столкнулась с проблемой. Интересно послушать твое мнение. Нам попался странный заказчик. Он не хочет выходить за рамки бюджета, но при этом уже сейчас говорит, что возможно пересмотрит набор фичей для запуска MVP. Как ты думаешь, какую стратегию лучше использовать?

Как вы думаете, какая стратегия управления рисками лучше подойдет в этом случае?

Единственно правильного варианта никогда не бывает, но это звучит логично. Давай еще раз закрепим порядок действий:

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Ну что, я могу прорабатывать риски для SportLife дальше?

Да, заноси их в этот же реестр. Это поможет тебе держать все риски в одном месте и регулярно к ним возвращаться. Как заполнишь — скидывай мне.

Окей, спасибо 👍

Резюмируем

Предусмотреть все на свете не получится. Но чем основательнее проджект подходит к анализу рисков, тем меньше вероятность, что проект сорвется по срокам и принесет компании финансовые и репутационные потери.

Если вы столкнулись с проблемой, не волнуйтесь. В следующий раз вы учтете этот риск, чтобы не пришлось задействовать дополнительные ресурсы и переносить релизы.

Как определяются риски при управлении проектами

Для краткости мы сосредоточимся на первых трех шагах, которые охватывают идентификацию рисков; последующие шаги необходимы для проверки и формализации выводов в отношении общего объема проекта.

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

Базовая идентификацияЭто ответ на два вопроса о потенциальных рисках: почему с данными рисками должны (или не должны) столкнуться именно мы, и сталкивались ли мы с ними ранее. Первое можно получить с помощью SWOT-анализа, а второе обычно берется из отчета по результатам проекта или из базы знаний.

Подробная идентификацияЭто более трудоемкий шаг, чем предыдущие, но он обеспечивает детализацию, необходимую для верной оценки риска. PMI называет пять необходимых инструментов:

  • Интервьюирование
  • Анализ предположений
  • Анализ документов
  • Дельфийский метод
  • Мозговой штурм

Завершив эти шаги, вы должны классифицировать риск на следующем этапе — в ходе внешней перекрестной проверки. Об этом мы пишем в статье «Структура разбивки рисков».

Пятый этап — это внутренняя перекрестная проверка, в ходе которой риски сопоставляются с соответствующими частями работ. На этом этапе у вас начинает формироваться представление о том, какие части проекта более рискованны, чем другие, и какие стратегии снижения риска следует принять.

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

Совет: ведите по всем вашим проектам реестр рисков, к которому вы можете обращаться, приступая к новому проекту — для этого можно использовать такой инструмент, как Wrike.

Примеры идентификации рисков

Приведем пару примеров: первый основан на методологии PMI, описанной выше, а второй отражен в онлайн-реестре рисков.

Основные методы выявления рисков и разработки моделей для государственных программ и проектов Альтернативные стратегии управления рисками

Эти два примера не обязательно представляют альтернативные подходы. Скорее, первый является шаблоном идентификации риска, а второй — пример из реестра рисков с той же информацией.

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

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

Думайте о найденных вами рисках как об основе вашего плана управления рисками, в который обычно входят следующие части:

  • Распределение ответственности за те или иные риски между участниками проектной команды
  • Реакция на риски
  • Планирование постоянного мониторинга новых рисков и их устранения

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

Но на этом работа не прекращается. По мере реализации проекта нужно отслеживать и выявлять новые риски. Важна и ответственность за риски, поэтому должны быть определены процессы коммуникации и эскалации. И это приводит нас к следующему вопросу: кто должен контролировать риски?

Кто должен контролировать риски?

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

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

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

  • Спонсор проекта
    Несет общую ответственность за проект, имеет представление о плане управления рисками и утверждает его.
  • Менеджер проекта
    Несет общую ответственность за управление рисками, включая коммуникации и эскалации.
  • Ответственный за риск
    Это может быть член команды проекта или стейкхолдер, который входит в команду и отвечает за тот или иной риск.
  • Комитет по рискам
    Имеет представление о рисках каждого проекта организации.

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

Использование Wrike для управления (и митигации) рисков

Управление рисками — критически важная и весьма существенная часть управления проектами. К тому же оно довольно дорого стоит, если учесть, что на него может уходить до 20% всего проектного времени.

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

Используя современный, универсальный и мощный инструмент управления проектами, такой как Wrike, вы одновременно повышаете эффективность ведения проекта и снижаете риски. И вот почему:

  • процессы идентификации рисков и управления ими централизованы и легко доступны
  • Для облегчения выполнения этапов плана управления рисками можно разрабатывать специальные рабочие процессы
  • Чтобы проще было находить одни и те же риски в разных проектах, можно создавать для них дополнительные уровни категоризации и тегов
  • Система предупреждает о наиболее критических и высокоприоритетных рисках
  • Вы всегда в курсе событий и получаете отчеты одним щелчком мыши
  • Коммуникации и совместная работа идут в режиме реального времени

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *