Управление рисками Уровни зрелости компаний Уровни зрелости компаний и организаций с точки зрения управления рисками: 1. 2. 3. 4. 5. Problem stage Mitigation stage Prevention stage Anticipation stage Opportunity stage Problem and Mitigation stages Problem stage — когда работа с рисками не ведется до тех пор, пока они не станут проблемами. Mitigation stage (Стадия смягчения)— когда людям знакомо понятие «риск», однако никто не знает, как управлять рисками на регулярной основе (концепция управления рисками была им представлена, но пока в очень ограниченных объемах). Зачастую единственной стратегией борьбы с рисками является уменьшение вероятности его появления. Prevention stage Prevention stage — когда управление рисками становится активностью команды в целом, а не только задачей менеджмента (проекта, отдела, компании). В процесс вовлекается все больше и больше заинтересованных людей, которые могут идентифицировать риски, однако их количественные оценка пока вызывают определенные трудности. Данная стадия является поворотной точкой от реактивного к проактивному методу управления рисками. Anticipation stage Anticipation stage (Стадия ожидания) — данная стадия характеризуется сбором и анализом метрик, для того чтобы предугадывать будущие проблемы и предсказывать определенные события, связанные с проектом. В процесс управления рисками вовлекается и заказчик (клиент), что дает возможность более аккуратно проводить количественную оценку рисков, а также верно расставлять приоритеты. Opportunity stage Opportunity stage — данная стадия представляет позитивное видение процесса управления рисками, когда в процесс вовлечены все заинтересованные стороны (менеджеры, проектная команда, представители заказчика). На данной стадии каждый риск трактуется (может трактоваться) еще как и некоторая возможность. Все осознают эти возможности и связанные с ними риски и могут выбирать различные пути движения дальше, находя компромиссы между уровнем риска и новыми возможностями. Процессы PMBOK Управление рисками проекта включает в себя следующие процессы: • • • • • • • Планирование управления рисками Идентификация рисков Качественный анализ рисков Количественный анализ рисков Планирование реагирования на риски Осуществление реагирования на риски Мониторинг рисков Ключевые концепции • Все проекты подвержены риску, поскольку они являются уникальными предприятиями с различным уровнем сложности, которые осуществляются с целью получения выгод. • Они осуществляются в контексте ограничений и допущений, а также ожиданий заинтересованных сторон, которые могут противоречить друг другу и изменяться. • Организации должны брать на себя осознанный и контролируемый риск по выполнению проекта с целью создания ценности, соразмеряя при этом риски и выгоды. Планирование управления рисками Планирование управления рисками Основные цели Основные цели планирования управления рисками проекта: • определение подходов к управлению рисками конкретного проекта; • определение правил и процедур управления рисками; • выбор и/или разработка форм шаблонов и отчетов по управлению рисками. План управления рисками План управления рисками является методологическим документом, в котором самих рисков нет. Риски появляются на выходе другого процесса — идентификации рисков. План управления рисками — одна из важнейших составляющих проектной документации. Аудитор по рискам (риск-менеджер), прежде всего, интересуется наличием этого документа у руководителя проекта. План управления рисками — это компонент плана управления проектом, в котором описывается, каким образом действия по управлению рисками будут структурированы и исполнены. План управления рисками План управления рисками может включать все перечисленные ниже элементы или некоторые из них: • Стратегия управления рисками • Методология • Роли и сферы ответственности • Финансирование • Определение сроков • Категории рисков (RBS) • Склонность к риску заинтересованных сторон • Определения вероятности и воздействий рисков • Матрица вероятности и воздействия • Форматы отчетности • Отслеживание Стратегии и методологии Стратегия управления рисками. Описывает общий подход к управлению рисками в рамках данного проекта. Методология. Определение конкретных подходов, инструментов и источников данных, которые будут использоваться для управления рисками в данном проекте. Risk owners Ответственность участвующих в управлении рисками. В этом разделе плана может быть сказано, что для управления рисками проекта будут назначены ответственные за риски (risk owners). Ответственными за риски могут быть любые участники проекта: • руководитель проекта • члены команды • поставщики или субподрядчики • кураторы Risk owners Ответственность участвующих в управлении рисками. Задачами ответственного за риски являются постоянное наблюдение за рисками, отслеживание миграции рисков, изменение методов реагирования на риски. В случае идентификации рисков в организации заказчика руководитель проекта может обратиться с просьбой к заказчику взять на себя данные риски и нести за них ответственность. Бюджет для управления рисками В этом разделе плана может быть сказано, что в бюджете проекта будет сформирован резерв на возможные потери от известных рисков, а в случае возникновения неизвестных рисков руководитель проекта будет эскалировать просьбу куратору проекта о выделении дополнительных финансовых средств из резерва руководства. Project risk review meetings Периодичность процедур по управлению рисками. Периодичность процедур по управлению рисками должна быть четко определена в данном разделе плана. Например, может быть сказано, что совещания команды по статусу рисков проекта (project risk review meetings) будут проводиться каждый третий четверг месяца, в 10:00. Или, например, что аудит рисков будет проводиться риск-менеджером раз в квартал. Конечно, в случае возникновения экстренной ситуации, связанной с миграцией риска в зону критических рисков или с появлением нового критического риска, следует немедленно реагировать на риск и не ждать очередного запланированного совещания по рискам. Однако экстренные решения по критическим рискам не отменяют регулярных совещаний команды по статусу рисков проекта. Пороговые критерии Пороговые критерии для распознавания наступления риска. Связаны с оценками вероятностей наступления риска. Если на основе опыта команды могут быть установлены пороговые значения вероятности, при преодолении которых событие однозначно происходит, то по мере приближения к порогам в оценках вероятности риска растет уверенность команды, что событие произойдет, и следует предпринимать проактивные шаги по реагированию на риск. Категории рисков Рекомендуется разделять риски по категориям, учитывая четыре возможных источника рисков: 1) технические, связанные с работой оборудования, разработкой новых технологий и технических продуктов; 2) внешние, связанные с внешней средой проекта — экономической, политической, социальной, конкурентной — или внешними организациями заказчиков и поставщиков; 3) организационные, связанные со структурой компании, организационными политиками и процедурами; 4) управленческие, связанные с отсутствием профессионального управления проектом, планирования работ, неверными оценками содержания, сроков, стоимости, ресурсов и качества результатов проекта. Risk breakdown structure Общепринятым способом структурирования категорий рисков является использование иерархической структуры рисков (risk breakdown structure, RBS), которая представляет собой иерархическое представление потенциальных источников риска RBS помогает команде проекта учитывать в полном объеме источники, из которых могут возникать индивидуальные риски проекта. Это может быть полезным при идентификации рисков или в процессе распределения по категориям идентифицированных рисков. Пример RBS Матрица вероятности и влияния рисков Данная матрица является приложением к плану управления рисками и используется при качественном анализе рисков для оценки параметров риска (вероятности возникновения и степени влияния) и определения величин рисков (произведения оценок вероятностей и влияния). По строкам данной матрицы показаны уровни вероятностей рисков, а по столбцам — уровни влияния. На пересечении строк и столбцов в ячейках таблицы указаны величины рисков как произведения оценок вероятностей и влияния. Матрица вероятности и влияния рисков Категории рисков В случае использования данной матрицы с определенными значениями шкал влияния и вероятностей все риски проекта могут быть разбиты на три категории по значениям их величин: 1. критические риски (с величинами, равными или большими 0,18); 2. умеренные риски (с величинами от 0,04 до 0,18); 3. незначительные риски (с величинами до 0,04). Пример матрицы вероятности и воздействия со схемой оценки в баллах Пример определений вероятности и воздействий Форматы и шаблоны отчетов Форматы и шаблоны отчетов по управлению рисками основаны на использовании реестра рисков, в котором в динамике отражаются названия рисков, значения их параметров и величин, выбранные стратегии реагирования на риски и запланированные действия по реализации выбранных стратегий. Идентификация рисков Идентификация рисков Основная цель Основная цель идентификации рисков проекта — определение рисков проекта, т. е. вероятных событий, способных повлиять на работы и результаты проекта. Данный процесс должен обеспечить итерационное определение и документирование рисков, способных повлиять на проект в течение всего его жизненного цикла. Категории Стандарт рекомендует разделять все идентифицированные риски на три категории в зависимости от особенностей их влияния на проект: 1) чистые риски (pure risks) — риски с негативным влиянием, представляющие потенциальную угрозу для проекта; 2) возможности (opportunities) — риски с позитивным влиянием, являющиеся потенциально благоприятными событиями для проекта; 3) бизнес-риски (business risks) — возможные события в будущем, представляющие одновременно как угрозу, так и благоприятную возможность для проекта. Известные и неизвестные риски Также риски можно разделить на известные и неизвестные. Известные риски (known unknown — «известная неизвестность») представляют собой вероятные события в будущем, о которых что-то известно команде проекта. Например, если команде проекта становится известно, что поставщик услуг собирается повысить цены на данную слугу, то команда может идентифицировать известный ей риск, связанный с повышением стоимости поставки услуги. К известному риску можно подготовиться заранее. Известный риск можно проанализировать, оценить его вероятность и влияние, выбрать методы реагирования, сформировать под него резервы стоимости (contingency reserve), времени или других ресурсов. Известные и неизвестные риски Неизвестные риски (unknown unknown — «неизвестная неизвестность») представляют собой вероятные в будущем события, абсолютно неизвестные команде, которые невозможно проанализировать и к которым невозможно заранее подготовиться. В случае возникновения неизвестного риска руководителю проекта приходится эскалировать куратору проекта просьбу о выделении для реагирования на риск дополнительных резервов (management reserve) стоимости, времени или других ресурсов. Детальный анализ Детальному анализу с точки зрения выявления рисков проекта прежде всего подвергаются официальные документы — контракты с заказчиком и поставщиками, технические задания, официальные протоколы и др. Однако стоит обратить внимание и на другие источники сведений о потенциальных рисках проекта, в том числе: • описания продуктов; • допущения и предположения; • информация о рисках подобных проектов в прошлом. Риски в IT Риски при реализации ИТ-проектов можно разделить на 4 группы: 1. риски, связанные с качеством разрабатываемого продукта (требования, архитектура) 2. риски, связанные со скоростью разработки (оценки) 3. риски, связанные с бюджетом, выделенным на разработку 4. риски, связанные с людьми Наиболее часто встречающиеся риски 1) неточность и неконкретность целей ИТ-проекта; 2) недооценка требований ИТ-проекта; 3) невовлеченность пользователей; 4) ошибки в процессе реализации ИТ-проекта; 5) невовлеченность руководства; 6) нереалистичные сроки и бюджет; 7) изменения требований в процессе реализации ИТ-проекта; 8) неэффективное использование методологий проектного управления; 9) знания и умения проектной команды не соответствуют требованиям проекта; 10) завышение качества, неэффективное управление требованиями (Gold-plating). Для ИТ-проектов, срок реализации которых составляет более года 1) влияние внешних факторов на проект; 2) нехватка опыта участников проектной команды; 3) нехватка компетенций; 4) неточность целей проекта; 5) изменения требований в процессе реализации ИТ-проекта; 6) неэффективное использование методологий проектного управления; 7) отсутствующая или недостаточная коммуникация с пользователем; 8) нереалистичные сроки и бюджет; 9) конфликт между заинтересованными лицами проекта. SWOT-анализ SWOT-анализ Данный метод позволяет провести анализ проекта с точки зрения каждого из аспектов: сильных и слабых сторон, благоприятных возможностей и угроз (strengths, weaknesses, opportunities, and threats, SWOT). Этот метод используется при идентификации рисков, чтобы расширить идентифицированные риски за счет включения рисков, возникающих внутри самого проекта. При использовании данного метода начинают с определения сильных и слабых сторон организации, уделяя особое внимание либо проекту, либо организации, либо области бизнеса в целом. SWOT - анализ Затем в процессе SWOT-анализа идентифицируют любые благоприятные возможности проекта, которые могут возникать благодаря сильным сторонам организации, а также любые угрозы, являющиеся результатом ее слабых сторон. При помощи данного анализа также исследуют, насколько сильные стороны организации компенсируют угрозы, а также определяют, могут ли слабые стороны помешать реализации благоприятных возможностей. Ранжирование рисков При идентификации рисков может быть выявлено большое количество рисков. Например, может оказаться, что в проекте 50 рисков, а в команде всего пять человек. Конечно, такая команда не может управлять всеми 50 рисками, ресурсов явно недостаточно. В этом случае необходимо ранжировать риски по приоритетности. Например, в ходе дальнейшего качественного анализа рисков команда может оценить значения вероятности, влияния, подсчитать величину рисков для каждого из них и распределить риски по значениям их величин. Ранжирование рисков Первые 10 рисков с самыми высокими значениями величин (Top ten) должны быть в поле пристального внимания команды. Риски, начиная с 11-го в этом списке, как правило, уже не представляют значительной угрозы (для негативных рисков) и не открывают больших возможностей (для позитивных рисков), за ними можно оставить факультативное наблюдение. Тем не менее это наблюдение должно иметь место, так как риски — явления с высокой динамикой, и в любой момент риск с 20-й позиции может переместиться на пятую, и наоборот. Миграция рисков Миграция рисков — изменение приоритетов рисков в ходе проекта. Миграция рисков возможна в случае: • изменения вероятности; • изменения степени влияния. Вероятность и влияние рисков меняются в ходе исполнения проекта, в результате чего изменяется величина рисков. Критические риски могут стать незначительными и наоборот. Мозговой штурм Идентификация рисков должна быть результатом коллективного обсуждения в команде проекта, желательно в форме мозгового штурма. Если руководитель проекта не советуется с членами команды по вопросам управления рисками, тем самым он привносит в проект дополнительные риски, связанные с доминированием его личного мнения и субъективных представлений. Реестр рисков В реестр рисков вносятся подробные сведения об идентифицированных индивидуальных рисках проекта. Результаты качественного анализа рисков, планирования реагирования на риски, осуществления реагирования на риски и мониторинга рисков вносятся в реестр рисков по мере проведения указанных процессов на всем протяжении проекта. Реестр рисков может содержать ограниченную или расширенную информацию, в зависимости от переменных проекта, таких как масштаб и сложность. По завершении процесса идентификации рисков содержание реестра рисков может включать в себя, среди прочего: • Список идентифицированных рисков. • Потенциальных владельцев риска • Список возможных мер реагирования. Реестр рисков Качественный анализ рисков Качественный анализ рисков Качественный анализ рисков Качественный анализ рисков — это процесс расстановки приоритетов в отношении индивидуальных рисков проекта для дальнейшего анализа или действий, выполняемый путем оценки вероятности возникновения и воздействия рисков, а также других характеристик. Ключевая выгода данного процесса состоит в том, что он позволяет сосредоточить усилия на высокоприоритетных рисках. Основные цели Основные цели качественного анализа рисков проекта: • определение на качественном вероятностей и влияния рисков; уровне значений • оценка срочности реагирования на наиболее значимые риски. Влияние рисков Стандарт рекомендует оценивать влияние рисков на четыре стороны проекта: 1. 2. 3. 4. стоимость работ проекта; сроки работ проекта; содержание работ проекта; качество работ и результатов проекта. Классы рисков Шкала оценки влияния рисков на каждую из этих сторон включает пять уровней, каждому из которых соответствует определенный вес: • • • • • очень низкое влияние (вес 0,05); низкое влияние (вес 0,1); умеренное влияние (вес 0,2); высокое влияние (вес 0,4); очень высокое влияние (вес 0,8). Пример: оценка вероятности риска Вероятность риска, % Качественная характеристика Оценка (ранг) Очень низкая (менее 5%) Событие может произойти в исключительных случаях. Предположение больше теоретическое, чем практическое. Реально подобный риск не случался 0,01 Низкая (5—10%) Редкое событие, но уже имело место (однажды произошло) 0,1 Средняя (10— 30%) Существуют свидетельства, достаточные для предположения возможности события. Событие произошло 1—2 раза на других проектах 0,2 Высокая (30— 60%) Событие весьма вероятно. На предыдущих проектах такое случалось часто. «Скорее «ДА», чем «НЕТ», «50 на 50» и даже больше 0,4 Очень высокая (60—99%) Событие, скорее всего, случится. Почти есть уверенность, что это произойдет 0,8 Пример: оценка влияния (воздействия) риска на проект Очень слабое (ранг 0,01) Слабое (ранг 0,1) Среднее (ранг 0,2) Сильное (ранг 0,4) Очень сильное (ранг 0,8) Цели проекта Изменения незначительные Изменения коснулись малой части Изменена большая часть целей Изменения неприемлемы для заказчика Продолжение проекта бессмысленно Стоимость Небольшое увеличение стоимости (до 1%) Увеличение Увеличение стоимости не более стоимости на 5— чем на 5% 10% Увеличение стоимости на 10— 20% Увеличение стоимости более чем на 20% Сроки Незначительное отставание (до 1%) Отставание до 5% Отставание по проекту 5—10% Отставание по проекту 10—20% Отставание более чем на 20% Затронута малая часть свойств Снижение качества требует одобрения заказчика Снижение качества неприемлемо для заказчика Продолжение проекта бессмысленно Влияние Показатель Качество Незначительное снижение качества Один или два риска? Иногда в ходе качественного анализа рисков возникает ситуация, при которой один и тот же риск одновременно влияет на несколько сторон проекта. Например, один и тот же риск, в случае возникновения, одновременно влияет и на сроки, и на стоимость проекта. В таком случае мы имеем дело не с одним, а с двумя рисками. Необходимо провести детальный анализ источника этого потенциального события и определить, в каких аспектах оно влияет на сроки, а в каких (других) аспектах — на стоимость проекта. В итоге мы получаем два разных риска, влияющих на разные области проекта. Качественные оценки вероятности Важны качественные оценки вероятности и влияния рисков, которым можно доверять и на основе которых можно строить всю дальнейшую работу по управлению рисками. Причиной некачественных оценок параметров риска может быть отсутствие экспертной власти у членов команды. Совместное влияние негативных рисков может оказаться губительным для проекта. Поэтому важно проанализировать эффекты, возникающие при одновременном действии различных рисков внутри первой десятки. Может возникнуть ситуация, при которой чистые риски (возможно, никак не связанные друг с другом по сути) при одновременном возникновении «убивают» проект своим совместным влиянием. Иерархические диаграммы В случаях, когда приоритизация рисков была выполнена с использованием более двух параметров, использовать матрицу вероятности и воздействия нельзя, и требуется применение других видов графического представления. Например, на кружковой диаграмме (bubble chart) представлены три измерения данных, где каждый риск изображается в виде кружка (пузырька), и все три параметра выражены значениями по оси х и по оси у, а также размером кружка. Пример кружковой диаграммы показан на след рисинке, где величины выявляемости и близости показаны по осям х и у, а величина воздействия представлена размером кружка. Bubble chart Количественный анализ рисков Количественный анализ рисков Количественный анализ рисков Количественный анализ рисков — это процесс численного анализа совокупного воздействия идентифицированных индивидуальных рисков проекта и других источников неопределенности на цели проекта в целом. Ключевая выгода данного процесса состоит в том, что он позволяет дать количественную оценку подверженности совокупному риску проекта, а также представить дополнительную количественную информацию о рисках в целях планирования мер в отношении рисков. Не требуется осуществлять данный процесс во всех проектах, но там, где он используется, он исполняется на всем протяжении проекта. Основные цели Основные цели количественного анализа рисков проекта: • оценка эффекта влияния на проект наиболее значимых рисков и определение их рейтинга; • проведение количественного анализа принятия решений по управлению рисками в условиях неопределенности. Основные инструменты Основными инструментами количественного анализа рисков являются следующие: • Имитация (Метод Монте-Карло) • Анализ чувствительности • Анализ дерева решений (Анализ ожидаемой денежной величины) Анализ чувствительности Он показывает, какие риски потенциальным влиянием на проект. обладают наибольшим Применение данного метода позволяет команде проекта оценить, как изменяются показатели проекта при различных значениях заданных переменных, необходимых для расчета. Этот анализ позволяет определить критические переменные (sensitive factors), которые в наибольшей степени могут повлиять на результаты проекта, его осуществимость и эффективность. Анализ чувствительности: Торнадо Одним из типичных представлений анализа чувствительности является диаграмма «торнадо», которая представляет расчетный коэффициент корреляции для каждого элемента модели количественного анализа рисков, который может оказать влияние на конечный результат проекта. Это может включать индивидуальные риски проекта, операции проекта с высокой степенью вариативности или конкретные источники неоднозначности. Объекты располагаются в порядке снижения силы коэффициента корреляции, что дает типичную картину торнадо. Анализ чувствительности: Торнадо Анализ дерева решений Дерево решений используется для обеспечения выбора наилучшего из нескольких альтернативных путей действий. Альтернативные пути на протяжении проекта показаны на дереве решений с помощью ветвей, представляющих различные решения или события, которые в каждом случае могут иметь связанные с ними стоимость и индивидуальные риски проекта (в том числе угрозы и благоприятные возможности). Конечные точки ветвей дерева решений представляют конечный результат следования данным конкретным путем, который может быть негативным или позитивным. Оценка дерева решений производится путем расчета ожидаемого значения каждой ветви в денежном выражении, что позволяет выбрать оптимальный путь. Анализ дерева решений Анализ дерева решений Анализ ожидаемой денежной величины Анализ ожидаемой monetary value — EMV). денежной величины (expected С помощью этого метода можно рассчитать ожидаемый денежный выигрыш или проигрыш в случае осуществления каждого из сценариев развития проекта и определить наиболее выгодный. Метод Монте-Карло Это сложная методика, основанная на итерационных компьютерных вычислениях и построении имитационной модели развития проекта, по мере возникновения различных рисков. Подставляя различные значения переменных в специальную компьютерную программу, можно получить набор результатов, возникающих с различной вероятностью, и сделать вывод, какие значения переменных являются приемлемыми (например, вывод о необходимом размере бюджета проекта или его сроков). Результатом такого анализа также является распределение вероятностей возможных результатов проекта. Результаты количественного анализа Основными рисков являются: результатами количественного анализа • численная оценка возможных результатов проекта и их вероятности; • оценка вероятности достижения конкретной цели или результата проекта; • идентификация рисков, требующих наибольшего внимания; • нахождение реалистичных и достижимых стоимостей, сроков или результатов проекта. Планирование реагирования на риски Планирование реагирования на риски Основные цели Основные цели планирования реагирования на риски проекта: • выбор стратегии (или нескольких стратегий) реагирования на риски проекта; • разработка плана работ по реализации выбранных стратегий реагирования. Стратегии реагирования Стандарт рекомендует использовать определенные стратегии реагирования на негативные, позитивные и бизнес-риски. К стратегиям реагирования на негативные риски относятся следующие действия: • Эскалация • Уклонение от риска • Передача риска • Снижение риска Эскалация Стратегия эскалации является целесообразной в случаях, когда команда или спонсор проекта согласны, что угроза выходит за рамки проекта или что предлагаемые меры реагирования выходят за рамки полномочий руководителя проекта. Управление эскалацией рисков осуществляется на уровне программы, портфеля или другой подходящей части организации, но не на уровне проекта. Руководитель проекта определяет, кого следует уведомить об угрозе и доводит информацию о ней до сведения этого лица или части организации. Важно, чтобы владение экскалированными угрозами было принято соответствующим лицом или частью организации. В порядке эскалации угрозы обычно передаются на уровень, соответствующий целям проекта, на которые окажет влияние угроза, если она реализуется. После осуществления эскалации команда проекта не ведет мониторинг угрозы, переданной в порядке эскалации, хотя эта угроза может быть внесена в реестр рисков для информации. Уклонение от риска Уклонение от риска (risk avoidance) — действия, приводящие к полному устранению риска. В случае уклонения от риска его вероятность становится равной нулю, т. е. уклонение гарантирует, что риска больше не существует. Частным случаем уклонения от риска является остановка проекта. В этом случае риск устраняется, но и заказчик не получает желаемых результатов. Поэтому принципиальное решение об остановке проекта должно быть принято заказчиком. Уклонение от риска Как правило, уклонение от риска связано с отказом от проведения работ, в которых идентифицирован риск. Например, если в проекте переезда офиса компании в новое здание идентифицирован риск порчи дорогостоящего сервера, то уклонением от этого риска будет отказ от проведения рискованной операции транспортировки оборудования. В этом случае компания принимает решение продлить аренду помещения серверной в старом здании, чтобы уклониться от риска, связанного с поломкой сервера в процессе его транспортировки на новое место. Передача риска Передача риска (risk transference) — перенос последствий риска на участника проекта (заказчика или подрядчика) или на третью сторону, не являющуюся участником проекта. Например, риск порчи оборудования в процессе переезда в новое здание можно попытаться перенести на страховую компанию, заключив с ней контракт, страхующий от поломки оборудования в процессе переезда. При возникновении страхового случая компания хотя бы частично компенсирует ущерб от поломки оборудования. Передача риска Можем ли мы передать кому-то риск, связанный с неполными требованиями? Как вариант, мы можем передать работу, связанную со сбором требований, консультантам «под ключ», прописав в контракте штрафные санкции за ошибки (это будет непросто, но вполне возможно). Можно передать и риск, связанный с изменением требований. Но нужно подумать, кому его передавать. Ключевым источником изменения требований, как правило, выступает заказчик. В уставе проекта (или контракте на проект) руководитель проекта прописывает, что при любом изменении требований понадобится пересмотр базового расписания проекта и базового бюджета. В этом случае, если риск материализуется, команда получает дополнительное время и дополнительный бюджет. Снижение риска Снижение риска (risk mitigation) — снижение вероятности наступления риска и его негативного влияния до приемлемого уровня. Если уклонение от риска приводит к нулевой вероятности его возникновения, то снижение риска приводит к уменьшению вероятности риска, но не исключает его возникновения. Например, снизить риск, связанный с порчей оборудования в процессе переезда, можно с помощью дополнительной упаковки, строгих указаний грузчикам аккуратно переносить оборудование, а шоферу — ехать с максимальной осторожностью и т. п. Снижение риска Снижение риска всегда требует привлечения дополнительных ресурсов, в том числе материальных, человеческих, финансовых, для выполнения дополнительных работ. Надо отметить, что при реагировании на чистые риски очень часто необходимо использовать стратегию снижения риска, которая требует привлечения дополнительных ресурсов. Любой ресурс стоит денег, поэтому для реагирования на чистые риски необходимо формировать резервы бюджета проекта. Снижение риска Резерв бюджета проекта, используемый руководителем проекта для реагирования на известные риски (contingency reserve), формируется по результатам качественного и количественного анализа рисков. Суммарная величина всех чистых известных рисков, выраженных в денежных единицах, составляет резерв бюджета проекта на известные риски. При отсутствии точных оценок и обоснований рекомендуемая величина данного резерва составляет порядка 10% от бюджета проекта, т. е. от совокупной стоимости работ проекта. В случае несложного содержания проекта и хорошо известных рисков, когда можно произвести более точные расчеты и обосновать размер резерва, его величина может составить и менее 10% от бюджета проекта. Но если проект сложный и точно рассчитать риски невозможно, рекомендуемая величина резерва на известные риски составляет порядка 10% от бюджета проекта. Снижение риска Стратегия снижения является самой распространенной и может применяться к любому риску, т.к. подразумевает уменьшение вероятности или влияния риска на проект. Применим эту стратегию для наших рисков. Сначала проработаем риск с неполными требованиями. Можно ли как-то снизить вероятность того, что список требований окажется неполным? Хороший вариант, если мы сбор требований выведем в отдельный проект или этап проекта, при этом на эту работу привлечем профессионального бизнесаналитика (или нескольких), и выделим на проект представителя заказчика, который будет отвечать за утверждение требований, то резко снизим вероятность того, что некоторые важные требования будут пропущены. Но лишь снизим вероятность, а не полностью устраним этот риск. Снижение риска Как можно снизить влияние риска, связанного с неполными требованиями, на проект? Один из вариантов – учесть вероятность пропуска требований при проработке архитектуры продукта. Однако не для всех случаев он сработает. Некоторые новые требования будут крайне трудоемкими в реализации без серьезных переделок архитектуры. Снижение риска Вероятность риска, связанного с изменениями требований, можно снизить, разработав и внедрив специальную процедуру работы с изменениями требований. Она должна внести ясность и понимание того, как обрабатываются запросы на изменения. Процедура заставит задуматься тех, кто хотел бы внести изменения в требования, о том, насколько сложно это будет сделать. И, возможно, приведет к желанию лучше проработать требования изначально. Снижение риска Как можно снизить влияние риска, связанного с изменениями требований, на проект? Один из вариантов – включить алгоритм оценки влияния изменений на срок и бюджет проекта. Как минимум, принимая решения об изменениях, заказчик будет понимать их стоимость и от некоторых изменений, возможно, откажется. Риски в сложных проектах В сложных комплексных проектах чистые известные риски могут трансформироваться из незначительных в критические, и резерва менее 10% может не хватить. В то же время если создавать резерв более 10%, то это может привести к неоправданному увеличению бюджета проекта и завышению цены проектного решения. В этом случае дороговизна проектного решения может отпугнуть заказчиков. Подробнее на примерах Риск 1. Выбор программного продукта без понимания полного списка требований к нему. Приведет к необходимости делать большое количество доработок продукта под процессы компании (а это означает «расползание» рамок проекта и рост объемов работ). Риск 2. Изменение требований к программному продукту по ходу проекта внедрения. Приведет к «расползанию» рамок проекта и росту объемов работ по нему. Действия при реагировании на чистые риски При реагировании на чистые риски, приводящие к финансовым потерям в проекте, рекомендуются четыре типа действий: Позитивные риски В случае позитивного риска возможны несколько стратегий реагирования на благоприятные возможности: • • • • Использование риска (risk exploit) Совместное использование риска (risk share) Усиление риска (risk enhance) Принятие риска (acceptance) Использование риска Использование риска (risk exploit), т. е. максимальное использование положительного эффекта риска в интересах проекта. Использование требует привлечения лучших ресурсов проекта на выполнение тех работ, в которых идентифицирован позитивный риск. Совместное использование риска Совместное использование риска (risk share), т. е. использование эффекта от позитивного риска совместно с заказчиками, партнерами, конечными пользователями результатов проекта. Примером совместного использования риска может быть акционирование компании, продажа акций на фондовом рынке, привлечение новых партнеров. Усиление риска Усиление риска (risk enhance), т. е. увеличение риска путем проведения действий, повышающих вероятность возникновения риска и его влияние. Усиление риска также требует привлечения дополнительных ресурсов на выполнение тех работ, в которых идентифицирован позитивный риск. Принятие риска Принятие риска (acceptance) при наличии бизнес-риска. Это стратегия, при которой команда осознанно идет на риск и не предпринимает шагов по управлению данным вероятным событием. Это событие может не представлять значительной угрозы либо интересной возможности и не сулить проекту какого-то серьезного ущерба или приобретения. Стратегия принятия также возможна в ситуации, когда, несмотря на значительную угрозу, компания вынуждена идти на риск и принимать его ради достижения важных для нее целей, например расширения доли рынка или удержания стратегического заказчика. Принятие риска Как кажется из названия стратегии, до наступления риска предполагается «ничего не делать». С человеческой ментальностью это часто любимая стратегия работы с рисками. Однако совсем ничего не делать – это не управление рисками. Есть два варианта для четвертой стратегии – активное и пассивное принятие. • Активное – формируется резерв времени и денег на устранение последствий материализации риска. • Пассивное – предполагает наличие плана Б (устранения последствий проблемы) на случай, если риск материализуется. Принятие риска Рассмотрим стратегию активного принятия для риска неполных требований. В случае если некоторые требования будут пропущены, нам нужно иметь запас времени и бюджета на их устранение. В каком размере заложить этот запас? Ответ зависит от количества пропущенных требований и сложности их реализации. Не имея никакого прогноза на этот счет, мы можем заложить любой резерв, на который согласится заказчик проекта. Понятно, что для руководителя, чем больше резерв времени и денег – тем лучше, а для заказчика проекта – наоборот. Поэтому размер резерва станет предметом переговоров. Для риска изменения требований стратегия активного принятия та же. И размер резерва времени и денег так же становится предметом переговоров. Пассивным принятием для обоих рисков станет использование резерва времени и денег, который был заложен в проект. Уклонение от Риска 1 Стратегия уклонения предполагает полное исключение риска из проекта. Мы должны придумать реагирование, которое позволит быть уверенными, что риск не материализуется. Это самая «дорогая» стратегия, т.к. для некоторых рисков она вынуждает отказываться от определенных работ, менять цели проекта или, в самом радикальном случае, отказываться от проекта. Попробуем уклониться от риска неполного списка требований (риск 1). Можно ли быть уверенным на 100%, что мы собрали все требования? Практика показывает, что это невозможно. Даже если мы будем считать, что собрали все, по ходу реализации проекта может возникнуть новое требование. Подробнее на примерах В случае изменений требований к программному продукту по ходу проекта внедрения (риск 2), мы можем избежать риска материализации, если пропишем в контракте, что требования изменять нельзя ни под каким предлогом и ни при каких обстоятельствах. Согласитесь, это звучит как минимум странно. Подробнее на примерах Риск 1. Выбор программного продукта без понимания полного списка требований к нему. Приведет к необходимости делать большое количество доработок продукта под процессы компании (а это означает «расползание» рамок проекта и рост объемов работ). Стратегия уклонения предполагает полное исключение риска из проекта. Мы должны придумать реагирование, которое позволит быть уверенными, что риск не материализуется. Это самая «дорогая» стратегия, т.к. для некоторых рисков она вынуждает отказываться от определенных работ, менять цели проекта или, в самом радикальном случае, отказываться от проекта. Осуществление реагирования на риски Осуществление реагирования на риски Осуществление реагирования на риск Осуществление реагирования на риск и мониторинг рисков: • Осуществление реагирования на риски — это процесс выполнения согласованных планов реагирования на риски. • Ключевая выгода данного процесса состоит в обеспечении выполнения согласованных действий реагирования на риски в соответствии с планом с целью принятия мер против подверженности совокупному риску проекта, минимизации индивидуальных угроз проекта и максимизации индивидуальных благоприятных возможностей проекта. Этот процесс осуществляется на протяжении всего проекта. Список рисков и методик их управлением № Нехватка компетенций сотрудников Наем высококвалифицированных сотрудников, мероприятия по формированию команды, обучение сотрудников 1 Нереалистичные сроки и бюджет Детализация оценки затрат и сроков, разработка повторно используемого ПО, уточнение требований 2 Несоответствие разработанной и требуемой функциональности Анализ организации, анализ целей, опрос пользователей, прототипирование, оценка производительности, проверка качества 3 Несоответствие разработанного и Прототипирование, разработка сценариев использования, участие требуемого пользовательского интерфейса пользователей 4 Неэффективное управление требованиями Уточнение требований, прототипирование, анализ стоимости и качеством (Gold-plating) Список рисков и методик их управлением № Риск Методика управления риском 5 Постоянный поток изменений требований Установка ограничений для внесения изменений, итеративность разработки (внесение изменений в следующих итерациях) 6 Недостатки используемых внешних компонентов Сравнительное тестирование, технический аудит, анализ совместимости 7 Проблемы в задачах, выполняемых внешними подрядчиками Проверка контрагентов, подготовка макетов и прототипирование, мероприятия по формированию команды 8 Недостаточная производительность Моделирование, проведение сравнительного тестирования, прототипирование 9 Технологическое отставание Технический анализ, анализ стоимости, прототипирование Мониторинг рисков Мониторинг рисков Мониторинг рисков Мониторинг рисков — это процесс мониторинга выполнения согласованных планов реагирования на риски, отслеживания идентифицированных рисков, выявления и анализа новых рисков и оценки результативности процесса управления рисками на протяжении всего проекта. Ключевая выгода данного процесса состоит в создании условий для того, чтобы решения в рамках проекта были основаны на актуальной информации о подверженности совокупному риску проекта и об индивидуальных рисках проекта. Этот процесс осуществляется на протяжении всего проекта. Основные цели Основные цели контроля над рисками проекта: • наблюдение за существующими рисками и отслеживание/изменение их параметров; • выявление новых рисков; • оценка хода выполнения плана реагирования на риски; • пересмотр стратегий реагирования на риски проекта. Основные действия руководителя Основные действия руководителя проекта в данном процессе заключаются в организации проведения следующих работ: • • • • непрерывное отслеживание статуса рисков ответственными за них; идентификация новых рисков; реагирование на остаточные риски; оценка эффективности выбранных стратегий реагирования и их пересмотр. Ключевым инструментом данного процесса является аудит рисков, за проведение которого несет ответственность рискменеджер. Риск-менеджер Риск-менеджер не подчиняется руководителю проекта и является виртуальным членом команды проекта. Риск-менеджер, как правило, является бывшим руководителем проектов с огромным опытом управления крупными проектами. Его основная задача — тщательная проверка работы руководителя проекта и его команды по идентификации, анализу рисков и выбору стратегий реагирования на риски проекта. Риск-менеджер Риск-менеджер обладает двумя прерогативами: • полнотой полномочий. Например, риск-менеджер имеет право потребовать для ознакомления любой документ проекта, в том числе планы проекта, официальную переписку с заказчиками, поставщиками и т. п. Он может поставить перед руководителем компании вопрос о смене руководителя проекта; • независимостью от локального руководства. Например, в крупных международных корпорациях риск-менеджер, курирующий проекты в отдельной стране, не подчиняется руководителю отделения корпорации в данной стране. Риск-менеджер Риск-менеджер принимает участие в регулярных совещаниях, посвященных состоянию рисков проекта (risk review meetings), и дает рекомендации по обновлению реестра рисков, в том числе: • идентифицирует новые риски; • пересматривает оценки параметров рисков; • пересматривает выбранные стратегии реагирования. Для эффективного мониторинга и контроля над рисками проекта можно использовать: • обсуждение рисков с руководителями функциональных подразделений организации; • привлечение независимых внешних экспертов; • анализ базы данных извлеченных уроков.
