Методические основы управления ИТ-проектами

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

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

Устав проекта

"Утверждаю" "Утверждаю"
Председатель управляющего комитета, Генеральный директор "BigCo"
генеральный директор
компании "Client Company"
__________________ Ю.Б. Большова ________________ П.Б. Никитин
"___" __________________ 2009 г. "___" ________________ 2009 г.
.
.
.
.
.
УСТАВ ПРОЕКТА
Внедрение Microsoft Dynamics AX
в компании "Client Company"
.
.
Согласовано:
.
.
Заместитель генерального директора
компании "Client Company"
Канаева Елена Владимировна ______________________
.
.
.
.
.
Руководитель проекта со стороны
компании "Client Company",
начальник отдела БП департамента
информатизации
Бахвалова Евгения Анатольевна ______________________
.
.
.
.
.
Руководитель проекта
со стороны "BigCo"
Захарова Екатерина Павловна ______________________

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

Авторы Генеральный директор компании "Client Company" Большова Ю.Б.
Файл Устав.doc
Создан 14.09.2009 18:32
Последнее редактирование 17.09.2009 18:30
Количество страниц 8
Версия Дата изменения Описание изменения Автор изменения Подпись
01 14.09.2009 Создание проекта устава Большова Ю.Б.
02 17.09.2009 Уточнены сроки проекта Большова Ю.Б.
.
.
.
.

Согласование Замечания

№ Дата поступления Наименование документа Автор замечания Подпись
1.
2.
3.

Обработка замечаний

№ Дата обработки Версия документа, учитывающая замечание Исполнитель Подпись
1.

Бизнес-причины возникновения проекта

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

Потребность во внедрении ERP-системы связана со следующими причинами:

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

    Цели проекта

    Бизнес-цель:Получить инструмент для эффективного принятия управленческих решений.

    Цели проекта:создание и внедрение ERP-системы с целью автоматизации основных бизнес-процессов "Client Company". Срок - до 01.10.2011. Качество - согласно спецификации (требования Заказчика, закрепленные в техническом задании).

    Требования к проекту

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

    Расписание контрольных событий

    Дата начала выполнения проекта: 01.08.2010

    Дата завершения проекта: 01.10.2011.

    Участники проекта

    Компания "Client Company" осуществляет данный проект совместно с компанией "BigCo", выступающей генеральным подрядчиком по проекту.

    Инициатор проекта (спонсор) - генеральный директор компании "Client Company" Большова Ю.Б.

    Заказчик - компания "Client Company".

    Руководители проекта, команда проекта - определены в п. 0.

    Функциональные группы - будут определены в содержании проекта.

    Генеральный подрядчик - "BigCo".

    Лицензоры - Microsoft.

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

    Окружение проекта

  • Факторы внешней среды
  • ? клиенты
  • ? партнеры
  • ? конкуренты
  • ? законодательство
  • ? экономические условия, такие как финансовые показатели и др.
    •
  • Факторы внутренней среды
  • ? политика руководства компании "Client Company"
  • ? отношение персонала компании "Client Company" к проекту
  • ? корпоративная культура "Client Company"
  • ? команда проекта

    • Допущения и ограничения

    Допущения

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

    Ограничения

    Окружение проекта

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

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

    • Технологии

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

  • Microsoft Dynamics AX;
  • Microsoft SQL Server - СУБД, используемая для работы Microsoft Dynamics AX;
  • Локальные ИС - локальные информационные системы Заказчика;
  • Приложения Microsoft Office;
  • Microsoft Visio, ARIS - графические системы для отражения бизнес-процессов ("Как есть" и "Как будет").
    •

    Стоимость проекта

    Совокупная стоимость проекта внедрения ERP-системы для компании "Client Company" составит 2 000 000 евро (без НДС). Данный показатель состоит из стоимости прав пользования ERP-системы (лицензионная составляющая), стоимости консалтинговых услуг и стоимости обучения конечных пользователей.

    Руководитель проекта

    Инициатором (спонсором) проекта является генеральный директор компании "Client Company" Большова Ю.Б..

    Руководителем проекта со стороны компании "Client Company" назначается ведущий специалист департамента информатизации компании "Client Company" Бахвалова Евгения Анатольевна.

    Руководителем проекта со стороны "BigCo" назначается Захарова Екатерина Павловна.

    Полномочия команды управления проектом

    Роль ФИО Контактная информация Должностная ответственность
    Спонсор проекта со стороны компании "Client Company" Большова Юлия Борисовна 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1234)
  • генеральная ответственность за финансовое обеспечение проекта
  • обеспечение контроля внедрения результатов проекта в те бизнес-процессы/отделы, которые входят в сферу влияния проекта
  • принятие окончательного решения при возникновении спорной ситуации
  • утверждение изменений основных параметров проекта, обеспечение при необходимости дополнительного финансирования
  • участие в управлении проектом и своевременное принятие решений, обеспечивающих успешное завершение проекта
  • утверждение подходов к выполнению проекта и прием результатов проекта в соответствии с утвержденными подходами
  • утверждение документов, завершающих этапы работ по проекту, и акта сдачи-приемки работ по договору
    •
    Спонсор проекта со стороны "BigCo" Никитин Павел Борисович Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8123)
  • генеральная ответствен ность за достижение результатов проекта
  • утверждение изменений основных параметров проекта, обеспечение при необходимости дополни тельными людскими ресурсами
  • участие в управлении проектом и своевременное принятие решений, обеспечивающих успешное завершение проекта
  • утверждение подходов к выполнению проекта и прием результатов проекта в соответствии с утвержденными подходами
  • утверждение документов, завершающих этапы работ по проекту, и акта сдачи-приемки работ по договору
    •
    Руководитель проекта со стороны компании "Client Company" Бахвалова Евгения Анатольевна 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1235)
  • обеспечение сохранности проектной документации на электронных и бумажных носителях
  • участие в подготовке общего плана на этапы проекта и детальных планов работ проектных групп на месяц
  • формирование структуры управления
  • разработка проектных процедур
  • оперативное руководство выполнением планов работ проекта
  • проведение оперативных рабочих совещаний
  • выполнение функций председателя на заседаниях оперативного совета
  • организация (подготовка повестки заседаний) заседаний управляющего комитета и оперативного совета
  • решение проблем, возникающих на уровне подразделений проектной группы, и, при необходимости, их вынесение на уровень управляющего комитета
  • представление на оперативном совете еженедельного (ежемесячного) отчета о статусе проекта, управляющему комитету - отчетов о состоянии работ на проекте, контроль своевременности рассылки протоколов заседаний
    •
    Руководитель проекта со стороны "BigCo" Захарова Екатерина Павловна 119018, г. Москва, ул. Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8976)
  • выполнение работ на проекте в полном соответствии с установленными объемом и сроками, контроль качества
  • подготовка общего плана на фазу проекта и детальных планов работ проектных групп на месяц
  • подготовка повестки заседаний оперативных советов и участие в заседаниях оперативного совета
  • решение проблем, возникающих на уровне проектных групп, группы интеграции, и, при необходимости, их вынесение на уровень оперативного совета
  • согласование проектных решений
    •
    Команда исполнителей проекта - предмет дальнейшего уточнения при планировании проекта. Содержание проекта утверждает управляющий комитет

    В сферу общей ответственности руководителей проекта входит:

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

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

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

    Описание содержания проекта будет представлено на рассмотрение управляющего комитета 10 сентября 2009 года руководителем проекта со стороны "BigCo" Захаровой Е.П.

    Приложение. Принятые термины и сокращения

    БП Бизнес-процесс
    КИСУ Корпоративная информационная система управления
    Общество, компания компания "Client Company"

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

    Подготовка документации по решению Microsoft Dynamics AX Утв./ А Согл. / С Исп./ R Разработка дополнительной функциональности Утв./ А Согл. / С Исп./ R Настройка и тестирование миграции данных Исп./ R Интеграционное тестирование Утв./ А Исп./ R Проведение завершающего тестирования Исп./ R Согл. / С Организация тренингов пользователей Исп./ R Переход на новую рабочую среду Утв./ А Исп./ R Проведение опциональных дополнительных тренингов пользователей Согл. / С Исп./ R Проверка корректности функционирования рабочей среды и окончательная настройка системы Согл. / С Исп./ R Приемка системы заказчиком Утв./ А Исп./ R Утв./ А Согл. / С

    Процедуры обеспечения проекта персоналом

    Процедура набора персонала

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

  • Организовать встречу, посвященную началу проекта. Знакомство членов команды друг с другом. Тимбилдинги для развития взаимоотношений. Распределение работы таким образом, чтобы использовать имеющиеся ресурсы и сильные стороны членов команды лучшим образом. 2.
  • Определить роль команды внутри организации. Соотнести процессы и системы с другими проектами и системами. 3.
  • Построить рабочие взаимоотношения внутри команды. 4.
  • Установить и поддерживать общение (в т.ч. используя компьютерные технологии). 5.
  • Учитывать мнение всей команды. 6.
  • Соотнести цели, которые стоят перед каждым из членов команды, с личными предпочтениями и целями. 7.
  • Уменьшить привлечение аутсорсинга для выполнения разовых задач. 8.
  • Поощрять разрешение трудностей в конструктивной манере.
    •

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

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

    Процедура обеспечения безопасности

    В соответствии с Трудовым кодексом регулируется обеспечение безопасности труда. Ответственным за обеспечение безопасности назначается руководитель проекта со стороны Исполнителя.

    План управления коммуникациями

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

    Взаимодействия по вертикали управления внутри одной команды: куратор (спонсор) проекта - руководитель проекта - команда проекта, - должны быть формальными и поддерживаться официальными документами. Взаимодействия руководителей проекта компании "Client Company" и "BigCo" также являются формальными и должны оформляться официальными документами. Допускаются неформальные взаимодействия между кураторами проекта и членами команд проекта от компании "Client Company" и "BigCo". Схема взаимодействия компаний "Client Company" и "BigCo" в проекте представлена на рисунке.

    Схема взаимодействия "Client Company" и "BigCo".

    Предмет коммуникации:Отчеты о проделанной работе

    Цель:Контроль хода выполнения работ

    Частота:Ежедневный, еженедельный и ежемесячный

    Даты начала/завершения:Конец отчетного периода (дня, недели, месяца)

    Формат/средство связи:По электронной почте и в бумажном виде

    Ответственное лицо:Каждый участник команды

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

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

    Процедура предоставления отчетов по исполнению

  • Сбор информации и формирование отчета участниками проекта.
  • Передача отчета участниками команды проекта как со стороны Исполнителя, так и со стороны Заказчика в электронном и бумажном виде вышестоящему руководству.
  • Передача отчета руководителю проекта со стороны Исполнителя или Заказчика.
  • Передача отчета от руководителя проекта со стороны Исполнителя руководителю проекта со стороны Заказчика и наоборот.
  • Формирование и предоставление отчетов руководителями проектов со стороны Заказчика и Исполнителя спонсорам проекта со стороны Заказчика и Исполнителя соответственно.
  • Формирование и предоставление отчетов руководителями проектов руководству своей компаний.
    •

    Процедура распространения информации

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

    Процедура анализа накопленных знаний

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

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

    Ответственным лицом для организации работы с рисками назначается руководитель проекта со стороны компании "BigCo".

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

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

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

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

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

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

    Шкала оценки влияния рисков

    Количественная характеристика Очень низкое Низкое Умеренное Высокое Очень высокое
    Объект влияния 0,05 О,1 0,2 0,4 0,8
    Стоимость Незначительное увеличение Увеличение<5% Увеличение5-10% Увеличение 11-20% >20% увеличение
    Сроки Незначительное увеличение Увеличение сроков <5% Увеличение 5-10% Увеличение 11-20% >20% увеличение
    Качество Изменения незаметны Незначительные изменения Изменения не требуют согласования Неприемлемое для клиента изменение Достижение конечных результатов невозможно

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

    Процедура идентификации рисков

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

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

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

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

    Форма реестра рисков

    № Дата возникновения риска Дата регистрации риска Наименование риска Описание риска Инициатор Причины, вызвавшие риск Последствия Владелец риска Дата окончания действия риска
    1
    2

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

    Вновь выявленные риски вносятся в реестр ассистентом руководителя проекта компании "BigCo"

    Риски, выявляемые на дальнейших этапах проекта, необходимо вносить в Реестр рисков.

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

    Классификация рисков.

    № Категории рисков Риски
    1 Организационные
  • Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ
  • Сопротивление конечных пользователей, неприятие результатов проекта
  • Неполнота, несвоевременность или некорректность бизнес-информации, передаваемой Заказчиком Исполнителю в ходе проекта
  • Сложность эксплуатации системы
    •
    2 Технологические
  • Отсутствие интерфейсов взаимодействия со смежными системами
  • Отказ от использования стандартной функциональности решения и замена ее на самостоятельные разработки
    •
    3 Процессные
  • Изменения структуры компании и/или методов ведения бизнеса
  • Изменение целей, задач и подхода к реализации проекта на поздних стадиях проекта
  • Существенное изменение состава проектной команды со стороны Заказчика или Исполнителя
  • Возникновение ложного представления у заказчика о результатах проекта
    •
    4 Внешние
  • Вероятность нарушения обозначенных условий контракта, отсутствие санкций.
    •
    5 Юридические
  • Вероятность нарушения обозначенных условий контракта, отсутствие санкций.
    •
    6 Методологические
  • Требование чрезмерной конфигурации со стороны Заказчика
  • Незнание методологии
    •

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

    Качественный анализ рисков производится после процесса идентификации рисков.

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

    Матрица вероятностей и последствий

    Последствия
    Вероятность 0,05 0,1 0,2 0,4 0,8
    0,9 0,05 0,09 0,18 0,36 0,72
    0,8 0,04 0,08 0,16 0,32 0,64
    0,7 0,04 0,07 0,14 0,28 0,56
    0,6 0,03 0,06 0,12 0,24 0,48
    0,5 0,03 0,05 0,10 0,20 0,40
    0,4 0,02 0,04 0,08 0,16 0,32
    0,3 0,02 0,03 0,06 0,12 0,24
    0,2 0,01 0,02 0,04 0,08 0,16
    0,1 0,01 0,01 0,02 0,04 0,08

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

    Категории рисков Вероятность Последствия
    Технологические
    Отсутствие интерфейсов взаимодействия со смежными системами 0.2 0.1
    Отказ от использования стандартной функциональности решения и замена ее на самостоятельные разработки 0.2 0.4
    Процессные/ процедурные
    Изменения структуры компании и/или методов ведения бизнеса 0.8 0.2
    Изменение целей, задач и подхода к реализации проекта на поздних стадиях проекта 0.8 0.4
    Существенное изменение состава проектной команды со стороны Заказчика или Исполнителя 0.3 0.4
    Возникновение ложного представления у заказчика о результатах проект 0.6 0.1
    Организационные
    Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ 0.5 0.8
    Сопротивление конечных пользователей, неприятие результатов проекта 0.6 0.2
    Неполнота, несвоевременность или некорректность бизнес-информации, передаваемой Заказчиком Исполнителю в ходе проекта 0.1 0.4
    Сложность эксплуатации системы 0.5 0.2
    Внешние
    Вероятность нарушения обозначенных условий контракта, отсутствие санкций. 0.1 0.1
    Методологические
    Требование чрезмерной конфигурации со стороны Заказчика 0.1 0.8
    Незнание Заказчиком методологии 0.1 0.2
    Юридические
    Вероятность нарушения обозначенных условий контракта, отсутствие санкций 0.1 0.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Определение статуса конфигурации

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

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

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

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

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

    Проведенные изменения Спецификация изменений Соответствие проведенных изменений спецификации Объекты, связанные с изменением Модифицированные объекты Модифицированы ли все связанные с изменением объекты конфигурации?
    .
    .
    Рекомендации по устранению несоответствий
    1.
    Страницы:

    Устав проекта

    "Утверждаю" "Утверждаю"
    Председатель управляющего комитета, Генеральный директор "BigCo"
    генеральный директор
    компании "Client Company"
    __________________ Ю.Б. Большова ________________ П.Б. Никитин
    "___" __________________ 2009 г. "___" ________________ 2009 г.
    .
    .
    .
    .
    .
    УСТАВ ПРОЕКТА
    Внедрение Microsoft Dynamics AX
    в компании "Client Company"
    .
    .
    Согласовано:
    .
    .
    Заместитель генерального директора
    компании "Client Company"
    Канаева Елена Владимировна ______________________
    .
    .
    .
    .
    .
    Руководитель проекта со стороны
    компании "Client Company",
    начальник отдела БП департамента
    информатизации
    Бахвалова Евгения Анатольевна ______________________
    .
    .
    .
    .
    .
    Руководитель проекта
    со стороны "BigCo"
    Захарова Екатерина Павловна ______________________

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

    Авторы Генеральный директор компании "Client Company" Большова Ю.Б.
    Файл Устав.doc
    Создан 14.09.2009 18:32
    Последнее редактирование 17.09.2009 18:30
    Количество страниц 8
    Версия Дата изменения Описание изменения Автор изменения Подпись
    01 14.09.2009 Создание проекта устава Большова Ю.Б.
    02 17.09.2009 Уточнены сроки проекта Большова Ю.Б.
    .
    .
    .
    .

    Согласование Замечания

    № Дата поступления Наименование документа Автор замечания Подпись
    1.
    2.
    3.

    Обработка замечаний

    № Дата обработки Версия документа, учитывающая замечание Исполнитель Подпись
    1.

    Бизнес-причины возникновения проекта

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

    Потребность во внедрении ERP-системы связана со следующими причинами:

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

    Цели проекта

    Бизнес-цель:Получить инструмент для эффективного принятия управленческих решений.

    Цели проекта:создание и внедрение ERP-системы с целью автоматизации основных бизнес-процессов "Client Company". Срок - до 01.10.2011. Качество - согласно спецификации (требования Заказчика, закрепленные в техническом задании).

    Требования к проекту

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

    Расписание контрольных событий

    Дата начала выполнения проекта: 01.08.2010

    Дата завершения проекта: 01.10.2011.

    Участники проекта

    Компания "Client Company" осуществляет данный проект совместно с компанией "BigCo", выступающей генеральным подрядчиком по проекту.

    Инициатор проекта (спонсор) - генеральный директор компании "Client Company" Большова Ю.Б.

    Заказчик - компания "Client Company".

    Руководители проекта, команда проекта - определены в п. 0.

    Функциональные группы - будут определены в содержании проекта.

    Генеральный подрядчик - "BigCo".

    Лицензоры - Microsoft.

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

    Окружение проекта

  • Факторы внешней среды
  • ? клиенты
  • ? партнеры
  • ? конкуренты
  • ? законодательство
  • ? экономические условия, такие как финансовые показатели и др.
    •
  • Факторы внутренней среды
  • ? политика руководства компании "Client Company"
  • ? отношение персонала компании "Client Company" к проекту
  • ? корпоративная культура "Client Company"
  • ? команда проекта

    • Допущения и ограничения

    Допущения

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

    Ограничения

    Окружение проекта

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

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

    • Технологии

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

  • Microsoft Dynamics AX;
  • Microsoft SQL Server - СУБД, используемая для работы Microsoft Dynamics AX;
  • Локальные ИС - локальные информационные системы Заказчика;
  • Приложения Microsoft Office;
  • Microsoft Visio, ARIS - графические системы для отражения бизнес-процессов ("Как есть" и "Как будет").
    •

    Стоимость проекта

    Совокупная стоимость проекта внедрения ERP-системы для компании "Client Company" составит 2 000 000 евро (без НДС). Данный показатель состоит из стоимости прав пользования ERP-системы (лицензионная составляющая), стоимости консалтинговых услуг и стоимости обучения конечных пользователей.

    Руководитель проекта

    Инициатором (спонсором) проекта является генеральный директор компании "Client Company" Большова Ю.Б..

    Руководителем проекта со стороны компании "Client Company" назначается ведущий специалист департамента информатизации компании "Client Company" Бахвалова Евгения Анатольевна.

    Руководителем проекта со стороны "BigCo" назначается Захарова Екатерина Павловна.

    Полномочия команды управления проектом

    Роль ФИО Контактная информация Должностная ответственность
    Спонсор проекта со стороны компании "Client Company" Большова Юлия Борисовна 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1234)
  • генеральная ответственность за финансовое обеспечение проекта
  • обеспечение контроля внедрения результатов проекта в те бизнес-процессы/отделы, которые входят в сферу влияния проекта
  • принятие окончательного решения при возникновении спорной ситуации
  • утверждение изменений основных параметров проекта, обеспечение при необходимости дополнительного финансирования
  • участие в управлении проектом и своевременное принятие решений, обеспечивающих успешное завершение проекта
  • утверждение подходов к выполнению проекта и прием результатов проекта в соответствии с утвержденными подходами
  • утверждение документов, завершающих этапы работ по проекту, и акта сдачи-приемки работ по договору
    •
    Спонсор проекта со стороны "BigCo" Никитин Павел Борисович Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8123)
  • генеральная ответствен ность за достижение результатов проекта
  • утверждение изменений основных параметров проекта, обеспечение при необходимости дополни тельными людскими ресурсами
  • участие в управлении проектом и своевременное принятие решений, обеспечивающих успешное завершение проекта
  • утверждение подходов к выполнению проекта и прием результатов проекта в соответствии с утвержденными подходами
  • утверждение документов, завершающих этапы работ по проекту, и акта сдачи-приемки работ по договору
    •
    Руководитель проекта со стороны компании "Client Company" Бахвалова Евгения Анатольевна 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1235)
  • обеспечение сохранности проектной документации на электронных и бумажных носителях
  • участие в подготовке общего плана на этапы проекта и детальных планов работ проектных групп на месяц
  • формирование структуры управления
  • разработка проектных процедур
  • оперативное руководство выполнением планов работ проекта
  • проведение оперативных рабочих совещаний
  • выполнение функций председателя на заседаниях оперативного совета
  • организация (подготовка повестки заседаний) заседаний управляющего комитета и оперативного совета
  • решение проблем, возникающих на уровне подразделений проектной группы, и, при необходимости, их вынесение на уровень управляющего комитета
  • представление на оперативном совете еженедельного (ежемесячного) отчета о статусе проекта, управляющему комитету - отчетов о состоянии работ на проекте, контроль своевременности рассылки протоколов заседаний
    •
    Руководитель проекта со стороны "BigCo" Захарова Екатерина Павловна 119018, г. Москва, ул. Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8976)
  • выполнение работ на проекте в полном соответствии с установленными объемом и сроками, контроль качества
  • подготовка общего плана на фазу проекта и детальных планов работ проектных групп на месяц
  • подготовка повестки заседаний оперативных советов и участие в заседаниях оперативного совета
  • решение проблем, возникающих на уровне проектных групп, группы интеграции, и, при необходимости, их вынесение на уровень оперативного совета
  • согласование проектных решений
    •
    Команда исполнителей проекта - предмет дальнейшего уточнения при планировании проекта. Содержание проекта утверждает управляющий комитет

    В сферу общей ответственности руководителей проекта входит:

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

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

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

    Описание содержания проекта будет представлено на рассмотрение управляющего комитета 10 сентября 2009 года руководителем проекта со стороны "BigCo" Захаровой Е.П.

    Приложение. Принятые термины и сокращения

    БП Бизнес-процесс
    КИСУ Корпоративная информационная система управления
    Общество, компания компания "Client Company"

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

    Подготовка документации по решению Microsoft Dynamics AX Утв./ А Согл. / С Исп./ R Разработка дополнительной функциональности Утв./ А Согл. / С Исп./ R Настройка и тестирование миграции данных Исп./ R Интеграционное тестирование Утв./ А Исп./ R Проведение завершающего тестирования Исп./ R Согл. / С Организация тренингов пользователей Исп./ R Переход на новую рабочую среду Утв./ А Исп./ R Проведение опциональных дополнительных тренингов пользователей Согл. / С Исп./ R Проверка корректности функционирования рабочей среды и окончательная настройка системы Согл. / С Исп./ R Приемка системы заказчиком Утв./ А Исп./ R Утв./ А Согл. / С

    Процедуры обеспечения проекта персоналом

    Процедура набора персонала

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

  • Организовать встречу, посвященную началу проекта. Знакомство членов команды друг с другом. Тимбилдинги для развития взаимоотношений. Распределение работы таким образом, чтобы использовать имеющиеся ресурсы и сильные стороны членов команды лучшим образом. 2.
  • Определить роль команды внутри организации. Соотнести процессы и системы с другими проектами и системами. 3.
  • Построить рабочие взаимоотношения внутри команды. 4.
  • Установить и поддерживать общение (в т.ч. используя компьютерные технологии). 5.
  • Учитывать мнение всей команды. 6.
  • Соотнести цели, которые стоят перед каждым из членов команды, с личными предпочтениями и целями. 7.
  • Уменьшить привлечение аутсорсинга для выполнения разовых задач. 8.
  • Поощрять разрешение трудностей в конструктивной манере.
    •

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

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

    Процедура обеспечения безопасности

    В соответствии с Трудовым кодексом регулируется обеспечение безопасности труда. Ответственным за обеспечение безопасности назначается руководитель проекта со стороны Исполнителя.

    План управления коммуникациями

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

    Взаимодействия по вертикали управления внутри одной команды: куратор (спонсор) проекта - руководитель проекта - команда проекта, - должны быть формальными и поддерживаться официальными документами. Взаимодействия руководителей проекта компании "Client Company" и "BigCo" также являются формальными и должны оформляться официальными документами. Допускаются неформальные взаимодействия между кураторами проекта и членами команд проекта от компании "Client Company" и "BigCo". Схема взаимодействия компаний "Client Company" и "BigCo" в проекте представлена на рисунке.

    Схема взаимодействия "Client Company" и "BigCo".

    Предмет коммуникации:Отчеты о проделанной работе

    Цель:Контроль хода выполнения работ

    Частота:Ежедневный, еженедельный и ежемесячный

    Даты начала/завершения:Конец отчетного периода (дня, недели, месяца)

    Формат/средство связи:По электронной почте и в бумажном виде

    Ответственное лицо:Каждый участник команды

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

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

    Процедура предоставления отчетов по исполнению

  • Сбор информации и формирование отчета участниками проекта.
  • Передача отчета участниками команды проекта как со стороны Исполнителя, так и со стороны Заказчика в электронном и бумажном виде вышестоящему руководству.
  • Передача отчета руководителю проекта со стороны Исполнителя или Заказчика.
  • Передача отчета от руководителя проекта со стороны Исполнителя руководителю проекта со стороны Заказчика и наоборот.
  • Формирование и предоставление отчетов руководителями проектов со стороны Заказчика и Исполнителя спонсорам проекта со стороны Заказчика и Исполнителя соответственно.
  • Формирование и предоставление отчетов руководителями проектов руководству своей компаний.
    •

    Процедура распространения информации

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

    Процедура анализа накопленных знаний

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

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

    Ответственным лицом для организации работы с рисками назначается руководитель проекта со стороны компании "BigCo".

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

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

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

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

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

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

    Шкала оценки влияния рисков

    Количественная характеристика Очень низкое Низкое Умеренное Высокое Очень высокое
    Объект влияния 0,05 О,1 0,2 0,4 0,8
    Стоимость Незначительное увеличение Увеличение<5% Увеличение5-10% Увеличение 11-20% >20% увеличение
    Сроки Незначительное увеличение Увеличение сроков <5% Увеличение 5-10% Увеличение 11-20% >20% увеличение
    Качество Изменения незаметны Незначительные изменения Изменения не требуют согласования Неприемлемое для клиента изменение Достижение конечных результатов невозможно

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

    Процедура идентификации рисков

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

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

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

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

    Форма реестра рисков

    № Дата возникновения риска Дата регистрации риска Наименование риска Описание риска Инициатор Причины, вызвавшие риск Последствия Владелец риска Дата окончания действия риска
    1
    2

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

    Вновь выявленные риски вносятся в реестр ассистентом руководителя проекта компании "BigCo"

    Риски, выявляемые на дальнейших этапах проекта, необходимо вносить в Реестр рисков.

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

    Классификация рисков.

    № Категории рисков Риски
    1 Организационные
  • Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ
  • Сопротивление конечных пользователей, неприятие результатов проекта
  • Неполнота, несвоевременность или некорректность бизнес-информации, передаваемой Заказчиком Исполнителю в ходе проекта
  • Сложность эксплуатации системы
    •
    2 Технологические
  • Отсутствие интерфейсов взаимодействия со смежными системами
  • Отказ от использования стандартной функциональности решения и замена ее на самостоятельные разработки
    •
    3 Процессные
  • Изменения структуры компании и/или методов ведения бизнеса
  • Изменение целей, задач и подхода к реализации проекта на поздних стадиях проекта
  • Существенное изменение состава проектной команды со стороны Заказчика или Исполнителя
  • Возникновение ложного представления у заказчика о результатах проекта
    •
    4 Внешние
  • Вероятность нарушения обозначенных условий контракта, отсутствие санкций.
    •
    5 Юридические
  • Вероятность нарушения обозначенных условий контракта, отсутствие санкций.
    •
    6 Методологические
  • Требование чрезмерной конфигурации со стороны Заказчика
  • Незнание методологии
    •

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

    Качественный анализ рисков производится после процесса идентификации рисков.

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

    Матрица вероятностей и последствий

    Последствия
    Вероятность 0,05 0,1 0,2 0,4 0,8
    0,9 0,05 0,09 0,18 0,36 0,72
    0,8 0,04 0,08 0,16 0,32 0,64
    0,7 0,04 0,07 0,14 0,28 0,56
    0,6 0,03 0,06 0,12 0,24 0,48
    0,5 0,03 0,05 0,10 0,20 0,40
    0,4 0,02 0,04 0,08 0,16 0,32
    0,3 0,02 0,03 0,06 0,12 0,24
    0,2 0,01 0,02 0,04 0,08 0,16
    0,1 0,01 0,01 0,02 0,04 0,08

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

    Категории рисков Вероятность Последствия
    Технологические
    Отсутствие интерфейсов взаимодействия со смежными системами 0.2 0.1
    Отказ от использования стандартной функциональности решения и замена ее на самостоятельные разработки 0.2 0.4
    Процессные/ процедурные
    Изменения структуры компании и/или методов ведения бизнеса 0.8 0.2
    Изменение целей, задач и подхода к реализации проекта на поздних стадиях проекта 0.8 0.4
    Существенное изменение состава проектной команды со стороны Заказчика или Исполнителя 0.3 0.4
    Возникновение ложного представления у заказчика о результатах проект 0.6 0.1
    Организационные
    Отсутствие или несвоевременное выделение необходимого количества специалистов заказчика требуемой квалификации для выполнения работ 0.5 0.8
    Сопротивление конечных пользователей, неприятие результатов проекта 0.6 0.2
    Неполнота, несвоевременность или некорректность бизнес-информации, передаваемой Заказчиком Исполнителю в ходе проекта 0.1 0.4
    Сложность эксплуатации системы 0.5 0.2
    Внешние
    Вероятность нарушения обозначенных условий контракта, отсутствие санкций. 0.1 0.1
    Методологические
    Требование чрезмерной конфигурации со стороны Заказчика 0.1 0.8
    Незнание Заказчиком методологии 0.1 0.2
    Юридические
    Вероятность нарушения обозначенных условий контракта, отсутствие санкций 0.1 0.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Определение статуса конфигурации

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

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

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

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

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

    Проведенные изменения Спецификация изменений Соответствие проведенных изменений спецификации Объекты, связанные с изменением Модифицированные объекты Модифицированы ли все связанные с изменением объекты конфигурации?
    .
    .
    Рекомендации по устранению несоответствий
    1.
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^