9. Управление рисками ІТ-проекта

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

9.1. Основные понятия управления рисками

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

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

Событие риска - потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту [23].

Вероятность возникновения риска - вероятность того, что событие риска наступит [23]. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта.

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

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

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

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

Планирование реагирования на риски включает разработку плана управления рисками - документа, разрабатываемого в начале проекта и представляющего собой график работы с рисками в течение всего ЖЦ проекта. План содержит следующую информацию [18].

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

Роли и обязанности - раздел содержит описание, кто какую работу выполняет в ходе управления рисками проекта.

Бюджетирование - определяет бюджет для управления рисками проекта.

Временные рамки - устанавливают частоту процессов управления рисками.

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

Контроль - раздел, определяющий формат плана реагирования на риски.

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

Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework) [11]. MSF описывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта.

Методы управления проектными рисками для малых и средних проектов достаточно проработаны и позволяют эффективно снижать уровень рисков и трудозатраты по проекту (см. табл. 9.1) Для ведения крупных проектов "стандартного" набора методов оказывается недостаточно [15].

Таблица 9.1. Примеры управления рисками

Масштаб проекта	Число работ	Число подпроектов	Связность работ	Методы управления
Малый	too	Нет	Низкая	PMI 1 FMEA MSF, личный опыт руководителя
Средний	50-100	Единицы	Низкая, средняя	Стандартные методики ( ASAP 2 PJM 3 PMI), SPICE4 COBIT
Крупный	100-1000	От нескольких десятков до нескольких сотен	Высокая	Проработаны слабо

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

На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия:

• утвердить систематический подход к определению рисков, их оценке и обработке.

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

• идентифицировать риски.

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

9.2. Определение уровней вероятности возникновения рисков и их последствий

Общие определения уровней вероятности и уровней воздействия адаптируются отдельно для каждого проекта в ходе процесса планирования управления рисками и используются в процессе качественного анализа рисков. Можно применить относительную шкалу, на которой вероятность обозначена описательно, со значениями от "крайне маловероятно" до "почти наверное", или шкалу, на которой вероятности соответствует цифровое значение, например: 0,1 - 0,3 - 0,5 - 0,7 - 0,9. В табл. 9.2 представлено семиуровневое разделение вероятности [11]. Для каждого интервала вероятностей выполнена относительная и числовая оценка.

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

Таблица 9.2. Семиуровневая оценка вероятности возникновения риска

Интервал вероятностей	Значение вероятности, используемое для вычислений	Словесная формулировка	Числовая оценка
От 1% до 14%	7%	крайне маловероятно	1
От 15% до 28%	21%	низкая вероятность	2
От 29% до 42%	35%	скорее нет	3
От 43% до 57%	50%	50-50	4
От 58% до 72%	65%	возможно	5
От 73% до 86%	79%	весьма правдоподобно	6
От 87% до 99%	93%	почти наверняка	7

Таблица 9.3. Шкала для оценкипоследствий риска, измеряемых в деньгах

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

Таблица 9.4. Шкала для оценки последствий риска, измеряемых отклонениями в стоимости, сроках и технических условиях проекта

Оценка	Перерасход средств	Календарный график	Технические условия
1 (низкая)	до 1%	сдвиг на 1 неделю	небольшая потеря производительности
2 (средняя)	до 5%	сдвиг на 2 недели	умеренное снижение производительности
3 (высокая)	до 10%	сдвиг на 1 месяц	серьезный ущерб для производительности
4 (критическая)	от 10%	сдвиг более 1 мес.	задача не может быть выполнена

Таблица 9.5. Определение шкалы оценки воздействия для четырех целей проекта

Определенные условия для шкалы оценки степени возможного влияния риска (показаны только примеры негативных воздействий)
Цель проекта	Показаны значения по относительной и числовой шкалам
	Очень низкое	Низкое	Умеренное	Высокое	Очень высокое
	0,05	0,10	0,20	0,40	0,80
Стоимость	Незначительное увеличение	Увеличение < 5%	Увеличение 5-10%	Увеличение 10-20%	Увеличение > 20%
Сроки	Незначительное увеличение	Увеличение < 5%	Увеличение 5-10%	Увеличение 10-20%	Увеличение > 20%
Содержание (объем)	Изменения незаметны	Незначительные изменения	Значительные изменения	Неприемлемое для клиента изменение	Достижение конечных результатов невозможно
Качество	Изменения незаметны	Незначительные изменения	Изменения требуют согласия клиента	Неприемлемое для клиента изменение	Достижение конечных результатов невозможно

Рис. 9.1. Матрица воздействия (вероятностей и последствий) рисков

Относительная шкала последствий разрабатывается каждой организацией самостоятельно. Шкала содержит только описательные обозначения, например, "очень низкий", "низкий", "средний", "высокий" и "очень высокий", расположенные в порядке возрастания максимальной силы воздействия риска согласно определению данной организации. То же самое можно сделать иначе, путем присвоения данным последствиям цифровых значений, которые могут быть линейными и нелинейными, например, 0,1 - 0,3 -0,5 - 0,7 - 0,9 или 0,05 - 0,1- 0,2 - 0,4 - 0,8. В табл. 9.5 представлены как относительный, так и цифровой (в данном случае нелинейный) способы обозначения последствий риска для четырех целей проекта [23].

Шкала уровней воздействия является основой для построения матрицы вероятности и последствий.

Матрица вероятности и последствий содержит комбинации вероятности и воздействия, при помощи которых рискамприсваивается определенный ранг: низкий, средний или высший [23]. Матрица может содержать описательные термины или цифровые обозначения (см. рис. 9.1) и строится на основании шкал оценки вероятности и оценки степени влияния возможногориска. Левый столбец матрицы содержит значения вероятности возникновения риска, в первой строке расположена шкала со значениями возможных последствий. Ячейки заполняются результатами перемножения значений этих шкал. Сопоставляя значениеячейки матрицы со шкалой оценки воздействия, риски можно разделить по категориям: малые, средние и большие. Рассмотрим матрицу вероятности и последствий, представленную на рис. 9.1. Риски, имеющие очень высокую вероятность, но незначительные последствия, а также риски, имеющие низкую вероятность и незначительные последствия, считаются рисками, не оказывающими воздействия (клетки таблицы серого цвета). Риски с очень большими последствиями, но малой вероятностью, как и риски с незначительными последствиями и высокой вероятностью (клетки светло-серого цвета), имеют среднее воздействие на проект. Риски, которым необходимо уделять особое внимание, имеют достаточно высокую вероятность и существенные последствия (клетки таблицы, окрашенные темно-серым цветом).

9.3. Методики идентификации рисков

Для идентификации рисков используют следующие методы [11,23].

Мозговой штурм. Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек - члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Об этом говорит сайт https://intellect.icu . Далее риски сортируют по категориям и уточняют.

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

Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 7-10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им рискипроекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление спискарисков в порядке их важности.

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

Опросы экспертов с большим опытом работы над проектами.

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

Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель проведения анализа - оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрыв между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда.

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

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

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

Таблица 9.6. Сравнение методов идентификации рисков

Метод идентификации	Преимущества	Недостатки
Мозговой штурм	Способствует взаимодействию членов группы. Быстрый. Недорогой	Может проявиться преобладание одной личности. Можно сосредоточиваться только в конкретных областях. Требует сильного ведущего. Для оценки необходимо контролировать склонности группы
Метод Delphi	Нет доминирования одной личности. Может проводиться дистанционно, через электронную почту. Исключается проблема ранней оценки. Требует участия каждого члена группы	Занимает много времени. Высокая загрузка ведущего
Метод номинальных групп	Уменьшается эффект доминирующей личности. Обеспечивает взаимодействие участников. Дает упорядоченный список рисков	Требует много времени. Высокая загрузка ведущего
Карточки Кроуфорда	Быстрый. Легко реализуется. Должен участвовать каждый член группы. Вырабатывается большое количество идей. Можно проводить с группами большеобычного размера. Уменьшает эффект доминирующей личности	Меньшее взаимодействие между участниками
Опрос экспертов	Используется прошлый опыт	Эксперт может быть предвзятым. Требует много времени
Контрольные списки	Конкретный и упорядоченный. Легко использовать	Предвзятость. Может не содержать конкретных элементов для данного проекта
Метод аналогии	Использует прошлый опыт для исключения проблем в будущем. Подобные проекты содержат много сходных черт	Требует много времени. Легко получить результаты, не подходящие для данного случая. Аналогия может быть некорректной
Методы с использованием диаграмм	Ясное представление участвующих процессов. Легкость построения. Для них имеется много компьютерных инструментов	Иногда вводит в заблуждение. Может занимать много времени

Сравнение методов идентификации рисков проекта [11] представлено в табл. 9.6.

Идентифицированные риски документируются в так называемых реестрах рисков.

Примеры шаблонов реестра рисков [11] приведены в таблицах 9.7 и 9.8.

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

Таблица 9.7. Шаблон реестра рисков

ИДЕНТИФИКАЦИЯ РИСКА
№	Датавозникновенияриска	Датарегистрациириска	Наименование и описание риска	Инициатор	Причины	Последствия	Владелец риска	Дата окончания действия риска
.
.

Таблица 9.8. Пример заполнения реестра рисков (упрощенный)

Первопричина	Условие	Последствие
Необеспеченность кадрами	Могут быть объединены проектные роли. Несовместимые роли: менеджер по качеству и разработчик,тестировщик и разработчик	Совмещение ролей может затруднить контроль и оценку результатов, что снизит качество программного продукта
Изменения в технологии	Разработчикам придется осваивать новые технологии и использовать их впервые	Увеличится время на разработку программного продукта. Возможно снижение качества________
Организация работы	Участники проекта территориально удалены	Обмен информацией внутри группы затрудняется. Время на достижение целей проекта увеличивается_____

Таблица 9.9. Пример заполнения расширенного журнала рисков

Тип риска	Описание риска	Проактивные мероприятия	Реактивные мероприятия	Вероятность	Последствия	Фактор риска
Технологический	Заказчик может задержать выпуск продукта из-за постоянных изменений и дополнений требований к продукту	1. Разделить требования на "абсолютно необходимые" и "хорошо бы было иметь", до запуска системы выполнять только абсолютно необходимые требования 2. Убедиться в том, что руководство заказчика понимает и поддерживает подход, что заявки на изменения будут выполняться после завершения основных работ везде, где это возможно	1. Обсудить изменение сроков ввода системы в эксплуатацию из-за накопившегося объема изменений для обеспечения необходимого уровня качества финального продукта	8	6	48
Финансовый	Заказчик настаивает на бесплатном исправлении всех ошибок (в данном случае речь идет только о тех пунктах, которые мы также можем признать ошибками), что может привести к серьезным финансовым потерям	1. Включить в план работ бюджет и время программистов на исправление ошибок по результатам тестирования. 2. Разъяснять ключевым представителям заказчика, что выявление и исправление ошибок является частью технологии разработки ПО	1. В случае невозможности достижения договоренности поднять вопрос на уровень управляющего комитета	8	6	48

9.4. Организация управления рисками

Согласно стандарту ISO 15288, процесс контроля включает следующие действия:

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

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

Для обеспечения контроля и управления рисками на этапе планирования разрабатывают план реагирования на риски, шаблонкоторого представлен в табл. 9.10.

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

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

Таблица 9.10. Пример шаблона плана реагирования на риски

План реагирования на риски
Название проекта:					Дата оценивания:
Пакет работ	Описание риска	Вероятность возникновения риска	Степень тяжести воздействия	Статус события риска	Степень критичности	Номер затрагиваемого риском события	Превентивные действия	Пороговое значение	Реактивные действия	Владелец риска

На рассматриваемой стадии ЖЦ ИТ наиболее вероятно возникновение рисков, вызванных следующими обстоятельствами [22]:

1. неправильно определена область применения проекта;

2. не определен спонсор проекта;

3. не разработана стратегия реагирования на риски ;

4. не определены ожидания участников проекта;

5. не установлена ответственность за обеспечение проекта материальными и финансовыми ресурсами.

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

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

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

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

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

9.5. Пример процедуры управления рисками

Настоящая процедура применятся для управления рисками на проекте внедрения ИС. По согласованию сторон процедура может изменяться. Управление рисками выполняется на протяжении всего проекта с использованием журнала регистрации (реестра)рисков.

Запись риска

• Любой член функциональной группы от исполнителя или заказчика может сформулировать риск и инициировать его решение согласно процедуре. Риск фиксируется руководителями функциональных групп "Финансы", "Персонал" или лицами, назначенными ими; в журнале рисков необходимо дать ссылку на файл журнала рисков в проектной библиотеке.
• Одновременно оформляется форма регистрации риска ; необходимо дать ссылку на файл формы регистрации рисков в проектной библиотеке.
• Журнал рисков размещается в проектной библиотеке секретарем проекта и обновляется/дополняется ежедневно в конце дня.
• Формы регистрации рисков размещаются в проектной библиотеке и обновляются/дополняются ежедневно в конце дня.
• Управление/минимизация рисков
• Возможные варианты управления/минимизации риска обсуждаются на ежедневных оперативных совещаниях и на еженедельных совещаниях группы управления проектом и документируются в форме регистрации рисков

Таблица 9.11. Пример формы регистрации риска

Запрос на регистрацию риска Номер в журнале рисков:< Заполняется в ГУПР>
< Заполняется автором запроса> ФИО автора:<Петров Петр Петрович> Роль:<Руководитель группы финансы> Проект: <ВМС 2> Фаза проекта:<Планирование>						<Заполняется автором запроса> Приоритет:<Критично, высокий, средний, низкий (*)> Дата запроса:<дд.мм.гпт> Желаемая дата разрешения:<дц.мм.птг>
Описание риска:<Заполняется автором запроса> <Детальное описание риска, контрольная точка (дата) наступления рискового события> < Описание уже предпринятых действий для минимизации риска > Дата окончания действия риска:<дд.мм.птт> (**) Предпосылки: < Описание причин возникновения риска> Последствия:<Описание возможных последствий в случае наступления рисковых событий и их влияния на проект> Варианты решения: < Описание предложений по вариантам решения> < Какие действия от проектного офиса ожидаются для минимизации риска>
<Заполняется в ГУП>
Статус (***):			Дата				Комментарий к статусу:
<статус>			<дц.мм.гггг>				<комментарии к статусу>
<статус>			<дд.мм.гггг>				<комментарии к статусу>
<статус>			<дд.мм.гпт>				<комментарии к статусу>
<статус>			<дд.мм.гпт>				<комментарии к статусу>
Результаты анализа риска (****): <Заполняется в ГУПР>
Вероятность		Влияние			Степень угрозы				Стратегия работы
100%		Сильное			Критическая				Избежать
75%	<Х>	Среднее		<Х>	Высокая		<Х>		Принять
50%		Слабое			Средняя				Снижать	<Х>
25%					Низкая
< Обоснование выбора стратегии (обязательно заполняется в случае выбора стратегии принятия риска) > <Описание предложений по вариантам решения и действиям для совещания> < Предложение по назначению владельца риска> Ответственный за риск: <ФИО сотрудника>
Утвержденный вариант решения по минимизации риска:< Заполняется в ГУП><Заполняется в ГУЛ на основании протокола совещания>
Назначенные действия			Ответственный			Срок		Источник действия		Статус
< Описание назначенного действия>			<Сидоров СО			<дд.мм.гггг>		< Совещание от ...>		<(*****)>

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

Информация фиксируется в форме регистрации риска (см. табл. 9.11), состоящей из:

1.верхнего колонтитула с указанием:

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

2.формулировки текущего состояния (изменяется по мере необходимости):

• назначенный ответственный за разрешение риска ;
• приоритет: "критично", "высокий", "средний", "низкий";

3.изучения/минимизации риска:

• возможные пути решения: возможные пути минимизации риска, включая влияние на проект в терминах нарушения хода проекта, времени, качества;
• оценка влияния: оценка влияния на бизнес/технические аспекты проекта;

4. решения:

• рекомендация: окончательное решение для утверждения;

5.утверждения:

• утверждено исполнителем, дата;
• утверждено заказчиком, дата;
• соответствующий номер запроса на изменение (если присутствует запрос на изменение);
• запрос на изменение утвержден, дата.

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

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

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

Также при разработке плана учитывается опыт выполнения аналогичных проектов.

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

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

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

Рис. 9.2. Отображение миграции риска А в матрице воздействия риска

Матрица вероятностей и последствий - инструмент, позволяющий определять ранг риска отдельно для каждой цели, например, для стоимости, времени или содержания. Ранг риска помогает управлять реагированием на риски. Например, для рисков, расположенных в зоне высокого риска (область красного цвета) матрицы, необходимы предупредительные операции и агрессивная стратегия реагирования (рис. 9.2). Для угроз, расположенных в зоне низкого риска (зеленый цвет), осуществление предупредительных операций может не потребоваться.

Рис. 9.3. Пример отслеживания временной динамики ранга риска А

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

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

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

Исходной информацией для количественного анализа рисков служат:

• активы организационного процесса;
• описание содержания проекта;
• план управления рисками;
• реестр рисков;
• план управления проектом.

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

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

Точки принятия решений - это моменты времени, когда происходит выбор альтернатив.

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

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

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

Ожидаемое значение (последствия) - это расположенное в конце ветви количественное выражение каждой альтернативы.

Рис. 9.4. Дерево решений для проектной ситуации, находящейся под воздействием

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

Пример использования дерева решения

Таблица 9.12. Сравнение стратегий реагирования на риски

Классификация рисков	Уклонение от риска	Передача риска	Принятие риска	Снижение последствий вероятности возникновения риска
Риски, связанные с масштабом проекта	Разделение проекта на несколько под-проектов. Сокращение функционального и географического объема проекта	Разделение проекта на несколько под-проектов, выделение пилотного проекта по подсистемам (ограниченного масштаба)	Увеличение трудоемкости работ и стоимости проекта	Детальный анализ каждого этапа работ, взаимодействие участников, организация работ	Детально проработанная программа качества, отработанное управление конфигурацией проекта, специальные процедуры взаимодействия участников
Риски, связанные с недостаточным опытом в сфере ИТ	Реализация только не технологической части проекта, передача технологической части проекта другой компании	Согласование с заказчиком большинства проектных документов, согласование всех изменений в функциональности системы	Увеличение трудоемкости работ и стоимости проекта	Проведение обучения пользователей, включая руководство, соблюдение технологии работы	Разработка и утверждение концепции проекта на возможно более ранней его стадии
Технические риски проекта	Использование более надежных	Документально зафиксированная	Увеличение трудоемко-	Строгий отбор проектной команды по	Использование стандартов пред-
	технологических решений	персональная ответственность участников проекта, документальное фиксирование всех изменений в процессе проекта	сти работ и стоимости проекта	квалификационным критериям. Обучение участников проекта технологии проектных работ, инструментальным средствам	приятия для проектных работ, разработка стандартов проекта
Организационные риски проекта	Значительное сужение объема проекта и превращение его в чисто инфраструктурный технологический проект	Включение представителей заказчика в рабочие группы	Увеличение трудоемкости работ и стоимости проекта	Обучение участников проекта(курс "управление проектом"), тренинги команды, как можно более полная формализация деятельности	Включение в команду администратора проекта, детальное распределение ролей в проекте
Операционные риски проекта	Изменение модели оплаты компании-исполнителю: перевод на оплату по результату оценки качества реализованного решения	Акт сдачи заказчику любого документа. Фиксирование отсутствия претензий заказчика по каждому этапу работы	Увеличение трудоемкости работ и стоимости проекта	Многократное тестирование созданных продуктов, тщательная экспертиза документов	Строгое выполнение процедур программы качества

Торговая компания открывает новый магазин, который должен быть укомплектован новейшим оборудованием. Оборудование производят два конкурирующих поставщика (П1 и П2), объявивших одну и ту же дату появления на рынке нового оборудования. Для увеличения эффективности работы компания планирует осуществить внедрение ИС класса ERP. Разработаны три варианта расписания внедрения информационной системы: вариант 1, вариант 2, вариант 3. Длительность проекта рассматривается какпараметр первостепенной важности. Расписание внедрения ИС зависит от поставки и монтажа оборудования. Команда проектаоценила вероятность того, что поставщик 1 (П1) или поставщик 2 (П2) поставит нужное оборудование первым. Анализинформации о прежних разработках поставщиков позволил предположить, что поставщик 1 поставит на рынок новое оборудование с вероятностью 60%; соответственно, для поставщика 2 эта вероятность будет равна 40%.

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

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

1. ожидаемая длительность для случайного узла А: (80 дней* 0,6) + (70 дней *0,4) = 76 дней;

2. ожидаемая длительность для случайного узла Б: (70 дней * 0,6) + (75 дней *0,4) = 72 дня;

3. ожидаемая длительность для случайного узла В: (75 дней * 0,6) + (80 дней *0,4) = 77 дней

Результат дерева решений - вариант расписания с наименьшей продолжительностью, равной 72 дням.

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

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

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

Существует четыре типовые стратегии реагирования на появление негативных рисков: уклонение, передача, принятие и снижение.

1. Уклонение от риска

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

2. Передача риска

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

3. Принятие риска

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

4. Снижение риска

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

9.8. Подтверждение содержания проекта

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

Входной информацией для процесса являются:

• описание содержания проекта;
• словарь ИСР;
• план управления содержанием проекта;
• результаты поставки.

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

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

Вау!! 😲 Ты еще не читал? Это зря!

• ГОСТ Р ИСО 31000:2010
• Антикризисное управление
• Превентивное управление
• Уровни зрелости управления
• Кредитоспособность
• Финансовый риск-менеджмент
• управление зависимостями ,

В общем, мой друг ты одолел чтение этой статьи об управление рисками іт-проекта. Работы впереди у тебя будет много. Смело пиши комментарии, развивайся и счастье окажется в твоих руках. Надеюсь, что теперь ты понял что такое управление рисками іт-проекта, управление рисками и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Управление разработкой программных IT проектов