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

Управление рисками проекта

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

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

Американский Институт управления проектами (PMI), разрабатывающий и публикующий стандарты в области управления проектами, значительно переработал разделы, регламентирующие процедуры управления рисками. В новой версии PMBOK (принятие которого ожидается в 2000 году) описаны шесть процедур управления рисками. В данной статье мы предлагаем краткий обзор процедур управления рисками (без комментариев).

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

Процесс управления рисками проекта обычно включает выполнение следующих процедур:

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

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

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

Идентификация рисков

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

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

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

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

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

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

Количественная оценка рисков

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

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

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

Планирование реагирования на риски

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

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

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

Мониторинг и контроль

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

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

Целью мониторинга и контроля является выяснить, было ли:

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

Источник

Основные риски инвестиционного проекта

Как правило, при оценке эффективности бизнес-проектов анализируют инвестиционные риски проектов. И в величине поправки на риск обычно учитывают 3 типа рисков, связанных с реализацией проекта.

Основные виды рисков инвестиционного проекта

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

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

Далее приводим анализ рисков инвестиционного проекта каждого вида.

Страновой риск

Обычно он выражается в возможности:

Величину поправки на страновой риск оценивают экспертно:

По зарубежным странам

На основании рейтингов стран мира по уровню странового риска инвестирования, публикуемых:

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

В расчетах общественной эффективности страновой риск учитывают только по проектам за рубежом или с иностранным участием.

А вот в расчетах коммерческой эффективности, эффективности участия предприятий в проекте и эффективности инвестирования в акции предприятия учет странового риска необходим.

Риск ненадежности участников проекта

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

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

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

В частности, размер поправки:

Риск неполучения предусмотренных проектом доходов

Он обусловлен прежде всего:

Поправку на этот вид риска определяют с учетом:

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

Ориентировочная величина поправок на риск неполучения предусмотренных проектом доходов (применительно к оценке бюджетной эффективности – постановление Правительства РФ от 22.11.97 № 1470):

Величина риска

Величина поправки на риск, %

НизкийВложения в развитие производства на базе освоенной техники3 – 5СреднийУвеличение объема продаж существующей продукции8 – 10ВысокийПроизводство и продвижение на рынок нового продукта13 – 15Очень высокийВложения в исследования и инновации18 – 20

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

Риск неполучения предусмотренных проектом доходов снижается:

Источник: Методические рекомендации по оценке эффективности инвестиционных проектов (утв. Минэкономики РФ, Минфином РФ, Госстроем РФ 21.06.1999 № ВК 477).

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник