Сегодня я хотел бы поделиться с многоуважаемыми завсегдатаями Хаброхабра своим обобщённым опытом управления рисками в рамках проектной деятельности. Данное описание методики управления рисками будет полезно руководителям проектов, лицам, принимающим решения, тим-лидам отдельных коллективов в проектных командах. Ознакомившись с методикой, вы сможете использовать её полностью или частично при управлении своими проектами.
Данная методика основана на рекомендациях PMBoK. Также при выкристаллизовывании методики учитывались знания и опыт, полученные мной на проектах в интересах Национального Центра Управления в Кризисных Ситуациях МЧС России. Методика апробировалась на проектах МЧС России, ГИБДД МВД, финансовых организаций и организаций-разработчиков программного обеспечения.
1. Термины и определения
Риск — неопределённое событие, возникающее в процессе выполнения работ над проектом, которое негативно влияет на один или несколько из ключевых факторов успешного проекта. Данное определение отличается от определения PMBOK, поскольку в нём не учитываются положительные последствия. Наличие рисков с положительными возможностями для проекта свидетельствует о недостаточно детальном анализе ситуации и прогнозов её развития. Неопределённое событие, положительно влияющее на проект, называется «шансом».Управление рисками — дисциплина из состава практик управления проектами, направленная на уменьшение влияния рисков на цели и конечное состояние проекта. Управлением рисками занимается либо сам руководитель проекта (для небольших проектов), либо специально выделенный для этих целей сотрудник (риск-менеджер). Если в компании принята практика централизованного управления рисками, то в её рамках производится обмен информацией и знаниями об управлении рисками, идентифицированных рисках, методах предупреждения и реагирования и т. д. между руководителями проектов, риск-менеджерами и Проектным офисом (в случае наличия такого подразделения; здесь и далее считается, что Проектный офис присутствует в организации, в случае его отсутствия его функции могут выполнять такие подразделения, как Отдел управления проектами, Отдел методологии и т. д.).Система управления рисками — комплекс средств автоматизации, нормативной и организационной документации, рабочих процедур, штатных позиций и конкретных сотрудников их занимающих, предназначенный для управления рисками в рамках проектной деятельности организации.Информационная система управления рисками — программно-информационный комплекс, элемент Системы управления рисками. Представляет собой программное обеспечение и информационные базы данных для поддержки процессов и процедур управления рисками в рамках проектной деятельности в компании.Риск-менеджер — специально выделенный в проектной команде сотрудник, чьей основной обязанностью является управление рисками проекта. Риск-менеджер структурно входит в состав Проектного офиса. Один риск-менеджер может быть задействован на нескольких проектах. На небольших проектах управление рисками осуществляет сам руководитель проекта.Проектный офис — структурное подразделение, отвечающее за развитие и реализацию методологии проектного управления в компании. Одной из функций Проектного офиса является централизованное управление рисками.Централизованное управление рисками — набор процедур, позволяющих успешно распространять информацию и знания по дисциплине управления рисками между всеми задействованными в Системе управления рисками сотрудниками. К распространяемым знаниям относятся методические инструкции и другие нормативно-справочные материалы по управлению рисками, реестры идентифицированных рисков, шаблоны и образцы документов по управлению рисками, типовые планы реагирования на риски различных категорий, описание лучших практик по управлению рисками.Иерархическая структура рисков — иерархически организованное представление идентифицированных рисков проекта, распределённых по категориям и подкатегориям рисков, указывающим на различные области и источники возможных рисков. Иерархическая структура рисков часто бывает адаптирована под конкретные типы проектов.
2. Общие положения
Данная статья описывает методику управления рисками в рамках осуществления проектной деятельности организации. В ней описываются процедуры, предпринимаемые уполномоченными сотрудниками для мониторинга, предотвращения и реагирования на риски.
Общий процесс управления рисками показан на рисунке 1.Рисунок 1. Общий процесс управления рисками
В процессе управления проектными рисками осуществляются следующие этапы:Идентификация рисков, на котором строится как можно более полный список рисков, имеющих место в конкретном проекте. В процессе идентификации конкретизируются большинство параметров всех выделенных рисков в перечне их свойств.
Категоризация рисков, в процессе которой каждому риску приписывается одна из трёх категорий, влияющая на метод мониторинга, предотвращения и реагирования на риск.
Планирование мониторинга, предотвращения и реагирования на риски, результатом которого будут планы мониторинга, предотвращения и реагирования на риски различных категорий. В данных планах должны будут быть прописаны конкретные ответственные за мониторинг лица, описан регламент выполнения работ, приведены конкретные действия по предотвращению или реагированию на риск.
Собственно, этап мониторинга, предотвращения и реагирования на риски, который является итеративным и выполняется в соответствии с плановым регламентом. В рамках данного процесса на периодической основе происходит возврат к предыдущим процессам, поскольку для гибкого управления рисками необходимо постоянно перепланировать в связи с изменяющимися условиями.
После окончания проекта (его закрытия) необходимо провести процедуру анализа эффективности управления рисками, результатом которой становится аналитическая записка с выводами относительно успешности управления рисками, оценками прибыли/расходов в связи с выполнением процедуры управления рисками, рекомендациями по изменению базы известных рисков.
Обновление базы известных рисков, когда в базу вносится новая информация и новые знания, полученные в процессе работы над проектом.
Далее в данном документе все перечисленные процессы будут описаны более подробно.
3. Идентификация рисков
После организации проекта руководителем проекта или риск-менеджером, если этот сотрудник выделен на проект на этапе старта проекта, запускается процесс идентификации рисков. Данный процесс предназначен для составления исчерпывающего перечня (реестра) рисков, с которыми можно столкнуться в процессе работ по данному конкретному проекту. И, соответственно, такой перечень становится главным инструментом мониторинга, предотвращения и реагирования на риски, поскольку в этом перечне кроме наименований самих рисков приводится и постоянно держится в актуальном состоянии вся необходимая для управления рисками информация.
На следующей диаграмме показан процесс идентификации рисков.Рисунок 2. Процесс идентификации рисков
3.1. Получение исчерпывающего перечня рисков
Для получения перечня проектных рисков руководитель проекта или риск-менеджер может воспользоваться следующими методами:
Использование базы известных рисков. Поскольку на выходе каждого проекта имеется отчёт о выполнении, частью которого должно быть описание рисков проекта, все такие описания в конечном итоге собираются в централизованной базе рисков, которую можно использовать как первичный источник для наполнения перечня рисков для конкретного проекта. Ответственный за управление рисками просматривает базу рисков и выбирает из неё те записи, которые применимы к текущему проекту.
Мозговой штурм проектной команды. Ответственный за управление рисками собирает всю проектную команду (единоразово или на периодической основе в целях пересмотра перечня рисков) и проводит мозговой штурм на тему «Риски проекта». Данный метод позволит учесть риски, видимые с точки зрения аналитиков, проектировщиков, разработчиков, тестировщиков и других ролей в проектной команде, которые могут быть не видны руководству.
Диверсионный анализ. Специально приглашённые эксперты или участники проектной команды ставят себя на место «злоумышленников» (заказчика, аудиторов, ревизоров, государственных органов регулирования и т. д.) и пытаются с этой точки зрения посмотреть на то, каким образом можно навредить проекту. Данный метод может совмещаться с мозговым штурмом.
STEEP-анализ. Если применимо, то ответственный за управление рисками может использовать анализ окружения проекта по пяти категориям: социальные, технологические, экономические, экологические и политические факторы. Впрочем, для конкретных проектов может быть применима только часть перечисленных факторов, равно как и найтись иные факторы (например, правовые, кадровые и т. д.).
Метод Дельфи. Взамен мозгового штурма проектной команды можно воспользоваться методом Дельфи. Для этих целей необходимо привлечь достаточное количество экспертов (от 10 до 20) из разных областей и аспектов, касающихся проекта. Желательно привлечение независимых экспертов, в этом случае результаты станут более объективными. Все эксперты должны работать независимо друг от друга и сдавать свои ответы в письменном виде. Ответственный за управление рисками координирует деятельность экспертов, структурирует их ответы, готовит промежуточные и окончательный результаты работы экспертной группы.
Карточки Кроуфорда. Если проведение исследований рисков методом Дельфи нецелесообразно для проекта, то можно использовать так называемые карточки Кроуфорда, для работы с которыми привлечь от 5 до 10 экспертов. Каждый эксперт должен десять раз ответить на вопрос ответственного за управление рисками «Какой риск является наиболее важным в этом проекте?», при этом каждый эксперт работает независимо, и ответы одного эксперта не должны повторяться. После сбора всех карточек ответственный за управление рисками проводит анализ, структуризацию, классификацию и составление перечня рисков.
Данный список методов не является полным, и руководитель проекта или риск-менеджер может использовать весь свой опыт и знания для составления перечня рисков.
3.2. Паспортизация рисков в списке
После составления наиболее исчерпывающего перечня рисков, все риски этого перечня необходимо паспортизовать, то есть описать в формализованном виде, заполнить паспорта рисков. Для этих целей используется таблица, содержащая следующие столбцы:
№
Наименование
Тип
Описание
Заполняется
1
Идентификатор
Код риска
Код риска в рамках проекта в виде строки «R##». В принципе, в каждом проекте может быть своя кодировка рисков, однако целесообразней, чтобы коды рисков брались из базы известных рисков для соблюдения единообразия и совместимости с базой.
На этапе паспортизации
2
Наименование
Текст
Краткое описание сути риска.
На этапе паспортизации
3
Код проекта
Код проекта
Код проекта, к которому относится риск.
На этапе паспортизации
4
Тип
Риск
Неизвестность
Риск — это в принципе известное событие, которое может произойти по тем или иным причинам. Неизвестность — неизвестные события, предсказать и предугадать которые невозможно. Для неизвестностей стратегией реагирования может быть только «Резервирование».
На этапе паспортизации
5
Вероятность
Низкая
Средняя
Высокая
Вероятность реализации риска. Качественное значение, выбираемое из трёх приведённых в столбце слева.
На этапе классификации
6
Степень воздействия
Низкая
Средняя
Высокая
Степень воздействия риска на объект воздействия при реализации. Качественное значение, выбираемое из трёх приведённых в столбце слева.
На этапе классификации
7
Класс
A
B
C
Автоматически вычисляемое значение на основе выбранных значений двух предыдущих показателей. Подробно описывается в разделе 4 «Классификация рисков».
На этапе классификации
8
Объект воздействия
Бюджет проекта
Рамки проекта
Сроки проекта
Проектная команда
Управляемость
…
Значение должно выбираться из открытого для наполнения классификатора. Большинство рисков воздействуют на «проектную тройку» — бюджет, рамки и сроки.
На этапе паспортизации
9
Категория
Технологический
Финансовый
Кадровый
Правовой
Внешний
…
Значение должно выбираться из открытого для наполнения классификатора. Используется в качестве информационного показателя, который руководитель проекта может использовать для принятия решений относительно ответственного за мониторинг, предупреждение и реагирование.
На этапе паспортизации
10
Ответственное лицо
Фамилия И. О.
Сотрудник из состава проектной команды, который отвечает за исполнение процессов мониторинга, предупреждения и реагирования на риск.
На этапе планирования
11
Причины
Текст
Перечень причин возникновения риска. Те действия или бездействия, события или явления, которые влекут за собой реализацию риска.
На этапе паспортизации
12
Критерии реализации
Текст
Перечень условий, выполнение которых свидетельствует о том, что риск реализовался.
На этапе паспортизации
13
Дата актуальности
Дата
Конечная дата, до которой риск может реализоваться, а после которой риск становится неактуальным.
На этапе планирования
14
Методы предупреждения
Текст
Перечень действий, которые должно предпринимать ответственное лицо, чтобы предотвратить проявление риска.
На этапе планирования
15
Стратегия реагирования
Отказ
Передача Заказчику
Страхование
Резервирование
Принятие
…
Значение выбирается из открытого для дополнения классификатора. Ответственное лицо реагирует на риск в соответствии с выбранной стратегией.
На этапе планирования
16
Действия по реагированию
Текст
Перечень действий, которые должно предпринимать ответственное лицо, чтобы отреагировать на проявившийся риск.
На этапе планирования
17
Статус
Идентифицирован
Отслеживается
Предотвращается
Реализован
Закрыт
Текущий статус риска, значение которого выбирается из классификатора, представленного в столбце слева.
На всех этапах
В целях упрощения процедуры идентификации рисков Проектный офис предоставляет шаблон таблицы с перечисленными столбцами и классификаторами.
3.3. SWOT-анализ
После получения исчерпывающего перечня рисков руководитель проекта или риск-менеджер должен провести SWOT-анализ для понимания того, как использовать сильные стороны и нивелировать слабые стороны проекта в вопросах предотвращения и реагирования на риски, которые в рамках SWOT-анализа рассматриваются в качестве «угроз». Результаты SWOT-анализа ложатся в основу планирования управления рисками.
В числе материалов Проектного офиса для управления рисками должен иметься специальный шаблон для проведения SWOT-анализа и представления его результатов.
4. Классификация рисков
После первоначального составления или актуализации перечня проектных рисков, все риски перечня необходимо классифицировать. Для этих целей необходимо выбрать для рисков значения таких показателей, как «Вероятность» и «Степень воздействия». Оба этих показателя имеют три возможных качественных значения: «Низкая», «Средняя» и «Высокая».
Вероятность реализации риска устанавливается лицом, ответственным за управление рисками на основании своего понимания того, насколько возможна реализация риска в проекте. Для практических целей можно пользоваться следующим правилом преобразования качественных значений в количественные и наоборот:Вероятность «Низкая»: 0 — 25 %.
Вероятность «Средняя»: 25 — 75 %.
Вероятность «Высокая»: 75 — 100 %.
4.1. Критерии выбора значений параметра «Степень воздействия»
При выборе значения параметра «Степень воздействия» необходимо пользоваться следующими критериями, если объект воздействия риска является одной из трёх главных целей проекта (бюджет, срок, качество):
Значение параметра «Степень воздействия»
Низкая
Средняя
Высокая
Бюджет (выход за рамки бюджета)
< 10 %
10 % < … 50 %
Срок (выход за срок реализации проекта)
< 10 %
10 % < … 50 %
Качество (несоответствие требованиям Заказчика)
< 10 %
10 % < … 20 %
Если риск воздействует на несколько объектов воздействия, то в качестве значения параметра «Степень воздействия» выбирается максимальный из выбранных по вышеприведённой таблице. Например, если риск воздействует на бюджет проекта с возможностью превышения оного на 15 % (Средняя степень воздействия), а на срок проекта с возможностью превышения на год при запланированных полутора годах (Высокая степень воздействия), то в качестве окончательного значения данного параметра выбирается значение «Высокая».
Если риск воздействует на какие-либо иные объекты, то значение параметра «Степень воздействия» определяется лицом, отвечающим за управление рисками, по своему усмотрению, основываясь на опыте и здравом смысле.
4.2. Матрица серьёзности рисков
После выбора значений параметров «Вероятность» и «Степень воздействия» в соответствии со следующей матрицей производится назначение одного из трёх классов риска.
Низкая
Средняя
Высокая
Низкая
C
C
B
Средняя
C
B
B
Высокая
B
B
A
Риски класса A («красные риски») являются очень критичными для любого проекта. Таким рискам необходимо уделять максимум внимания, их предотвращению должны быть посвящены значительные усилия.
Риски класса B («оранжевые риски») являются критичными для высокобюджетных и краткосрочных проектов и достаточно серьёзными для остальных типов проектов.
Риски класса C («жёлтые риски») являются обычными для любых проектов, для их мониторинга и предотвращения силы и средства распределяются в соответствии с принципом экономности — общая стоимость мероприятий по управлению риском не должна превышать потенциальных убытков, помноженных на вероятность реализации риска.
В соответствии с классификацией рисков конкретного проекта и их количеством проекту также назначается один и следующих классов:
Высокорискованный проект — проект, в котором имеется пять или более красных рисков, остальных рисков произвольное количество.
Рискованный проект — проект, в котором имеется пять или более оранжевых рисков, и при этом имеется до пяти красных рисков, а жёлтых рисков произвольное количество.
Среднерискованный проект — проект, в котором имеется пять или более оранжевых рисков, произвольное количество жёлтых рисков, но красных рисков нет.
Низкорискованный проект — проект, в котором красных рисков нет, менее пяти оранжевых рисков и произвольное количество жёлтых рисков.
Следующая таблица обобщает эту классификацию проектов:
Класс проекта
Красные риски
Оранжевые риски
Жёлтые риски
Высокорискованный
⩾ 5
Произвольное
Произвольное
Рискованный
> 1
⩾ 5
Произвольное
Среднерискованный
Нет
⩾ 5
Произвольное
Низкорискованный
Нет
> 1
Произвольное
5. Планирование мониторинга, предотвращения и реагирования на риски
Планирование мониторинга, предотвращения и реагирования на риски осуществляется в обязательном порядке для рисков категорий A и B, и по усмотрению руководителя проекта для рисков категории C.
Для рисков классов A и B должны разрабатываться индивидуальные планы по мониторингу, предотвращению и реагированию (план МПР) на риск. Для рисков категории C соответствующие планы разрабатываются по усмотрению руководителя проекта. Если в базе известных рисков соответствующий риск описан, то для рисков категории C можно пользоваться типовым планом реагирования.
Для каждого риска, для которого готовится план МПР, указывается дата актуальности и лицо, ответственное за мониторинг, предотвращение и реагирование на риск. Дата актуальности определяет, до которого срока риск остаётся актуальным для проекта, и для него необходимо осуществлять все запланированные мероприятия. При достижении даты актуальности лицо, ответственное за данный конкретный риск вместе с ответственным за управление рисками и руководителем проекта (если, конечно, это все разные люди) принимают решение о закрытии риска или переносе даты актуальности.
Лицо, ответственное за риск, — это любой сотрудник, за которым закрепляется задача мониторинга, предупреждения и реагирования на данный конкретный риск. Это может быть сам руководитель проекта, или риск-менеджер, если таковой выделен на проект, либо кто-либо из состава проектной команды, либо кто-то из руководства организации или даже со стороны заказчика. Выделение ответственного за риск лица должно производиться официальным назначением и внесением в проектный план-график работ всех необходимых задач, запланированных в соответствующем плане МПР.
В плане МПР также должны быть указаны методы предупреждения риска, стратегия реагирования на него и действия по реагированию, если риск наступает. Если стратегией реагирования является стратегия принятия риска, то в плане МПР должны быть прописаны конкретные действия по предупреждению и реагированию. Для стратегий «Передача Заказчику», «Страхование» и «Резервирование» в плане МПР и плане-графике работ по проекту должны быть предусмотрены резервы времени и бюджета, достаточные для реагирования на соответствующий риск.
Если для риска используется какая-либо иная стратегия реагирования, то решение о составе плана МПР принимает руководитель проекта вместе с риск-менеджером.
5.1. Критерии выделения риск-менеджера на проект
Решение о том, необходимо ли выделить на проект риск-менеджера в дополнение к руководителю проекта, принимается на основании следующих критериев:Для высокорискованных проектов отдельный риск-менеджер выделяется, если проектная команда насчитывает не менее 5 специалистов (исключая руководителя проекта и выделяемого риск-менеджера).
Для рискованных проектов отдельный риск-менеджер выделяется, если проектная команда насчитывает не менее 10 специалистов (исключая руководителя проекта и выделяемого риск-менеджера).
Для среднерискованных проектов отдельный риск-менеджер выделяется, если проектная команда насчитывает не менее 15 специалистов (исключая руководителя проекта и выделяемого риск-менеджера).
Для низкорискованных проектов отдельный риск-менеджер выделяется на усмотрение руководства компании.
6. Мониторинг, предотвращение и реагирование на риски
К моменту запуска работ по проекту в распоряжении руководителя проекта должны быть следующие компоненты подсистемы управления рисками в его проекте:Перечень паспортизованных и классифицированных проектных рисков.
Индивидуальные планы реагирования на риски классов A и B, а также типовые планы реагирования на риски классов C.
Лица, ответственные за определённые риски в проекте. При этом само собой разумеется, за некоторые риски может отвечать сам руководитель проекта.
Лицо, занимающееся управлением рисками. Им также может быть сам руководитель проекта.
Для каждого риска из перечня проектных рисков, производится мониторинг его состояния. Для рисков класса A данный мониторинг производится на ежедневной основе. Для рисков класса B мониторинг производится не реже, чем раз в неделю. Для рисков класса C частота мониторинга определяется руководителем проекта или лицом, ответственным за управление рисками.
В процессе мониторинга лицо, ответственное за риск, осуществляет проверку критериев реализации на приближение к условиям осуществления риска. Для количественных показателей риска проверяется их значения и сравниваются с пороговыми значениями, сигнализирующими о наступлении риска. Для качественных показателей риска производится сравнение текущего значения с целевым.
При обнаружении тренда в том или ином показателе, свидетельствующем о приближении к пороговому значению, когда риск может реализоваться, лицо, ответственное за риск, осуществляет меры по предотвращению риска, используя спланированные меры предупреждения. При этом класс риска повышается на 1 балл (для рисков классов B и C), в связи с чем меняется частота его мониторинга.
Если меры по предупреждению риска не помогают, и событие риска происходит, то лицо, ответственное за риск, осуществляет запланированные действия по реагированию на риск. При этом мониторинг состояния проблемы (проблема — реализовавшийся риск) осуществляется на ежедневной основе.
Для всех рисков с указанной ранее периодичностью (в зависимости от класса конкретного риска) производится процедура переоценки их состояния, то есть осуществляется возврат к процессам идентификации и классификации, во время которых могут измениться значения некоторых параметров известных рисков или даже обнаружиться новые риски проекта.
Таким образом, процесс мониторинга, предупреждения и реагирования на риски выглядит следующим образом:Рисунок 3. Процесс мониторинга, предупреждения и реагирования на риски
6.1. Обязанности лица, ответственного за риск
Лицо, ответственное за конкретный риск и входящее в состав проектной команды со стороны Исполнителя, обязано выполнять следующие задачи:Проверять критерии реализуемости риска в соответствии с регламентом, определённым для данного риска.
При возникновении трендов, свидетельствующих о подходе риска к его реализации, незамедлительно уведомить о данной ситуации лицо, управляющее рисками в проекте, а также начать выполнение предупреждающих действий.
Если риск реализовался, то незамедлительно уведомить об этом лицо, управляющее рисками в проекте, и начать проводить мероприятия по реагированию на риск.
После завершения проекта предоставить лицу, управляющему рисками в проекте, полное описание того, как проводилось управление данным риском.
Если лицом, ответственным за конкретный риск, является представитель Заказчика или субподрядчика, то лицо, управляющее рисками, должно проводить своевременный мониторинг состояния процесса управления данным риском.
6.2. Обязанности лица, управляющего рисками
Лицо, управляющее рисками в проекте, обязано выполнять следующие задачи:Осуществлять общее руководство всеми лицами, ответственными за конкретные риски, в части мониторинга, предупреждения и реагирования на риски.
Проводить периодические совещания всех лиц, ответственных за конкретные риски, на которых производить «информационное выравнивание» относительно рисков, их текущих вероятностей, приближении к критериям реализации.
При получении сигнала о приближении к реализации риска класса А или В незамедлительно уведомлять об этом руководителя проекта и руководство компании.
При получении сигнала о реализации риска класса А или В незамедлительно эскалировать данную проблему на руководство компании.
После завершения проекта подготовить полный отчёт об управлении рисками на проекте.
7. Анализ эффективности управления рисками
После завершения проекта лицо, управляющее рисками, должно представить полный аналитический отчёт об управлении рисками, на основании которого делается заключение об эффективности управления рисками на проекте. Вместе с выводами об эффективности управления рисками данный отчёт становится частью Post Mortal Report об управлении проектом, который готовит руководитель проекта.
7.1. Структура аналитического отчёта об управлении рисками
Типовой аналитический отчёт об управлении рисками на проекте состоит из трёх частей.
В первой части описывается сам проект, приводится его код, руководитель проекта, лицо, управляющее рисками, команда проекта и спонсор проекта. Далее описываются первоначальные и фактические рамки проекта, а также указываются отклонения от рамок и их причины. Затем по усмотрению составителя отчёта приводится описание открывшихся возможностей с указанием того, какие из них были использованы на проекте, а какие были упущены.
Во второй части необходимо дать расширенные ответы на следующие вопросы:Что было сделано правильно, а что нет?
Какие ошибки были допущены?
Что можно было сделать лучше?
Что можно было сделать иначе?
Какие «сюрпризы» не были предвидены?
Пришлось ли тратить резерв на исправление ошибок?
Пришлось ли отходить на запасные позиции?
Какие уроки можно почерпнуть на будущее?
Третья часть состоит из отчётов лиц, управлявших конкретными рисками. В данных отчётах должно быть указано, реализовался ли риск, и если реализовался, то по какой причине. Также должно быть указано, как в процессе работы над проектом менялись показатели риска, за которыми вёлся мониторинг, и если показатели начинали приближаться к зоне реализации риска, какие методы предупреждения использовались.
7.2. Критерии эффективности управления рисками
В следующей таблице представлены критерии успешности процесса управления рисками на проекте:
Класс проекта
Эффективно
Малоэффективно
Не эффективно
Высокорискованный
Реализовалось менее 10 % рисков
Реализовалось менее 25 % рисков
Реализовалось более 25 % рисков
Рискованный
Реализовалось менее 20 % рисков
Реализовалось менее 50 % рисков
Реализовалось более 50 % рисков
Среднерискованный
Реализовалось менее 30 % рисков
Реализовалось менее 60 % рисков
Реализовалось более 60 % рисков
Низкорискованный
Реализовалось менее 50 % рисков
Реализовалось менее 75 % рисков
Реализовалось более 75 % рисков
8. Обновление базы рисков
В рамках централизованного управления рисками Проектным офисом ведётся иерархическая структура типовых рисков проекта. После завершения очередного проекта и сдачи проектной документации в архив Проектным офисом проводятся работы по обновлению базы известных рисков. Для этих целей в базу вносится любая информация, которая может помочь в процедуре управления рисками в будущих проектах.
Если в рамках проекта были идентифицированы риски, описания которых нет в базе, то полные описания таких рисков вносятся в базу.
Если в рамках проекта успешно использовалась информация об известных рисках, при этом лицом, ответственным за риск или лицом, управляющим рисками, были сделаны улучшения процедур предупреждения или процедур реагирования, либо были внесены какие-либо иные существенные исправления в паспорте риска, приведшие к более эффективному управлению риском (риск не должен проявиться на проекте), то все такие изменения вносятся в базу рисков.
Если перечисленными выше лицами были внесены изменения, однако риск в процессе работы над проектом проявился, то данная ситуация предполагает более тщательный анализ того, почему проявился риск и не было ли причиной проявления изменение типовых процедур.
Всех читателей благодарю за силы и время, потраченные на эту статью. Ну а за конструктивные комментарии с предложениями, замечаниями и критикой как всегда низкий поклон.
Если вы хотите дополнительно отблагодарить автора, но не знаете как, то вам сюда.
