В 2019 году была разработана очередная версия стандарта PMI по управлению рисками в проектах, программах и портфелях. Предлагаем вашему вниманию обзор этого стандарта, сделанный в рамках Risk Awareness Week-2020 сертифицированным профессионалом по управлению проектами PMI (Сертификат PMP) с 2006 года, MVP (Microsoft) Александром Зубрицким.
В этой статье использовались следующие стандарты: PMBOK (A guide to the project management body of knowledge) – шестое издание, выпущенное в 2017 году, которое включает главу, посвященную риск-менеджменту в проектах, и Стандарт по риск-менеджменту в портфелях проектов, программах и непосредственно в самих проектах (The standard for risk-management in portfolios, programs and projects).
Сперва определимся, что такое риск. Термин трактуется по‑разному. В этом нам как раз и помогут стандарты. В стандарте PMBOK термину «риск» дается следующее определение: это неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта. Уже здесь очевидно различие с нашей практикой – на российских предприятиях под риском всегда понимается некое негативное вероятностное событие. Почти каждый раз, когда речь идет про риск-менеджмент, управление рисками на предприятиях, подразумеваем, что риски – это что‑то негативное, это угроза, которая приведет к увеличению срока проекта или повышению затрат.
Стандарт более широко трактует термин «риск», когда под риском подразумеваются в том числе и возможности (!) – то есть то, что положительно скажется на целях проекта. Такой подход, его еще называют финансовым подходом в риск-менеджменте, более эффективен, потому что нашими возможностями мы должны управлять так же, как и угрозами. А процессы, как мы увидим далее, одинаковы и для угроз, и для возможностей.
Несколько слов про категории рисков. В стандарте уточняется, что риски могут быть событийные (нечто, что может произойти или не произойти в будущем) и несобытийные. Это не единственная категоризация рисков, но если ориентироваться на то, что написано в стандарте и что происходит на практике, чаще всего наблюдается ситуация, когда на событийный риск в компании действительно как‑то реагируют, в то время как несобытийные риски, а именно какая‑то вариативность и неоднозначность, на практике выпадают из области управления. Это второе отличие от стандарта.
Давайте рассмотрим процессы управления рисками, а именно как они отражены в стандарте, разберемся детально с каждым процессом и проанализируем, какие методы и инструменты применяются в российской практике.
В стандарте PMBOK в разделе управления рисками семь процессов:
• планирование управления рисками;
• идентификация рисков;
• качественный анализ рисков;
• количественный анализ рисков (стандарт рекомендует выполнять такой анализ не на всех проектах);
• разработка мероприятий реагирования;
• осуществление мероприятий реагирования;
• мониторинг и контроль рисков.
Процессы управления рисками циклические, следовательно, в рамках мониторинга и контроля могут выявиться новые риски, и нам нужно будет вернуться к идентификации рисков.
Планирование управления рисками
Первый процесс – планирование управления рисками – больше методологический: он определяет, какой методологии мы будем придерживаться при управлении рисками проекта. Идеальная картина – когда на предприятии есть методология, описывающая, как управлять рисками на тех или иных специфичных для этого предприятиях, проектах. К сожалению, редко встречаю такие предприятия.
Этот процесс описывает, как будут происходить все последующие процессы – идентификация рисков, качественный и количественный анализ, разработка мероприятия реагирования, каких стратегий будем придерживаться при разработке таких мероприятий, как будем их осуществлять и мониторить и как будем контролировать риски.
Для этого процесса должна быть сформирована политика предприятия в области риск-менеджмента. Необходимо понимать форматы описания рисков, чтобы правильно заполнять документы по управлению рисками (реестры рисков и отчеты по рискам). Кроме того, в организации в целом и на проекте в частности должны быть разработаны категории рисков, иерархическая структура рисков. Конечно, необходима терминология в области рисков. Шаблоны реестров, отчетов и других документов по управлению рисками – без них тоже никуда. Должны быть обозначены границы и зоны ответственности в области управления рисками, уровни полномочий для принятия решений. И в завершение необходимого – база знаний и извлеченных уроков.
Идентификация рисков
Следующий процесс – идентификация рисков проекта. По сути, на этом этапе создается перечень рисков. С формальной точки зрения стандарта это процесс выявления рисков, источников рисков и документирование их основных характеристик.
Выделяются следующие методы идентификации рисков:
• экспертный подход;
• мозговой штурм;
• SWOT-анализ;
• анализ допущений;
• контрольные листы;
• использование диаграмм.
В большинстве случаев на российских предприятиях применяется экспертный подход, когда эксперт выявляет риски проекта. Опыт и знания эксперта здесь просто обязательны. На некоторых предприятиях есть контрольные листы или проводится мозговой штурм по риск-менеджменту.
Достоинства экспертного подхода в том, что эксперт может работать в условиях недостатка информации. Проект, в отличие от операционной деятельности, это нечто новое, какие‑то задачи ранее не выполнялись, нет полной информации по задачам проекта, в этих случаях и привлекают эксперта. Он часто знает о специфическом риске больше руководителя проекта, поскольку глубоко погружается в задачу, понимает суть многих задач и по рискам знает гораздо больше.
Основные недостатки такого подхода – субъективность суждения экспертов и трудность их привлечения ввиду загруженности.
Мозговой штурм – собрание с участием нескольких экспертов, в рамках которого генерируются возможные риски. Главное – не уйти куда‑то в сторону. Основное достоинство – возможность выявить специфические риски проекта. Недостаток – возможен уход от реальных рисков.
SWOT-анализ – это анализ сильных и слабых сторон. Вначале анализируется, какие сильные стороны есть у проекта, затем рассматривается, какие возможности есть для нашего проекта, далее проводится анализ слабых сторон и выявляются угрозы для проекта. Достоинства: гибкость, универсальность, не требуется специальных знаний. Недостаток – выявляет риски только на момент анализа (статичность).
Анализ допущений. Допущение – это некое предположение, которое в дальнейшем используется для планирования проекта. Любое допущение – источник риска, поэтому нужно подходить к нему следующим образом: «а что произойдет, если допущение окажется неверным?» На практике допущения редко документируются, в российской практике я не встречал такого отдельного инструмента, как анализ допущений.
Достоинства данного процесса: идентификация рисков, допущенных вследствие неточности, неполноты, нестабильности допущений. Недостаток – метод работает только для документально зафиксированных допущений.
Контрольные листы, на мой взгляд, очень хороший инструмент. Он представляет собой список известных рисков прошедших проектов. Из опыта могу сказать, что он достаточно часто используется. Его основные достоинства – простота использования и универсальность. Недостаток – в чек-листе отражаются только известные риски прошедших проектов, а так как любой проект связан с новизной, в нем есть новые специфические риски, которые отсутствуют в чек-листе.
При использовании данного метода это следует учитывать.
Метод использования диаграмм применяется, в первую очередь, для структурирования рисков, поскольку позволяет выявить причинно-следственные связи. Мы идем от причины к возможным рискам. Недостаток – сложность правильного определения причины в случае комплексного риска.
Рассмотрим пример иерархической структуры рисков. В данном примере риски проекта делятся на технические, организационные, управленческие и внешние, которые затем декомпозируются на более мелкие. Допустим, внешние риски можно декомпозировать на два аспекта: изменение законодательства и изменение ситуации на рынке. Можно добавить вероятность пандемии коронавируса или другого вируса.
Переходим к идентификации конкретных рисков проекта.
В итоге мы должны получить реестр рисков, где указывается описание риска и его код, код связанной с ним задачи. В следующих столбцах должны быть отражены такие процессы, как вероятность, влияние на длительность задачи, увеличение затрат на задачу, ранг, стратегия реагирования, мероприятие реагирования, вероятность успеха мероприятия реагирования, затраты на реагирование.
Проведя идентификацию, получаем список рисков. Необходимо понимать, на какие риски нужно реагировать, а какие можно просто принять. Для этого ранжируем риски. Качественный и количественный анализ в этом помогут.
Качественный анализ рисков
Качественный анализ рисков проекта – процесс расстановки приоритетов в отношении рисков проекта для дальнейшего анализа или действий, выполняемый путем оценки вероятности возникновения и воздействия рисков на проект.
Как оценить вероятность риска на проекте? Достаточно сложный вопрос, если учесть, что сам по себе проект – нечто уникальное, соответственно, могут быть новые, очень специфические риски.
Если есть возможность – проводится анализ статистики прошлых проектов (если она есть), но чаще привлекаются, опять же, эксперты для оценки вероятности.
Еще один важный нюанс – эксперту сложно оценить вероятность рисков в процентах, поэтому часто употребляются общие фразы – такие, как «скорее всего», «с большой вероятностью» и т.п. Было проведено исследование для англоговорящих людей, что значит каждое слово.
Из этого исследования следует, что если эксперт говорит, что такое событие происходит «достаточно часто», его вероятность на уровне от 70 до 80%.
Я не встречал подобного исследования для русского языка – что подразумевается под тем или иным словом: «всегда», «точно», «почти всегда», «обычно» и т.д. Возможно, лингвисты сделают в дальнейшем такое же исследование для русского языка. Тогда станет более понятным, что эксперты, сотрудники, коллеги понимают под тем или иным словом или фразой.
Чаще используется пятибалльная оценка вероятности риска. Таким образом, мы ограждаем эксперта от численных оценок вероятности, и он применяет следующие термины: «очень высокая вероятность», «высокая», «средняя», «низкая», «очень низкая». В то же время помним, что эксперт может ошибиться вследствие своей субъективности. Этот риск можно снизить привлечением нескольких экспертов. Есть методы, которые рекомендуются стандартом, тот же метод Дельфи позволяет согласовать мнения экспертов.
Оценка влияния риска. Каждый человек может по‑своему оценить влияние события как с точки зрения сроков, так и с точки зрения затрат, которые мы понесем, если оно произойдет. Чтобы согласовать оценки экспертов, рекомендуется использовать матрицу, которая позволяет оценить одинаково. Работает это так: если мы моделируем наступление какого‑либо рискового события, то необходимо рассчитать, как это изменит срок проекта. Вносим это событие в календарный план проекта и определяем, насколько сдвинулся срок проекта, насколько увеличилась стоимость проекта, как изменилось качество, как событие повлияло на содержание, цели проекта. К примеру, если сроки увеличились на 5%, то оцениваем влияние этого события как слабое. Если стоимость выросла на 18%, влияние этого риска оцениваем как достаточно сильное. Таким образом, согласовываем оценки экспертов в области влияния риска.
Получив оценку вероятности и оценку влияния, можно посчитать ранг риска. Самая простая формула:
Ранг = Вероятность * Влияние
Чтобы расшифровать полученное значение, обратимся к таблице
Это не единственная формула для расчета ранга риска, есть и другие. Все зависит от внутренней методологии. Если после расчета риск попадает в красную ячейку, это сигнализирует об опасности, на такие риски нужно обязательно реагировать. В желтых ячейках – средние риски и в зеленых – слабые, которые можно просто принять.
Кроме того, в стандарте уточняется, что при расчете ранга риска может учитываться ряд параметров. Допустим, срочность – период времени, в течение которого меры реагирования на риск должны быть осуществлены, чтобы они дали ожидаемый результат. Короткий период показывает высокую срочность.
Если учитывать срочность риска, формула выглядит следующим образом:
Ранг = Вероятность * Влияние * Срочность
Таким образом, срочные риски получают более высокий приоритет.
Количественный анализ рисков
Количественный анализ рисков проекта – это процесс численного анализа совокупного воздействия рисков проекта и других источников неопределенностей на цели проекта в целом. Количественный анализ является единственным надежным методом оценки совокупного риска проекта.
Как правило, количественный анализ выполняется для серьезных проектов, в нем участвуют только опасные риски проекта.
В стандарте выделяются три основных метода количественного анализа: анализ дерева решений, анализ чувствительности проекта к рискам, моделирование/имитации.
Я встречал использование количественного анализа рисков на единичных проектах, но и в самом стандарте напрямую указывается, что он применяется не для всех проектов.
Начнем с неопределенности. Она может быть представлена как распределение вероятности.
Наиболее распространенные модели:
• треугольное распределение;
• нормальное распределение;
• логарифмически нормальное распределение;
• бета-распределение;
• равномерное распределение;
• дискретное распределение.
Вначале на примере рассмотрим анализ дерева решений. Допустим, у нас появилась бизнес-потребность производить абсолютно новый продукт, который пока на нашем производстве не выпускается, и мы стоим перед дилеммой: создавать новое производство или модернизировать существующее. У нас есть две альтернативы. Первая – создать новое производство, вложив в него 60 миллионов рублей. С вероятностью 70% мы получим выгоду до 120 миллионов. При этом есть вероятность 30%, что выгода для предприятия будет всего 60 миллионов. Вторая альтернатива – модернизация существующего производства. Для этого придется потратить 50 миллионов рублей. Выгода, с вероятностью 60%, может составить 100 миллионов, а с вероятностью 40% – всего 40 миллионов. Чтобы принять адекватное решение, можно воспользоваться формулой:
ОДЗ (1) = 120 * 0,7 + 60 * 0,3–60 = 32
ОДЗ – это оценка ожидаемого денежного значения. Поскольку речь идет о первой альтернативе, берем предполагаемую выгоду 120 миллионов, умножаем ее на вероятность 0,7, прибавляем выгоду 60 миллионов, умноженную на вероятность 0,3 и вычитаем затраты на сам проект (60 миллионов). Получаем 32 миллиона.
Аналогичные расчеты производим для второй альтернативы.
ОДЗ (2) = 100 * 0,6 + 40 * 0,4–50 = 26
Выходит, в данном примере выгоднее создавать новое производство.
Второй метод – анализ чувствительности проекта, он помогает определить, как риски или другие источники неопределенности могут потенциально оказать влияние на результат проекта. Как правило, анализируются такие показатели проекта, как длительность и стоимостные показатели (к примеру, NPV и др.).
Третий метод – имитация или моделирование – предполагает использование модели проекта, которая имитирует совокупное воздействие рисков и источников неопределенности с целью оценить их потенциальное влияние на достижение целей проекта. Как правило, моделирование проводится по методу Монте-Карло. Для полноценного анализа обычно делают несколько тысяч итераций, каждая из которых это возможный сценарий выполнения проекта и реализации рисков. Конечно, без специального программного обеспечения это невозможно сделать.
Как этот метод работает. Начнем с плана проекта. Под планом понимается не только план-график проекта, но и ресурсный план, бюджет проекта и ряд других планов, интегрированных в одну цельную модель. Как правило, чтобы получить хороший результат, требуется приложить достаточно много усилий, нужны серьезные проработки. Плохой план не приведет к хорошему результату. Итак, речь идет о качественном плане проекта. Вопрос в том, что считать качественным планом проекта. Есть несколько подходов, и на наших предприятиях встречаются различные критерии качества плана.
Предлагаю рассмотреть модель, которая достаточно широко используется на Западе (у нас тоже используется, но реже) – DCMA. Она включает 14 параметров. Остановлюсь подробнее на каждом.
Первый параметр – логика (logic). Его суть заключается в том, что у каждой задачи должны быть предшествующая задача и последующая. Все задачи должны быть связаны между собой, хотя допускается порядка 5% несвязанных задач.
Что обеспечивает связь между задачами – результат одной задачи необходим для начала следующей. Если такая связь обусловлена технологией, но она отсутствует в нашей модели, это приведет к тому, что по факту последующая задача сместится по времени в плане на более поздний срок. Вроде по плану мы успеваем выполнить проект в срок, но по факту, скорее всего, нарушим эту директивную дату или у нас будет аврал.
Второй параметр – опережение (leads). В соответствии с методологией DCMA запрещается использовать «опережения» в связях между задачами. Опережения (отрицательные задержки) – это попытка уменьшить срок проекта за счет сильного распараллеливания работ. Не завершив предшествующую работу, мы начинаем последующую. Очевидно, что резко возрастает риск переделки.
Третий параметр – задержки (lags) обусловлен тем, что после выполнения одной задачи мы делаем паузу перед началом следующей в связи, допустим, с технологией (бетон должен застыть, форма должна остыть перед ее последующим применением и т.д). Такие задержки допускаются, но не более 5% связей могут иметь задержки.
Четвертый параметр – типы связей (relationship types). Большинство типов задач (по крайней мере – 90%) должны быть связаны зависимостью «Финиш –
Старт», то есть завершение одной задачи является стартом последующей. По опыту могу сказать, это сильно облегчает анализ с целью оптимизации календарного плана проекта.
Пятый параметр – типы ограничений задач (hard constraints). Основной тип – «Как можно раньше». Использование других типов связей типа «Фиксированное начало», «Фиксированное завершение», «Начать как можно позднее» можно использовать не более чем в 5% случаев при реализации наших задач.
Шестой параметр – величина резерва (high float). Если резерв операции превышает 44 рабочих дня (что составляет два месяца), как правило, это означает пропущенные связи. По моему опыту, два месяца – достаточно большой резерв, для своих проектов, если использую этот критерий, закладываю меньший резерв.
Количество операций с большим резервом не должно превышать 5%. Данный критерий подсказывает, что если задача проекта имеет большой резерв, значит, мы забыли указать какие‑то связи. Напомню: если связь не указана, значит, модель проекта проработана плохо.
Седьмой параметр – отрицательный резерв (negative float) – по сути, означает нарушение директивной даты выполнения проекта. Если такая ситуация возникает, необходимо разработать план ликвидации этого отрицательного резерва, а именно проанализировать, как можно увеличить скорость выполнения работ проекта, сократить время выполнения и продолжительность задач, чтобы сделать проект к нужной дате.
Восьмой параметр – продолжительность задачи (high duration). Длительность задачи считается чересчур большой, если она превышает 44 рабочих дня (опять же, это два месяца). Количество таких операций в плане не должно превышать 5% от числа незаконченных задач. В своей практике во многих проектах, когда мне приходилось сталкиваться с теми или иными проблемами, хорошая декомпозиция предполагает, что длительность задачи – менее 44 рабочих дней.
Девятый параметр – некорректные даты (invalid dates). В плане проекта не должно быть задач, у которых фактическое начало или фактическое завершение в будущем по отношению к текущей задаче. Другими словами, я не могу сегодня отметить, что завтра задача уже сделана.
Десятый параметр – ресурсы (resources). У каждой задачи должны быть назначены ресурсы, то есть выделены стоимость и плановая трудоемкость задачи.
Одиннадцатый параметр – отстающие задачи (missed tasks). Количество операций, отстающих от плана, не должно превышать 5%.
Двенадцатый параметр – тест критического пути (critical path test). Если отложить какую‑либо критическую работу, то завершение проекта должно пропорционально задержаться.
Тринадцатый параметр – индекс критического пути (critical path leigh index – CPLI), когда мы делим сумму длительности критического пути и величину общего резерва по проекту на длительность критического пути. Этот индекс должен стремиться к 1, то есть общий временной резерв по проекту должен стремиться к нулю.
Четырнадцатый параметр – индекс выполнения базового плана (baseline execution index – BEI). Соотношение количества выполненных задач к тем задачам, которые должны быть выполнены в соответствии с базовым планом, должно стремиться к 1. Если индекс выполнения базового плана менее 0,95, это говорит о серьезных проблемах на нашем проекте.
Итак, без хорошего календарного планирования и разработки хорошего бюджета на проекте невозможно эффективно управлять рисками. Если на проекте нет хорошего календарного плана, хорошей календарной сметы, управление рисками сводится просто к резерву. То есть создается какой‑то резерв, и если что‑то случится, нам может его хватить, а может и не хватить.
Как это должно делаться на практике. У нас есть план проекта, созданный в системе календарного планирования, – наша модель. Загружаем ее проект в информационную систему управления рисками, которая автоматически проверяет ее по 14 признакам DCMA. Если признак не прошел, он выделяется красным цветом, и мы получаем сигнал, что на него надо обратить внимание и наша модель недостаточно качественна для последующего анализа рисков, в первую очередь, количественного.
Скорректировав наш план (если есть необходимость), добавляем в модель неопределенность. К примеру, задачу можно сделать за три дня, за пять или за двенадцать. В такой ситуации никакой эксперт не может дать точной оценки. Поэтому в нашу модель добавляем оптимистичную, ожидаемую и пессимистичную оценку этой задачи. Эти три оценки тоже будут учитываться при количественном анализе рисков.
Далее непосредственно вносим в систему риски. Каждый должен быть связан с какой‑то задачей проекта или каким‑то ресурсом. Кроме того, вносим всю необходимую информацию о риске, в том числе является этот риск угрозой или возможностью. Помним: и в стандарте, и в программном обеспечении риск – это либо возможность, либо угроза. Вносим в модель вероятность каждого риска, его влияние, и система рассчитывает ранг нашего риска.
Каждый риск назначаем к конкретной задаче или ресурсу. Это так называемые индивидуальные риски. Как только внесли оценки вероятности, оценки влияния, система рассчитывает ранги каждого риска. Добавляем и глобальные риски. В стандарте это называется «совокупный риск проекта». Глобальный риск не связан с конкретной задачей, он связан со всем проектом и рассчитывается как сумма рисков всего проекта. Затем по матрице рисков смотрим, в какую зону попадают риски (красную, желтую, зеленую), и в зависимости от этого реагируем.
Далее запускаем имитирование выполнения проекта. Система многократно «прокручивает» наш проект, задействовав метод Монте-Карло, то есть генератор случайных чисел случайным образом с заданной вероятностью рассчитывает, произошел ли риск, и мы получаем некое отклонение по срокам, стоимости нашего проекта.
В результате моделирования метод Монте-Карло рассчитывает диапазон завершения задач в ту или иную дату.
Можно привести в качестве примера анализ чувствительности, для чего используется диаграмма Торнадо.
Аналогичная ситуация с затратами по проекту – мы видим, с какой вероятностью можно выполнить проект и удержаться в рамках его бюджета. Например, если у нас есть резерв порядка 140 тысяч рублей, всего 40% вероятности, что мы сделаем проект и нам хватит этого резерва. Система покажет вероятность завершения проекта с той или иной продолжительностью. Аналогично со сроками проекта – какова вероятность завершить его к тому или иному сроку.
Разработка мероприятий реагирования
Следующий процесс – планирование реагирования на риски – предполагает разработку вариантов, выбор стратегий и согласование действий относительно рисков проекта. Мы должны разработать такие противорисковые мероприятия, которые уменьшат вероятность или последствия угроз и увеличат вероятность возможностей или влияние возможностей на наш проект.
Начнем с угроз. В стандарте описаны четыре стратегии реагирования на угрозы:
• эскалация (передача риска наверх);
• уклонение (исключение риска из проекта);
• снижение (уменьшение вероятности возникновения риска);
• передача (ответственность за риск передается на третью сторону).
Бытовой пример. Допустим, у нас есть автомобиль, и есть угроза его угона.
Стратегия уклонения будет заключаться в том, чтобы вообще не иметь автомобиль – раз его нет, значит, риска угона нет. Стратегия снижения – это когда мы уменьшаем вероятность угона, ставим какую‑то серьезную систему сигнализаций. Хотя профессиональный угонщик может сказать, что вскроет любую систему, но вероятность того, что он будет заниматься именно нашим автомобилем, ниже, если рядом стоит аналогичная машина с простой сигнализацией.
Стратегия передачи предполагает, что мы передаем ответственность за событие, которое может произойти, на третью сторону, в нашем примере это страховка КАСКО. Стратегия эскалации применима в том случае, если хозяин автомобиля передает его родственнику, а тот предупреждает хозяина, что оставил машину в неблагоприятном с точки зрения возможности угона месте. Таким образом, он эскалирует риск, сообщив хозяину об угрозе, а тот уже должен предпринять действия.
Выделяются также четыре стратегии реагирования на возможности:
• эскалация (мы сообщаем о возможности наверх – нашему шефу, спонсору проекта, который решает, как эту возможность можно эффективно использовать);
• использование (нужно постараться сделать так, чтобы наша возможность обязательно произошла);
• разделение (делимся информацией с партнерами по проекту или по бизнесу, которые тоже используют наши возможности);
• увеличение (проводим какие‑то мероприятия, увеличивающие вероятность возможности, ее влияние на проект).
Затем выбираем одну стратегию как для угроз, так и для возможностей. Хотя стратегии можно комбинировать. Например, если говорим про угрозы, в примере про автомобиль можно комбинировать стратегии снижения и передачи, то есть можно поставить серьезную сигнализацию и при этом застраховать автомобиль КАСКО.
Определившись со стратегией, прорабатываем для нее мероприятия реагирования. Все это делаем только для опасных рисков.
Есть стратегия общего реагирования как на возможности, так и на угрозы. Для принятых рисков формируются резервы по стоимости и резерв по срокам, которые рассчитываются следующим образом:
Резерв по стоимости:
Резерв = Вероятность + Влияние (деньги)
Резерв по срокам:
Резерв + Вероятность + Влияние (сроки)
Понятно, что риски все равно будут реализовываться, но если мы правильно рассчитаем резервы, они помогут реализовать проект в срок и в рамках заложенного на проект бюджета.
В большинстве случаев в организациях с невысоким уровнем риск-менеджмента все управление рисками сводится к тому, чтобы заложить резервы по стоимости, срокам, даже не обосновав их, а исходя из позиции: «наверное, такой резерв нам понадобится» или «такого резерва хватит на наш проект». На мой вопрос, почему они так считают, слышу в ответ, что в прошлый раз закладывали меньше и резерва не хватило, поэтому сейчас заложили немного больше. Эта практика, на мой взгляд, объясняется тем, что персонал, задействованный в проекте, и руководитель проекта не имеют навыков управления рисками и знаний в этой области.
Осуществление мероприятий реагирования
Таким образом, мы выбираем стратегию, формируем резервы, планируем противорисковые мероприятия. Следующий процесс – реализация противорисковых мероприятий, осуществление реагирования на риски проекта.
В первую очередь, это делается для минимизации угроз и максимизации благоприятных возможностей. Напомню: в стандарте PMBOK угрозы соседствуют с возможностями, а в нашей российской практике, говоря про риски, мы подразумеваем угрозы, возможности вычеркиваем из цикла управления.
В рамках этого процесса мы должны создать такие условия, чтобы команда эффективно работала с рисками, эффективно выполняла противорисковые мероприятия, осуществляла коммуникации, в том числе внешние.
Да, мы не можем повлиять на внешние риски, но можем получать информацию от стейкхолдеров, имеющих влияние на эти внешние риски. Важно привлекать экспертов в ходе выполнения противорисковых мероприятий, использовать информационную систему управления проектами. Как упоминалось ранее, если у нас нет качественного календарного плана, бюджета проекта, нельзя эффективно управлять рисками. Информационная система должна все это поддерживать.
В соответствии со стандартом необходимы следующие документы:
• журнал проблем (для регистрации выявленных проблем в ходе реагирования на риски):
• реестры извлеченных уроков (сюда вносятся сведения о результативности и эффективности противорисковых мероприятий; отражаются проверенные подходы, что сработало, что нет);
• реестр рисков (для коррекции данных о рисках или противорисковых мероприятиях. В результате может измениться вероятность или оценка влияния риска, соответственно, поменяется ранг риска).
• матрица ответственности (для распределения прав и обязанностей среди членов команды проекта в области управления рисками; прописывается, кто отвечает за риски, кто имеет право принимать то или иное решение в области рисков и брать на себя ответственность за его принятие);
• отчет по рискам (в него попадает вся информация об изменениях в рисках и противорисковых мероприятиях).
Мониторинг и контроль рисков
Заключительный процесс – мониторинг и контроль рисков – направлен на отслеживание выполнения планов реагирования на риск, отслеживание самих рисков, выявление и анализ новых рисков, оценку результативности процессов управления рисками на протяжении всего проекта и анализ резервов, заложенных в проект.
Для управления рисками используются следующие информационные технологии: Tamara, Spyder Project, Risky Project, PERT Master и другие. Все перечисленные системы обеспечивают ведение реестра рисков, моделирование, интеграцию с календарным планом и ведение базы знаний по рискам.
Меня нередко спрашивают: почему хорошо проработанные методы, процессы и инструменты управления рисками чаще всего не находят применения в российской практике? Здесь две основные причины. Первая – наш менталитет, вторая – отсутствие навыков управления рисками. Беседуя с менеджерами различных российских предприятий, я убедился: они знают теорию по управлению рисками, знают процесс управления рисками, но не применяют их на своих предприятиях. Следовательно, у них отсутствуют навыки в данной области, а значит, отсутствует доверие к этим процессам. Для выработки навыков можно использовать бизнес-игры, которые сегодня проводятся, в том числе в онлайн-
формате.
Александр ЗУБРИЦКИЙ,
сертифицированный профессионал по управлению проектами PMI, MVP
