какие факторы могут повысить рискованность проекта

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

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

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

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

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

Время на чтение: 9 минут

Что будет в статье:

Какие бывают источники рисков

Шаблон реестра рисков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы открываете почту, переходите по ссылке и погружаетесь в чтение.

Как анализировать риски

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задание

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

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

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

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

Бесплатный курс по проджект-менеджменту

За неделю вы узнаете, какие 5 soft skills необходимы для работы в проджект-менеджменте и как их развить

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

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

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

Высокие риски нужно прорабатывать в первую очередь, так как они представляют наибольшую опасность для проекта.

С рисками из средней группы можно работать двумя способами:

1. Снизить их влияние и переместить в низкие

2. Переместить в высокие и составить план их отработки

Рисками из низкой группы можно пренебречь и мониторить их состояние. Их вероятность и влияние на проект не такие существенные.

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

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

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

Читайте лучшие статьи о запуске и росте продуктов

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

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

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

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

Определить, что делать, если риск станет проблемой.

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

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

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

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

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

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

Задание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Риски проекта и все, что нужно о них знать

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

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

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

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

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

Зачем управлять рисками

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

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

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

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

Какие риски проекта самые опасные

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

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

Качественный анализ рисков проекта

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

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

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

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

Результаты качественного анализа ложатся в основу количественного.

Риски проекта — количественный анализ

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

При количественном анализе, в отличие от качественного, значения определяются точно. Выделить высокие и низкие риски проекта недостаточно. Для оценки используются разные способы от анализа ожидаемой денежной стоимости (ОДС) до создания дерева решений.

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

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

Как найти выход

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

Для работы с рисками есть несколько стратегий:

Стратегии управления рисками

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

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

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

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

Как управлять рисками с помощью BPM-системы

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

собирать и документировать риски проекта;

хранить и передавать информацию о выполненных задачах;

обеспечивать мониторинг статусов рисков;

обеспечивать контроль со стороны проектного менеджера над всеми работами.

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

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

Одним из примеров BPM-систем является система ELMA. С помощью дополнительного модуля Проекты+ она позволяет запустить бизнес-процесс прямо из карточки проекта. А используя мониторинг процессов, проектный менеджер сможет контролировать все этапы работы и получать подробную аналитику после завершения процесса.

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

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

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

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

Менеджер проекта подводит итоги анализа, пересматривает реестр рисков и приступает к выбору стратегии. Любое изменение статуса риска, например, если он состоялся или решился, менеджер сможет зафиксировать в реестре.

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

После выполнения работ проектный менеджер оценивает эффективность всего процесса.

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

Если кратко

Гарантировать успех проекта невозможно — всегда будет оставаться элемент неопределенности и риски проекта, угрожающие целям. Чтобы уменьшить неприятности, можно подстраховаться и устранить угрозы заранее. По большому счету работа с рисками заключается в поиске баланса между затратами на решение рисков и потенциальным ущербом в случае их принятия. Достичь этот баланс получится, опираясь на результаты анализа. Только после аргументированной оценки угроз можно приступать к выбору стратегии управления: уклонение, передача, снижение или принятие. Работать с рисками удобнее с помощью бизнес-процесса, а в качестве инструмента для управления рисками использовать BPM-систему.

Вот небольшой чек-лист, как начать работу с рисками проекта:

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

Проведите качественный анализ: разделите все риски проекта на важные и второстепенные.

Проведите количественный анализ: определите влияние рисков на проект в точных значениях.

Подберите и примените к каждому риску одну или несколько стратегий управления.

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

Источник