Управление рисками

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

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

Чтобы вы не запутались в терминах, в этой главе мы будем использовать слово «риск» в негативном контексте.

Как работать с рисками

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

Риск состоит из трех частей:

• событие;
• вероятность;
• влияние на проект.

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

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

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

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

Как и во всех остальных областях знаний проектного менеджмента, управление рисками начинается с планирования. А конкретно — с принятия решения о том, будем ли мы ими вообще управлять. Если ответ «да», то далее работа строится по схеме, показанной на рисунке 12.

Остановимся на каждом пункте этой схемы подробнее.

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

Для чего нужно планирование?

• Убедиться, что все заинтересованные стороны одинаково понимают, что такое риск: на какие события нужно реагировать, а какие можно оставить без внимания.
• Договориться о доступных команде инструментах, которыми она обязательно будет пользоваться при управлении рисками. Часто возникает ситуация, когда команда, только увидев весь арсенал инструментов для управления рисками, собирается использовать их все: метод Дельфи, диаграмму «торнадо», метод Монте-Карло и т.д. Когда же дело доходит до их применения, то оказывается, что мало кто знает, как ими пользоваться. И тогда уже команда невольно старается отложить эти активности на потом. Ведь требуется больше усилий, чтобы сначала погрузиться в вопрос, а затем научиться применять новые знания на практике. Когда же инструмент знаком, то им пользуются охотнее, а результаты появляются намного быстрее.
• Договориться о минимальном времени, которое команда готова тратить на управление рисками. Важно определить именно минимальное время на эту активность. В самом начале проекта, когда команда еще полна энтузиазма, она, например, может принять решение проводить двухчасовые встречи по управлению рисками еженедельно. Правда, обычно от этой идеи легко отказываются при первом же сомнении, что время тратится с пользой. В то же время договоренность встречаться минимум раз в две недели на 30 минут выполнить проще. В этом чаще видят пользу.
• Определить уровень толерантности к рискам заинтересованных сторон проекта, в том числе и организации-заказчика. Толерантность к рискам индивидуальна, поэтому иногда два человека, говорящих об одном и том же событии, абсолютно не понимают друг друга.

Вернемся к примеру с рулеткой. Сколько вы готовы поставить на красное? А на зеро? Представьте себе, что руководитель проекта предлагает спонсору поставить на красное X условных единиц, чтобы использовать выигрыш для компенсации сверхурочного времени, которое потратила команда для возвращения проекта в запланированное расписание. Если спонсор — азартный человек, который ежедневно делает ставки, в несколько раз превышающие Х, то ему это предложение может показаться весьма здравым. Если же спонсор — человек не азартный и за квартал обходит казино, то, скорее всего, менеджер будет уволен.

Идентификация рисков

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

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

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

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

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

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

Карточки Кроуфорда. Одна из техник мозгового штурма. Всем членам команды раздают карточки и просят написать один самый значимый, по их мнению, риск проекта. Заполненные карточки помещаются в центр стола. Затем все повторяется 5–10 раз с единственным условием: нельзя указывать риски, которые участник написал в предыдущих итерациях.

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

Метод «Дельфи». Техника объединяет в себе опрос экспертов и мозговой штурм. Экспертами могут быть как члены команды, имевшие опыт работы над подобным проектом, так и внешние по отношению к команде специалисты с релевантным опытом.

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

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

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

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

Что нужно делать на этом этапе:

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

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

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

Что нужно сделать:

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

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

Составление рейтинга риска

Для того чтобы оценить степень влияния риска на проект, ему следует присвоить рейтинг (severity). Рассчитывается он по формуле:

Рейтинг риска = вероятность риска × влияние риска.

Матрица вероятности и воздействия — это инструмент, который сопоставляет вероятность возникновения и влияние риска. В зависимости от правил компании могут использоваться описательные или числовые значения.

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

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

Количественный анализ

На этом этапе оцифровывается вероятность наступления рисков и их влияние на проект. Вероятность оценивается в процентах, а влияние — в деньгах.

Рассмотрим все шаги оцифровки на примере отсутствующего из-за болезни сотрудника.

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

2. Оцифровываем влияние. В качестве влияния берем недельную нетрудоспособность сотрудника, которая может привести или к смещению даты сдачи проекта, или к сверхурочным работам для оставшихся членов команды с трудоемкостью 40 человеко-часов. Предположим, что ставка за час сверхурочной работы составляет 10 единиц. Таким образом, оцифрованное влияние будет вычисляться так:

40 человеко-часов × 10 единиц = 400 единиц.

3. Вычисляем рейтинг риска в деньгах. Для этого берем вероятность наступления риска, которая в нашем случае равна 50%, или 0,5, и умножаем на влияние, которое для данного случая равняется 400 единицам. Получаем денежный эквивалент рейтинга риска в 200 единиц.

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

Планирование реагирования на риски

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

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

Уклонение (Avoid). В этом случае за рамки проекта выводятся те работы, которые содержат этот риск, — их не делают вообще. Таким образом, риски просто исчезают.

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

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

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

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

Снижение (Mitigate). Вероятность наступления риска можно попытаться снизить. Например, менеджер видит, что ключевой сотрудник (пусть это будет архитектор) уже несколько раз приходил на работу в костюме, а в течение дня куда-то отпрашивался. Скорее всего, он ищет новую работу и посещает интервью. Оценим вероятность этого риска в 40%. Если он все же уйдет, то на поиск и адаптацию нового специалиста уйдет время, а это могут быть потери, например, в 35 000 единиц.

Можно попытаться снизить вероятность этого риска — например, пообещав архитектору премию за успешное завершение проекта. И вот уже вероятность его ухода падает с 40% до 10%, так как теперь он мотивирован довести проект до конца.

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

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

Принятие риска (Accept). Принятие риска может быть активным и пассивным.

При пассивном мы просто констатируем: «Да, риск есть, но делать мы с этим ничего не будем». Даже если избрана такая тактика, то менеджер все равно обязан предупредить о риске все заинтересованные стороны.

Активное принятие подразумевает закладывание в бюджет резерва на случай возникновения риска. Например, если сломалось какое-то оборудование, то должны быть деньги на покупку или аренду нового. Рекомендуется закладывать резерв в размере рейтинга риска в деньгах. Например, риск того, что ноутбук разработчика выйдет из строя, составляет 20%, стоимость 2000 единиц, количество ноутбуков 5. Значит, в резерве на этот риск, согласно формуле 0,2 × 2000, должно быть заложено 400 единиц на сотрудника. На всех сотрудников понадобится резерв в 2000 единиц.

Риски — это «известное неизвестное», так как мы их выявили и подготовились к ним. Существует еще такое понятие, как «неизвестное неизвестное» — непредвиденные обстоятельства. Как правило, менеджер и команда даже представить себе их не могут, не говоря уже о том, чтобы оценить вероятность возникновения.

Как правило, на такие события в каждом проекте предусмотрен управленческий резерв. Его величина обычно достигает 10% от бюджета проекта.

Давайте определимся, в чем разница между резервом на возможные потери и управленческим резервом (табл. 2).

Реестр рисков

Реестр обновляется после каждого промежуточного этапа проекта. В него вносится следующая информация:

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

Вот пример реестра рисков для проекта по внедрению единого решения автоматизации бизнес-процессов в сети гостиниц (рис. 14).

Контроль рисков

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

Выводы

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

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

Завершить эту главу хотелось бы цитатой из книги Тимоти Листера и Тома Демарко «Вальсируя с медведями»: «Избегать рисков — дело проигрышное. Раньше вы могли бы отнестись к проекту, свободному от рисков, как к неожиданному подарку судьбы и благодарили бы звезды за эту редкую удачу — легкий проект. Мы реагировали так же. Какими глупцами мы были! Проекты без риска — удел неудачников».

Отправить