Что такое риски проекта и как ими управлять

Не бывает технологических проектов без рисков. Чем сложнее продукт мы реализуем, чем больше процессов запускаем, тем сильнее рискуем. Обычно дело в неопределенности: заказчик до конца не знает, что хочет → менеджер выбирает некорректные инструменты решения задачи → команда некорректно оценивает бюджет → разработчики допускают ошибки в архитектуре системы. Цепочка событий, которую трудно предсказать.

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

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

Допустим, мы хотим разработать продукт за 500 000 ₽: просчитали расходы, утвердили смету, приступили к работе. Любое событие, которое приводит к дополнительным расходам, не предусмотренным бюджетом, можно считать риском.

Или наша задача — выпустить на рынок продукт быстрее конкурентов. Если мы укладываемся в сроки, то рискуем накосячить с качеством, выпустить сырое решение — теряем клиента. Если заморачиваемся над качеством, рискуем сорвать сроки — теряем клиента. Ну, вы поняли.

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

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

Риски бывают известные и неизвестные:

• Известные можно прогнозировать и контролировать, для них возможно планирование. Например, если мы заходим в насыщенную конкурентами нишу, то мы прогнозируемо рискуем остаться без достаточного спроса на свой продукт
• Неизвестные риски не удается прогнозировать и тем более контролировать. Допустим, мы откладываем поставку импортного оборудования на 1 месяц. За этот месяц нефть просаживается в цене, стоимость доллара в России растет, стоимость импортного оборудования вырастает на треть. Мы не имели возможности предугадать рост курса — понесли убытки из-за неизвестных рисков

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

Риски проекта могут ударить в самое больное место: свести на нет рентабельность, растянуть сроки, убить качество. Чтобы спасти важную составляющую работы, мы выполняем профилактику — прогнозируем возможные проблемы и стараемся принять меры для их исключения.

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

Чтобы грамотно управлять угрозами для бизнеса, мы решили использовать метод фреймворка PMBoK от PMI. Разработчики предлагают поделить процесс управления на 6 этапов:

1. Планирование управления
2. Идентификация факторов
3. Качественная оценка
4. Количественная оценка
5. Планирование реакции
6. Мониторинг и контроль

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

Такую схему из 6 этапов предлагает PMBoK.

Планирование управления

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

Вот такую проектную схему предлагают разработчики PMBoK.

Диаграмма потоков данных планирования управления рисками в PMBoK.

3 главных аспекта правильного планирования:

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

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

Обычно в плане управления указывают:

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

Идентификация

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

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

Классификация рисковых событий по степени их контролируемости.

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

Пример классификации рисковых событий в зависимости от их источника.

При формулировании угрозы важно использовать двух составные понятия: с указанием на источник события и саму угрозу. Например, «угроза срыва сроков реализации из-за отсутствия определенности с функционалом» или «риск отсутствия финансирования из-за нестабильной ситуации с бюджетом у компании-заказчика». Результат — создание реестра возможных рисковых ситуаций.

Фрагмент реестра рисковых ситуаций.

Анализ и оценка рисков проекта

Здесь мы совмещаем качественную и количественную оценку.

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

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

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

Матрица вероятности/воздействия угроз и благоприятных возможностей из PMBoK.

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

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

Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень рисковой угрозы.

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

Количественная оценка помогает проанализировать:

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

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

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

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

Имитационное моделирование — оценка, сделанная на основе многократных опытов с моделью.

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

Планирование реакции

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

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

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

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

3. Снижение. Формируем предупредительные меры по снижению вероятности наступления негативных событий или последствий их наступления. Например, при формировании команды включаем в нее возможных дублеров — на случай, если разработчик заболеет, а дизайнер-фрилансер решит пропасть на неделю без предупреждения.

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

На основании выбранного варианта реагирования предпринимаются дальнейшие действия. Например, в PMBoK рекомендуют вносить изменения в документацию или план проекта.

Диаграмма потоков данных планирования реакции на угрозы из PMBoK.

Мониторинг и управление

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

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

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

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

1. Риски — это возможные события, наступление которых влечет негативные последствия для команды и разрабатываемого продукта. Они не возникают сами по себе и могут быть следствием косяков команды или внешних факторов. Обычно такие угрозы связаны с неопределенностью
   
2. Угрозы могут быть известными и неизвестными. с неизвестными работать сильно сложнее — они проявляются в процессе реализации и не могут быть спрогнозированы обычными методами
3. Чтобы минимизировать или предотвратить последствия, угрозами можно управлять. Для этого в PMBoK придумали свои алгоритмы и методологию. Их можно взять за основу и адаптировать под свою компанию
4. Рисковое управление сводится к прохождению стандартных этапов идентификации, оценки и планирования возможных реакций. Если заранее продумать, как реагировать на угрозу, гораздо легче с ней справиться
5. Для эффективного управления не стоит взваливать всю работу на проектного менеджера. Лучше назначить каждому риску ответственного. Или создать целую рисковую группу