Когда менеджер знает, как эффективно управлять рисками, то сумеет вовремя нейтрализовать угрозы, поставляя работы в рамках бюджета, и с нужным результатом.
Команда тоже работает продуктивнее, если не находится постоянно в режиме аврала, из-за того, что PM заранее не подумал о возможных проблемах.
В статье собрали 10 правил, которые помогут подготовиться к появлению рисков, подскажут, как увидеть опасность и составить план реагирования.
Работа с рисками проекта: 10 важных правил
Любой список правил — это уникальный документ, который может меняться и совершенствоваться со временем. Мы предлагаем универсальные правила, которые подойдут большинству проектных команд и организациям разного размера.
Ниже вы найдете основные правила или стратегии управления рисками. Постарайтесь всегда держать их в уме на старте проекта.
1. Сделайте управление рисками частью проекта
Риски могут появиться на любом этапе проекта.
Первое правило говорит о том, что с ними нужно работать систематически, а не от случая к случаю. Понимание основных принципов управления рисками будет солидным бонусом на собеседовании РМа, потому что учет возможных опасностей помогает выполнять все договоренности в рамках «проектного треугольника».
Под риском понимают условие или событие, которое с большей или меньшей вероятностью повлияет на достижение целей проекта: сроки, стоимость или качество.
Любой проект развивается в среде опасностей и неопределенности, поэтому выбирать не приходится: команда либо начнет работать с рисками, либо «позволит рискам» управлять процессом.
Некоторые компании игнорируют вопрос возможных неприятностей при реализации проекта и «реагируют на проблемы по мере поступления». Из-за этого вся система проекта подвергается опасности, становится малоэффективной.
Стандартно, работа по нейтрализации угроз состоит из 5 шагов:
- Идентификация возможных рисков.
- Классификация.
- Анализ.
- Составление плана реагирования.
- Отслеживание и предупреждение.
Эти шаги не происходят только однажды, в самом начале работы, а повторяются циклично, по крайней мере раз в каждой фазе проекта.
Для успешной реакции важно определять не только риски, но и триггеры — факторы или обстоятельства, которые предшествуют их наступлению.
Если есть условие (угрозы или улучшения), возникает триггер, после которого наступают последствия.
Когда триггер определен, нужно оценить его и понять — насколько событие находится в зоне контроля, а затем установить стратегию смягчения триггера:
Допустим, есть риск упустить критическую дату запуска.
Задайте себе вопрос: «Почему появилась опасность не успеть? В чем первоначальная причина?»
Конкретизируйте, что именно не успеваете: разработать, портировать, тестировать. Например, выяснилось, что ключевое промежуточное ПО не портировано на вашу платформу.
Дальше нужно выяснить сроки: когда наступит last responsible moment для портирования ключевого промежуточного ПО, если критической датой для запуска будет 28 декабря?
Дата, которую определили как last responsible moment (например, 1 октября), и будет триггером. Если к 1 октября работа не будет сделана — с высокой вероятностью наступит риск не успеть к дате запуска.
Для потенциального смягчения триггера можно, например, купить лицензию на исходный код и портировать самостоятельно.
Отслеживание триггеров помогает заметить, что команда не успевает пройти запланированные шаги и вовремя отреагировать.
2. Определяйте риски на ранних стадиях проекта
Идентифицировать риски начинают на ранних стадиях, когда идет инициализация, определяется содержание проекта, а команда настраивается на условия работы.
Именно на этой стадии задача менеджера — подумать не только о том, как все должно быть, но еще и о том, что может пойти неправильно.
Используйте разные способы для идентификации угроз:
- Опыт участников проекта.
- Знания сторонних экспертов.
- Интервью и собеседования.
- Мозговой штурм.
- SWOT-анализ.
- Изучение документации.
Может показаться, что, проработав на проекте достаточно долго, менеджер способен определить любые возможные риски. Но проблема в том, что иногда РМ просто не знает какой-то информации. Всегда остается зона неопределенности — неизвестные опасности, о которых никто не догадывается.
Кейс ниже ярко иллюстрирует, как неизвестный риск может повлиять на проект
Компания High Moon Studios разрабатывала проект видеоигры «The Bourne Conspiracy». Создатели опирались на книгу и фильм об агенте ЦРУ Джейсоне Борне.
В начале проекта командам предложили поработать с рисками: создать матрицу всех потенциальных событий, которые могут пойти не так на каждом этапе разработки игры.
- Известные риски обнаружили без затруднений: каждая команда легко сформировала список возможных угроз.
- Команды достаточно быстро поняли, где есть пробелы в знаниях, и какую помощь нужно привлечь, чтобы узнать о дополнительных рисках.
- Участники смогли договориться о триггерах: какие ключевые события должны происходить, чтобы говорить о приближении риска.
- Проблема возникла только с идентификацией неизвестных рисков, о которых команды проекта не имели ни малейшего представления, что эти события могут случиться.
Персонажа игры сделали похожим на Мэтта Деймона — исполнителя главной роли в фильме. Дополнительно, актер должен был сняться в коротком вступительном сюжете.
Разработка игры проходила по плану, и актер готовился к съемке видеоролика. Здесь и появился неизвестный фактор: агент Мэтта Деймона сообщил, что мама Мэтта очень не любит компьютерные игры, поэтому запретила ему принимать участие в проекте.
Когда создателям не удалось договориться с Дэймоном, чтобы использовать его внешность и голос как прототип, — пришлось перерисовать главного персонажа игры.
Менеджер проекта не может управлять неизвестным. Цель минимизации рисков — это нейтрализовать угрозы, которые можно определить и классифицировать, а для событий, которые находятся в зоне полной неопределенности, закладывают резерв. Размер такого фонда определяет спонсор проекта на основании информации, которую предоставил РМ.
3. Общайтесь на тему управления рисками
Абсолютно на каждой встрече должно быть время для разговора о рисках, будет ли это отдельный пункт в повестке дня или одно предложение в meeting minutes. Когда о видах рисков проинформированы команда, заказчик и руководство, можно вовремя включить в рабочий план задачи по устранению опасности.
Чтобы общение было действительно продуктивным, менеджеру необходимо строить доверие в команде, иначе неизбежны непонимание и конфликты. Если люди не привыкли общаться для достижения общих целей, то могут пропустить момент, когда нужно что-то интегрировать и протестировать. Когда люди постоянно пишут письма и отчитываются — они не сотрудничают, а «решают вопросы».
Менеджер может определять проблемы с доверием в других терминах, например, считать:
- Что команда неправильно оценивает.
- Долго разрабатывает.
- Не может предвидеть какие-то обстоятельства.
- Работает не слажено.
- Использует слово «зависимость» вместо «сотрудничество».
Такого рода проблемы РМ пытается «починить» усилением контроля: заводит дополнительные отчеты, сосредотачивается на стандартах и процессах. Однако, если появляется постоянная потребность контролировать членов команды, это уже само по себе сигнал об отсутствии доверия.
Когда менеджер пытается усилить контроль, то, фактически, «прячет под ковер» список рисков. Потому что внешние риски в проекте — это не только то, что пойдет «не так» от заказчика, но и маркер доверия и сотрудничества в команде.
4. Учитывайте как угрозы, так и возможности в процессе управления рисками проекта
Часто любое неожиданное событие трактуется как риск — фактор, который обязательно окажет негативное воздействие на проект. На самом деле, есть два типа неожиданных событий: риски и возможности.
Возможности тоже случаются внезапно, и могут влиять на ограничения, стоимость, сроки и цели проекта, но с позитивным результатом.
Неожиданная возможность приводит к уменьшению стоимости программы или проекта, улучшает производительность, задает другие цели или меняет график.
Возможности планируют на том же этапе, что и угрозы, а задача менеджера — сделать так, чтобы неожиданных улучшений было как можно больше или расширить их влияние на проект.
Предугадать позитивные события помогут вопросы: «Что может пойти по незапланированному сценарию, потому что какой-то фактор улучшится? Что члены команды внутри компании могут сделать, чтобы сэкономить время и деньги?» Ответы на эти вопросы — это и есть потенциальные возможности.
Откуда могут прийти улучшения:
- Потенциальные зоны возможностей. За годы работы в определенном домене, в программе проектов, менеджер уже заранее видит потенциальные зоны возможностей.
- Конкуренция поставщиков. Поставщики могут предоставить лучшие условия за счет конкуренции друг с другом.
- Тест по сходству и анализу. Всегда полезно проверять, что происходит с похожими продуктами на вашем или других рынках.
- Автоматизированное гибкое (Lean) производство. Можно привлекать консультантов или использовать принципы бережливого производства самостоятельно.
- Использование коммерческих частей. Речь идет об использовании коммерческих частей из других продуктов.
- Agile разработка. При разработке, согласно agile mindset, появляются дополнительные возможности, помимо тех, которые есть в waterfall.
Кроме угроз и возможностей в риск-менеджменте существует слово «проблема». Риск может стать проблемой, но отличается тем, что риск — это обстоятельство, которое возможно случится, а проблема — угрожающее для проекта событие, которое уже точно происходит.
Когда идентифицируете риски, начинайте с проблем — того, что уже идет не так или точно пойдет не так в будущем. Другими словами, если мы точно знаем, что событие наступит, это уже не риск, а проблема.
Риск определяется как то, что потенциально может повредить успеху проекта. Проблема — то, что уже сейчас влияет на проект.
Если РМ не управляет рисками, они становятся проблемами, и вероятность успешного завершения проекта снижается.
5. Определите владельца риска
Для каждого риска надо определить собственника (risk owner), и это не обязательно будет проектный менеджер. Владелец риска — человек, который несет ответственность за конкретный риск. Каждый собственник риска ответственен за то, чтобы сказать или сделать действие, которое для него определил руководитель проекта.
Risk owner:
- Отслеживает риск по графику, о котором предварительно договорились.
- Следит, чтобы не наступал ни один из триггеров.
- Управляет риском, если он все-таки возник.
- Внедряет все ответные действия, которые определили, когда планировали минимизацию рисков.
- Создает отчетность по результатам работы.
Руководителю проекта нужно определиться и с владельцами финансовых последствий рисков: кто из стейкхолдеров будет нести финансовую ответственность или получит прибыль, если риск окажется возможностью.
6. Приоритизируйте риски
Потенциальные риски и возможности после идентификации необходимо приоритизировать. Вряд ли получится работать со всеми рисками одновременно, поэтому выбирайте самые важные.
Для приоритизации рисков используют:
- Матрицу рисков.
- Качественный анализ и оценка рисков.
- Количественный анализ.
- Категоризацию согласно источнику, например, риски от поставщиков серьезнее и важнее, чем риски от процесса управления проектом.
Матрица рисков поможет оценить и увидеть рискованные моменты, наиболее опасные для проекта.
Каждый риск оценивают по двум параметрам:
- Вероятность наступления по шкале от 1 (крайне маловероятно) до 5 (практически достоверно).
- Масштаб последствий, если риск все-таки наступит:
- Незначительный. Опасность легко смягчается обычным повседневным процессом.
- Небольшой. Задержка до 10% от графика, дополнительные расходы до 10% бюджета.
- Средний. Задержка до 30% графика, дополнительные расходы до 30% бюджета.
- Высокий. Опоздание по срокам до 50%, непредусмотренные расходы бюджета до 50%.
- Крайне высокий. Проекту грозит срыв.
Риски, которые попали в темно-синюю зону, будут наиболее весомыми для результатов проекта, и с ними нужно работать в первую очередь. Возможные угрозы в бирюзовой зоне имеют самый низкий приоритет.
7. Анализируйте риски
После определения приоритетности РМ сам или с рабочей группой, анализирует, на что именно повлияет конкретный риск:
- Бюджет.
- Сроки.
- Качество.
- Цели.
Анализировать нужно даже те угрозы, которые выделили в приоритетные, потому что не бывает такого риска, который влияет абсолютно на все. Сам по себе факт, событие, которое возможно наступит, — это еще не риск. Важен business impact — каким будет влияние, почему конкретное событие будет риском для графика проекта.
Информация, которую РМ с командой проекта соберет в результате такого анализа, поможет найти меры для оптимизации рискованной ситуации.
8. Составьте план реагирования
Если вы просто построили матрицу рисков, но не выбрали никакой стратегии управления, то работа не закончена. Поэтому следующий этап после оценки и анализа — это составить систему реагирования и снижения угроз.
В плане нужно предусмотреть действия для двух сценариев: как предотвращать риски, и что делать, если угрожающий сценарий все-таки осуществился.
Если риск средней степени и его можно предотвратить, разрабатывают план как реакции, так и предотвращения. Для неустранимых рисков с высоким приоритетом создают план действий, рассчитывают, сколько нужно ресурсов и предлагают тому, кто оплачивает проект, заложить резервный фонд с запасом времени и бюджета.
Для снижения риска нужно выбрать стратегию или комбинацию разных стратегий. Самые распространенные:
- Избегание (уклонение). Изменяют план проекта для исключения угрозы, например, уточняют требования, ограничивают функциональность, избегают новых технологий или подходов.
- Перемещение или передача. Распределяют негативные последствия и ответственности за реагирование на сторону, которая лучше с этим справится. Стратегия эффективна по отношению к финансовым рискам.
- Контроль и смягчение. Понижают или устраняют вероятности и/или последствия риска до приемлемого уровня, например, делают больше тестов или привлекают дополнительные ресурсы.
- Принятие. Признают, что некоторые существующие риски невозможно уменьшить, их нельзя избежать, нельзя перенести и/или они не имеют достаточно высокого приоритета/влияния на расходование ресурсов.
9. Зарегистрируйте проектные риски
Всю проведенную работу нужно зафиксировать в Реестре (журнале) рисков. Регистрация всех угроз поможет следить за актуальной ситуацией на любом этапе проекта и не забыть о каком-то риске.
Для успешного управления угрозами в журнале фиксируют следующие атрибуты:
- Ключевая причина.
- Вероятность наступления.
- Влияние на задачи проекта.
- Уровень или категория риска.
- Ответная стратегия реагирования.
- Имя или роль risk owner-а.
10. Отслеживайте связанные задачи
Отслеживать нужно не только сам риск и то событие, которое служит триггером, но и все задачи, связанные с риском.
Контролировать задачи поможет:
- Risk burndown chart.
- Визуализация в системах управления проектами, task менеджерах.
- Ведение учета в Excel.
Будет ошибкой составить на старте реестр возможных угроз и больше не возвращаться к нему. Активность менеджера проекта в контроле рисков должна продолжаться на каждом этапе проекта. Совместно с командой PM систематически отслеживает и пересматривает данные: изменился ли приоритет рисков, какие обстоятельства стали более или менее вероятными.
Инструмент для управления проектами
Планируйте и контролируйте проекты с помощью диаграммы Ганта.
Попробуйте бесплатноСделайте управление рисками проекта надежным и эффективным
Работа с рисками входит в задачи управления проектом в рамках менеджмента качества. Однако часто в компаниях не хотят тратить время на управление обстоятельствами, которые «могут и не случиться».
Поэтому когда проектный менеджер предлагает команде разные подходы к вероятным угрозам, его воспринимают как «пораженца». Любые техники, матрицы, документы для уменьшения рисков могут быть отвергнуты, потому что решат, будто РМ изначально настраивается на провал.
На самом деле, внедряя контроль рисков в проект, управленец ответственно подходит не только к запланированной деятельности, но и к событиям, которые могут случиться.
Стратегия состоит не только в том, чтобы обезопасить работу и предотвратить новые риски внутри проекта. Главная задача — определить, что может пойти не так, и смягчить влияние возможных угроз на процесс.
Постоянный контроль рисков однозначно должен стать частью подготовки к запуску, элементом планирования и регулярных встреч в каждом проекте, независимо от его продолжительности.
Часто задаваемые вопросы про управление рисками в проекте
-
Управление рисками в проекте — это постоянный процесс идентификации, анализа и реакции на возможные угрозы, которые могут повлиять на достижение целей бизнеса. Эта непрерывная деятельность направлена на сокращение негативных последствий и рост позитивных возможностей. Контроль рисков помогает командам быть готовыми к неопределенности и принимать обоснованные решения.
-
Управление рисками заключается в идентификации возможных угроз, в качественном и количественном анализе, а также организации реагирования на риски. На практике — это создание реестра рисков с оценкой их вероятности. Главная цель такого управления — проактивно контролировать неопределенность, а не реагировать на проблемы постфактум.
-
Риски следует формулировать четко, используя принцип «причина — событие — последствие». Формулировка риска должна быть конкретной, измеримой и понятной всем заинтересованным сторонам. Важно избегать расплывчатых описаний.