Планирование управления рисками должно быть завершено на ранней стадии планирования проекта, поскольку оно крайне важно для успешного выполнения других процессов. План управления рисками проекта разрабатывается на основе внутренних документов предприятия, а также контрактов с внешними заинтересованными сторонами.
Процедура идентификации рисков должна проводиться регулярно на протяжении жизненного цикла ИТ-проекта для выявления упущенных и новых образовавшихся потенциальных рисков. Мероприятия по выявлению рисков могут привязываться к временному графику (например, быть ежедневными, еженедельными или ежемесячными) или вехам проекта.
После формирования плана управления рисками начинается этап идентификации рисков, на котором определяются риски, способные повлиять на проект, и документируются характеристики этих рисков. Идентификация рисков – это итеративный процесс, который периодически повторяется на всем протяжении проекта, поскольку в рамках его жизненного цикла могут обнаруживаться новые риски. Поэтому процедура идентификации рисков должна проводиться регулярно на протяжении реализации проекта для выявления упущенных и новых образовавшихся потенциальных рисков. В идентификации рисков должно быть задействовано как можно больше участников: менеджеров проекта, заказчиков, пользователей, независимых специалистов.
В рамках процесса идентификации рисков ИТ-проекта необходимо:
• определить, какие риски могут повлиять на проект;
• обеспечить итеративный процесс выявления рисков;
• организовать методы идентификации и совещания по проекту;
• анализировать все возможные допущения и ограничения;
• анализировать сильные и слабые стороны, угрозы и возможности;
• обеспечить своевременное и полное документирование рисков проекта;
• обеспечить четкие и своевременные коммуникации.
В идентификации рисков должно быть задействовано как можно больше участников: менеджеров проекта, заказчиков, пользователей, независимых специалистов, – поскольку требуется понимание миссии проекта, его предметной области, целей заказчика, инвестора и других заинтересованных лиц.
Для сбора информации о рисках могут применяться различные подходы. Среди этих подходов наиболее распространены:
1) обзор документации;
2) метод мозгового штурма;
3) метод Дельфи (Delphi);
4) SWOT-анализ;
5) интервью (опросы экспертов);
6) контрольные списки;
7) анализ предположений/сценариев;
8) причинно-следственные диаграммы;
9) структурирование рисков с использованием структурной декомпозиции риска.
Обзор документации. Метод используется для первоначального ознакомления с проектом и предполагает проведение обзора существующих документов группой управления рисками проекта, включает структурированный анализ плана проекта и имеющихся предложений (ограничений) как на уровне всего проекта, так и на уровне отдельных работ.
Исходные данные для выявления и описания характеристик рисков могут браться из разных источников. В первую очередь это база знаний организации. Информация о выполнении прежних проектов может быть доступна в архивах предыдущих проектов. Следует помнить, что проблемы завершенных и выполняемых проектов – это, как правило, риски в новых проектах.
Другим источником данных о рисках проекта может служить разнообразная информация из открытых источников, научных работ, маркетинговая аналитика и другие исследовательские работы в данной области. Наконец, многие форумы по программированию могут дать бесценную информацию о возникших ранее проблемах в похожих проектах (рис. 9).
Среди документов, которые могут быть эффективно использованы с целью идентификации рисков для максимально полного списка рисков, предлагаются следующие документы:
• устав проекта;
• структурная декомпозиция работ;
• описание продукта;
• расписание проекта;
• предполагаемые затраты и сроки;
• ресурсный план;
• план поставок;
• список предположений и ограничений.
Дополнительно может использоваться документация предыдущих проектов и доступная внешняя информация – коммерческие базы данных, учебные пособия, специализированные издания, открытые публикации по похожим проектам и прочее.
При анализе планов проекта проводится анализ соответствия задач по плану договорным документам и ранее принятым соглашениям, соответствия выделяемого времени масштабам задач, возможности управлять и контролировать работы по представленному плану, анализ процедур взаимодействия, методологий и подходов к работе и порядка выполнения работ.
Рис. 9. Процесс выявления рисков согласно методологии MSF
Каждый проект задумывается и разрабатывается на основании ряда гипотез, сценариев и допущений. Как правило, в описании содержания проекта перечисляются принятые допущения – факторы, которые для целей планирования считаются верными, реальными или определенными без привлечения доказательств. Неопределенность в допущениях проекта следует также обязательно рассматривать в качестве потенциального источника возникновения рисков проекта. Анализ допущения позволяет идентифицировать риски проекта, происходящие от неточности, несовместимости или неполноты допущений.
Метод мозгового штурма. Метод «мозгового штурма» – наиболее распространенный метод идентификации рисков. Цель – составить перечень возможных рисков, которые позднее могут быть отобраны в процессе окончательного формирования списка рисков. При использовании этого метода организуются встречи с наиболее квалифицированными специалистами, которые высказывают свои идеи по рискам проекта.
На первом этапе все члены команды называют риски, которые кажутся им наиболее актуальными. Все предложения записываются без обсуждения, это продолжается до тех пор, пока есть идеи, которые можно записать, или до наступления определенного срока. Встреча может оказаться более удачной, если участники подготовятся заранее, выбрав определенные категории рисков. На втором этапе происходит обсуждение предложенных рисков. Оставляют только те риски, которые команда признала интересными для дальнейшего рассмотрения. Встречи проходят без перерыва и без комментариев по поводу суждения каждого – споры и замечания не допускаются. Затем риски группируются по типам и их характеристикам, им даются определения.
Основным недостатком этого метода является то, что на встречах участники не имеют возможности выступить анонимно, что может повлиять на качество результата, в случае если участник боится выступить с идеей, обратной мнению начальника или более авторитетного лидера.
