10 Золотых Правил Работы с Рисками на Проекте

Аудиоверсия:

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

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

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

Работа с рисками проекта: 10 важных правил

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

1. Сделайте управление рисками частью проекта

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

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

Некоторые компании игнорируют вопрос возможных неприятностей и «реагируют на проблемы по мере поступления». Из-за этого вся система проекта подвергается опасности, становится малоэффективной.

Стандартно, работа по нейтрализации угроз состоит из 5 шагов:

1. Идентификация возможных рисков.
2. Классификация.
3. Анализ.
4. Составление плана реагирования.
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. Вероятность наступления по шкале от 1 (крайне маловероятно) до 5 (практически достоверно).
2. Масштаб последствий, если риск все-таки наступит:

• Незначительный. Угроза легко смягчается обычным повседневным процессом.
• Небольшой. Задержка до 10% от графика, дополнительные расходы до 10% бюджета.
• Средний. Задержка до 30% графика, дополнительные расходы до 30% бюджета.
• Высокий. Опоздание по срокам до 50%, непредусмотренные расходы бюджета до 50%.
• Крайне высокий. Проект под угрозой срыва.

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

7. Анализируйте риски

После определения приоритетности РМ сам или с рабочей группой, анализирует, на что именно повлияет конкретный риск:

• Бюджет.
• Сроки.
• Качество.
• Цели.

Анализировать нужно даже те угрозы, которые выделили в приоритетные, потому что  не бывает такого риска, который влияет абсолютно на все. Сам по себе факт, событие, которое возможно наступит, — это еще не риск. Важен business impact — каким будет влияние, почему конкретное событие будет риском для проекта.

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

8. Составьте план реагирования

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

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

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

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

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

9. Зарегистрируйте проектные риски

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

Для успешного управления угрозами в журнале фиксируют следующие атрибуты:

• Ключевая причина.
• Вероятность наступления.
• Влияние на проект.
• Уровень или категория риска.
• Ответная стратегия реагирования.
• Имя или роль risk owner-а.

10. Отслеживайте связанные задачи

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

Контролировать задачи поможет:

• Risk burndown chart.
• Визуализация в системах управления проектами, task менеджерах.
• Ведение учета в Excel.

Будет ошибкой составить на старте реестр возможных угроз и больше не возвращаться к нему. Активность менеджера проекта в работе с рисками должна продолжаться на каждом этапе проекта. Совместно с командой PM систематически отслеживает и пересматривает данные: изменился ли приоритет рисков, какие обстоятельства стали более или менее вероятными.

Инструмент для управления проектами

Планируйте и контролируйте проекты с помощью диаграммы Ганта.

Попробуйте бесплатно

В итоге

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

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

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

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

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