Примеры проектных документов

Список рисков: вероятности и последствия.

Таким образом, стоит обратить внимание на риски, попавшие в красную зону. Эти риски требуют немедленного реагирования.

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

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

На основании информации, полученной от качественного анализа рисков, осуществляется обновление реестра рисков. Обновленный реестр рисков включает:

1. список приоритетов рисков проекта;
2. риски, сгруппированные по категориям;
3. список рисков, требующих немедленного реагирования;
4. список рисков для дополнительного анализа и реагирования;
5. список рисков с низким приоритетом, нуждающихся в наблюдении;
6. тренды результатов качественного анализа рисков. Процедура количественного анализа рисков

В рамках процедуры количественной оценки рисков строится диаграмма "Дерево решений" (см. рис.).

увеличить изображение

В результате построения дерева решений получаем обновленный вариант расписания.

Составляется список приоритетных оцененных рисков, на которые обращается особое внимание.

На основании информации, полученной от количественного анализа рисков, осуществляется обновление реестра рисков. Обновленный реестр рисков включает:

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

Процедура планирования реагирования на риски

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

1. стратегия реагирования на негативные риски - уклонение, снижение, передача;
2. стратегия реагирования на позитивные риски - принятие;
3. стратегия реагирования на непредвиденные обстоятельства - передача, снижение.

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

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

Процедура мониторинга и управление рисками

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

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

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

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

Руководителем проекта со стороны "Big&Co" к 5 числу месяца, следующего за отчетным, подготавливается отчет по результатам аудита рисков и анализа резервов для предоставления компании "Client Company".

По мере надобности обновляется матрица вероятностей и последствий.

План управления изменениями

План управления изменениями описывает управление изменениями и, в частности , управление конфигурациями.

Процедуры управления изменениями

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

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

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

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

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

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

"Big&Co" в рамках данного Проекта несет ответственность только за то, что явным образом описано в настоящем Содержании проекта как задачи или ответственность компании "Big&Co".

Процедуры управления конфигурацией проекта

1. Идентификация объектов конфигурации

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

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

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

   • Тип объекта
   • Имя объекта
   • Идентификация программы или проекта
   • Номер версии
   • Номер ревизии (ревизия для конкретной версии)
   • Данные о готовности
2. Контроль конфигураций

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

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

Для определения статуса конфигурации автоматически генерируется отчет о статусе. Отчет включает следующую информацию.

• Время возникновения каждого изменения.
• Время определения каждого объекта конфигурации.
• Описательная информация о каждом объекте конфигурации.
• Статус запросов на изменения (принят, отклонен, ожидает выполнения).
• Описание статусов.
• Описательная информация о каждом запросе на изменение.
• Статус изменения.
• Описательная информация о каждом изменении. 4. Аудит конфигураций

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

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

Форма отчета по результатам аудита конфигураций