Управление рисками в проекте
Как и любое серьезное начинание, ни один проект в процессе своей реализации не застрахован от рисков. Чем крупнее проект, тем больше и масштаб потенциальных рисков. Но когда речь идет об управлении проектами, по большей части нужно думать не об оценке рисков, т.к. она представляет собой промежуточное действие, а о разработке такого плана реагирования на изменения, который помог бы снизить степень рискованности. И в этом уроке мы поговорим о наиболее важных тонкостях и специфических особенностях управления рисками.
Проектные риски и неопределенность
Термин «риск» в проект-менеджменте означает вероятное событие, мешающее руководителю проекта и его команде достичь целей проекта или отдельных его параметров, обусловленных временными, количественными и стоимостными рамками. Риск связан с конкретными причинами и источниками и всегда имеет свои последствия. Другими словами, риск влияет на результаты проекта.
Риски проекта всегда связаны с неопределенностью. Исходя из этого, необходимо иметь представление о степени неопределенности и ее причинах. Неопределенность следует понимать как состояние объективных условий, в которых проект начинает реализовываться, но которое не позволяет предвидеть результаты принимаемых решений из-за неполноты и неточности информации. Степень неопределенности играет большую роль, т.к. проект-менеджер может управлять лишь теми рисками, по которым известно хотя бы что-то существенное.
Когда информации нет, любые риски называются неизвестными. Они требуют создания специального резерва без реализации управленческих процедур. Если же по угрозам есть даже минимальная информация, уже можно разрабатывать план реагирования, направленный на минимизацию риска. Ниже представлена схема управления рисками с позиции неопределенности:
Другой не менее важный нюанс для понимания специфики риска проекта – это динамичность карты рисков, изменяющаяся по мере решения проектных задач. Обратите внимание на модель динамики вероятности риска и объема потерь:
На начальном этапе проекта вероятность угрозы максимальна, однако возможные потери находятся на низком уровне. К окончанию же проектных работ возрастает величина потерь, но снижается вероятность угроз.
Руководствуясь этой особенностью, можно сделать два вывода: во-первых, в процессе осуществления проекта имеет смысл анализировать риски по нескольку раз (карта рисков всегда будет изменяться), а во-вторых, наиболее оптимально риски минимизируются на стадии разработки проекта или в процессе разработки проектной документации (это многократно снижает затраты, нежели на стадии непосредственной реализации проекта).
Концепция управления рисками
Методология управления рисками, имеющаяся на сегодняшний день, подразумевает активную работу с источниками и последствиями определяемых угроз. Вообще, управление рисками является совокупностью процессов, основой которых служит идентификация и анализ рисков и разработка мер по минимизации уровня негативных последствий как результата наступления рисковых событий.
В PMBoK (Своде знаний по управлению проектами (от англ. Project Management Body of Knowledge)) выделяются шесть основных процессов управления рисками. Визуальная схема их последовательности такова:
Т.е., к основным процедурам управления проектными рисками относятся:
- Идентификация рисков
- Анализ риска (качественный и количественный)
- Планирование реагирования на риски
- Контроль над рисками
Идентификация – это определение рисков, основанное на определении продуцирующих их факторов, а также документальное оформление параметров этих рисков. Качественный и количественный анализ причин возникновения и возможности отрицательных последствий необходимы для формирования оценочной процедуры. Планирование реагирования на найденные риски предполагает создание комплекса мер, направленных на снижение негативного воздействия рисков на параметры и результаты проекта. Но главенствующее место в этой системе занимают именно мониторинг рисков и контроль над ними – они осуществляются на протяжении всего жизненного цикла проекта.
Благодаря умелому управлению рисками можно достичь:
- Объективного восприятия и понимания участниками проекта неопределенностей и рисков, связанных с его реализацией, их источников и возможных отрицательных событий как результата появления рисков
- Поиска и расширения возможностей для эффективного решения проектных задач с учетом найденных неопределенностей
- Разработки путей минимизации проектных рисков
- Доработки проектных планов с учетом выявленных рисков и комплексов мер по их минимизации
Проектные риски могут управляться как менеджером проекта, так и всеми участниками проектной команды в разной степени. В процессе применяются методы экспертных оценок, мозговые штурмы, обсуждения и интервьюирование, а также программно-математический аппарат и т.д.
Перед тем как начинать управление рисками, необходимо сформировать информационный контекст, в который входят внешние и внутренние условия для решения задач. К внешним условиям относятся конкурентные, экологические, технологические, социальные, правовые и экономические, политические и прочие аспекты. А внутренние состоят из ряда характеристик – это:
- Характеристики проекта и его целей
- Характеристики структуры и целей компании-организатора проекта
- Корпоративные регламенты и стандарты
- Информация о ресурсном обеспечении проекта
Начинать же управление проектными рисками, как и следует полагать, нужно с планирования.
Планирование управления рисками
Планирование управление рисками – это первый процесс среди всего комплекса процедур по работе с проектными угрозами. Планирование – это инструмент, позволяющий определить выбранные методы, инструменты и степень организации управления относительно конкретного проекта. Институт по управлению рисками (PMI от англ. Project Management Institute) придает данному процессу огромное значение в плане коммуникации с каждой заинтересованной в проекте стороной. В Руководстве PMBoK предлагается такая схема планирования управления рисками:
План управления рисками является документом, состоящим из нескольких разделов, а именно из:
- Общих положений
- Основных характеристик компании-организатора проекта
- Уставных характеристик проекта
- Целей и задач управления рисками
- Методологического раздела с описанием методов, средств анализа и оценки, источников сведений, рекомендуемых для использования с целью управления проектными рисками (все инструменты и методы необходимо расписывать по стадиям проектной реализации)
- Организационного раздела, включающего в себя распределение ролей и ответственности среди членов проектной команды, а также описание взаимосвязей с другими элементами управления проектом
- Бюджетного раздела, включающего в себя правила формирования и обеспечения выполнения бюджета управления рисками
- Регламентного раздела с указанием сроков, периодичности и продолжительности операций по управлению рисками, форм и состава управляющих документов
- Метрологического раздела, состоящего из принципов оценки, правил пересчета параметров и справочных шкал (они выполняют функцию вспомогательных средств для качественного и количественного анализа)
- Пороговых значений рисков – допустимых значений рисковых параметров на уровне проекта и отдельных угроз (необходимо учитывать важность и новизну проектной реализации)
- Раздела отчетности, рассматривающего вопросы периодичности, формы, порядки заполнения, сдачи и рассмотрения отчетов
- Раздела мониторинга и документационного обеспечения управления проектными рисками
- Раздела шаблонов для управления проектными рисками
После завершения этапа планирования управления рисками следует процесс их идентификации.
Идентификация проектных рисков
В процессе идентификации определяются и демонстрируются проектные риски. Результатом становится перечень рисков, рассортированных по степени их опасности. Как и к планированию рисков, к их идентификации следует привлекать всех членов проектной команды и участников проекта.
Идентификация является повторяющимся процессом, т.к. по ходу развития проекта могут возникать новые риски и становиться известной ранее недоступная информация об уже выявленных. Частота повторений, а также состав участников идентификации могут варьироваться, исходя из ситуации. Риски всегда должны описываться последовательно, чтобы было обеспечено четкое и недвусмысленное понимание каждого из них – это позволит поддерживать эффективный анализ и разработку плана реагирования. Описания должны составляться так, чтобы было можно сравнивать взаимосвязи рисков с проектом и воздействием других рисков.
Идентификацию нужно проводить в соответствии с результатами изучения всех определенных ранее факторов, но нужно понимать, что далеко не каждый фактор может быть выявлен и управляем. По мере разработки и дополнения проектных планов нередко появляются новые источники угроз, а число потенциальных рисков увеличивается по мере продвижения проекта к полной реализации. Результативная идентификация зависит также от того, есть ли в распоряжении детальная классификация рисков. Одной из самых полезных классификаций служит классификация рисков по степени контролируемости, например, такая:
Классификация рисков по степени контролируемости полезна тем, что помогает четко определить, под какие конкретные неконтролируемые факторы необходимо создавать резервы. Однако контролируемость рисков не дает гарантии того, что в управлении ими будет достигнут успех, по причине чего нужно руководствоваться и иными способами деления. Также заметим, что универсальной классификации рисков на сегодняшний день нет, что обусловлено уникальностью каждого проекта и многообразием сопровождающих проекты рисков. Помимо этого достаточно сложно определить грань между схожими рисками.
Что касается типовых признаков классификации, то к ним относятся:
- Источники рисков
- Последствия рисков
- Методы минимизации угроз
На стадии идентификации чаще всего используют первый признак. Ниже предлагается одна из наиболее популярных классификаций проектных рисков по источникам возникновения:
Оставшиеся два признака полезны при анализе факторов риска. Поэтому имеет смысл рассмотреть виды проектных рисков на основе уникальности их факторов:
- Специфические риски с позиции локального проекта (риски, зависящие от инновационной технологии, и т.п.)
- Специфические риски с позиции типа реализации проекта (учитываются факторы для IT-проектов, инновационных проектов, строительных проектов и т.п.)
- Общие риски для всех проектов (низкий уровень бюджетной проработки, рассогласование планов и т.п.)
Правильная идентификация зависит от грамотной формулировки риска, и очень важно не перепутать риск, его источник и последствия. Формулировка риска состоит, как правило, из двух частей: указания источника возникновения риска и указания события, несущего в себе угрозу. После того как риски идентифицированы и сформулированы следует переходить к их анализу и оценке.
Анализ и оценка проектных рисков
Анализировать и оценивать риски необходимо для того чтобы преобразовать найденные на этапе идентификации сведения в данные, которые позволят принимать ответственные решения. Качественный анализ включает в себя комплекс экспертных оценок вероятных неблагоприятных последствий, зависящих от выявленных факторов. А количественный анализ позволяет определить и уточнить количественные показатели вероятности возникновения угроз. Количественный анализ отнимает больше сил, но более достоверен. Чтобы его провести, нужно иметь качественные входные данные и использовать эффективные математические модели. Проводить же его должен высококвалифицированный персонал.
Но нередко и качественных аналитических показателей бывает достаточно, однако для этого по завершении анализа проект-менеджер должен получить:
- Приоритизированный перечень рисков
- Перечень позиций, для которых нужно провести дополнительный анализ
- Общее заключение по рискованности проекта
Эксперты выделяют два вида оценок: оценку вероятности наступления рисковых событий и оценку степени их воздействия на проект. Главным результатом качественного анализа можно назвать перечень ранжированных рисков с произведенными оценками и карту рисков. Вероятности наступления рисковых событий и их воздействия разделяются на группы в определенном диапазоне значений.
После проведения оценок выстраиваются специальные матрицы с ячейками, где указываются результаты произведения значения вероятности на степень воздействия. Итоговые данные делятся на сегменты, играющие роль основания ранжирования рисков. Матрица вероятности и воздействия может выглядеть так:
Исходя из вероятности наступления риска и степени его воздействия на проект, каждому из рисков присваивается свой рейтинг. Матрица отображает выявленные организационные пороги для разных рисков (низких, средних и высоких), позволяющие произвести оценку рисков как низкие, средние и высокие применительно к проекту.
В итоге в матрице появляются сегменты недопустимых, средних и незначительных рисков, называемые пороговыми уровнями. Но кроме установления двух главных параметров (вероятности и воздействия) качественный анализ требует установления и самой возможности управления рисками. Так, риски могут быть:
- Управляемыми
- Частично управляемыми
- Неуправляемыми
Ниже представлен алгоритм принятия решения по выявлению степени управляемости и величины риска:
Если выявляются неуправляемые опасные риски, их нужно обсуждать с заказчиками и инвесторами, т.к. выявление подобных угроз может стать причиной остановки процесса осуществления проекта.
Другим результатом анализа и оценки риска является карта риска, в наглядной форме представляющая рассмотренную выше матрицу. Карты выглядит примерно так:
Большой круг в правом верхнем углу – это недопустимые риски. Вероятности, находящиеся снизу и слева от красной линии в центре – это неопасные риски. На основе этой карты рисков можно планировать способы реагирования на риски.
Планирование реагирования на риски
В практической деятельности обычно выделяют четыре категории последствий рисков:
- Влияющие на бюджет
- Влияющие на сроки
- Влияющие на качество продукта
- Влияющие на функционирование продукта
Планирование способов реагирования является регламентированной процедурой разработки плана снижения рисков. В этом процессе определяются оптимальные меры повышения вероятности успеха проекта, предполагающие реагирование на угрозы в порядке приоритета. При расчете проектного бюджета в него следует включать целевые ресурсы и операции, ответственность за которые распределена между участниками проекта.
Всего существует четыре основных метода реагирования на риски:
- Избегание рисков. Считается самым активным методом, однако применим он не всегда. Актуален в случаях, когда можно полностью исключить источники риска.
- Минимизация рисков. Еще один активный метод, состоящий в уменьшении вероятности и снижении опасности рисков. Риски в этом случае должны полностью поддаваться контролю (чаще всего это внешние риски).
- Передача-страхование рисков. Для использования метода нужно найти третью сторону, которая будет готова принять на себя риски и их негативные последствия.
- Принятие рисков. Предполагает осознанную готовность к рискам и направление всех последующих усилий на устранение последствий.
Такова вкратце методологическая база риск-менеджмента на сегодняшний день. Проект-менеджер в своей работе в обязательном порядке должен учитывать эту информацию, т.к. от нее и ее использование зависит эффективность командной работы и достижение целей проекта. Но намного важнее, конечно же, практические навыки идентификации, анализа и реагирования на риски. Поэтому в качестве дополнения к представленному материалу предлагаем вам познакомиться с десятью золотыми правилами управления рисками от Барта Джутта.
10 золотых правил управления рисками от Барта Джутта
Барт Джутт – управляющий директор нидерландской компании Concilio по разработке специализированного программного обеспечения и признанный авторитет в области риск-менеджмента с 15-летним опытом работы с проектами. В своем пособии по управлению рисками он формулирует 10 правил, позволяющих успешно работать с угрозами при реализации проектов.
1
Сделайте управление рисками частью проекта
Первое правило очень важно для успешного проектного риск-менеджмента. Если вы не сделаете управление рисками частью проекта, вы не сможете получить всех преимуществ от его использования. Некоторые компании, особенно те, которые сталкиваются с проектами впервые, не уделяют этому вопросу внимания, надеясь на то, что не столкнутся с рисками. От этого вся их проектная система становится неэффективной и подверженной массе опасностей. Но профессионалы всегда делают управление рисками частью своих ежедневных операций по проекту, в том числе и обсуждают соответствующие вопросы на совещаниях и мероприятиях по обучению персонала.
2
Определяйте риски на начальном этапе проекта
Первый этап в проектном риск-менеджменте основывается на выявлении присутствующих в проекте рисков. Для этого нужно сконцентрироваться на разработке возможных сценариев возникновения рисков. В работе следует использовать опыт и знания всех членов команды и участников проекта, а также сторонних экспертов. Такой подход позволит определить всевозможные угрозы, в том числе даже те, которые изначально не попали в поле зрения.
Для определения рисков рекомендуется проводить интервью и собеседования с членами команды, а также мозговые штурмы. Информация может заноситься в электронные документы и отражаться на бумаге. В качестве вспомогательных инструментов желательно использовать бизнес-планы, стратегии и прочие документы уже осуществленных проектов. Естественно, далеко не всегда можно определить все риски до их появления, но с помощью разных методов идентификации появляется возможность выявить большинство из них.
3
Сообщайте о рисках
Ошибка многих руководителей проектов состоит в том, что они не сообщают команде и другим участникам об угрозах. Причем это бывает даже в тех случаях, когда риски налицо. Но если у вас есть цель оперативно проработать угрозы, необходимо сразу же брать их во внимание и информировать о них других людей, чтобы своевременно включить в план работы задачи по их устранению.
4
На совещаниях по проекту информация о рисках всегда должна выноситься на повестку дня – это позволит обсудить проблемы, выделить время для их решения и выявить другие потенциальные угрозы, которые могут возникнуть. Не забывайте и о том, что обо всех рисках в обязательном порядке нужно сообщать спонсору и инициатору проекта.
5
Рассматривайте риски как возможности
Проектные риски – это в первую очередь угроза, но при помощи современных подходов можно найти положительные для проекта риски и сфокусироваться на них. Некоторые риски могут сослужить хорошую службу проекту, повлияв на его успешность и скорость реализации в позитивном ключе.
Чтобы у вас и у вашей команды была возможность найти обратную сторону рисков, нужно оставлять в запасе некоторое время на их дополнительное рассмотрение, а не бросаться, сломя голову, на их устранение. Даже 30 минут могут в корне изменить ситуацию, если вам удастся найти способ извлечь выгоду из, казалось бы, безвыходной ситуации.
6
Уточняйте вопросы ответственности
Ряд руководителей считает, что риски предупреждены уже после составления их перечня. Однако список служит лишь отправной точкой. Следующим шагом будет распределение ответственности за риски. За оптимизацию каждого риска для проекта должен отвечать конкретный сотрудник, и последствия такого подхода могут быть крайне благоприятны для исхода всего дела.
Изначально члены вашей команды могут чувствовать себя некомфортно, понимая, что на них возложена серьезная ответственность. Но с течением времени они адаптируются и станут выполнять действия и решать задачи по минимизации угроз должным образом.
7
Расставляйте приоритеты
Многие руководители предпочитают рассматривать и учитывать все риски в равной степени, считая, что это значительно упрощает реализацию проекта. Но это не лучшая стратегия, т.к. одни риски могут быть опаснее, чем другие, и степень их вероятности может быть выше. По этой причине лучше уделять время на проработку рисков, способных привести к самым крупным потерям.
Проанализируйте ваш проект на наличие недостатков, способных его подорвать. Если таковые имеются, присвойте им наивысший приоритет. Остальные риски следует приоритизировать, исходя из критериев важности, специфических для каждого конкретного проекта. Но обычно критериями служат последствия рисков.
8
Анализируйте риски
Четкое понимание характера риска – обязательное условие для управления им. По этой причине следует избегать поспешных выводов, а сосредотачиваться на более тщательном исследовании угроз. Анализ рисков осуществляется на нескольких уровнях. Если ваша цель – понять суть риска, подробно изучите его возможные последствия. Их скрупулезный анализ покажет вам особенности риска с позиции затрат, времени и качества результата.
А пристальное внимание к предшествующим возникновению риска событиям поможет составить список причин и обстоятельств его появления, благодаря чему можно будет разработать комплекс мер по их минимизации. Информация, собранная в процессе анализа, представляет собой ценные данные для проекта и служит исходным материалом для поиска мер по оптимизации рисков.
9
Планируйте риски
Наличие плана действий по работе с рисками повышает ценность всего проекта, т.к. вы имеете возможность предотвращать потенциальные угрозы и снижать воздействие уже существующих. А такой план можно составить только в том случае, если пройдены шаги, описанные выше, такие как разделение ответственности, приоритизация и анализ рисков.
При столкновении с угрозами есть несколько вариантов действий: минимизировать, избежать, принять или передать риски. Продумывайте стратегию реагирования на возможные риски, основываясь на этих вариантах. Понимание того, как действовать в ответ на угрозу, также помогает и в поиске самой угрозы.
10
Регистрируйте риски
Несмотря на то, что это правило по большей части относится к области бухучета, пренебрегать им не следует. Регистрация рисков позволяет отслеживать прогресс реализации проекта и всегда держать угрозы во внимании. Кроме того, это еще и отличный способ коммуникации, информирующий членов команды и участников проекта о происходящих событиях.
Заведите журнал рисков, в котором описывайте их, разъясняйте связанные с ними вопросы, анализируйте причины и следствия, а также фиксируйте наиболее эффективные способы реагирования. Такими записями вы всегда повысите эффективность своего риск-менеджмента.
Исследуйте риски и связанные с ними задачи
Благодаря регистрации рисков, о которой мы только что говорили, вы сможете отслеживать риски и связанные с ними задачи. Отслеживание является повседневной работой любого проект-менеджера, и его просто нужно внести в план своих дел на каждый день. Вместе с изучением сопутствующих задач гораздо легче выработать комплекс ответных мер.
Основное внимание в отслеживании рисков нужно уделять текущей ситуации в ходе проекта. Подумайте о том, какой риск наиболее вероятен на данный момент и изменились ли приоритеты рисков, чтобы понять, как действовать дальше и с какой стороны следует ожидать удара.
Грамотное управление проектными рисками сопряжено с множеством существенных выгод. Сюда относится и минимизация неопределенности, и нахождение массы возможностей и путей развития проекта, и соблюдение временных, стоимостных и качественных рамок, и, конечно же, получение прибыли.
Но все это станет реальностью только в том случае, если вместе с управлением рисками вы будете профессионально управлять и самими проектами. Для этого разработаны специальные методы, такие как Scrum, Agile, Kanban, PRINCE2 и некоторые другие. И в следующем уроке мы расскажем вам об этих методах и приведем их характеристики.
Проверьте свои знания
Если вы хотите проверить свои знания по теме данного урока, можете пройти небольшой тест, состоящий из нескольких вопросов. В каждом вопросе правильным может быть только 1 вариант. После выбора вами одного из вариантов, система автоматически переходит к следующему вопросу. На получаемые вами баллы влияет правильность ваших ответов и затраченное на прохождение время. Обратите внимание, что вопросы каждый раз разные, а варианты перемешиваются.


Система управления рисками на предприятии: виды, методы
В статье дается определение рискам и описываются основные методы и системы управления ими. Также статья раскрывает особенности классификации основных рисков.
Что содержит в себе понятие системы управления рисками
Управление рисками – один из ключевых факторов успешности открытия нового бизнеса и развития уже существующего
Под системой управлением рисками понимается комплекс мероприятий по оценке вероятности возникновения негативных факторов, оказывающих влияние на результаты деятельности, а также разработку мер по противодействию этим факторам.
Что дает система управления рисками компании:
- достоверные прогнозы возникновения возможных рисков на любой стадии работы фирмы;
- анализ причин возникновения и комплексного влияния рисков;
- разработка стратегии по предотвращению негативных последствий действия рисковых факторов;
- благоприятные условия для осуществления подобных планов;
- системный мониторинг;
- анализ и контроль результатов, с целью повышения эффективности.
Разделение полномочий ответственных лиц при организации системы управления рисками осуществляет топ менеджмент. Основанием для решений должны быть цели и задачи организации, действующие правовые ограничения и уровень квалификации и опыта сотрудников, контролирующих процессы управления рисками.
Этапы управления рисками:
- выявление риска и определение степени его влияния на компанию;
- использование методов качественного и количественного анализа;
- составление и запуск работы по плану управления рисками;
- мониторинг и контроль надлежащего исполнения плана;
- выявление закономерностей между работой системы управлением рисками и текущими финансовыми результатами;
- заключение об эффективности.
Грамотно разработанная стратегия управления рисками позволяет в значительной степени снизить негативное влияние факторов неопределенности, постоянно воздействующих на любые виды бизнеса. При разработке проекта следует опираться на услуги профессионалов — скачайте с нашего сайта полноценный готовый бизнес-план, включающий расчеты основных экономических и финансовых показателей и анализ рисковой составляющей. В качестве альтернативы вы можете заказать индивидуальный бизнес-план «под ключ», в котором будут учтены все основные моменты организации деятельности конкретного предприятия в выбранной сфере.
Этапы управления рисками
Рассмотрим подробнее этапы управления рисками, как важную составляющую соответствующей стратегии
- Анализ риска – — это начальный этап, который позволяет составить описание и поучить представление о самом хозяйствующем объекте и рисках, которые могут негативно влиять на его деятельность. Чем больше информации о потенциальных рисках удастся собрать на этом этапе, тем проще будет разработать контрмеры:
- если риск непредсказуем, но выявлен, то есть возможности разработки вариантов его снижения;
- если риск не выявлен, то его наступление может поставить под удар весь проект, вплоть до фатальных для компании последствий.
В итоге, информация, собранная на этапе должна стать достаточным основание для проведения следующих этапов разработки системы управления рисками.
- Выявление существенных и несущественных рисков. В этом процессе разработчики часто опираются на закономерность, известную, как закон или правило Парето. Он гласит, что от 20% факторов зависит 80% результата. Это закономерно для любых сфер исследуемой деятельности. Для рисковой составляющей означает, что надо выделить те 20%рисковых переменных, которые способны принести до 80% потерь и негативного влияния на бизнес процессы.
- Качественный и количественный анализ.
Эти этапы отвечают за классификацию рисков и расчеты оцифрованных оценок вероятных потерь из-за влияния рисковых переменных. Качественный анализ включает:
- поиск причин и возможных источников риска, границы их влияния;
- однозначная идентификация каждого риска;
- определение негативных последствий и возможных выгод от претворения в жизнь решений с рисковыми переменными.
Шкала, используемая при качественной оценке рисков, предполагает сравнение категорий вероятности наступления и степени влияния (очень вероятно, вероятно, маловероятно, значительное влияние, незначительное влияние и т.д.).
Количественный анализ использует результаты качественного, как основу все расчетов. Основными результатами грамотного проведенного количественного анализа будет:
- степень вероятности наступления каждого неблагоприятного события;
- сумма возможного ущерба;
- уровень риска для каждой переменной.
В итоге, получаем классификацию рисков, которые используются для дальнейшей организации стратегии управления рисками:
- уровень влияния на работу предприятия;
- управляемость определенных рисков;
- источники возникновения.
Методы управления рисками
Существует множество методов управления рисками на предприятиях, к основным из которых можно отнести:
- Отказ от риска. Бывают ситуации, когда рисковая переменная слишком серьезно угрожает деятельности компании или проекту, и не существует реальных способов снижения этого риска. Чтобы избежать таких ситуаций, следует сознательно отказаться от этого направления деятельности или проекта, как заранее бесперспективного (Боитесь сломать ноги – не прыгайте с парашютом).
- Понижение частоты вреда или вероятности образования убытка. Этот метод управления рисками проекта предполагает подготовительную работу, которая направлена на снижение вероятности наступления рискового события и несения потерь. Пример – бизнесмены и политики нанимают охрану, чтобы снизить вероятность нападения и причинения вреда здоровью; все водители, перед тем как сесть за руль, проходят обучение; если в помещении хранятся горючие материалы, то его строительство осуществляется из негорючих, и т.д. Метод эффективен, когда существует значительная вероятность наступления риска.
- Снижение величины убытков. Если все усилия по снижению риска не принесли успеха, этот метод управления рисками предусматривает инструменты по снижению суммы полученного ущерба. Суть мероприятий – это превентивные действия, которые позволят снизить потери компании от наступления рисковых событий. Например, комплекс пожаротушения позволит сохранить часть имущества при возгорании; дифференциация политики инвестирования позволит сохранять среднюю доходность при изменении ставок по отдельным вкладам или ценным бумагам.
- Разделение потенциальных рисков. Суть метода – отсечение ситуации возникновения риска, как единичного случая, а не цепочки негативных событий. Практические способы:
- дифференциация или разделение рисков. То есть источники возникновения потерь или объекты, которым наступление риска причинит вред, разделяются в пространстве. Например, чтобы снизить риск потерь всего производства в случае наступления форс – мажорных обстоятельств, существует несколько резервных параллельных площадок для выпуска продукции, и остановка одной из них не приведет к остановке всего производства;
- дублирование важных элементов управленческих, финансовых или производственных схем, потенциально подверженных рискам. Метод управления рисками предполагает создание копий элементов или процессов, значимых для деятельности компании: резервные копии информационных ресурсов и важной документации, кадровый резерв на всех уровнях управления, запасы сырья и материалов и т.д.
Все описанные методы управления рисками позволяют снизит вероятность их наступления или степень негативного влияния на показатели деятельности компании.
Концепции систем управления рисками проекта или предприятия
После того, как вероятность наступления риска оценена, как и возможные потери, каждая организация выбирает свою стратегию комплексной защиты – в виде системы управления рисками предприятия.
Концепции таких стратегий многообразны, рассмотрим основные из них.
- Статическая или традиционная система управления рисками. В рамках стратегии и концепции, все мероприятия и решения по предотвращению и нивелированию эффекта от наступления рисков, остаются неизменными после принятия соответствующего управленческого решения. В современности подобные стратегии используются ф финансовой сфере и на небольших предприятиях с достаточно простой структурой капитала и деятельности.
- Современные тенденции по обеспечению постоянного роста и развития компании требуют новых систем управления рисками, к которым относится динамическая концепция риск менеджмента. Ее суть – это ответ на вопрос: насколько полно мы используем имеющиеся возможности и учитываем риски, чтобы обеспечивать постоянное развитие? Стратегия предполагает оценку риска, относительно того экономического эффекта, который компания может получить в виде дополнительной прибыли. Если соотношение вероятностей удовлетворяет владельца или топ — менеджера, то он идет на сознательный риск.
Первая стратегия – это стратегия конформистов и приспособленцев, которые реагируют реактивно, то есть по факту наступления события. Ее плюс – это большая вероятность стабильности в ведении дел, когда достигаются заложенные нормы прибыли и не происходит скачкообразных изменений. Другой полюс такого подхода – возможная стагнация, так как в современном мире ни одна компания не хочет оставаться на существующих позициях – все хотят улучшения текущих результатов.
Вторая система управления рисками также требует осторожности, так как в ней заложена возможность недооценки рисков и вероятность несения больших потерь.
В идеале, следует сочетать особенности двух подходов – учитывать риски и оценивать их последствия, но в то же время разумно рисковать – то есть использовать потенциал возможностей с большей рисковой составляющей, но и с большими ставками получения прибыли.
Система управления рисками необходима для любого проекта. Например, при разработке бизнес-плана в сфере услуг красоты, здоровья или спорта, вам нужно будет определить все потенциальные факторы риска.
Современные методы и стратегии риск менеджмента проектов и предприятий позволяют практически полностью обезопасить бизнес от негативных последствий, если их созданием и адаптацией занимаются профессионалы. Оцените квалификацию наших аналитиков – скачайте с нашего сайта полноценный структурированный бизнес-план, с основными расчетами финансовых и экономических показателей эффективности и оценкой существующих рисков. Тогда вы сможете вовремя открыть бизнес и занять желаемую долю рынка, с привлечением внешнего финансирования. Или закажите индивидуальный бизнес-план «под ключ», который позволит раскрыть всю специфику вашей бизнес идеи.
Управление рисками. Часть 2 / Хабр
Первую часть вы можете найти здесь: Управление рисками. Часть 1
«Нужно пожертвовать многим, чтобы спасти все» Тадеуш Костюшко
После крайне важных двух первых шагов: определения рисков и первоначальной их оценки, вам пора начать что-то делать с ними.
Здесь существуют следующие возможные стратегии:
• принятие
• передача
• уменьшение
Что значит принятие риска? Это значит, что вы говорите себе: да, я вижу этот риск, да я вижу его последствия, я принимаю этот риск. Причиной этому может быть низкая вероятность, низкая стоимость воздействия или же ваше стратегическое решение. Если вы приняли риск, то обязательно включите его в бюджет. Вы принимаете риск, что на новом складе будут воровать и оцениваете это примерно в тысячу денег в месяц. Включите это в бюджет. Вы принимаете риск, что ваш лучший инженер уйдет после изменения структуры предприятия? Включите затраты на поиск и обучение нового в бюджет на следующий год. Вы принимаете риск, что ваша жена не одобрит ваш план поехать на рыбалку? Включить стоимость цветов и конфет в бюджет рыбалки. Неважно, почему вы решили принять этот риск, важно, не забыть включить его стоимость
Стратегия передачи риска означает, что вы не хотите нести этот риск сами, а вместо этого передаете его третьим лицам. Например, страхуете ваш склад от пожара. Или отдаете расчет налогов и бухгалтерию на аутсорс. Или картинки для вашего приложения вам рисует дизайнерское бюро. Здесь важно понимание того, во-первых, сколько вам будет стоить эта передача: сколько стоит страховой полис? Сколько стоят услуги дизайнерского бюро? И во-вторых: передаете ли вы ваш риск вместе с задачей? Если вы нанимаете дизайнерское бюро, то что прописано в договоре об их ответственности? Если бухгалтерская компания ошибется в расчете налога на имущество – будут ли они оплачивать штраф? Потому что если нет, то это не передача риска. Если ответственность за исправление последствий риска остается за вами, когда вы передаете что-то внешней компании на исполнение – означает, что риск сохраняется.
Еще раз: передача риска возможна только если вместе с исполнением работ вы передаете ответственность в полном объеме. Только в этом случае вы можете исключить риск из вашего списка и считать его переданным.
Если же электрикой для вашего объекта занимается малознакомый дядя Вася, который просто исчезнет с горизонта, когда что-то пойдет не так – то риск, что что-то пойдет не так с электрикой не только не передан дяде Васе, а и вовсе – может вырасти в результате такого решения об аутсорсе электрики.
Уменьшение риска – это внедрение мер по уменьшению либо вероятности его наступления либо стоимости его последствий. Например, чтобы уменьшить риск задержки выпуска приложения, вы берете еще одного разработчика. Чтобы уменьшить риск осыпи, вы делаете более дорогое укрепление. Чтобы уменьшить риск непоступления вашего сына в универ, вы берете дополнительные уроки у репетитора. Чтобы уменьшить риск потери при доставке, вы заказываете экспедиционные услуги.
Когда вы уменьшаете риск, стоит соотнести затраты на его уменьшение и итоговое выражение уменьшения риска.
Пример: чтобы корпус не ломался, можно сделать его из более качественного (но и более дорогого) пластика, но если стоимость нового пластика выше, чем затраты по гарантии на замену поломок корпусов из старого пластика – это нецелесообразная мера. Но! Бизнес-решения не должны отталкиваться лишь от управления рисками. Попытка смотреть на бизнес лишь как на набор рисков – слишком узок и недальновиден. Если ваш дорогой корпус позволит вам расширить целевую аудиторию покупателей, увеличить цену/маржу, занять другую позицию на рынке – тогда считайте дальше. Не оставливайтесь лишь на рассмотрении «стоимость гарантийных случаев» vs «стоимость другого пластика». Для подобных решений риски – лишь часть картины.
Но в общем случае меры стоят того, чтобы их внедрять, лишь если они дешевле риска. Возможно, оценив стоимость внедрения мер, вы решите принять риск. Это тоже нормально. Вы знаете, что делать: включите его в бюджет.
После того, как вы определились с мерами, которые либо уменьшают объем потерь либо вероятность наступления риска, пришло время для окончательной оценки.
Нетто-оценка = Новая вероятность*Новый объем риска + Стоимость мер
Про это часто забывают: что стоимость мер должна стать частью окончательной стоимости риска. Только так вы сможете уменьшить ваш риск.
По сути ваша брутто-оценка нужна вам как входная информация для принятия решения о реагировании на риск, а вот нетто-оценка – это уже те цифры, с которыми вы будете дальше жить.
Итак, перед вами список ваших рисков с окончательной оценкой. Теперь пришло время принимать решения относительно этих рисков.
«Слабый человек сомневается перед тем, как принять решение; сильный — после» Карл Краус
Мы расскажем вам об условно-стандартных подходах к рискам, но всегда стоит учитывать специфику вашего бизнеса, вашего проекта, вашей ситуации.
Стандартный подход:
• риски с вероятностью выше 80% — считать почти случившимися и в полном объеме включать их в бюджет
• риски с вероятностью ниже 20% — считать маловероятными и включать в бюджет лишь меры по их уменьшению/устранению
• риски с вероятностью между 20% и 80% — включать в бюджет нетто-оценку, то есть остаточную оценку риска и стоимость мер.
Это опять-таки зона управленческих решений. Именно вы принимаете решение, что должно случиться с этими рисками и в каком объеме они должны войти в ваш бюджет. Математика, модели, процессы – лишь инструменты, помощь в принятии решений, но не замена стратегии, видению и менеджменту. В конце концов, именно вы отвечаете за принятые решения. И процесс управления рисками – по своей сути, тоже мера уменьшения наступления рисков.
Пример из проекта:
Ситуация: мы пишем приложение для заказчика, к 1ому апреля должны сдать продукт, согласно договору за каждый день просрочки нам начисляется пеня в размере 0,1% от цены продукта (цена: 1 миллион денег).
Риск: «мы не успеем и нам придется платить, а потом они вообще с нами больше не будут!!!!!» — ок, это не формальное описание риска, но на самом деле куда важнее идентификация риска и его оценка, чем красота корпоративного копирайта в списке рисков. Первоначальная оценка риска: исходя из нашей истории, мы каждый раз в среднем задерживаемся на 15 дней. Проектный менеджер говорит, что разработчик недавно сменился и ему потребуется какое-то время, чтобы понять, что вообще надо делать и что продажники опять пообещали нереальные сроки и его экспертная оценка, что мы отстанем минимум дней на 30. Руководитель принимает решение использовать оценку Проектного менеджера. То есть первоначальная оценка потерь: 30*0,1%*1 миллион денег=30 тысяч денег. Вероятность, что мы опоздаем на 30 дней проектный менеджер оценивает в 70%, то есть первоначальная оценка этого риска 30 тысяч пени*70%вероятности=21 тысяча денег. Менеджер по продажам говорит, что это уже третий проект этому заказчику, который мы задерживаем и что если мы на месяц опять опоздаем, то они у нас вообще ничего больше не закажут, а он рассчитывал продать им еще два продукта: за 0,5 миллиона денег и еще за 1 миллион. И что вероятность, что больше они заказывать не будут, если мы просрочим этот проект – 30%. А потери – вот эти 1,5 миллиона и недополучим, то есть оценка потерь 1,5миллиона*30%=450 тысяч денег. Внимание – это связанные риски, но это два отдельных риска с общим событием. Здесь легко ужаснуться, что вот внезапно мы уже рискуем 450+30=480 тысяч денег и потерей заказчика. Это не те риски, который мы можем принять. И передать их тоже практически невозможно. Тогда давайте его уменьшим. Например, давайте вот эти два куска кода отдадим фрилансерам, чтобы наш разработчик их только проверил, а не писал сам. Стоимость работы фрилансеров будет 20 тысяч денег. Проектный менеджер ворчит, но согласшается, что это снизит количество дней просрочки до 15. Да и вероятность, что на 15 дней просрочим уже лишь 40%. А за 15 дней просрочки, и с этим соглашается даже менеджмер по продажам, заказчик уже не откажется от наших будущих проектов. Ну или может отказаться. Но вероятность – не больше 10%.
Таким образом, в окончательном варианте мы имеем два риска:
— риск выплаты пени: 15 дней просрочки (15*0,01%*1млн)15тысяч*40%вероятности+20тысяч стоимости фрилансеров=26 тысяч денег – нетто-оценка риска
— риск потери заказчика: 1,5 миллиона*10%=150 тысяч денег
Второй риск имеет 10%-ную вероятность. Считаем его маловероятным. Продолжаем мониторить, но в бюджет не включаем. А в бюджет проекта включаем 26 тысяч денег по первому риску. И сразу же начинаем поиск фрилансеров. И вот тут имеет смысл еще определить и оценить дополнительные риски работы с фрилансерами. И напоминаю, фрилансеры не несут ответственность за задержку сдачи приложения, поэтому это была не передача риска, а его уменьшение.
И не забывайте о регулярном обновлении – ваши риски меняются, появляются новые, отваливаются старые, законодательство и ситуации на рынках меняются.
Как часто обновлять риски – зависит опять-таки от специфики бизнеса. В быстро меняющеся мире изменения могут происходить каждый день, но строить все бизнес-процессы лишь вокруг управления рисками – нерационально. Здесь необходимо найти баланс между затратами на получение информации (в том числе временными) и ценностью полученной информации. Но раз в квартал проанализировать, что изменилось за это время, выросли ли вероятности рисков, выполняются ли в срок меры для уменьшения/устранения рисков, не изменилась ли оценка воздействия – не займет много времени, но даст возможность держать руку на пульсе. А раз в год, особенно для собственного бизнеса, стоит провести повторный анализ рынка, окружения, законодательства и экспертное обсуждение, не появились ли новые риски, неучтенные ранее.
Мы надеемся, что наш обзор процесса управления рисками окажется вам полезным.
Данная статья – лишь обзор процесса управления рисками. Каждый из аспектов этого процесса заслуживает куда более детального внимания, но для создания общего впечатления о процессе и его важности можно составить на основе обзора.
Идеи для дальнейших статей – более подробный разбор следующих тем:
— способы оценки рисков
— меры по уменьшению рисков
— практическое внедрение процесса
Держите нос по ветру и ваши риски под контролем! Удачи!
«Больше всего рискует тот, кто не рискует» Иван Бунин
виды, анализ и оценка проектных рисков
Проектов без рисков не бывает. Увеличение сложности проекта приводит к увеличению числа и масштабов сопутствующих рисков. Когда мы осмысляем управление проектами, в большей степени думаем не об оценке рисков, что является промежуточным действием, а о том, как разработать такой план реагирования, чтобы добиться снижения рискованности. Управление рисками проекта имеет свои специфические особенности, о которых пойдет речь в настоящей статье.
Понятие проектного риска
Под риском в проектной деятельности будем понимать вероятное событие, в результате которого субъект, принявший решение, теряет возможность достичь запланированных результатов проекта или его отдельных параметров, имеющих временную, количественную и стоимостную оценку. Риск характеризуется определенными источниками или причинами и имеет последствия, т.е. оказывает влияние на результаты проекта. Ключевыми словами в определении являются:
- вероятность;
- событие;
- субъект;
- решение;
- потери.
Риски проекта всегда связаны с неопределенностью. И в этой связи нас должны заботить два момента: степень неопределенности и ее причины. Под неопределенностью предлагается понимать состояние объективных условий, в которых проект принимается к исполнению, не позволяющее предвидеть последствия решений в силу неточности и неполноты доступной информации. Степень неопределенности имеет существенное значение, потому что мы способны управлять только теми рисками, по которым имеется хоть какая-либо значимая информация.
Если информации нет, то такого рода риски именуются неизвестными, и по ним приходится закладывать специальный резерв без реализации процедур управления. Для данной ситуации вполне подходит пример риска внезапного изменения налогового законодательства. Для угроз, по которым имеется хотя бы минимальная информация, уже можно разработать план реагирования, и минимизация риска становится возможной. Далее показана небольшая схема границ управления риском с позиции его определенности.
Схема границ управления рисками с позиции определенности
Следующим моментом для понимания специфики риска проекта является динамичность карты рисков, изменяющейся по мере реализации проектной задачи. Обратите внимание на размещенную ниже схему. В начале проекта вероятность угроз высока, но возможные потери отличаются низким уровнем. Но к концу выполнения всех работ по проекту величина потерь значительно возрастает, а вероятность угроз снижается. С учетом данной особенности следуют два вывода.
- Целесообразно в процессе реализации проекта производить анализ рисков несколько раз. При этом карта рисков трансформируется.
- Минимизация рисков наиболее оптимально происходит на этапе разработки концепции или в момент разработки проектной документации. Такой вариант обходится значительно дешевле, чем на этапе непосредственной реализации.
Модель динамики вероятности риска и величины потерь
Рассмотрим небольшой пример. Если в самом начале проекта будет выявлена угроза качеству его продукта из-за дорогостоящего материала, не подходящего по техническим условиям, то издержки, связанные с исправлением, окажутся незначительными. Изменение плана проекта, вызванное заменой материала, повлечет небольшую задержку сроков. Если же возможные негативные последствия выявятся на стадии исполнения заказа, ущерб может оказаться существенным, и достичь снижения потерь не получится.
Элементы концепции управления проектными рисками
Современная методология управления проектными рисками предполагает активный подход в работе с источниками и последствиями выявляемых угроз и опасностей в отличие от недавнего прошлого, когда реагирование носило пассивный характер. Под управлением рисками следует понимать совокупность взаимосвязанных процессов, основанных на идентификации, анализе рисков, разработке мер по снижению уровня негативных последствий, возникающих при наступлении рисковых событий. PMBOK выделяет шесть процессов управления рисками. Визуальная схема последовательности этих процессов представлена ниже.
Схема процессов управления проектными рисками по PMBOK
Основными процедурами данного вида управления являются:
- идентификация;
- оценка;
- планирование реагирования;
- мониторинг и контроль.
Идентификация подразумевает определение рисков на основе выявленных факторов их возникновения, документальное оформление их параметров. Качественный и количественный анализ причин возникновения, вероятности негативных последствий формируют оценочную процедуру. Планирование реагирования на выявленные факторы предполагает разработку мер по снижению неблагоприятного воздействия на результаты и параметры проекта. Проектный вид деятельности отличается динамичностью, уникальностью событий и сопутствующих рисков. Поэтому их мониторинг и контроль занимают особое место в системе управления и выполняются на всем протяжении жизненного цикла проектной задачи. Управлением рисками обеспечивается следующее.
- Восприятие участниками проекта неопределенностей и угроз в среде его реализации, их источников и вероятных негативных событий вследствие проявления рисков.
- Поиск и расширение возможностей для результативного и эффективного решения проектной задачи с учетом выявленной неопределенности.
- Разработка путей снижения проектных рисков.
- Доработка проектных планов с учетом выявленных рисков и комплексом мер для их снижения.
Проектные риски подвергаются управляющему воздействию со стороны менеджера проекта. К этой работе привлекаются в разной степени все участники проектной задачи. Используются программно-математический аппарат, методы экспертных оценок, интервьюирования, обсуждения, «мозгового штурма» и т.д. Перед началом управления формируется информационный контекст, включающий выявление внешних и внутренних условий, в которых будут решаться задачи. Внешние условия включают политические, экономические, правовые, социальные, технологические, экологические, конкурентные и другие аспекты. Возможные внутренние условия состоят из:
- характеристик и целей самого проекта;
- характеристик, структуры и целей компании;
- корпоративных стандартов и регламентов;
- информации о ресурсном обеспечении проекта.
Планирование управления рисками
Первым процессом среди общего состава процедур работы с проектными угрозами является планирование управления рисками. Оно позволяет уточнить выбранные методы, инструменты и уровень организации управления применительно к конкретному проекту. Институт PMI данному процессу отводит важную роль для целей коммуникаций со всеми заинтересованными сторонами. Ниже представлена процессная схема планирования, размещенная в Руководстве PMBOK.
Диаграмма потоков данных планирования управления рисками. Источник: Руководство PMBOK (издание пятое)
План управления рисками представляет собой документ, включающий определенный состав разделов. Рассмотрим пример развернутого содержания подобного плана.
- Общие положения.
- Основные характеристики компании.
- Уставные характеристики проекта.
- Цели, задачи управления рисками.
- Методологический раздел. К методологии относятся методы, средства анализа и оценки, источники сведений, которые рекомендуется использовать для управления рисками проекта. Методы и инструменты расписаны по стадиям проектной реализации.
- Организационный раздел. В него включается распределение ролей участников проектной команды с установлением ответственности за выполнение предусмотренных планом процедур, состав взаимосвязей с другими компонентами управления проектом.
- Бюджетный раздел. Включаются правила формирования и обеспечения выполнения бюджета управления рисками.
- Регламентный раздел, включающий сроки, периодичность, продолжительность операций по управлению рисками, формы и состав управляющих документов.
- Раздел метрологии (оценки и пересчета). Принципы оценки, правила пересчета параметров и справочные шкалы определяются заранее, служат вспомогательными средствами качественного и количественного анализа.
- Пороговые значения рисков. С учетом важности и новизны проектной реализации устанавливаются допустимые значения рисковых параметров на уровне проекта и отдельных угроз.
- Раздел отчетности посвящен вопросам периодичности, формам, порядку заполнения, сдачи и рассмотрения отчетов по настоящему блоку управления проектами.
- Раздел мониторинга и документационного обеспечения управления рисками по проекту.
- Раздел шаблонов для управления рисками.
Идентификация проектных рисков
Следующим процессом рассматриваемого блока управления является идентификация рисков. В ходе ее реализации проектные риски выявляются и документируются. В результате должен возникнуть список рисков, ранжированный по степени их опасности. К идентификации факторов следует привлекать не только членов команды, но и всех участников проекта. В Руководстве PMBOK данный процесс охарактеризован следующим образом.
Выписка из Раздела 11 Руководства PMBOK.
Идентификация производится по результатам исследования всех выявленных факторов. При этом не следует забывать, что далеко не все факторы идентифицируются и подлежат управлению. В ходе разработки и уточнений проектных планов часто возникают новые возможные источники угроз и опасностей. Тенденция такова, что по мере продвижения проекта к завершению число вероятных рисковых событий растет. Качественная идентификация зависит от присутствия под рукой подробной классификации рисков. Одним из полезных классификационных признаков является уровень их контролируемости.
Классификация рисков по уровню контролируемости
Классификация проектных рисков на основе признака контролируемости полезна определенностью, под какие неконтролируемые факторы нужно заводить резервы. К сожалению, контролируемость рисков часто не гарантирует успеха в управлении ими, поэтому важны и другие способы деления. Стоит заметить, что универсальной классификации не существует. Это вызвано тем, что все проекты уникальны и сопровождаются массой специфичных рисков. Кроме того, часто сложно прочертить границу между схожими видами рисков.
Типовыми признаками классификации являются:
- источники;
- последствия;
- способы снижения угроз.
Первым признаком активно пользуются именно на этапе идентификации. Последние два оказываются полезными, когда проводится анализ факторов риска. Рассмотрим виды проектных рисков в связи с уникальностью их факторов.
- Специфические угрозы с позиции локального проекта. Например, риски, привязанные к конкретной вводимой технологии.
- Специфические угрозы с позиции типа проектной реализации. Спецификой обладают факторы для строительных, инновационных, IT-проектов и т.п.
- Общие риски для любых проектов. Можно привести пример рассогласования планов или низкого уровня бюджетной проработки.
Для идентификации имеет значение грамотность формулировки риска, нельзя путать источник, последствия и сам риск. Формулировка должна быть двусоставной и включать указание на источник, из-за которого возникает риск, и собственно угрожающее событие. Например, «риск срыва финансирования из-за рассогласований в бюджете проекта». Как было отмечено, виды проектных рисков часто делятся по основным источникам. Далее приводится пример наиболее распространенной версии такой классификации.
Классификация проектных рисков по источникам
Анализ и оценка проектных рисков
Анализ и оценка рисков производятся с целью преобразования добытых в ходе идентификации сведений в информацию, позволяющую принимать ответственные решения. В ходе процесса качественного анализа производится ряд экспертных оценок возможных неблагоприятных последствий, обусловленных выявленными факторами. В процессе количественного анализа определяются и уточняются значения количественных показателей вероятности возникновения угрожающих событий. Количественный анализ значительно более трудоемкий, но и более точный. Он требует качества входных данных, использования развитых математических моделей и более высокой компетентности от персонала.
Бывают ситуации, когда качественные аналитические исследования оказываются достаточными. На выходе аналитической работы менеджер проекта намерен получить:
- сгруппированный по приоритетам список рисков;
- список позиций, требующих дополнительного анализа;
- оценку рискованности проекта в целом.
Различают экспертные оценки вероятности наступления неблагоприятных событий и уровня воздействия на проект. Основным выходом процесса качественного анализа является список ранжированных рисков с выполненными оценками или оформленная карта рисков. И вероятности, и влияния разбиваются на категориальные группы в заданном диапазоне значений. В результате оценок строятся различные специальные матрицы, в ячейках которых помещаются результаты произведения значения вероятности на уровень воздействия. Полученные результаты делятся на сегменты, которые служат основанием для ранжирования угроз. Пример такой матрицы «вероятность/воздействие» можно найти в Руководстве PMBOK, он и представляется вашему вниманию ниже.
Пример матрицы вероятности и воздействия. Источник: Руководство PMBOK. Издание пятое.
Таким образом, в матрице формируется три сегмента: недопустимые, средние и незначительные риски (так называемые «пороговые уровни»). Помимо определения двух основных параметров (вероятности и воздействия) для качественной оценки необходимо также установить саму возможность управления рисками. Исходя из источников, риски подразделяются на:
- управляемые;
- частично управляемые;
- неуправляемые.
Далее размещен алгоритм принятия решения по факту выяснения вопроса управляемости и величины риска. В случае, если установлены неуправляемые опасные риски, они выносятся на обсуждение с заказчиком и инвестором. Выявление опасной неуправляемой угрозы может послужить основанием для остановки реализации проекта.
Блок-схема принятия решения по результатам анализа
Еще одним результатом анализа и оценки может быть карта риска, которая в визуально наглядной форме представляет ту же матрицу вероятности/воздействия. Посмотрим на представленный ниже пример карты. Большому кругу в верхнем правом углу соответствуют риски, которые считаются недопустимыми. Неопасным уровнем риска в данном примере считаются вероятности событий, расположенных ниже и левее красной линии.
Пример карты риска
Планирование способов реагирования на риски
Еще раз пройдемся по цепи событий, связанных с управлением рисками. Что предстоит сделать?
- Определить источники риска.
- Выявить риски, которые из этих источников следуют.
- Выяснить, на что это влияет.
- Построить модель зависимостей.
- Определить принадлежность рисков по уровню допустимости и последствий.
- Разработать план минимизации выявленных угроз.
В практике различают четыре типа последствий, которые влияют на бюджет, сроки, качество продукта либо на его функционирование. Планирование способов реагирования – это регламентированная процедура разработки плана минимизации угроз. В ходе этой работы выбираются наиболее подходящие меры, способные повысить вероятность успеха проекта. Данные меры предусматривают реагирование на риски в порядке приоритетов. В бюджет проекта включаются целевые ресурсы и операции. Ответственность за них распределяется между участниками проекта. Далее представлена соответствующая процессная диаграмма из Руководства PMBOK.
Диаграмма потоков данных планирования реагирования на риски. Источник: Руководство PMBOK. Издание пятое.
Различают четыре основных метода реагирования на риски, первые два из которых относятся к активным методам.
- Избежание. Полное устранение источников риска. Это наиболее активный метод реагирования. Его не всегда возможно применить. Допускается он, когда удается полностью исключить источник риска, например, если источник риска связан с отсутствием какой-либо информации. Проект-менеджер обязан необходимую информацию получить любым доступным способом: собрать, купить и т.д. Не совсем правильным решением является, когда избежание связано с отказом от каких-то отдельных элементов проекта, что является пассивным нерациональным действием.
- Минимизация. Уменьшение вероятности и снижение опасности риска. Это второй активный способ реагирования. Виды рисков, для которых применяется данный метод, должны быть полностью контролируемы. Обычно это внешние риски.
- Передача-страхование. Предполагается нахождение третьей стороны, готовой принять риск и его негативные последствия на себя. В данном методе лучшие условия получает тот, у кого сильнее переговорная позиция (монопольная позиция на проекте).
- Принятие. Предполагается осознанная готовность к риску. Все усилия направляются на устранение последствий.
В настоящей статье мы осуществили краткий обзор методологической базы управления рисками проекта в ее современной трактовке. Тенденции развития проектного управления постоянно повышают значение данного компонента системы Project 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-а тем, что принимает участие в выработке наиболее оптимальных путей достижения целей проекта, в том числе и путем своевременного нахождения потенциальных проблем (рисков) и предложения альтернативных вариантов их решения.
Немного теории об управлении рисками / Хабр
Вводная информация по управлению рисками
К теме управления рисками я решил обратиться по нескольким причинам:
- недавно я разрабатывал методику и процедуру по управлению рисками в компании, где я работаю (разработка ПО под заказ, аутсорсинг) – соответственно, было перерыто и изучено очень много материалов, информация из которых потом была структурирована и оформлена в отдельный документ, который сейчас используется
- само по себе управление рисками является одной из ключевых активностей на проекте: на мой взгляд одной из самых сложных, но в то же время интересных (из каждого риска и события можно извлечь выгоду)
- как показывает опыт работы в компаниях-разработчиках ПО, управлению рисками выделяется либо очень мало времени, либо ими начинают управлять только тогда, когда они становятся проблемами (что, согласитесь, довольно поздно). Надеюсь, что информация, собранная здесь, подтолкнет интересующихся к дальнейшему изучению темы и внедрению соответствующих практик в работе
Однако стоит помнить следующее – управление рисками в любой сфере человеческой деятельности, на мой взгляд, это все-таки только прикладная дисциплина, которая предоставляет общие и практические рекомендации.
Ответы же на все вопросы в каждой конкретной ситуации придется искать самостоятельно – так что не стоит видеть в процессе управления рисками какой-то панацеи от всех бед, либо немедленного и радикального улучшения процесса разработки. Впрочем, несмотря на это, я считаю управление рисками обязательной частью хорошего процесса управления проектами.
Определение риска
Определений рисков огромное множество и все они, в принципе, общеизвестны и интуитивно понятны. Приведу тут лишь несколько запомнившихся мне цитат.
Risks are schedule delays and cost overruns waiting to happen (by Peter Kulik)
Risk is the possibility of suffering loss (SEI, Dorofee 96)
Также следует понимать основное отличие понятия риска от понятия проблемы:
- риск это некоторое событие, которое может случиться в будущем и может привести к определенным потерям (снижение качества продукта, перерасходование бюджета, задержка сроков либо полной неудачи проекта)
- проблема же – это событие, которое уже случилось. Риски превращаются в проблемы, если с ними не работать
Некоторые термины и определения
- Риск – некоторое событие или условие, которое может позитивно либо негативно повлиять на результат проекта (план, качество, стоимость, объем реализованной функциональности)
- Вероятность риска (Likelihood) – вероятность того, что риск сработает. Является одним из атрибутов риска и может измеряться целыми числами от 1 до 4 (где 1 – очень низкая вероятность, 4 – высокая вероятность)
- Влияние риска (Impact) – обозначает величину позитивных или негативных последствий для проекта, если риск срабатывает. Является одним из атрибутов риска и может измеряться целыми числами от 1 до 4 (где 1 –малое влияние, 4 – блокирующее влияние). Может также носить название «потери»
- Величина риска (Risk Exposure) – произведение вероятности на влияние риска (Risk Exposure = Likelihood x Impact)
- Mitigate (к сожалению, не смог адекватно перевести) – разрабатывать стратегии и план действия для снижения вероятности и/или влияния риска до какого-либо приемлемого уровня (к примеру, можно использовать матрицу величины риска, речь о которой пойдет позже)
- Mitigation strategy – план действий, направленный на снижение вероятности и/или влияния риска до какого-либо приемлемого уровня (план митигации рисков)
- Contingency – подход, направленный на минимизацию влияния риска после того, как он сработал
- Contingency plan – план, направленный на снижения влияния риска (последствий риска) после того, как риск сработал
Следует различать понятия Mitigation и Contingency – первый относится к рискам, второй – к проблемам. Реализовывать mitigation plan – снижать или вероятность или влияние риска когда/если он наступит; реализовывать contingency plan – снижать последствия уже наступившего риска.
Для одного и того же риска могут разрабатываться оба плана, но в большинстве случаев – только один (тут уже надо решить что важнее – не допустить срабатывания риска, или же минимизировать потери при его срабатывании). Также при разработке mitigation plan часто руководствуются либо только стратегией снижения влияния или только стратегией снижения вероятности риска (что позволяет экономить – зачем направлять усилия на снижение влияния риска, если одновременно снижается и его вероятность).
Процесс управления рисками
Ниже перечислены шаги, которые я обычно выделяю в процессе управления рисками.
- идентификация рисков
- анализ рисков
- планирование рисков
- разрешение рисков
- отслеживание и модификация данных по рискам (параметров и/или планов и стратегий)
С чего начать?
С чего начинается процесс управления рисками на проекте? Согласно теории – с идентификации риска(ов). Необходимо составить список рисков, которые бы наиболее полно отражали картину рисков и потенциальных проблем на проекте. Следует помнить, однако, что даже самый большой список никогда не будет полным – что-то всегда будет упущено. 😉
Анализ
Результатом этого этапа является качественная и количественная оценка риска, которая может проводиться по следующим направлениям:
- оценка риска – определение значений атрибутов Вероятность риска (Likelihood) и Влияние риска (Impact)
- классификация риска – группировка рисков, основанная на каких-либо характеристиках (например, по типу рисков их можно разделить на «Quality», «Management», «Hardware», «Software» и тд)
- приоритизация риска – расставление приоритетов. Практически приоритизация делается на основе матрицы величины риска, о которой я говорил выше
Likelihood\Impact | Small =1 | Medium=2 | Critical=3 | Blocking=4 |
Very likely=4 | 4 | 8 | 12 | 16 |
High =3 | 3 | 6 | 9 | 12 |
Medium =2 | 2 | 4 | 6 | 8 |
Very low probability =1 | 1 | 2 | 3 | 4 |
При таком определении величина риска является простейшим способом определить количественную характеристику риска. Практически имеет смысл отслеживать и управлять рисками, которые находятся на главной диагонали данной матрицы или выше ее (то есть со значениями величины риска большими или равными 4 или 6).
После анализа риска мы можем составить топ10 рисков (Top 10 Risk List), выстроив риски по убыванию значения величины риска и выбрав первые десять. Следует помнить, что выбор большего числа рисков может превратить управление рисками в очень тяжелый процесс, который будет слишком дорог и неэффективен.
Планирование
Основной задачей планирования является ответ на вопрос, как мы будем обрабатывать каждый из рисков. Тут возможны следующие варианты:
- исследование риска (research) – проведение дальнейшего исследования риска для его детализации и более аккуратного планирования
- принятие риска (accept) – мы принимаем риск и готовы жить с его последствиями
- избежание риска (avoid) – мы предполагаем, что риск никогда не станет реальностью
- передача риска (transfer) – передача риска и ответственности за него в другую команду, другому менеджеру (возможно и руководству компании), другому лицу
Непосредственно для управления рисками должны быть разработаны mitigation strategy (действия, которые мы предпринимаем для снижения вероятности и/или влияния риска до какого-либо приемлемого уровня, если мы выбрали эту стратегию) и contigency plan (план действий на случай, если риск сработал).
Разрешение рисков
На данном этапе фактически происходит разрешение риска после того, как он сработал. То есть выполняется соотвуетствующий contingency plan. Задача этапа – выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о данном риске для следующего этапа.
Отслеживание и модификация данных по рискам
В данном этапе преследуются следующие цели:
- мониторинг статуса рисков
- мониторинг статуса mitigation strategy и contingency plan
- мониторинг проектных метрик, которые связаны с планами действий
- определять и извещать все заинтересованные стороны о том, что сработал триггер того или иного плана действий
Так как ситуация на проекте постоянно меняется, то необходимо постоянно отслеживать изменения параметров рисков, корректируя «Top 10 Risk List»:
- идентификация новых рисков, которые не учитывались до этого
- изменение количественных оценок на риски (возврат к этапу анализа, Top 10 Risk List может значительно измениться)
- определение, явилось ли изменение количественных оценок (если таковые есть) результатом выполнения тех или иных планов действий (mitigation strategy или contingency plan). Если величина риска снижается, то, скорее всего, mitigation strategy реализуется успешно, однако не стоит сильно обольщаться на этот счет
- определение методов и способов коррекции планов действий с учетом определенных изменений, переход к планированию
Заключение
Ключевым моментом процесса управления рисками должно быть периодическое повторение данных процессов, желательно согласованное с длительностью циклов разработки и рабочих процессов. Можно порекомендовать проводить оценку рисков один раз в 1-2 недели в зависимости от размера проекта (в некоторых особо крупных проектах периодичность может быть увеличена до месяца, однако больше я бы делать не стал).
Также хочу порекомендовать сохранять историю изменений списка рисков и их параметров (хотя бы Top 10 Risk List) – в будущем это даст нам необходимые статистические данные.
Постскриптум
Хочется отметить, что информация, приведенная выше, является выжимкой из большой, официальной и предельно формализованной процедуры по менеджменту рисков, которую я создал для компании, в которой работаю. Опущены некоторые формальные этапы (например, планирование управления рисками, контроль), для приведенных этапов дано описание их сути, что помогает понять их, но оставляет определенную свободу выбора и гибкость при применении на различных проектах.
Однако, можно обозначить пути для дальнейшего развития статьи
- детализация этапов (входные и выходные документы, ключевые активности и ответственности исполнителей)
- предложения по формату документов, которые могут использоваться в процессе
- обсуждение наиболее общих рисков и стратегий по их разрешению (так называемый Risk Assessment document)
Приглашаю все заинтересованные стороны к общению на данную интересную тему 😉
Полезные ссылки
MSF Risk Management Discipline v.1.1 — www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942&displaylang=en (http://www.microsoft.com/Rus/Download.aspx?file=/Msdn/Msf/MSF_risks_mngt_rus.doc)
‘Continuous Risk Management at NASA’ — satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html
PMBok — www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00100035801
Risk Management @ SEI — www.sei.cmu.edu/risk
SWEBOK (Guide to the SoftWare Engineering Body Of Knowledge) 2004 (Iron Man) — www.swebok.org
Просто интересные скетчи по управлению проектами — jchyip.blogspot.com/2008/12/lean-it-in-sketches.html
Управление рисками — почему процедуры так редко работают? / Хабр
Кажущаяся простотаВ любом учебнике, включая PMBOK, процедура управления рисками описывается в кристально простых и понятных терминах.
Риск нужно:
- выявить
- подвергнуть качественному и количественному анализу
- поместить в соответствующий раздел матрицы рисков
- принять решение по работе с ним
- отслеживать до наступления или потери актуальности.
Однако в реальной жизни не так часто можно увидеть аккуратное следование этим процедурам и еще реже — пользу от этого.
За кажущейся простотой лежит ежедневная работа руководителя проекта, требующая дисциплины, творческого подхода и интеллектуальных усилий. А поскольку риск — это вероятное событие в будущем, которое может быть и не произойдет, заниматься этим сейчас некогда и не хочется — есть более насущные задачи.
Допустим, руководитель проекта понимает, что управлять рисками необходимо. Убеждать его в этом не нужно. Но как это сделать наиболее эффективным способом? Какие приемы и инструменты стоит использовать, чтобы с минимальными затратами времени действительно снизить потери от наступления рисков?
Инструменты работы с рисками
Есть набор обязательных инструментов, наличие которых, а также качество содержания уже говорит о том, что руководитель проекта старается управлять рисками. Это
- Реестр рисков
- Карточки критических рисков
- Поручения и задачи, связанные с рисками
Однако их наличие само по себе не обеспечивает результат.
Первое — необходимо правильно определить риск. Как правило, к неблагоприятным последствиям приводит цепочка событий. Что называть риском? Последствия или одно из событий, которые к нему приводят?
Давайте рассмотрим простой пример.
На рисунке приведена одна и та же цепочка, но акцент сделан на разных звеньях.
Можно попытаться никогда не опаздывать на работу. Например, чтобы наверняка избежать опоздания, выходить на полчаса раньше. И это хороший вариант, если вы — жаворонок, и полчаса сна утром для вас не является большой ценностью.
А можно перенаправить стационарный телефон на мобильный, и наверняка избежать пропущенного звонка, несмотря на опоздание.
Стоимость борьбы с вероятностью наступления риска в двух случаях разная. Полчаса сна или ничего не стоящее перенаправление на мобильный. В зависимости от определения, с чем мы боремся, стоимость предотвращения может различаться кардинально.
Рисковое событие — это то, с чем мы будем бороться, что мы будем пытаться предотвратить.
В качестве практической подсказки для определения рискового события можно использовать следующие критерии:
- Событие находится под непосредственным контролем — его можно распознать, на него можно воздействовать.
- Событие гарантированно приводит к наступлению последствий.
- Есть стандартный способ решения возникающей проблемы и этот способ, как правило, недорогой.
Выявление рисков — процесс постоянный. Они могут быть сформулированы на основе предыдущего опыта, анализа текущей ситуации, их может сообщить кто угодно, и в какой угодно форме. Если держать глаза открытыми, информация о рисках будет всегда.
Вопрос в том, что из этого достойно попасть в реестр?
Запись в реестре рисков должна отличать конкретность:
- Если произойдет…
- Наступят последствия…
- Мы по этому поводу можем сделать следующее..
По каждому риску назначается ответственный и дата контроля.
Я рекомендую следующую структуру реестра рисков, которая, впрочем, может быть изменена или дополнена в соответствие с конкретными условиями и предпочтениями:
- № — Уникальный код риска
- Название — краткое обозначение риска
- Описание — описание рискового события и последствий
- Открыт — Дата регистрации риска
- Инициатор — ФИО инициатора
- Контроль риска — ФИО ответственного за регулярный контроль риска
- Приоритет — Высокий/ Средний/ Низкий
- Требуемая дата решения — Когда нужно решить о действиях по риску или проблеме
- Последствия наступления риска (сроки и стоимость) — К чему приведет наступление риска, в численном выражении.
- Действия по борьбе с риском — Что делать с риском
- Ответственный за действия — Кто должен эти действия выполнить
- Плановая дата действий — Когда нужно выполнить действия
- Действия при наступлении риска — Что делать, если риск наступит
- Дата статуса — Дата обновления статуса
- Статус — Открыт/ Анализ выполнен/ Решено/ Закрыт
Карта риска
Наиболее важные риски достойны того, чтобы по ним создать отдельный документ — карту риска.
В карте риска мы пишем:
- подробное описание того, что может произойти
- какие последствия возникнут, желательно выраженные в деньгах
- вероятность возникновения
- варианты действий (ничего не предпринимать, сделать что-то, сделать что-то другое)
- Решение и план действий
Карта риска очень удобна для эскалации. Если действия зависят от кого-то другого, кто не во власти руководителя проекта, то эскалация необходима.
3. Исполнение плана работы с рисками
Можно выявлять риски, вести реестр, оформлять карточки. Но если нет действий по рискам, то все предыдущие шаги оказываются бесполезными.
Возможны следующие стратегии работы с риском и примеры ее применения:
- Уклониться — не делать проект; отказаться от применения неизвестной технологии.
- Сдерживать — предпринять любые действия по снижению вероятности или степени влияния последствий: привлечь субподрядчика с соответствующим опытом; переместить рискованные задачи в начало проекта; провести дополнительное тестирование.
- Принять — сформировать резерв под наступление риска (временной буфер, запас в бюджете)
- Передать — возложить кого-то (заказчика, подрядчика, страховую компанию) ответственность за реализацию задачи, по которой есть риск, или его последствия.
После того, как вы решили, какую стратегию выбрать, запланировали действия, важно обеспечить их выполнение.
На одном из проектов я применял следующую практику. Назначал совещание по рискам с заместителем генерального директора заказчика и приходил с несколькими карточками рисков. Просил прочитать, при необходимости что-то пояснял, просил выбрать один из вариантов или сформулировать другое решение. После этого — расписаться на бумаге. Это очень стимулировало к действиям людей в подчинении этого руководителя.
Однако не всегда такая схема применима, если не соответствует корпоративной культуре или у руководителя есть тактика ухода от решения. Манипуляция — дело творческое.
На другом проекте мы оформляли карты рисков на портале проекта (см. Использование JIRA и Confluence в ведении проекта), которые потом собирались в реестр автоматически. Такой вариант удобнее, чем пытаться вместить все обилие информации в таблице Excel. Более того, за счет связи с системой управления задачами было легко вести планирование и контроль действий по рискам.
Это изложение не претендует на строгость терминов и полноту раскрытия темы. Вместо этого я постарался поделиться тем, что реально работает.
Если осознавать важность управления рисками, систематически пользоваться инструментами и подходить к этому практично, то можно избежать множества осложнений и вызванной ими лишней работы.
9 Закулисные истории
Трудно представить, что можно сделать с рисками проекта.
Да. Избегать, смягчать, передавать и т. Д.
Но что это значит?
Какие конкретные действия вы можете предпринять, чтобы чего-то избежать? Что вы, как руководитель проекта, можете сделать, чтобы снизить риск?
Добавление некоторых резервов риска и удаление требований из области действия — не единственные варианты.
Я хочу поделиться с вами некоторыми историями управления рисками.
Некоторые исходят из моего опыта. Некоторые я слышал от других PM.
Эти примеры управления рисками помогут вам расширить понимание.
Это не исчерпывающий список возможных действий.
Тем не менее, ваш разум начнет работать в новых направлениях.
Но имейте в виду:
Ваши усилия по управлению рисками так же хороши, как и каждый отдельный компонент. Вот почему я также делюсь своим Special Resource Guide:
Рекомендуемая загрузка: получите доступ к моему полному руководству по ресурсам и эксклюзивному видео о том, как управлять рисками проекта в ИТ-индустрии (щелкните здесь, чтобы загрузить PDF-файл).
Список примеров управления рисками в этой статье
Рекомендую прочитать статью целиком. Если он для вас великоват — выберите историю из списка:
Пример управления рисками с фиксированным сроком
Таких случаев будет много:
Клиенты приходят с фиксированным сроком для выпуска продукта или услуги.
Они имеют в виду особую область применения. Вначале они думают, что все их очки — must-Haves.
Бюджет тоже фиксирован.
Первый импульс — получить как можно больше людей и ресурсов. Делайте как можно больше. Молитесь, чтобы вы вписались.
Плохое планирование.
Реагирование на риски
Этот пример управления рисками показывает интегрированный подход к снижению угроз. Это означает, что он работает во всех ваших усилиях по управлению проектами.
Во многих случаях увеличение числа сотрудников не приводит к пропорциональному увеличению производительности.
Более того, подвергать людей чрезмерному стрессу в течение длительного периода времени не очень хорошо.
Они отключаются в тот момент, когда чувствуют, что достичь цели проекта невозможно. Там нет никакой выгоды упорной работы в течение следующих нескольких месяцев. А потом ни в коем случае не получится.
Есть подход получше:
Обычно критически важными знаниями обладают ваша команда и некоторые внутренние эксперты в данной области.
(Лучше, чем у клиентов)
Используйте их знания и авторитет, чтобы разбить объем на три группы:
- Необходимо
- Должно быть
- Приятно иметь
Не соглашайтесь класть все в первую корзину.Это не так, если вы не делаете MVP.
Определите объем работ, который имеет решающее значение для (первой) поставки.
Кроме того, обещайте доставить столько, сколько «должно было быть».
Обратите внимание на разницу:
Вы не предлагаете исключать проект, удалять функции или возможности.
Вы обещаете предоставить то, что важно для успеха проекта. Плюс вы добавляете все, что укладывается в срок.
Вполне возможно, что в итоге все доставят.
Однако, если нет — у вас есть приемлемый план действий в чрезвычайных ситуациях.
Огромная неопределенность в масштабе проекта
В данном случае риск повлиял на масштаб проекта. Однако это может быть также пример управления технологическими или интеграционными рисками.
У нас была важная и сложная корпоративная программа.
Не вдаваясь в подробности, пришлось добавить новый функционал.
С самого начала было ясно, что это большая работа.
Как обычно, есть вопрос. Сделать это или купить?
Даже если мы его купим, могут потребоваться усилия по интеграции и настройке решения.
Значит, он может выйти из штекерного модуля. Работает как есть.
Или может быть:
Купите модуль, потратите много сил на его настройку, если это вообще возможно. В конце концов, окажется, что это не рентабельное решение.
Как мы управляли рисками в этом примере?
План реагирования на риски
Фактически, мы ввели дополнительную фазу в проект.
Мы решили проверить концепцию.
Мы нашли доступные решения, которые можно использовать с нашим продуктом. Затем мы договорились о бесплатной пробной версии, в которой попробовали быструю и грязную интеграцию.
Теперь мы можем определить затраты и дополнительные работы.
Идея здесь проста:
Мы не начали проект со значительной неопределенностью объема и бюджета.
Вместо этого мы заранее провели небольшое исследование и устранили догадки.
Итак, мы сделали это еще до того, как начали планировать. Это означает, что мы начали управление рисками в самом начале проекта.
Это не то, чем вы ежедневно занимаетесь в Управлении проектами.
Однако это пример управления рисками, который показывает, что вы можете сделать лишнюю милю.
Помните, что ваша реакция на риск должна быть адекватной его воздействию.
Пример управления рисками с неэффективным качеством
Этот пример управления рисками показывает, что вы можете изменять процессы для преодоления рисков.
Итак, у меня была относительно неопытная команда.
В общем, у них был весь опыт для работы.
Однако из-за сложности продукта было много дефектов.
При смене участков дефекты складываются и множатся.
Они сильно повлияли на график.
Мы попробовали просто добавить рисковые резервы. Однако это были предположения без постоянной точности.
Более того, возникла сложность.
Время, необходимое для поиска, исправления и доставки исправленной версии приложения, растет вместе с его сложностью.
Итак, я нашел глубокое решение.
Реагирование на риски
Исходный рабочий процесс выглядит следующим образом:
Анализируйте требования -> Выполните требование -> Проверьте свою работу -> Создайте и передайте результат инженеру по обеспечению качества.


Затем QA Engineer тестирует результат.Регистрирует дефекты и возвращает результат разработчику для доработки.
Даже в небольшом проекте это трудоемкий процесс.
Итак, я ввел контрольную точку качества.
Это происходит в тот момент, когда разработчик протестировал свою работу и готов передать результат QA-инженеру.
Инженер по обеспечению качества должен сделать быстрый обзор работы, прежде чем она попадет в конечный результат.
Обычно это занимает от 5 до 15 минут. Для сравнения, тестирование для подтверждения требований может занять от нескольких часов до нескольких дней.
Это была быстрая победа.
Количество дефектов уменьшилось почти вдвое. К тому же и серьезность этих дефектов была ниже.
Однако есть загвоздка.
Это не идеальное решение:
Во-первых, это требует дополнительных усилий. Во-вторых, это отвлекает команду QA. В-третьих, это снижает ответственность разработчиков за качество.
С этими побочными эффектами (остаточными рисками) мне пришлось работать дополнительно.
Рекомендуемая загрузка: получите доступ к моему полному руководству по ресурсам и эксклюзивному видео о том, как управлять рисками проекта в ИТ-индустрии (щелкните здесь, чтобы загрузить PDF-файл).
Риск потери важного члена команды
Вы спланировали свой проект. Ваш план выглядит реалистичным. Клиентам это нравится.
Проверьте это:
Посмотрите на свое расписание. Есть ли у вас один человек, который участвует во всех действиях на Критическом пути?
Посмотрите в свою матрицу RACI.Одно и то же лицо отвечает за большинство результатов?
Изучите его или ее задания. Это человек, обладающий уникальными знаниями и опытом?
Что будет, если он или она уйдет в середине проекта?
Это типичный случай. В каждом проекте есть такие «трудно заменяемые» люди.
Реагирование на риски
Здесь следует применить целый комплекс предупреждающих действий. Вам необходимо снизить вероятность такого риска.
Это то, что вы все равно должны делать:
Поговорите с этим человеком один на один. Выявить опасения, которые у нее есть в связи с рабочей средой, ее счастьем, удовлетворенностью воздействием, которое она оказывает, и т. Д. (Снижение вероятности риска)
Однако главный вопрос остается прежним:
Что мне делать, если этот человек уйдет?
У вас может быть подходящий кандидат для продвижения по служебной лестнице. Возможно, это не идеальное решение. Но влияние будет ниже.(Снижение воздействия риска)
Вы можете срочно попытаться найти кого-нибудь за пределами компании. (Активно принимаем на себя риск)
Вы можете быть прозрачными с клиентами и согласиться взять на себя влияние. Внесите изменения в план. Погрузитесь в эффект. (Пассивно принимаем риск)
Есть много вариантов. Вам нужно выбрать один. Оно должно быть адекватным величине удара.
Пример риска неправильных требований
Ниже вы также найдете еще один пример управления рисками в случае нечетких требований.Это о предположениях и неверных требованиях.
Этот другой.
Здесь мы сделали критическое предположение.
Мы предположили, что четко понимаем потребности наших конечных пользователей.
Проблема в том, что наши конечные пользователи — люди с особыми потребностями и серьезными проблемами мелкой моторики.
Мы разработали решение, которое помогает таким людям взаимодействовать с телефонами и планшетами.
Безусловно, есть несколько подходов к его реализации.Однако делать ставку на одного из них мы не хотели.
Это будет означать, что мы потратим много времени на разработку и вывод этой возможности на рынок.
Для сбора фактических отзывов от конечных пользователей потребуется еще больше времени.
В конце концов, существует значительный риск (вероятность около 30%) того, что мы сделали неверное предположение.
Итак, что мы сделали?
План реагирования на риски
Решили создать прототип.Это заняло у нас меньше недели.
За эту неделю клиенты смогли организовать семинар с пользователями.
Они продемонстрировали прототип и позволили пользователю опробовать подход.
В целом наш подход подтвердился.
Однако была загвоздка:
Мы обнаружили, что все пользователи используют один и тот же подход к использованию устройства. Но у всех была разная скорость реакции.
Таким образом, мы определили новое требование для настройки этой функции.
Риск невыполнения поставщиком обязательств
Здесь есть эмпирическое правило:
Умножьте на три все взаимодействия с третьими сторонами.
Худший случай — когда несколько поставщиков работают на одного клиента и над одним продуктом.
Если вы зависите от каких-либо результатов от других, вы никогда не можете полагаться исключительно на свое расписание.
Задержки случаются полностью.
Они заканчивают свою работу позже. Затем выясняется, что результат вообще не работает.Кто-то уезжает в отпуск и ничего не может исправить.
Тогда вы обнаружите дефект во время интеграции. Они должны это исправить, и все ваши усилия будут потрачены зря. Вы должны сделать все это снова.
Добавьте сюда накладные расходы на связь, тонкую ответственность, отсутствие интеграции с другим проектом и т. Д.
Даже если вы раньше работали с поставщиком, не полагайтесь на предыдущий опыт. Просмотрите извлеченные уроки, но относитесь к ним осторожно.
Реагирование на риски
Во многих случаях у вас мало рычагов воздействия на третьих лиц.Более того, если вы не связываетесь с ними напрямую.
Итак, лучший подход здесь — распределить резервы времени на риски для уменьшения возможных задержек и переделок.
Вы делаете это по своему расписанию.
Однако, если у вас есть полномочия, вы можете попробовать принудительно обновить типичный контракт.
По крайней мере, вы можете добавить пункт для них, чтобы они предоставляли еженедельные отчеты и посещали некоторые собрания.
В последнее время я также видел случай, когда компания принудительно меняет общий подход к управлению проектами.
Каждый поставщик должен был придерживаться этого подхода, чтобы вписаться в стратегию доставки всего предприятия.
Обновлять контракты на ходу сложно.
Однако вы можете предоставить свои идеи в отдел закупок для всех будущих контрактов с поставщиками.
Вы можете предложить сделать то же самое своему клиенту. Они могут регулировать работу других третьих лиц, с которыми вам нужно взаимодействовать.
Рекомендуемая загрузка: получите доступ к моему полному руководству по ресурсам и эксклюзивному видео о том, как управлять рисками проекта в ИТ-индустрии (щелкните здесь, чтобы загрузить PDF-файл).
Примеры управления рисками проекта с помощью больничных листов
Этот случай настолько типичен, что его следует рассматривать по умолчанию в любом проекте.
Этот пример управления рисками также показывает, что в этом процессе должно быть много здравого смысла. Управление рисками не всегда связано с экспертными знаниями или уловками управления проектами.
У нас под рукой был важный проект.
У него были строгие сроки.
Таким образом, нам пришлось отсортировать прицел и все же быть готовым к выпуску со всем, что мы могли закончить.
А это была ранняя осень.
Погода резко изменилась. Традиционно в организации наступает период больничных листов.
Это то, что я должен был принять во внимание.
Как обычно думает руководитель проекта?
Если человек заболевает гриппом, он находится вне дома примерно на две недели. Более того, если критически настроенный человек не за горами, проект затянется на две недели. Если выбывает более одного человека — значит, будет еще больше.
Обычно заинтересованные стороны не принимают временные резервы на отпуск по болезни. Особенно такой большой. Я должен сказать, что они поступают правильно.
(Хотя именно это заставляет людей приходить в офис, когда они больны. Я не поддерживаю такой подход.)
Это пример неэффективного управления рисками. Итак, каков мой подход?
План реагирования
Прежде всего, мы работаем с людьми. В большинстве случаев люди болеют из-за того, что немного опрометчивы.
Пришлось включить режим мамочки. Поэтому я советую им одеваться по погоде. Еще советую заботиться, спать спокойно и думать о своем здоровье.
Они должны разделить ответственность. Это очень важный проект для компании. Они обязались это сделать. Поэтому им следует постараться не заболеть.
Во-вторых, я запрещаю посещать офис, если кто-то простудился и почувствовал себя плохо.
В-третьих, я с самого начала устраиваю возможность работать из дома.
Это был здравый смысл, не так ли?
Теперь об аспектах управления проектами. Сколько времени мне нужно?
Если вы не можете измерить это, вы не можете им управлять. Или что-то вроде того.
Итак, я получил статистику больничных за последние два года в отделе кадров.
(я уверен, что вы тоже можете найти такую статистику.)
Оказалось, что цифры значительно ниже. В среднем для команды это было примерно 10–15 человеко-дней во время осени.
У страха большие глаза.
Поэтому эпидемий в последнее время не планирую. Я знаю, это может отличаться для вашего проекта и организации. Однако здесь главное — использовать статистику.
Итак, что осталось?
Нам необходимо снизить риск заболевания одного критически важного человека.
Избегайте задач, которые может выполнить только один человек в команде. Вы можете сделать это во время планирования.
Если у меня есть критические люди, которые занимаются критическим путем, я трачу больше времени на подготовку.Я стараюсь, чтобы кто-то другой справился с этой задачей. По крайней мере, с пониженной производительностью.
Таким образом, мы документируем и сообщаем выбранный подход и технологии. Цель — найти замену.
Иногда мне приходится искать замену вне команды проекта. Основная идея — сделать это заранее. Этот человек не сидит без дела. Его или ее руководитель должен планировать совместное использование своих ресурсов, если это возможно.
В конце концов, за три месяца работы я резервирую только неделю на больничный для команды из десяти человек.
Более крупной команде могут потребоваться более значительные резервы. С другой стороны, у них есть лучшая способность покрывать убытки.
Риск нечетких требований
С самого начала было одно существенное неясное требование.
На самом деле, это было просто видение. Однако он попал в оператор области видимости именно так. Заказчики обещали в ближайшее время предоставить подробную спецификацию.
Конечно, в Реестр рисков он попал сразу. Сначала я оценил это как высокий уровень риска.
Такие риски обычно могут иметь разные последствия.
Обещанная спецификация может быть отложена. Может быть некачественного. Я имею в виду, что он может не покрывать все аспекты требований. Или даже хуже. Это может быть и то, и другое.
Кроме того, плохо сформулированные требования означают низкое качество.
Мы запланировали выполнение этого требования ближе к концу проекта. Мы хотели уделить время заказчику.
Тем не менее, мы постоянно отслеживали этот риск.Мы устанавливали сроки, создавали резервы времени и затрат. Была дата, к которой мы должны были получить спецификацию.
После этого нам придется приступить к работе и уточнить требования самостоятельно. Таким образом, это было нашим спусковым крючком для использования резервов.
Я чувствовал, что это большое дело.
Итак, я не остановился на этом. Я воспользовался некоторым провалом в расписании, чтобы обдумать проблему.
Эта функция во многом зависела от других функций нашего сервиса. Были сотни вариантов использования.Было ясно, что полной спецификации мы никогда не получим.
Мы решили не ждать крайнего срока и действовали на опережение.
Мы создали запрос на изменение. Он объяснил, что нам нужно действовать в соответствии с риском сейчас. Более того, нам нужно использовать резервы.
Итак, каков был наш план реагирования?
План реагирования
Мы проанализировали сложность требования:
Оказалось, что это не требует особых технических навыков. Это было больше о фундаментальном бизнес-анализе.
Мы оценили, что с этим должен справиться младший инженер по обеспечению качества.
Затем мы приобрели одну на неделю.
Я попросил его ознакомиться с нашим продуктом и сосредоточиться на одной конкретной функции. Его основной задачей было разработать все варианты использования нашей новой функции.
Он выполнил работу примерно за семь дней. Однако до реализации у нас еще оставалось много времени.
Итак, основная группа рассмотрела проект и разработала спецификацию.В конечном итоге они определяют алгоритм, охватывающий все случаи.
Кстати, сверхурочно мы не работали. Мы всегда планируем перерыв в расписании. Таким образом, в перерывах между действиями нам удалось смягчить влияние на наши сроки.
Это один из ярких примеров управления рисками, которые у меня есть.
Мы реализовали эту функцию безупречно. Без серьезных дефектов. Я сомневаюсь, что при других обстоятельствах мы могли бы сделать это лучше.
Более того, я считаю, что мы даже сэкономили много ресурсов в долгосрочной перспективе.Однако я никак не могу это доказать.
Управление рисками — это в первую очередь предотвращение проблем.
И это его проклятие.
Так сложно продемонстрировать, что вы сэкономили деньги, время и силы.
Риск деструктивных действий заинтересованных сторон
В частности, в этом случае я описываю деструктивные заинтересованные стороны с хорошими и ценными намерениями.
Они деструктивно сказываются на ваших обязанностях руководителя проекта.
Однако имейте в виду, что будут намеренные деструктивные стороны.Однако реакция на риски будет почти такой же.
Этот пример находится на грани этики для менеджера проекта.
С одной стороны, вам нужно найти способ работать со всеми ключевыми заинтересованными сторонами. Вам необходимо создать взаимовыгодные отношения.
С другой стороны, нужно успешно завершить проект.
Более того, у проблемы есть еще две стороны:
Хороший руководитель проекта также должен помогать клиентам развивать их бизнес.
Вам также может потребоваться помощь в развитии бизнеса организации, в которой вы работаете.По сути, это означает получение большего количества проектов и работы от клиента.
Все они находятся в постоянном конфликте.
Развитие бизнеса означает увеличение масштабов проекта. Но если бюджет ограничен, это означает увеличение риска для текущего проекта.
Вы можете работать с внутренними заинтересованными сторонами, которые несут ответственность за развитие бизнеса с вашим клиентом.
У вас одна цель — сделать клиента счастливым.
Но ваши критерии успеха другие.
После определения новой области необходимо убедиться, что вы выполнили ее через надлежащий процесс управления изменениями.
Теперь вы должны решить, подходит ли он для текущего проекта. Соответствует ли это цели проекта.
Реагирование на риски
Вы должны убедиться, что у вас есть четкие обязанности между вами и заинтересованным лицом по развитию бизнеса.
У вас должны быть четкие границы между их обещанием, что мы сможем это сделать. И ваше стремление реализовать это в текущем проекте в рамках заданных ограничений.
Довольно часто это означает, что вам нужно глубоко погрузиться во внутреннюю политику компании.
Вам нужно будет ограничить их власть над вашим проектом.
И обычно здесь нет простого пути.
Вы будете бороться за завершение проекта в срок и в рамках бюджета. Пока они работают, чтобы принести больше денег вашей компании.
Трудно доказать преимущества завершения проектов и предоставления ценности конечным пользователям.
Этот пример управления рисками относится к сфере деловой хватки и внутренней политики.
Тем не менее, это напрямую влияет на ваши усилия по управлению проектами.
Рекомендуемая загрузка: получите доступ к моему полному руководству по ресурсам и эксклюзивному видео о том, как управлять рисками проекта в ИТ-индустрии (щелкните здесь, чтобы загрузить PDF-файл).
Также рекомендую прочитать:
Проверьте себя в управлении рисками
Считаете ли вы, что знаете достаточно об управлении рисками проекта?
Пройдите этот короткий тест и определите пробелы в своих знаниях.
В конце я даю правильные ответы и пояснения.
.
Пример плана управления рисками для любого проекта
Пример плана управления рисками
Существует множество подходов к планированию управления рисками проекта, но, по сути, план управления рисками определяет риски, которые могут быть определены на любой стадии жизненного цикла проекта. План управления рисками оценивает выявленные риски и намечает действия по их снижению. План управления рисками следует периодически обновлять и расширять на протяжении всего жизненного цикла проекта, поскольку проект становится сложнее, а риски становятся более определенными.В этой статье вы познакомитесь с примером плана управления рисками, чтобы вы лучше понимали, как использовать этот важный инструмент. [captionaligncenter ”https://www.brighthubpm.com/wp-content/uploads/2008/08/risk-1945683_640.jpg» alt = «Используйте этот пример плана управления рисками, чтобы помочь спланировать риски проекта!» /> Дон ‘ t игнорировать риск! [/ caption] В идеале управление рисками включает в себя все этапы проекта: выявление рисков, оценка рисков и их разрешение. С развитием исследований и методов управления проектами, управление рисками заняло главное место в жизненном цикле проекта; в большинстве случаев в самом начале проекта.
Как вы планируете управление рисками?
План управления рисками должен быть частью вашего общего плана проекта. План рисков для небольших проектов может быть таким же простым, как матрица управления рисками. Сложные проекты требуют более тщательного анализа и планирования рисков. Для каждого риска, указанного в матрице рисков, вам нужно будет провести тщательный анализ каждого из них. Основная цель создания матрицы рисков — расставить приоритеты для ваших рисков. Вы никогда не сможете полностью устранить риски, но вы можете расставить приоритеты и задокументировать риски, чтобы попытаться снизить или устранить их.В матрице управления рисками будут задокументированы следующие элементы: 1. Риск и последствия — Проведите мозговой штурм по рискам перед тем, как начать свой проект, и продолжайте добавлять в свой план управления рисками по мере продвижения проекта на протяжении его жизненного цикла. Какие риски могут быть связаны с этим проектом? Повлияют ли риски на график, ресурсы или бюджет? 2. Вероятность — в таблице должна быть указана вероятность наступления риска. Это может быть процент или число. 3. Воздействие — каково влияние на проект, если риск возникнет? Создайте масштаб, подходящий для проекта — для небольших проектов можно использовать простое воздействие от 1 до 5 (от минимального до основного), тогда как для более крупных проектов может потребоваться более формальный масштаб.4. Priority — (Вероятность * Воздействие) даст вам представление о приоритете риска. Пункты с более высоким приоритетом должны быть смягчены и запланированы до пунктов с более низким приоритетом. 5. Mitigation Response — краткий обзор шагов по смягчению последствий для устранения или снижения риска.
Пример матрицы управления рисками
Начните с создания таблицы из шести столбцов. Столбцы будут названы в честь каждого из пяти пунктов в предыдущем разделе. Первый столбец может быть просто столбцом идентификатора.
- ID
- Риски и последствия
- Вероятность
- Удар
- Приоритет
- Меры по смягчению последствий
Пример плана управления рисками см. В таблице ниже.
Управление рисками в действии
После того, как вы составили план управления рисками, вы получите
.7 шагов процесса управления рисками
Процесс оценки и выбора альтернативных нормативных и ненормативных мер реагирования на риск.
Процесс отбора обязательно требует учета юридических, экономических и поведенческих факторов.
Управление рисками — это процесс принятия решений, включающий рассмотрение политических, социальных, экономических и технических факторов с соответствующими оценками рисков, связанных с потенциальной угрозой, с целью разработки, анализа и сравнения вариантов регулирования и выбора оптимального регулирующего реагирования для обеспечения безопасности от этой опасности.
По сути, управление рисками представляет собой комбинацию трех этапов:
- оценка рисков,
- контроль выбросов и воздействия,
- мониторинг рисков.
Системный подход, используемый для выявления, оценки и уменьшения или устранения возможности неблагоприятного отклонения от ожидаемого результата лечения и, таким образом, предотвращения травм пациентов в результате халатности и потери финансовых активов в результате такого травма, повреждение.’
Определения управления рисками
- «Управление рисками — это интегрированный процесс определения конкретных областей риска, разработки всеобъемлющего плана, интеграции плана и проведения текущей оценки». П.К. Гупта
- «Управление рисками — это процесс измерения или оценки риска с последующей разработкой стратегий управления риском». — Википедия
- «Управление риском может включать страхование убытков, хеджирование ссуды от повышения процентных ставок. , а также защита инвестиций от падения процентных ставок.
- -Oxford Business Dictionary
- «Решения о признании уязвимости или снижении уязвимостей путем снижения рисков или ответа на рентабельные меры контроля» — Анонимный
Будущее в значительной степени неизвестно. Большинство деловых решений принимаются на основе ожиданий относительно будущего.
Принятие решения на основе предположений, ожиданий, оценок и прогнозов будущих событий связано с риском.
Риск описывается как «сахар и соль жизни».
Это означает, что риск может иметь как положительную, так и отрицательную сторону.
Люди рискуют, чтобы достичь цели, которую они иначе не достигли бы, не взяв на себя этот риск.
С другой стороны;
Риск может означать, что при выполнении какой-либо деятельности может возникнуть некоторая опасность или потеря, и поэтому необходимо принять меры, чтобы избежать такой потери.
Здесь важно управление рисками, поскольку его можно использовать для защиты от потерь или опасности, возникающих в результате рискованной деятельности.
Для надлежащего контроля и управления рисками, как страховщики, мы всегда должны помнить следующее в отношении любого проекта или объекта страхования:
- Каковы возможные источники убытков?
- Каковы вероятные последствия убытка, если он вообще произойдет?
- Что делать при возникновении убытка? Следует ли позволить убытку увеличиться или нужно что-то сделать, чтобы минимизировать его? Следует рассмотреть вопрос о защите спасательных средств наилучшим образом, а также вопрос о проверке будущей возможности таких событий.
- Вероятные расходы или экономия на предотвращении убытков (следует помнить, что любые дополнительные расходы на предотвращение убытков будут экономически оправданы, если произведенные затраты меньше или в лучшем случае равны экономии, полученной за счет сокращения убытков.
Как уже упоминалось, в страховании риск изолирован от всего коммерческого предприятия, и его чистая часть риска полностью принимается на себя другой группой людей организации (страховщика) наиболее техническим, квалифицированным и экономичным образом.
Это возможно только путем правильной диагностики риска в вопросах выявления возможных источников убытков и последствий убытков, если они вообще возникнут.
Не следует упускать из виду и вопрос сведения к минимуму потерь и предотвращения будущей причинности убытков.
Принимая во внимание эти факторы, возникает вопрос о правильной оценке риска, поскольку это будет основанием для взимания премии или цены за риск.
В контексте управления рисками действительно важна «математическая оценка риска».
7 ступеней риск-менеджмента;
- Установите контекст,
- Идентификация,
- Оценка,
- Обработка потенциальных рисков,
- Создание плана,
- Реализация,
- Обзор и оценка плана.
Система управления рисками состоит из семи (7) шагов, которые фактически представляют собой цикл.
1. Установление контекста
Установление контекста включает планирование оставшейся части процесса и определение объема учений, идентичности и целей заинтересованных сторон, основы, на которой будут оцениваться риски, и определения основы для процесс и повестка дня для идентификации и анализа.
2. Идентификация
После установления контекста следующим шагом в процессе управления рисками является определение потенциальных рисков. Риски связаны с событиями, которые при запуске вызовут проблемы.
Следовательно, идентификация риска может начинаться с источника проблемы или с самой проблемы.
Выявление рисков требует знания организации, рынка, на котором она работает, правовых, социальных, экономических, политических и климатических условий, в которых она ведет свой бизнес, ее финансовых сильных и слабых сторон, уязвимости к незапланированным убыткам, производства процессы, а также системы управления и бизнес-механизмы, с помощью которых он работает.
Любая неспособность на этом этапе идентифицировать риск может нанести большой ущерб организации.
Идентификация рисков составляет основу управления рисками.
Методы идентификации формируются с помощью шаблонов или разработки шаблонов для определения источника, проблемы или события. Существуют различные методы идентификации рисков.
3. Оценка
После того, как риски были идентифицированы, они должны быть оценены с точки зрения их потенциальной серьезности потерь и вероятности возникновения.
Эти количества могут быть либо простыми для измерения в случае стоимости потерянного здания, либо их невозможно узнать наверняка в случае возникновения маловероятного события.
Следовательно;
В процессе оценки критически важно делать максимально обоснованные предположения, чтобы правильно расставить приоритеты в реализации плана управления рисками.
Основная трудность в оценке риска заключается в определении частоты возникновения, поскольку статистическая информация не доступна по всем видам прошлых инцидентов.
Кроме того;
Оценка серьезности последствий (воздействия) для нематериальных активов часто бывает довольно сложной. Оценка активов — еще один вопрос, который необходимо решить.
Таким образом, наиболее обоснованные мнения и имеющаяся статистика являются основными источниками информации.
Тем не менее, оценка риска должна предоставлять такую информацию для руководства организации, чтобы основные риски были легко понятны и чтобы решения по управлению рисками могли быть приоритетными.
Таким образом, было несколько теорий и попыток количественно оценить риски.
Существует множество различных формул риска, но, пожалуй, наиболее широко принятая формула для количественной оценки риска — это частота возникновения, умноженная на влияние события.
В бизнесе крайне важно представлять результаты оценки рисков в финансовом выражении. Роберт Кортни-младший (IBM. 1970) предложил формулу представления рисков с финансовой точки зрения.
Формула Кортни была принята в качестве официального метода анализа рисков правительственными агентствами США.
Формула предлагает расчет ALE (Годовой ожидаемый убыток) и сравнивает ожидаемую величину убытков с затратами на реализацию мер безопасности (Анализ затрат и выгод).
4. Обработка потенциальных рисков
После выявления и оценки рисков все методы управления рисками попадают в одну или несколько из этих четырех основных категорий;
Передача риска
Передача риска означает, что ожидаемая сторона полностью или частично передает убытки, вытекающие из риска, другой стороне за определенную плату.Договоры страхования в основном предполагают передачу рисков.
Помимо страхового механизма, существуют и другие способы передачи риска.
Предотвращение рисков
Избегание риска или обстоятельств, которые могут привести к убыткам иным образом, включая невыполнение деятельности, которая может быть сопряжена с риском.
Избегание может показаться ответом на все риски, но избегание рисков также означает потерю потенциальной выгоды, которую могло позволить принятие (сохранение) риска.Отказ от входа в бизнес во избежание риска убытков также исключает возможность получения прибыли.
Удержание риска
Удержание риска подразумевает, что убытки, возникающие в результате подверженности риску, должны быть сохранены или приняты стороной или организацией.
Удержание риска — это обычно преднамеренное решение для бизнес-организаций, унаследованное со следующими характеристиками. Самострахование и кэптивное страхование — это два метода удержания.
Контроль рисков
Рисками можно управлять, избегая или контролируя убытки.Избегание подразумевает, что либо определенный размер убытков не приобретается, либо существующий риск прекращается. Контроль убытков может осуществляться двумя способами.
5. Создайте план
Определите комбинацию методов, которые будут использоваться для каждого риска. Каждое решение по управлению рисками должно быть зарегистрировано и утверждено руководством соответствующего уровня.
Например,
Риск (в отношении имиджа организации должен приниматься высшим руководством, в то время как ИТ-руководство имеет право принимать решения о рисках компьютерных вирусов.
План управления рисками должен предлагать применимые и эффективные меры безопасности для управления рисками.
Хороший план управления рисками должен содержать график реализации контроля и лиц, ответственных за эти действия.
Концепция управления рисками устарела, но по-прежнему оценивается очень эффективно. Пример. Наблюдаемый высокий риск компьютерных вирусов можно снизить за счет приобретения и внедрения антивирусного программного обеспечения.
6. Внедрение
Следуйте всем запланированным методам для снижения воздействия рисков.
Приобретите полисы страхования рисков, которые было решено передать страховщику, избегайте всех рисков, которых можно избежать, не жертвуя целями организации, уменьшите другие и оставьте остальные.
7. Обзор и оценка плана
Первоначальные планы управления рисками никогда не будут идеальными.
Практика, опыт и фактические результаты убытков потребуют внесения изменений в план и внесения информации, позволяющей принимать возможные различные решения в отношении возникающих рисков.
Результаты анализа рисков и планы управления должны периодически обновляться. Для этого есть две основные причины;
- Чтобы оценить, применимы и эффективны ли ранее выбранные меры безопасности
, и, - , оценить возможные изменения уровня риска в бизнес-среде
. Например, информационные риски — хороший пример быстро меняющейся деловой среды.
Управление рисками — базовое понимание
Буквально говоря, управление рисками — это процесс минимизации или смягчения риска . Он начинается с выявления и оценки риска, за которым следует оптимальное использование ресурсов для его мониторинга и минимизации.
Риск обычно возникает из-за неопределенности. В организациях этот риск может исходить из неопределенности на рынке (спрос, предложение и фондовый рынок), провала проектов, несчастных случаев, стихийных бедствий и т. Д.Существуют разные инструменты для борьбы с одним и тем же в зависимости от вида риска.
В идеале в управлении рисками следует придерживаться процесса приоритизации рисков, при котором в первую очередь рассматриваются те риски, которые представляют собой угрозу больших потерь и имеют большую вероятность возникновения. См. Таблицу ниже:
УДАР | ДЕЙСТВИЯ | ||
ЗНАЧИТЕЛЬНОЕ | Требуется значительный менеджмент | Необходимо управлять и контролировать риски | Обязательно расширенное управление |
СРЕДНЯЯ | Риски в определенной степени допустимы | Управленческие усилия оправданы | Требуются управленческие усилия |
НЕЗАВИСИМЫЕ | Принять риски | Принимать, но контролировать риски | Управление и мониторинг рисков |
НИЗКИЙ | СРЕДНЯЯ | ВЫСОКАЯ | |
ВЕРОЯТНОСТЬ |
Приведенную выше диаграмму можно использовать для выработки стратегии в различных ситуациях.Два фактора, которые определяют требуемые действия, — это вероятность возникновения и влияние риска. Например, состояние, при котором воздействие незначительно и вероятность возникновения низка, лучше принять риск без каких-либо вмешательств. Состояние, при котором вероятность высока, а воздействие является значительным, требует обширного управления. Так можно установить определенный приоритет в борьбе с риском.
Помимо этого, как правило, большинство организаций следуют циклу управления рисками.См. Схему ниже:

В соответствии с этим циклом процесс управления рисками состоит из четырех этапов. Первым шагом является оценка риска, за которым следует оценка и управление им. Последний шаг — измерение воздействия.
Идентификация рисков может начинаться с базового или поверхностного уровня, в первом случае определяется источник проблем. Теперь у нас есть две вещи, которые нужно решить с источником и с проблемой.
Источник риска: Источник может быть внутренним или внешним по отношению к системе.Внешние источники неподконтрольны, тогда как внутренние источники можно в определенной степени контролировать. Например, количество осадков, погода над аэропортом и т. Д.!
Проблема: Проблема на поверхности может быть угрозой аварии или несчастного случая на станции, пожара и т. Д.
Когда один или оба из двух вышеизложенных известны заранее, можно предпринять определенные шаги для их решения.
После того, как риск (-ы) был идентифицирован, он / они должны быть оценены на предмет потенциальной критичности.Здесь мы подошли к приоритизации рисков. В общих чертах «вероятность возникновения × воздействие» равняется риску.
Затем следует разработка плана управления рисками и его реализация. Он состоит из эффективных средств контроля безопасности и механизмов контроля для снижения риска.
Более серьезным риском для эффективности организации является риск, который присутствует, но не может быть идентифицирован. Например, постоянная неэффективность производственного процесса накапливается в течение определенного периода времени и трансформируется в операционный риск.
Авторство / ссылки — Об авторе (ах)
Статья написана «Прачи Джунджа» и проверена группой Management Study Guide Content Team . В состав группы MSG по содержанию входят опытные преподаватели, профессионалы и эксперты в предметной области. Мы являемся сертифицированным поставщиком образовательных услуг ISO 2001: 2015 . Чтобы узнать больше, нажмите «О нас». Использование этого материала в учебных и образовательных целях бесплатно.Укажите авторство используемого содержимого, включая ссылку (-ы) на ManagementStudyGuide.com и URL-адрес страницы содержимого.
.