Механика проектного управления. Методология управления

Анализ рисков

Анализ рисков проводится в разрезе качественных и количественных показателей рисков.

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

• вероятности возникновения риска;

• степени влияния (воздействия) риска на достижение целей проекта (в случае реализации риска);

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

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

Для расстановки приоритетов рисков используются следующие ранги: критический риск («бордовая зона»), значительный риск («красная зона»), умеренный риск («желтая зона») и незначительный риск («зеленая зона»). В зависимости от ранга риска используется та или иная стратегия реагирования.

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

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

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

План реагирования на риски проекта разрабатывается Руководителем проекта совместно с Руководителями проектных групп и Кураторами проекта и предполагает последовательное выполнение следующих действий:

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

2) для каждого риска проекта выбирается стратегия реагирования (или комбинация из различных стратегий). Иногда целесообразно определить основную и резервную стратегии реагирования;

3) для каждой выбранной стратегии разрабатываются конкретные действия (мероприятия) по ее реализации – предупреждающие и/или корректирующие.

Предупреждающие действия (мероприятия) – перечень конкретных действий (мероприятий), которые должны предпринять участники проекта для предотвращения реализации (снижения последствий реализации) риска. Корректирующие действия (мероприятия) – перечень конкретных действий (мероприятий), которые должны предпринять участники проекта для изменения тех или иных факторов риска.

Основными стратегиями реагирования на риски являются:

1. Стратегии реагирования на негативные риски (угрозы):

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

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

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

2. Стратегии реагирования на позитивные риски (благоприятные возможности):

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

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

2.3. Усиление. Стратегия направлена на повышение вероятности возникновения и/или положительного воздействия благоприятной возможности. Повышение вероятности может достигаться, например, путем целенаправленного усиления условий появления благоприятной возможности.

3. Общая стратегия реагирования на угрозы и благоприятные возможности:

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

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

4. Стратегия реагирования на непредвиденные обстоятельства:

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

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

Мониторинг и администрирование рисков

Операции мониторинга и администрирования рисков являются непрерывными и выполняются на протяжении всего жизненного цикла проекта в рамках процедуры комплексного план-факт анализа.

В рамках данной операции выполняются следующие действия:

1) пересмотр рисков (выявление новых рисков, отслеживание уже возникших рисков, а также тех рисков, которые уже выявлены и находятся под постоянным наблюдением);

2) анализ отклонений и резервов;

3) аудит рисков (проверка и выполнение операций реагирования на риски, а также оценка их эффективности);

4) совещания по текущему состоянию (статусу) проекта.

1. Пересмотр рисков

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

2. Анализ отклонений и резервов

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

Анализ резервов проводится с целью определения адекватности соответствия резервов проекта оставшимся рискам по состоянию на текущий момент времени.

3. Аудит рисков

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

4. Совещания по текущему состоянию (статусу) проекта

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

3.1.2. Управление проблемными ситуациями проекта

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

– выявление и анализ проблемных ситуаций;

– принятие решений по проблемным ситуациям;

– исполнение принятых решений по разрешению проблемных ситуаций.

Выявление и анализ проблемных ситуаций

Проблемная ситуация может быть выявлена следующими основными способами:

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

• из обращения (жалобы) заказчиков/подрядчиков/партнеров.

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

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

Если проблемная ситуация связана с ранее выявленным риском, то вся информация, сформированная при управлении данным риском, используется для анализа проблемной ситуации.

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

1) Принятие решения по проблемной ситуации

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

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

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

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

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

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

Распространению проблемной ситуации на уровень Куратора проекта подлежат все проблемные ситуации, которые не удалось решить в рамках проектной команды и затрагивающее интересы Заказчика/Функционального заказчика.

При распространении проблемной ситуации Руководитель проекта заносит в Карту проблемных ситуаций все сведения, которые необходимы для принятия решения (текущий статус работ по проекту, предпринятые действия, возможные варианты решения проблемы и т.п.).

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

Принятое решение фиксируется в протоколе заседания ОС.

Распространение нерешенных проблемных ситуаций на уровень Управляющего совета.

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

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

Принятое решение фиксируется в протоколе заседания УС.

2) Исполнение принятого решения

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

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

3.8. Управление качеством проекта

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

Исходя из требований к результатам проекта, лучших практик, собственных наработок, требований законодательства и т. п. определяются требования к уровню качества результатов проекта. Уровень качества – степень, в которой свойства, а также неотъемлемые или установленные характеристики результата проекта (продукта или услуги), демонстрируют, что этот результат отвечает ожиданиям или заявленным потребностям, требованиям или спецификациям (критериям качества). Требуемый уровень качества результатов проекта достигается за счет исполнения процедур внешнего и внутреннего контроля качества (контроль качества – процесс мониторинга фактически полученных результатов, позволяющий установить, соответствуют ли они критериям качества, и, в случае выявления несоответствий, определить способы их устранения) и проведения следующих типовых мероприятий:

• проведение регулярных проверок полученных результатов на предмет их соответствия критериям качества;

• оперативное информирование заинтересованных лиц о потенциальных проблемах и рисках, связанных с качеством;

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

• предоставление последовательной отчетности о статусе проекта на протяжении всего жизненного цикла проекта.

1. Внешний контроль качества.

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

Контроль качества может осуществляться в следующих формах:

• анализ документации проекта;

• интервью с ключевыми участниками проекта;

• анализ результатов на соответствие их критериям качества;

• непосредственное участие в работе органов управления проектом, участие в заседаниях / совещания / встречах.

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

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

2. Внутренний контроль качества.

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

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

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

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

Описание основных операций группы управления качеством проекта (сгруппированные по фазам управления) приводится в Табл. 3.9.

Таблица 3.9. Операции группы управления качеством проекта

3.9. Управление закупками и контрактами проекта

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

Исходя из требований к результатам проекта, с учетом Плана-графика проекта формируются предварительный перечень контрагентов и предварительный план закупок проекта. План закупок проекта – проектный документ, содержащий перечень товаров и/или услуг, которые должны быть приобретены (закуплены и поставлены) в рамках проекта, а также информация о контрагенте (планируемом контрагенте) и планируемые сроки поставки. Контрагент – сторона, принявшая обязательство по договору и противопоставляемая другой стороне договора. Договор (контракт) – соглашение двух или более лиц (физических и/или юридических) – контрагентов (сторон договора), устанавливающее, изменяющее или прекращающее их права и обязанности. Договор, как правило, состоит из общей и содержательной частей. Договором также именуется документ, в котором это соглашение выражено. Общая часть договора – часть текста договора, включающая следующие разделы: Преамбула (или вводная часть); Предмет договора; Дополнительные условия договора; Прочие условия договора. Содержательная часть договора – часть текста договора, содержащая приложения и дополнительные соглашения к договору, например, Задание (техническое задание) на выполнение работ по договору; Протокол соглашения о договорной цене; Расчёт договорной цены; Календарный график выполнения работ по договору и др. Закупка – приобретение товаров и/или услуг для определенных нужд (целей). Поставка – передача товара во владение покупателя в соответствии с условиями договора; покупатель получает возможность осуществлять полный контроль над товаром. Вручение товаросопроводительных документов рассматривается как передача самого товара. Поставка, как правило, производится за счет продавца. План закупок проекта подлежит регулярному уточнению и детализации в рамках процесса управления интеграцией проекта (см. п. 4.).

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

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

По факту завершения проекта Руководитель проекта проводит закрытие контрактов с контрагентами в соответствии с действующими процедурами Процесса управления контрактами.

Описание основных операций группы управления закупками и контрактами проекта (сгруппированные по фазам управления) приводится в Табл. 3.10.

Табл. 3.10. Операции группы управления закупками и контрактами проекта

3.10. Управление заинтересованными лицами проекта

Целью операций группы управления заинтересованными лицами (ЗЛ) проекта является обеспечение постоянной вовлеченности в проект (на требуемом уровне) ключевых заинтересованных лиц проекта.

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

Для каждого заинтересованного лица необходимо определить его ожидания, потребности, интересы, степень влияния и потенциального воздействия на успех проекта. На основе собранной информации проводится качественный анализ и категорирование заинтересованных лиц по следующим критериям: 1) уровень полномочий (степень влияния) в проекте: низкий, средний, высокий; 2) уровень заинтересованности в результатах проекта: низкий, средний, высокий; 3) уровень вовлеченности в проект: «неосведомлённое» (заинтересованное лицо не осведомлено о проекте); «сопротивляющееся» (заинтересованное лицо осведомлено о проекте и сопротивляется вовлечению в проект (незаинтересованно в успехе проекта)); «нейтральное» (заинтересованное лицо осведомлено о проекте, не сопротивляется вовлечению в проект, но безразлично к достижению результатов); «поддерживающее» (заинтересованное лицо вовлечено в проект и поддерживает достижение его результатов); «лидирующее» (заинтересованное лицо активно вовлечено в проект и заинтересованно в его успехе). Исходя из полученных результатов выбирается целевая стратегия работы с заинтересованным лицом (см. Табл. 3.10). Результаты анализа фиксируется в Реестре заинтересованных лиц проекта.

Таблица 3.11. Матрица сценариев работы с заинтересованными лицами

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