Управление ИТ-проектами: теоретические основы, задачи и решения

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

Разбить на страницы
Показывать лекцию целиком

Риск проекта - неопределенное событие или условие, которое может повлиять как положительно, так и отрицательно на результаты, цели, сроки, стоимость, содержание или качество проекта [1, стр. 397].

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

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

Классификации рисков - структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации. Классификации рисков предназначены для нескольких целей. При проведении мозгового штурма классификации рисков облегчают одновременную работу с большим числом рисков, предоставляя подходящий способ группирования схожих рисков. Классифицировать риски можно с помощью составления их иерархической структуры или составив перечень различных составляющих проекта (процессы, команда, окружение и пр.). На рисунке 9.1 представлена высокоуровневая классификация источников рисков проектов, используемая в Microsoft Solutions Framework (MSF) [13].

(рис 9.1) Классификация источников риска

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

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

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

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

  • Эскалация. Стратегия реагирования на риск, при которой команда признает, что риск находится вне сферы ее влияния, и передает ответственность за риск на более высокий уровень организации, где управление риском будет более результативным.
  • Уклонение от риска. Стратегия состоит в полном исключении воздействия риска на проект за счет изменений характера проекта или плана управления проектом. Некоторые риски, возникающие на ранних стадиях проекта, например, из-за отсутствия четкого определения требований заказчика, можно избежать, затратив дополнительное время и увеличив трудозатраты на их выявление. Однако стратегия уклонения от риска не может полностью исключить риск
  • Передача риска. Стратегия передачи риска также исключает угрозу риска путем передачи негативных последствий риска с ответственностью за реагирование на риск на третью сторону. Передача риска обычно сопровождается выплатой премии за риск стороне, принимающей на риск и ответственность за его управление. Сам риск при этом не устраняется. Условия передачи ответственности за определенные риски третьей стороне могут определяться в контракте.
  • Принятие риска. Стратегия означает решение команды не уклоняться от риска. При пассивном принятии риска команда ничего не предпринимает в отношении риска и в случае его возникновения разрабатывает способ его обхода или исправления последствий. При активном принятии риска план действий разрабатывается до того, как риск может произойти и называется планом действий в непредвиденных обстоятельствах.
  • Снижение риска. Стратегия снижение риска предполагает усилие, направленное на понижение вероятности и/или последствий риска до приемлемых пределов. В стратегии снижения используется включение в план проекта дополнительной работы, которая будет выполняться независимо от возникновения риска, как например, проведение дополнительного тестирования функциональности информационной системы, разработка прототипа системы, дополнительное подключение к работе опытных сотрудников.
  • Управление рисками проекта включает в себя следующие процессы:

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

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

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

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

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

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

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

    Источниками информации при планировании являются:

  • Устав проекта
  • План управления проектом (Все компоненты плана)
  • Документы проекта (Реестр заинтересованных сторон)
  • Факторы среды предприятия
  • Активы процессов организации
  • Результатом планирования является План управления рисками - компонент плана управления проектом, который может включать все следующие элементы:

    Стратегия управления рисками. (Описывает общий подход к управлению рисками в рамках данного проекта).

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

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

    Финансирование. (Определяет объем финансирования, необходимого для исполнения операций, относящихся к управлению рисками проекта, а также устанавливает протоколы применения резервов на возможные потери и управленческого резерва).

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

    Категории рисков. (Определяются средства для распределения индивидуальных рисков по группам. Общепринятым способом структурирования категорий рисков является использование иерархической структуры рисков (risk breakdown structure, RBS), которая представляет собой иерархическое представление потенциальных источников риска (пример см. на рис. 9.2).

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

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

    (рис 9.2) Фрагмент примерной иерархической структуры рисков (рис 9.3) Пример матрицы вероятности и воздействия со схемой оценки в баллах

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

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

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

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

    Участниками процесса по идентификации рисков могут быть: руководитель проекта; члены команды проекта; заказчики; эксперты в предметной области, не входящие в команду проекта; конечные пользователи; другие руководители проектов; руководители производственных подразделений; заинтересованные стороны и эксперты по управлению рисками в организации. В таблице 9-1 представлена информация для организации процесса идентификации: инструменты и методы, входные документы и результат процесса.

    Входы, выходы и инструментальные средства процесса идентификации рисков
    Входные документы Методы и инструменты Выходные документы
  • План управления проектом

  • План управления требованиями
  • План управления расписанием
  • План управления стоимостью
  • План управления качеством
  • План управления ресурсами
  • План управления рисками
  • Базовый план по содержанию
  • Базовое расписание
  • Базовый план по стоимости
  • Документы проекта

  • Журнал допущений
  • Оценки стоимости
  • Оценки длительности
  • Журнал проблем
  • Реестр извлеченных уроков
  • Документация по требованиям
  • Требования к ресурсам
  • Реестр заинтересованных сторон
  • Соглашения
  • Закупочная документация
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных:

  • Мозговой штурм
  • Контрольные списки
  • Интервью
  • Метод Дельфи
  • Карточки Кроуфорда
  • Метод аналогии
  • Анализ данных

  • Анализ первопричины
  • Анализ допущений и ограничений
  • SWOT-анализ
  • Анализ документов
  • Навыки межличностных отношений и работы с командой

  • Фасилитация
  • Справочные списки
  • Совещания
  • Реестр рисков:

  • Список идентифицированных рисков
  • Потенциальные владельцы риска
  • Список возможных мер реагирования на риски
  • Отчет по рискам
  • Обновления документов проекта:

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

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

    Инструментальные средства, входы и выходы качественного анализа рисков
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Документы проекта

  • Журнал допущений
  • Реестр рисков
  • Реестр заинтересованных сторон
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных

  • Интервью
  • Анализ данных

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

  • Фасилитация
  • Категоризация рисков
  • Отображение данных

  • Матрица вероятности и воздействия
  • Иерархические схемы
  • Совещания
  • Обновления документов проекта

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

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

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

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

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

    Выходы количественного анализа рисков используются в качестве входов процесса планирования реагирования на риски. Входы и выходы этого процесса показаны в таблице 9.3.

    Инструментальные средства, входы и выходы количественного анализа рисков
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Базовый план по содержанию
  • Базовое расписание
  • Базовый план по стоимости
  • Документы проекта

  • Журнал допущений
  • Основа для оценок
  • Оценки стоимости
  • Прогнозы стоимости
  • Оценки длительности
  • Список контрольных событий
  • Требования к ресурсам
  • Реестр рисков
  • Отчет по рискам
  • Прогнозы в отношении расписания
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных

  • Интервью
  • Навыки межличностных отношений и работы с командой

  • Фасилитация
  • Представления неопределенности
  • Анализ данных

  • Имитации
  • Анализ чувствительности
  • Анализ дерева решений
  • Диаграммы влияния
  • Обновления документов проекта. Отчет по рискам:

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

    Планирование реагирования на риски: входы, инструменты и методы, выходы
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления ресурсами
  • План управления рисками
  • Базовый план по стоимости
  • Документы проекта

  • Реестр извлеченных уроков
  • Расписание проекта
  • Распределение обязанностей членов команды проекта
  • Календари ресурсов
  • Реестр рисков
  • Отчет по рискам
  • Реестр заинтересованных сторон
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных

  • Интервью
  • Навыки межличностных отношений и работы с командой

  • Фасилитация
  • Стратегии работы с угрозами
  • Стратегии работы с благоприятными возможностями
  • Стратегии реагирования на возможные потери
  • Стратегии для совокупного риска проекта
  • Анализ данных

  • Анализ альтернатив
  • Сравнительный анализ затрат и выгод
  • Принятие решений

  • Анализ решений на основе множества критериев
  • Запросы на изменения
  • Обновления плана управления проектом

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

  • Журнал допущений
  • Прогнозы стоимости
  • Реестр извлеченных уроков
  • Расписание проекта
  • Распределение обязанностей членов команды проекта
  • Реестр рисков
  • Отчет по рискам
  • В таблице 9-5 приведен ряд стратегий реагирования на риски: стратегии работы с угрозами; стратегии для благоприятных возможностей; стратегии для совокупного риска проекта.

    Стратегии реагирования на риски
    Стратегии работы с угрозами Стратегии для благоприятных возможностей Стратегии для совокупного риска проекта
  • Эскалация
  • Уклонение
  • Передача
  • Снижение
  • Принятие
  • Эскалация
  • Использование
  • Разделение
  • Увеличение
  • Принятие
  • Уклонение
  • Использование
  • Передача/Разделение
  • Снижение/Увеличение
  • Принятие
  • Осуществление реагирования на риски - процесс выполнения согласованных планов реагирования на риски, осуществляется на протяжении всего проекта.

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

    Осуществление реагирования на риски: входы, инструменты и методы, выходы
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Документы проекта

  • Реестр извлеченных уроков
  • Реестр рисков
  • Отчет по рискам
  • Активы процессов организации
  • Экспертная оценка
  • Навыки межличностных отношений и работы с командой

  • Влияние
  • Информационная система управления проектами
  • Запросы на изменения
  • Обновления документов проекта

  • Журнал проблем
  • Реестр извлеченных уроков
  • Распределение обязанностей членов команды проекта
  • Реестр рисков
  • Отчет по рискам
  • Мониторинг рисков - процесс мониторинга выполнения согласованных планов реагирования на риски, отслеживания идентифицированных рисков, выявления и анализа, осуществляется на протяжении всего проекта.

    Цель процесса - обеспечение актуальной информацией о подверженности совокупному риску проекта и об индивидуальных рисках проекта. Входы и выходы процесса представлены в таблице 9.7.

    Мониторинг рисков: входы, инструменты и методы
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Документы проекта

  • Журнал проблем
  • Реестр извлеченных уроков
  • Реестр рисков
  • Отчет по рискам
  • Данные об исполнении работ
  • Отчеты об исполнении работ
  • Анализ данных

  • Анализ технического исполнения
  • Анализ резервов
  • Аудиторские проверки
  • Совещания
  • Информация об исполнении работ
  • Запросы на изменения
  • Обновления плана управления проектом

  • Любой компонент
  • Обновления документов проекта

  • Журнал допущений
  • Журнал проблем
  • Реестр извлеченных уроков
  • Реестр рисков
  • Отчет по рискам
  • Обновления активов процессов организации
  • Задача процесса - осуществлять постоянный контроль хода работ по проекту для выявления новых, изменившихся или устаревших индивидуальных рисков проекта, а также изменений в уровне совокупного риска проекта.

    Результат мониторинга рисков используется с целью:

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

    Задание 1.

    1.1. На основе информации о проекте в кейсе (№3) и, при необходимости, дополнительных допущений идентифицируйте и классифицируйте риски (6-8 шт.) данного проекта.

    1.2. Используя предложенный ниже шаблон ( таблица 9.8), разработайте подход к управлению идентифицированными в предыдущем пункте рисками.

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

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

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

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

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

    На этапе планирования, предшествующем реализации проекта, руководителем проекта были идентифицированы следующие риски, а также экспертным методом установлены вероятность и последствия их наступления (таблица 9.9).

    Матрица описания рисков на этапе планирования
    Описание риска Вероятность наступления Последствие
    1 (A) Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ 20% Задержка даты завершения проекта на 1,4 месяца
    2 (B) Некорректная настройка системы (несоответствие первоначальным требованиям) 20% Отказ представителей компании Client Company акцептовать выполненные работы
    3 (C) Сопротивление конечных пользователей, саботаж проектных работ и неприятие результатов проекта 50% Увеличение стоимости проекта на €300 тыс.

    На выполнение проекта отводится 14 месяцев. Объем денежных средств, выделенных компанией на реализацию проекта, составляет € 2 млн.

    На этапе планирования экспертами для всего проекта была разработана эталонная шкала оценки влияния рисков ( Таблица 9.10):

    Шкала оценки влияния рисков
    Количественная характеристика -> Объект влияния (вниз) Низкий Средний Высокий Очень высокий
    <0,1 0.2 0.4 0.8
    Стоимость Увеличение <5% Увеличение 5-10% Увеличение 11-20% >20% увеличение
    Сроки Увеличение сроков <5% Увеличение 5-10% Увеличение 11-20% >20% увеличение
    Качество Незначительные изменения Изменения не требуют согласования Неприемлемое для клиента изменение Достижение конечных результатов невозможно

    Постановка задачи (качественный анализ рисков)

  • Постройте матрицу вероятности-воздействия рисков. Используя шкалу оценки влияния риска, выделите на матрице 4 ранга воздействия: низкий, средний, высокий и очень высокий.
  • Используя шкалу оценки влияния риска, отобразите на матрице вероятностей и последствий указанные риски и определите их приоритетность.
  • Инвентаризация рисков на этапе реализации показала, что вероятности-воздействие наступления рисков изменились. Отобразите на матрице вероятности-воздействия миграцию рисков по результатам произведенной инвентаризации ( таблица 9-11).
  • Матрица описания рисков на этапе реализации
    Описание риска Вероятность наступления Последствие
    1(A) Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ 20% Задержка даты завершения проекта на 4,2 месяца
    2(B) Некорректная настройка системы (несоответствие первоначальным требованиям) 40% Достижение конечных результатов невозможно
    3(C) Сопротивление конечных пользователей, саботаж проектных работ и неприятие результатов проекта 20% Увеличение стоимости проекта на €400 тыс.

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

  • Процедура планирования управления рисками
  • Процедура идентификации рисков
  • Процедура качественного анализа рисков
  • Процедура планирования реагирования на риски
  • Процедура мониторинга и управление рисками
  • Кейс 1

    Проект по внедрению ERP-системы на промышленном предприятии.

    Компания "Client Company", пройдя фазу первоначального роста и достигнув пика своего развития, стала испытывать затруднения. За последние 1,5 года рентабельность продаж "Client Company" упала с 14% до 11%, а рост операционных издержек составил 25%.

    С целью решения задачи повышения эффективности операционной деятельности компании и создания информационно-технологического фундамента для дальнейшего развития бизнеса, высшим менеджментом "Client Company" было принято решение о внедрении ERP-системы. Руководство компании рассчитывает, что внедряемая ИТ-система станет эффективным инструментом поддержки принятия эффективных и своевременных управленческих решений.

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

  • Создание интегрированного ИТ-решение на базе гибкой, тиражируемой и быстро реагирующей на изменения платформы с единым пользовательским интерфейсом
  • Поддержка совместного использования информации различными подразделениями "Client Company" и иерархически-ролевого доступа к ней
  • Повышение прозрачности функционирования и управляемости компании за счет обеспечения информации в необходимом аналитическом разрезе для принятия оперативных управленческих решений руководством компании
  • Повышение эффективности использования основных активов и ресурсов компании
  • Сокращение административно-управленческих косвенных затрат в том числе на закрытие финансовой отчетности за период (месяц, квартал, год) и на ведение параллельного учета по МСФО.
  • Следующие функциональные области должны быть охвачены проектом внедрения:

  • Управление финансами
  • Управление человеческими ресурсами
  • Управление входящей и внутренней логистикой
  • Управление производством
  • Управление исходящей логистикой
  • Управление реализацией готовой продукции и взаимодействием с клиентами
  • Управление административно-хозяйственными операциями
  • На выполнение проекта отводится 14 месяцев с датой окончания не позднее начала 4 квартала 2020 года. Объем денежных средств, выделенных компанией на реализацию проекта, составляет € 2 млн.

    Реализация проекта будет произведена силами стороннего исполнителя, системного интегратора "Bigamp;Co".

    Кейс 2

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

    Компания ИБИС-АйТи выиграла конкурс на оказание услуг по автоматизации обеспечивающих процессов производственного цикла государственной организации ГКУ "ЗАКАЗЧИК". Деятельность организации связана с осуществлением мероприятий по функционированию и администрированию парковых комплексов и зон отдыха жителей города.

    В настоящее время все процессы ГКУ "ЗАКАЗЧИК", связанные с формированием бюджета, сбором потребностей, планированием, ведением контрактов и формированием отчетных форм, не автоматизированы. Контроль исполнения работ осуществляется вручную с использованием Excel-таблиц. При существующей организации труда возникают многочисленные задержки при согласовании документации, потеря данных, что увеличивает сроки исполнения, снижает эффективность использования выделенных бюджетных средств и качество работы организации. Формирование в "ручном" режиме большого количества отчетов требует повышенных трудозатрат сотрудников.

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

    В Системе должен быть реализован следующий функционал:

  • сбор потребностей от структурных подразделений
  • согласование и утверждение плана заявок и контрактной документации
  • финансовое планирование
  • ведение и контроль исполнения контрактов
  • взаимодействие с внешними организациями, в том числе, поставщиками (подрядчиками, исполнителями)
  • формирование отчетов по финансовой и иной деятельности.
  • Автоматизация будет проведена для всех подразделений ГКУ "ЗАКАЗЧИК", в том числе -Финансового Управления, Контрактной Службы, Административно-хозяйственного управления, Бухгалтерии и Контрольного Управления.

    Согласно заключенному контракту, Компания ИБИС-АйТи должна поставить Базовое ПО Системы, провести инсталляцию и настройку. Ресурсы для размещения Системы предоставляет ГКУ "ЗАКАЗЧИК". Результатом оказания услуг по контракту должны стать автоматизированные процессы и настроенная в соответствии с требованиями Заказчика Система, прошедшая опытную эксплуатацию в ГКУ "ЗАКАЗЧИК".

    Цена контракта составляет 15 млн. ?.

    Услуги в рамках исполнения контракта должны быть оказаны в течение 160 (Ста шестидесяти) календарных дней с даты подписания контракта. При этом во время первого этапа должно быть выполнено обследование объекта автоматизации и разработано частное техническое задание (ЧТЗ) на Систему. Развертывание базового ПО, разработка эксплуатационной документации и выполнение пуско-наладочных работ запланировано на второй этап. Во время третьего этапа будут проведены наполнение Системы данными и настройка для работы в текущем году. Проведение предварительных испытаний и опытной эксплуатации с участием в ней пользователей и администраторов будет выполнено во время четвертого завершающего этапа. Продолжительность первого и второго этапов составляет по 10 дней, третьего и четвертого - 60 и 80 дней соответственно.

    Кейс 3

    Для практических заданий лекции 8 "Управление рисками проекта"

    Системный интегратор "Bigamp;Co" был выбран в качестве генерального подрядчика по проекту внедрения информационной системы (ИС) в компании "Client Company". В соответствии с договором, работы проводились в три этапа:

  • Выбор решения и поставка ПО
  • Внедрение ИС
  • Постпроектное сервисное обслуживание
  • Руководителем второго этапа работ был назначен Василий из числа менеджеров проектов "Bigamp;Co".

    К моменту назначения Василия первый этап был уже завершен: определен класс и вендор внедряемой ИС, ПО поставлено в соответствии со спецификацией. Для выполнения работ второго этапа со стороны "Bigamp;Co" были выделены архитектор ИТ-решения и консультант по внедрению ИС. Вместе с ними Василий разработал план-график предстоящих работ, согласовал его с представителями "Client Company" и внутри "Bigamp;Co". В соответствии с утвержденным планом было произведено проектирование ИС, разработано и согласовано с заказчиком техническое задание. Компания "Client Company" предоставила рабочие места команде Василия, после чего консультант по внедрению приступил к работе по настройке системы.

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

    Приступив к работам, консультант по внедрению "Bigamp;Co" обнаружил и сразу проинформировал Василия, что специалисты "Client Company" не могут уделять проектным работам достаточно времени, ссылаясь на недоукомплектованность штата, повышенную загрузку операционными задачами и низкий приоритет проекта. Так же от команды исполнителя стали поступать жалобы на сбои в работе персональных компьютеров. Выполнение проектных работ стало затягиваться, возникла опасность срыва сроков, отношение сотрудников "Client Company" к проекту ухудшилось. Василий переговорил с представителем компании-заказчика и получил заверения, что меры будут приняты. Вскоре стабильная работа ПК команды исполнителя была восстановлена, однако, ситуация с сотрудниками "Client Company" не изменилась. Василий повторно проинформировал "Client Company" и снова получил ответ, что проблема будет решена в кратчайшие сроки.

    Представитель "Client Company" сообщил Василию, что один из серверов вышел из строя, и заказчик не планирует производить его замену в ближайшее время. Проведя повторную оценку готовности аппаратного обеспечения заказчика, архитектор ИТ-решения компании "Bigamp;Co" предоставил Василию отчёт, в котором говорилось о существовании вероятности того, что после начала промышленной эксплуатации системы, сервера заказчика могут не выдержать возросшей нагрузки. Василий в свою очередь передал отчёт на верхний уровень принятия решений.

    Консультант по внедрению тем временем докладывал, что на объектах он часть времени бездействует, ожидая, пока технические специалисты "Client Company" освободятся и смогут выполнить свою часть работ, предусмотренную согласованным планом. Без их участия выполнить настройки ИС было невозможно, так как консультант "Bigamp;Co" не имел прав доступа к модулю настройки внедряемой ИС. Предложение о предоставлении этих полномочий было не раз отвергнуто представителями "Client Company". В этих условиях Василий принял решение о передаче проблемы на уровень старшего менеджера из отдела продаж Петра. Доложив Петру о ситуации, он предложил собрать рабочее совещание с привлечением высшего руководства "Client Company", чтобы найти выход. Петр высказал сомнение в пользе такого совещания и предоставил Василию полную свободу, посоветовав решать проблему самостоятельно.

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

    Компромисс был найден, но:

  • По причине выявленной некорректной работы, внедряемой ИС, отставание по срокам ликвидировать не удалось, а неприятие проекта сотрудниками "Client Company" усугубилось
  • За время проведения второго этапа были официально приняты новые ставки и порядок налогообложения, которые не были учтены во внедряемой ИС
  • Ресурсы заметную часть времени использовались неэффективно
  • Вследствие затягивания работ, возникли накладки с планированием ресурсов и сбои по срокам в других проектах
  • В связи с падением выручки "Client Company", вызванным неблагоприятной экономической ситуацией, финансирование проекта было урезано.

    Страницы:

    Риск проекта - неопределенное событие или условие, которое может повлиять как положительно, так и отрицательно на результаты, цели, сроки, стоимость, содержание или качество проекта [1, стр. 397].

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

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

    Классификации рисков - структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации. Классификации рисков предназначены для нескольких целей. При проведении мозгового штурма классификации рисков облегчают одновременную работу с большим числом рисков, предоставляя подходящий способ группирования схожих рисков. Классифицировать риски можно с помощью составления их иерархической структуры или составив перечень различных составляющих проекта (процессы, команда, окружение и пр.). На рисунке 9.1 представлена высокоуровневая классификация источников рисков проектов, используемая в Microsoft Solutions Framework (MSF) [13].

    (рис 9.1) Классификация источников риска

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

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

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

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

  • Эскалация. Стратегия реагирования на риск, при которой команда признает, что риск находится вне сферы ее влияния, и передает ответственность за риск на более высокий уровень организации, где управление риском будет более результативным.
  • Уклонение от риска. Стратегия состоит в полном исключении воздействия риска на проект за счет изменений характера проекта или плана управления проектом. Некоторые риски, возникающие на ранних стадиях проекта, например, из-за отсутствия четкого определения требований заказчика, можно избежать, затратив дополнительное время и увеличив трудозатраты на их выявление. Однако стратегия уклонения от риска не может полностью исключить риск
  • Передача риска. Стратегия передачи риска также исключает угрозу риска путем передачи негативных последствий риска с ответственностью за реагирование на риск на третью сторону. Передача риска обычно сопровождается выплатой премии за риск стороне, принимающей на риск и ответственность за его управление. Сам риск при этом не устраняется. Условия передачи ответственности за определенные риски третьей стороне могут определяться в контракте.
  • Принятие риска. Стратегия означает решение команды не уклоняться от риска. При пассивном принятии риска команда ничего не предпринимает в отношении риска и в случае его возникновения разрабатывает способ его обхода или исправления последствий. При активном принятии риска план действий разрабатывается до того, как риск может произойти и называется планом действий в непредвиденных обстоятельствах.
  • Снижение риска. Стратегия снижение риска предполагает усилие, направленное на понижение вероятности и/или последствий риска до приемлемых пределов. В стратегии снижения используется включение в план проекта дополнительной работы, которая будет выполняться независимо от возникновения риска, как например, проведение дополнительного тестирования функциональности информационной системы, разработка прототипа системы, дополнительное подключение к работе опытных сотрудников.
  • Управление рисками проекта включает в себя следующие процессы:

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

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

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

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

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

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

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

    Источниками информации при планировании являются:

  • Устав проекта
  • План управления проектом (Все компоненты плана)
  • Документы проекта (Реестр заинтересованных сторон)
  • Факторы среды предприятия
  • Активы процессов организации
  • Результатом планирования является План управления рисками - компонент плана управления проектом, который может включать все следующие элементы:

    Стратегия управления рисками. (Описывает общий подход к управлению рисками в рамках данного проекта).

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

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

    Финансирование. (Определяет объем финансирования, необходимого для исполнения операций, относящихся к управлению рисками проекта, а также устанавливает протоколы применения резервов на возможные потери и управленческого резерва).

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

    Категории рисков. (Определяются средства для распределения индивидуальных рисков по группам. Общепринятым способом структурирования категорий рисков является использование иерархической структуры рисков (risk breakdown structure, RBS), которая представляет собой иерархическое представление потенциальных источников риска (пример см. на рис. 9.2).

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

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

    (рис 9.2) Фрагмент примерной иерархической структуры рисков (рис 9.3) Пример матрицы вероятности и воздействия со схемой оценки в баллах

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

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

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

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

    Участниками процесса по идентификации рисков могут быть: руководитель проекта; члены команды проекта; заказчики; эксперты в предметной области, не входящие в команду проекта; конечные пользователи; другие руководители проектов; руководители производственных подразделений; заинтересованные стороны и эксперты по управлению рисками в организации. В таблице 9-1 представлена информация для организации процесса идентификации: инструменты и методы, входные документы и результат процесса.

    Входы, выходы и инструментальные средства процесса идентификации рисков
    Входные документы Методы и инструменты Выходные документы
  • План управления проектом

  • План управления требованиями
  • План управления расписанием
  • План управления стоимостью
  • План управления качеством
  • План управления ресурсами
  • План управления рисками
  • Базовый план по содержанию
  • Базовое расписание
  • Базовый план по стоимости
  • Документы проекта

  • Журнал допущений
  • Оценки стоимости
  • Оценки длительности
  • Журнал проблем
  • Реестр извлеченных уроков
  • Документация по требованиям
  • Требования к ресурсам
  • Реестр заинтересованных сторон
  • Соглашения
  • Закупочная документация
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных:

  • Мозговой штурм
  • Контрольные списки
  • Интервью
  • Метод Дельфи
  • Карточки Кроуфорда
  • Метод аналогии
  • Анализ данных

  • Анализ первопричины
  • Анализ допущений и ограничений
  • SWOT-анализ
  • Анализ документов
  • Навыки межличностных отношений и работы с командой

  • Фасилитация
  • Справочные списки
  • Совещания
  • Реестр рисков:

  • Список идентифицированных рисков
  • Потенциальные владельцы риска
  • Список возможных мер реагирования на риски
  • Отчет по рискам
  • Обновления документов проекта:

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

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

    Инструментальные средства, входы и выходы качественного анализа рисков
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Документы проекта

  • Журнал допущений
  • Реестр рисков
  • Реестр заинтересованных сторон
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных

  • Интервью
  • Анализ данных

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

  • Фасилитация
  • Категоризация рисков
  • Отображение данных

  • Матрица вероятности и воздействия
  • Иерархические схемы
  • Совещания
  • Обновления документов проекта

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

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

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

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

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

    Выходы количественного анализа рисков используются в качестве входов процесса планирования реагирования на риски. Входы и выходы этого процесса показаны в таблице 9.3.

    Инструментальные средства, входы и выходы количественного анализа рисков
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Базовый план по содержанию
  • Базовое расписание
  • Базовый план по стоимости
  • Документы проекта

  • Журнал допущений
  • Основа для оценок
  • Оценки стоимости
  • Прогнозы стоимости
  • Оценки длительности
  • Список контрольных событий
  • Требования к ресурсам
  • Реестр рисков
  • Отчет по рискам
  • Прогнозы в отношении расписания
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных

  • Интервью
  • Навыки межличностных отношений и работы с командой

  • Фасилитация
  • Представления неопределенности
  • Анализ данных

  • Имитации
  • Анализ чувствительности
  • Анализ дерева решений
  • Диаграммы влияния
  • Обновления документов проекта. Отчет по рискам:

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

    Планирование реагирования на риски: входы, инструменты и методы, выходы
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления ресурсами
  • План управления рисками
  • Базовый план по стоимости
  • Документы проекта

  • Реестр извлеченных уроков
  • Расписание проекта
  • Распределение обязанностей членов команды проекта
  • Календари ресурсов
  • Реестр рисков
  • Отчет по рискам
  • Реестр заинтересованных сторон
  • Факторы среды предприятия
  • Активы процессов организации
  • Экспертная оценка
  • Сбор данных

  • Интервью
  • Навыки межличностных отношений и работы с командой

  • Фасилитация
  • Стратегии работы с угрозами
  • Стратегии работы с благоприятными возможностями
  • Стратегии реагирования на возможные потери
  • Стратегии для совокупного риска проекта
  • Анализ данных

  • Анализ альтернатив
  • Сравнительный анализ затрат и выгод
  • Принятие решений

  • Анализ решений на основе множества критериев
  • Запросы на изменения
  • Обновления плана управления проектом

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

  • Журнал допущений
  • Прогнозы стоимости
  • Реестр извлеченных уроков
  • Расписание проекта
  • Распределение обязанностей членов команды проекта
  • Реестр рисков
  • Отчет по рискам
  • В таблице 9-5 приведен ряд стратегий реагирования на риски: стратегии работы с угрозами; стратегии для благоприятных возможностей; стратегии для совокупного риска проекта.

    Стратегии реагирования на риски
    Стратегии работы с угрозами Стратегии для благоприятных возможностей Стратегии для совокупного риска проекта
  • Эскалация
  • Уклонение
  • Передача
  • Снижение
  • Принятие
  • Эскалация
  • Использование
  • Разделение
  • Увеличение
  • Принятие
  • Уклонение
  • Использование
  • Передача/Разделение
  • Снижение/Увеличение
  • Принятие
  • Осуществление реагирования на риски - процесс выполнения согласованных планов реагирования на риски, осуществляется на протяжении всего проекта.

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

    Осуществление реагирования на риски: входы, инструменты и методы, выходы
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Документы проекта

  • Реестр извлеченных уроков
  • Реестр рисков
  • Отчет по рискам
  • Активы процессов организации
  • Экспертная оценка
  • Навыки межличностных отношений и работы с командой

  • Влияние
  • Информационная система управления проектами
  • Запросы на изменения
  • Обновления документов проекта

  • Журнал проблем
  • Реестр извлеченных уроков
  • Распределение обязанностей членов команды проекта
  • Реестр рисков
  • Отчет по рискам
  • Мониторинг рисков - процесс мониторинга выполнения согласованных планов реагирования на риски, отслеживания идентифицированных рисков, выявления и анализа, осуществляется на протяжении всего проекта.

    Цель процесса - обеспечение актуальной информацией о подверженности совокупному риску проекта и об индивидуальных рисках проекта. Входы и выходы процесса представлены в таблице 9.7.

    Мониторинг рисков: входы, инструменты и методы
    Входные документы Методы и инструменты Выходы процесса
  • План управления проектом

  • План управления рисками
  • Документы проекта

  • Журнал проблем
  • Реестр извлеченных уроков
  • Реестр рисков
  • Отчет по рискам
  • Данные об исполнении работ
  • Отчеты об исполнении работ
  • Анализ данных

  • Анализ технического исполнения
  • Анализ резервов
  • Аудиторские проверки
  • Совещания
  • Информация об исполнении работ
  • Запросы на изменения
  • Обновления плана управления проектом

  • Любой компонент
  • Обновления документов проекта

  • Журнал допущений
  • Журнал проблем
  • Реестр извлеченных уроков
  • Реестр рисков
  • Отчет по рискам
  • Обновления активов процессов организации
  • Задача процесса - осуществлять постоянный контроль хода работ по проекту для выявления новых, изменившихся или устаревших индивидуальных рисков проекта, а также изменений в уровне совокупного риска проекта.

    Результат мониторинга рисков используется с целью:

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

    Задание 1.

    1.1. На основе информации о проекте в кейсе (№3) и, при необходимости, дополнительных допущений идентифицируйте и классифицируйте риски (6-8 шт.) данного проекта.

    1.2. Используя предложенный ниже шаблон ( таблица 9.8), разработайте подход к управлению идентифицированными в предыдущем пункте рисками.

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

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

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

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

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

    На этапе планирования, предшествующем реализации проекта, руководителем проекта были идентифицированы следующие риски, а также экспертным методом установлены вероятность и последствия их наступления (таблица 9.9).

    Матрица описания рисков на этапе планирования
    Описание риска Вероятность наступления Последствие
    1 (A) Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ 20% Задержка даты завершения проекта на 1,4 месяца
    2 (B) Некорректная настройка системы (несоответствие первоначальным требованиям) 20% Отказ представителей компании Client Company акцептовать выполненные работы
    3 (C) Сопротивление конечных пользователей, саботаж проектных работ и неприятие результатов проекта 50% Увеличение стоимости проекта на €300 тыс.

    На выполнение проекта отводится 14 месяцев. Объем денежных средств, выделенных компанией на реализацию проекта, составляет € 2 млн.

    На этапе планирования экспертами для всего проекта была разработана эталонная шкала оценки влияния рисков ( Таблица 9.10):

    Шкала оценки влияния рисков
    Количественная характеристика -> Объект влияния (вниз) Низкий Средний Высокий Очень высокий
    <0,1 0.2 0.4 0.8
    Стоимость Увеличение <5% Увеличение 5-10% Увеличение 11-20% >20% увеличение
    Сроки Увеличение сроков <5% Увеличение 5-10% Увеличение 11-20% >20% увеличение
    Качество Незначительные изменения Изменения не требуют согласования Неприемлемое для клиента изменение Достижение конечных результатов невозможно

    Постановка задачи (качественный анализ рисков)

  • Постройте матрицу вероятности-воздействия рисков. Используя шкалу оценки влияния риска, выделите на матрице 4 ранга воздействия: низкий, средний, высокий и очень высокий.
  • Используя шкалу оценки влияния риска, отобразите на матрице вероятностей и последствий указанные риски и определите их приоритетность.
  • Инвентаризация рисков на этапе реализации показала, что вероятности-воздействие наступления рисков изменились. Отобразите на матрице вероятности-воздействия миграцию рисков по результатам произведенной инвентаризации ( таблица 9-11).
  • Матрица описания рисков на этапе реализации
    Описание риска Вероятность наступления Последствие
    1(A) Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ 20% Задержка даты завершения проекта на 4,2 месяца
    2(B) Некорректная настройка системы (несоответствие первоначальным требованиям) 40% Достижение конечных результатов невозможно
    3(C) Сопротивление конечных пользователей, саботаж проектных работ и неприятие результатов проекта 20% Увеличение стоимости проекта на €400 тыс.

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

  • Процедура планирования управления рисками
  • Процедура идентификации рисков
  • Процедура качественного анализа рисков
  • Процедура планирования реагирования на риски
  • Процедура мониторинга и управление рисками
  • Кейс 1

    Проект по внедрению ERP-системы на промышленном предприятии.

    Компания "Client Company", пройдя фазу первоначального роста и достигнув пика своего развития, стала испытывать затруднения. За последние 1,5 года рентабельность продаж "Client Company" упала с 14% до 11%, а рост операционных издержек составил 25%.

    С целью решения задачи повышения эффективности операционной деятельности компании и создания информационно-технологического фундамента для дальнейшего развития бизнеса, высшим менеджментом "Client Company" было принято решение о внедрении ERP-системы. Руководство компании рассчитывает, что внедряемая ИТ-система станет эффективным инструментом поддержки принятия эффективных и своевременных управленческих решений.

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

  • Создание интегрированного ИТ-решение на базе гибкой, тиражируемой и быстро реагирующей на изменения платформы с единым пользовательским интерфейсом
  • Поддержка совместного использования информации различными подразделениями "Client Company" и иерархически-ролевого доступа к ней
  • Повышение прозрачности функционирования и управляемости компании за счет обеспечения информации в необходимом аналитическом разрезе для принятия оперативных управленческих решений руководством компании
  • Повышение эффективности использования основных активов и ресурсов компании
  • Сокращение административно-управленческих косвенных затрат в том числе на закрытие финансовой отчетности за период (месяц, квартал, год) и на ведение параллельного учета по МСФО.
  • Следующие функциональные области должны быть охвачены проектом внедрения:

  • Управление финансами
  • Управление человеческими ресурсами
  • Управление входящей и внутренней логистикой
  • Управление производством
  • Управление исходящей логистикой
  • Управление реализацией готовой продукции и взаимодействием с клиентами
  • Управление административно-хозяйственными операциями
  • На выполнение проекта отводится 14 месяцев с датой окончания не позднее начала 4 квартала 2020 года. Объем денежных средств, выделенных компанией на реализацию проекта, составляет € 2 млн.

    Реализация проекта будет произведена силами стороннего исполнителя, системного интегратора "Bigamp;Co".

    Кейс 2

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

    Компания ИБИС-АйТи выиграла конкурс на оказание услуг по автоматизации обеспечивающих процессов производственного цикла государственной организации ГКУ "ЗАКАЗЧИК". Деятельность организации связана с осуществлением мероприятий по функционированию и администрированию парковых комплексов и зон отдыха жителей города.

    В настоящее время все процессы ГКУ "ЗАКАЗЧИК", связанные с формированием бюджета, сбором потребностей, планированием, ведением контрактов и формированием отчетных форм, не автоматизированы. Контроль исполнения работ осуществляется вручную с использованием Excel-таблиц. При существующей организации труда возникают многочисленные задержки при согласовании документации, потеря данных, что увеличивает сроки исполнения, снижает эффективность использования выделенных бюджетных средств и качество работы организации. Формирование в "ручном" режиме большого количества отчетов требует повышенных трудозатрат сотрудников.

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

    В Системе должен быть реализован следующий функционал:

  • сбор потребностей от структурных подразделений
  • согласование и утверждение плана заявок и контрактной документации
  • финансовое планирование
  • ведение и контроль исполнения контрактов
  • взаимодействие с внешними организациями, в том числе, поставщиками (подрядчиками, исполнителями)
  • формирование отчетов по финансовой и иной деятельности.
  • Автоматизация будет проведена для всех подразделений ГКУ "ЗАКАЗЧИК", в том числе -Финансового Управления, Контрактной Службы, Административно-хозяйственного управления, Бухгалтерии и Контрольного Управления.

    Согласно заключенному контракту, Компания ИБИС-АйТи должна поставить Базовое ПО Системы, провести инсталляцию и настройку. Ресурсы для размещения Системы предоставляет ГКУ "ЗАКАЗЧИК". Результатом оказания услуг по контракту должны стать автоматизированные процессы и настроенная в соответствии с требованиями Заказчика Система, прошедшая опытную эксплуатацию в ГКУ "ЗАКАЗЧИК".

    Цена контракта составляет 15 млн. ?.

    Услуги в рамках исполнения контракта должны быть оказаны в течение 160 (Ста шестидесяти) календарных дней с даты подписания контракта. При этом во время первого этапа должно быть выполнено обследование объекта автоматизации и разработано частное техническое задание (ЧТЗ) на Систему. Развертывание базового ПО, разработка эксплуатационной документации и выполнение пуско-наладочных работ запланировано на второй этап. Во время третьего этапа будут проведены наполнение Системы данными и настройка для работы в текущем году. Проведение предварительных испытаний и опытной эксплуатации с участием в ней пользователей и администраторов будет выполнено во время четвертого завершающего этапа. Продолжительность первого и второго этапов составляет по 10 дней, третьего и четвертого - 60 и 80 дней соответственно.

    Кейс 3

    Для практических заданий лекции 8 "Управление рисками проекта"

    Системный интегратор "Bigamp;Co" был выбран в качестве генерального подрядчика по проекту внедрения информационной системы (ИС) в компании "Client Company". В соответствии с договором, работы проводились в три этапа:

  • Выбор решения и поставка ПО
  • Внедрение ИС
  • Постпроектное сервисное обслуживание
  • Руководителем второго этапа работ был назначен Василий из числа менеджеров проектов "Bigamp;Co".

    К моменту назначения Василия первый этап был уже завершен: определен класс и вендор внедряемой ИС, ПО поставлено в соответствии со спецификацией. Для выполнения работ второго этапа со стороны "Bigamp;Co" были выделены архитектор ИТ-решения и консультант по внедрению ИС. Вместе с ними Василий разработал план-график предстоящих работ, согласовал его с представителями "Client Company" и внутри "Bigamp;Co". В соответствии с утвержденным планом было произведено проектирование ИС, разработано и согласовано с заказчиком техническое задание. Компания "Client Company" предоставила рабочие места команде Василия, после чего консультант по внедрению приступил к работе по настройке системы.

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

    Приступив к работам, консультант по внедрению "Bigamp;Co" обнаружил и сразу проинформировал Василия, что специалисты "Client Company" не могут уделять проектным работам достаточно времени, ссылаясь на недоукомплектованность штата, повышенную загрузку операционными задачами и низкий приоритет проекта. Так же от команды исполнителя стали поступать жалобы на сбои в работе персональных компьютеров. Выполнение проектных работ стало затягиваться, возникла опасность срыва сроков, отношение сотрудников "Client Company" к проекту ухудшилось. Василий переговорил с представителем компании-заказчика и получил заверения, что меры будут приняты. Вскоре стабильная работа ПК команды исполнителя была восстановлена, однако, ситуация с сотрудниками "Client Company" не изменилась. Василий повторно проинформировал "Client Company" и снова получил ответ, что проблема будет решена в кратчайшие сроки.

    Представитель "Client Company" сообщил Василию, что один из серверов вышел из строя, и заказчик не планирует производить его замену в ближайшее время. Проведя повторную оценку готовности аппаратного обеспечения заказчика, архитектор ИТ-решения компании "Bigamp;Co" предоставил Василию отчёт, в котором говорилось о существовании вероятности того, что после начала промышленной эксплуатации системы, сервера заказчика могут не выдержать возросшей нагрузки. Василий в свою очередь передал отчёт на верхний уровень принятия решений.

    Консультант по внедрению тем временем докладывал, что на объектах он часть времени бездействует, ожидая, пока технические специалисты "Client Company" освободятся и смогут выполнить свою часть работ, предусмотренную согласованным планом. Без их участия выполнить настройки ИС было невозможно, так как консультант "Bigamp;Co" не имел прав доступа к модулю настройки внедряемой ИС. Предложение о предоставлении этих полномочий было не раз отвергнуто представителями "Client Company". В этих условиях Василий принял решение о передаче проблемы на уровень старшего менеджера из отдела продаж Петра. Доложив Петру о ситуации, он предложил собрать рабочее совещание с привлечением высшего руководства "Client Company", чтобы найти выход. Петр высказал сомнение в пользе такого совещания и предоставил Василию полную свободу, посоветовав решать проблему самостоятельно.

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

    Компромисс был найден, но:

  • По причине выявленной некорректной работы, внедряемой ИС, отставание по срокам ликвидировать не удалось, а неприятие проекта сотрудниками "Client Company" усугубилось
  • За время проведения второго этапа были официально приняты новые ставки и порядок налогообложения, которые не были учтены во внедряемой ИС
  • Ресурсы заметную часть времени использовались неэффективно
  • Вследствие затягивания работ, возникли накладки с планированием ресурсов и сбои по срокам в других проектах
  • В связи с падением выручки "Client Company", вызванным неблагоприятной экономической ситуацией, финансирование проекта было урезано.

    Вернуться к учебному плану