Пример использования дерева решения

Таблица 9.1. Сравнение стратегий реагирования на риски
Классификация рисков	Уклонение от риска	Передача риска	Принятие риска	Снижение последствий вероятности возникновения риска
Риски, связанные с масштабом проекта	Разделение проекта на несколько под-проектов. Сокращение функционального и географического объема проекта	Разделение проекта на несколько под-проектов, выделение пилотного проекта по подсистемам (ограниченного масштаба)	Увеличение трудоемкости работ и стоимости проекта	Детальный анализ каждого этапа работ, взаимодействие участников, организация работ	Детально проработанная программа качества, отработанное управление конфигурацией проекта, специальные процедуры взаимодействия участников
Риски, связанные с недостаточным опытом в сфере ИТ	Реализация только не технологической части проекта, передача технологической части проекта другой компании	Согласование с заказчиком большинства проектных документов, согласование всех изменений в функциональности системы	Увеличение трудоемкости работ и стоимости проекта	Проведение обучения пользователей, включая руководство, соблюдение технологии работы	Разработка и утверждение концепции проекта на возможно более ранней его стадии
Технические риски проекта	Использование более надежных	Документально зафиксированная	Увеличение трудоемко-	Строгий отбор проектной команды по	Использование стандартов пред-
	технологических решений	персональная ответственность участников проекта, документальное фиксирование всех изменений в процессе проекта	сти работ и стоимости проекта	квалификационным критериям. Обучение участников проекта технологии проектных работ, инструментальным средствам	приятия для проектных работ, разработка стандартов проекта
Организационные риски проекта	Значительное сужение объема проекта и превращение его в чисто инфраструктурный технологический проект	Включение представителей заказчика в рабочие группы	Увеличение трудоемкости работ и стоимости проекта	Обучение участников проекта(курс "управление проектом"), тренинги команды, как можно более полная формализация деятельности	Включение в команду администратора проекта, детальное распределение ролей в проекте
Операционные риски проекта	Изменение модели оплаты компании-исполнителю: перевод на оплату по результату оценки качества реализованного решения	Акт сдачи заказчику любого документа. Фиксирование отсутствия претензий заказчика по каждому этапу работы	Увеличение трудоемкости работ и стоимости проекта	Многократное тестирование созданных продуктов, тщательная экспертиза документов	Строгое выполнение процедур программы качества

Торговая компания открывает новый магазин, который должен быть укомплектован новейшим оборудованием. Оборудование производят два конкурирующих поставщика (П1 и П2), объявивших одну и ту же дату появления на рынке нового оборудования. Для увеличения эффективности работы компания планирует осуществить внедрение ИС класса ERP. Разработаны три варианта расписания внедрения информационной системы: вариант 1, вариант 2, вариант 3. Длительность проекта рассматривается как параметр первостепенной важности. Расписание внедрения ИС зависит от поставки и монтажа оборудования. Команда проекта оценила вероятность того, что поставщик 1 (П1) или поставщик 2 (П2) поставит нужное оборудование первым. Анализ информации о прежних разработках поставщиков позволил предположить, что поставщик 1 поставит на рынок новое оборудование с вероятностью 60%; соответственно, для поставщика 2 эта вероятность будет равна 40%.

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

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

1. ожидаемая длительность для случайного узла А: (80 дней* 0,6) + (70 дней *0,4) = 76 дней;

2. ожидаемая длительность для случайного узла Б: (70 дней * 0,6) + (75 дней *0,4) = 72 дня;

3. ожидаемая длительность для случайного узла В: (75 дней * 0,6) + (80 дней *0,4) = 77 дней

Результат дерева решений - вариант расписания с наименьшей продолжительностью, равной 72 дням.

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

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

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

Существует четыре типовые стратегии реагирования на появление негативных рисков: уклонение, передача, принятие и снижение.

1. Уклонение от риска

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

2. Передача риска

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

3. Принятие риска

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

4. Снижение риска

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

10.3. Подтверждение содержания проекта

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

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

· описание содержания проекта;

· словарь ИСР;

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

· результаты поставки.

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

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

11. Управление в фазе проектирования

Формирование детальных планов стадии проектирования. Уточнение плана управления проектом. Руководство и управление исполнением проекта. Обеспечение качества проекта. Осуществление интегрированного управления изменениями. Матрица координации изменений. Запрос на внесение изменений. Журнал изменений проекта. Обеспечение качества проекта на этапе проектирования. Обеспечение целостности элементов конфигурации. Обновление реестра рисков на фазе проектирования. Набор команды проекта. Описание процесса. Планирование инфраструктуры для команды проекта. Оценка и управление персоналом проекта. Определение уточненных требований проекта. Мониторинг содержания и объема проекта. Управление требованиями проекта. Оценка потребности в обучении пользователей.

11.1. Формирование детальных планов стадии проектирования

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

Иерархическое расписание - метод разработки детальных планов расписания. Это многоуровневое расписание с переменной степенью детализации на каждом уровне [18]. На этапе планирования иерархическое расписание строится на основе ИСР.

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

Рис. 10.1. Пример иерархического расписания (адаптировано из [18])

Рис. 10.2. Схема процедуры корректировки фактического выполнения плана работ

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

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

11.2. Уточнение плана управления проектом

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

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

Дата добавления: 2015-04-29