Управление внедрением информационных систем

Управление интеграцией проекта. Управление содержанием проекта

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

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

  • Группа процессов инициации.
  • Группа процессов планирования.
  • Группа процессов исполнения.
  • Группа процессов мониторинга и управления.
  • Группа завершающих процессов.
    •

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

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

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

    С целью структуризации управления проектом процессы управления проектом распределены по девяти областям знаний :

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

    Распределение 44 процессов по областям знаний и группам процессов представлено в таблице 4.1.

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

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

    Управление интеграцией

    Область знаний "Управление интеграцией" включает все пять групп процессов :

  • Инициация,
  • Планирование,
  • Исполнение,
  • Управление и контроль,
  • Завершение.
    •

    Результаты процессов из группы .

    (рис 4.1) Группы процессов управления проектами из области знаний "Управление интеграцией"

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

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

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

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

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

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

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

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

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

    Процессы завершения формализуют приемку разработанной ИС. При успешном завершении приемки ИС осуществляется закрытие проекта (включая финансовое и организационное закрытие проекта).

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

    Общая схема управления интеграцией проекта приведена на рис 4.2.

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

    Управление проектами выполняется с помощью применения и интеграции процессов управления проектами: инициации, планирования, исполнения, контроля, завершения.

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

    (рис 4.2) Общая схема управления интеграцией проекта

    Интеграцию проекта обеспечивают три основных документа проекта.

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

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

    (рис 4.3) Основные документы управления проектом

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

    Устав проекта (Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.

    Процесс разработки Устава проекта относится к группе процессов Инициация и осуществляется в фазе (на этапе) проекта внедрения ИС, которая имеет свое специфическое название в каждой методологии внедрения ИС, например, "Предварительное определение проекта", "Определение проекта" - методология внедрения продуктов Microsoft, "Концепция" - методология внедрения ASUP.

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

    Устав проекта содержит следующую информацию:

    1. Название проекта.

    2. Бизнес-цели компании или причины возникновения проекта.

    Формулировка причины фактически дает ответ на вопрос " Зачем выполняется данный проект?".

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

    3. Цели проекта.

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

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

    Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):

  • Конкретные (Specific) - позволяющие сформировать расписание проекта;
  • Измеримые (Measurable) - позволяющие качественно (или количественно) оценить, что результат получен;
  • Достижимые (Achievable) - принципиально реализуемые Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны Заказчика;
  • Приносящие результат (Relevant) - соответствуют ожидаемой Заказчиком пользе;
  • Ограниченные во времени (Time-bound) - реализуемые в ожидаемые Заказчиком временные рамки проекта.
    •

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

    Примеры формулировок целей:

  • Проектирование единых унифицированных бизнес-процессов в Головной компании и дочерних компаниях холдинга.
  • Разработка единого унифицированного ERP-решения, которое предназначено для внедрения в Холдинге, состоящем из Головной компании и 10 дочерних компаний.
  • Разработка инструментальных средств развертывания/тиражирования полученного решения во всех дочерних компаниях Холдинга.
    •

    4. Границы проекта.

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

  • Организационные границы
    •

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

  • Функциональные границы
    •

    Указываются бизнес-направления, бизнес-процессы, которые будут покрываться ИС. Данным пунктом определяются модули ERP-систем.

  • Географические границы
    •

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

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

    5. Содержание проекта (задачи проекта).

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

    Пример описания содержания (задач) проекта

    Автоматизация бизнес-процессов:

  • Управление основными средствами.
  • Учет затрат.
  • Управление персоналом.
    •

    Требования к бизнес-процессам должны включать:

  • Требования законодательства РФ в области бухгалтерского, налогового и статистического учета и отчетности.
  • Требования международных стандартов финансового учета и отчетности.
  • Требования управленческого учета Головной компании Холдинга.
  • Требования внутренней отчетности (внутреннего аудита).
  • Требования ТК РФ, отраслевой отчетности, отчетности Головной компании Холдинга.
    •

    6. Основные предположения и ограничения.

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

    Примеры предположений:

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

    Для составления списка предположений рекомендуется использовать так называемый "мозговой штурм". Неправильные или незадокументированные предположения могут вызвать проблемы во время реализации проекта.

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

    Примеры ограничений:

  • наличие у консультантов Исполнителя сертификатов по управлению проектами, выдаваемых Институтом управления проектами (PMI);
  • увеличение стоимости проекта не более чем на 10%.
    •

    8. Контрольные события и ключевые даты.

    Контрольные события (вехи проекта) - это основные события проекта, контрольные даты получения результатов. Результаты и контрольные события могут совпадать или иметь разные значения. В Уставе приводятся основные вехи проекта. Вехи, указанные в Уставе проекта, будут контролироваться Заказчиком и должны жестко соблюдаться. Необходимо оценивать влияние всех изменений в проекте на соблюдение сроков по данным вехам. Примеры контрольных событий-вех проекта приведены в таблице 4.3.

    Примеры вех проекта по внедрению ИС
    Наименование вехи проекта Ключевые даты
    Конфигурирование программного обеспечения завершено 1 сентября 2008 г.
    Материалы для обучения разработаны 2 ноября 2008 г.
    Прототип разработан 12 декабря 2008 г.
    Тестирование завершено 1 марта 2008 г.
    Программное обеспечение выпущено 20 января 2009 г.

    9. Основные результаты и критерии успеха.

    Результаты проекта - ИС, отдельные модули ИС, входящие в ИС алгоритмы расчета, экранные формы, формы отчетов и документов, получаемые в рамках выполнения проекта.

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

    Приведем пример описания результатов и критериев успеха проекта по внедрению ИС.

    Разработанная ИС должна решить нижеследующие задачи.

    В части Управления Основными Средствами:

  • возможность ведения учета Основных Средств (ОС) Головной компании и дочерних компаний холдинга в соответствии с российским (бухгалтерским и налоговым) законодательством и МСФО;
  • возможность ведения единого реестра основных средств Холдинга;
  • возможность оперативного получения данных об ОС;
  • возможность осуществления контроля по учету и движению объектов ОС.
    •

    В части Управления Персоналом:

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

    В части Учета затрат:

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

    10. Планируемая стоимость проекта.

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

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

    Предварительное описание содержания проекта

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

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

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

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

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

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

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

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

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

  • Планирование содержания.
  • Определение содержания.
  • Создание ИСР.
  • Подтверждение содержания.
  • Контроль изменений содержания.
    •

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

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

    На рис 4.4 представлена схема взаимосвязи процессов управления содержанием проекта.

    (рис 4.4) Взаимосвязь процессов управления содержанием проекта

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

    Планирование содержания

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

    Согласно PMBOK , План управления содержанием проекта (Project Scope Management Plan) - это документ, описывающий, как будут определяться, разрабатываться и проверяться работы, которые необходимо выполнить для получения результата с указанными характеристиками, и задающий действия по управлению содержанием проекта.

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

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

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

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

    Уточнение (определение) содержания

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

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

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

    (рис 4.5) Пример сетевого графика взаимодействия с Заказчиком

    Результат процесса определения содержания:

  • описание содержания проекта,
  • обновленный подробный план управления содержанием проекта,
  • запрос на изменения.
    •

    Рассмотрим результаты процесса определения содержания более подробно.

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

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

    Цели проекта. Цели проекта - это измеримые критерии его успешности, связанные с бизнесом, стоимостью, расписанием и качеством проекта. У каждой цели проекта есть свои атрибуты: название (например, стоимость), единица измерения (например, доллар США) и абсолютное или относительное значение (например, не более 1,5 млн долларов).

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

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

    Границы проекта. Определяют в целом то, что включается в проект, и явно указывают, что в него не входит, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый результат, услугу или результат входящими в проект. При определении границ проекта необходимо привлекать к работе системного архитектора, консультантов по внедряемой ИС. Как показывает практика, наиболее "узким местом" в определении границ проекта по разработке и внедрению ИС являются разрабатываемые формы отчетов. Если в содержании проекта указать "Разработать отчеты" и не задать в качестве границ проекта количество разрабатываемых отчетов, их наименования, то проект может быть никогда не закончен: у Заказчика может возникать необходимость в получении все новых и новых отчетов. Необходимо задокументировать все решения, связанные с границами проекта.

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

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

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

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

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

    Изначально сформулированные риски. Перечисляются известные риски.

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

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

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

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

    Спецификации проекта. Определяют спецификации, которым должен соответствовать проект.

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

    План управления содержанием проекта (обновления)

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

    Запрошенные изменения

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

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

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

    Создание иерархической структуры работ

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

    Входной информацией для процесса создания ИСР являются описание содержания проекта, план управления содержанием проекта, активы организационного процесса, одобренные запросы на изменение (рис 4.6).

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

    Шаблоны иерархической структуры работ

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

    Стандарт Института управления проектами (PMI) для иерархической структуры работ содержит руководство по созданию, доработке и применению иерархических структур работ. В это руководство включены примеры шаблонов ИСР, которые можно адаптировать под конкретные проекты в конкретной области приложения. На рис 4.6 показана часть шаблона ИСР с несколькими ответвлениями, разбитыми до уровня пакетов работ.

    (рис 4.6) Шаблон иерархической структуры работ с несколькими ответвлениями, разбитыми до уровня пакетов работ [4]

    Декомпозиция

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

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

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

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

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

    Системный подход к составлению ИСР

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

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

    (рис 4.7) Пример иерархической структуры работ, организованной по фазам [9]

    Выходные документы процесса создания ИСР

    Описание содержания проекта (обновления)

    Если одобренные запросы на изменение являются результатом создания ИСР, то в описание содержания проекта включаются эти одобренные изменения.

    Иерархическая структура работ

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

    Словарь ИСР

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

    Базовый план по содержанию

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

    План управления содержанием проекта (обновления)

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

    Запрошенные изменения

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

    Подтверждение содержания

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

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

  • описание содержания проекта;
  • словарь ИСР;
  • план управления содержанием проекта;
  • результаты поставки.
    •

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

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

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

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

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

    Управление изменениями содержания

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

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

    Входная информация процесса:

  • описание содержания проекта;
  • иерархическая структура работ;
  • словарь ИСР;
  • план управления содержанием проекта;
  • отчеты об исполнении;

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

  • одобренные запросы на изменение;

    Одобренный запрос на изменение, оказывающий влияние на содержание проекта, - любое изменение в согласованном базовом плане проекта, ИСР и словаре ИСР.

  • информация об исполнении работ.
    •

    Инструменты и методы

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

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

    Корректировка планов. Одобренные запросы на изменения, оказывающие влияние на содержание проекта, могут повлиять на ИСР и словарь ИСР, описание содержания проекта и план управления содержанием проекта. Эти одобренные запросы на изменения могут потребовать обновления компонентов плана управления проектом.

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

    Выходы процесса

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

    Иерархическая структура работ (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то ИСР редактируется и в новую редакцию включаются эти одобренные изменения.

    Словарь ИСР (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то словарь ИСР редактируется и в новую редакцию включаются эти одобренные изменения.

    Базовый план по содержанию (обновления)

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

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

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

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

    Страницы:

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

  • Группа процессов инициации.
  • Группа процессов планирования.
  • Группа процессов исполнения.
  • Группа процессов мониторинга и управления.
  • Группа завершающих процессов.
    •

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

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

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

    С целью структуризации управления проектом процессы управления проектом распределены по девяти областям знаний :

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

    Распределение 44 процессов по областям знаний и группам процессов представлено в таблице 4.1.

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

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

    Управление интеграцией

    Область знаний "Управление интеграцией" включает все пять групп процессов :

  • Инициация,
  • Планирование,
  • Исполнение,
  • Управление и контроль,
  • Завершение.
    •

    Результаты процессов из группы .

    (рис 4.1) Группы процессов управления проектами из области знаний "Управление интеграцией"

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

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

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

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

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

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

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

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

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

    Процессы завершения формализуют приемку разработанной ИС. При успешном завершении приемки ИС осуществляется закрытие проекта (включая финансовое и организационное закрытие проекта).

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

    Общая схема управления интеграцией проекта приведена на рис 4.2.

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

    Управление проектами выполняется с помощью применения и интеграции процессов управления проектами: инициации, планирования, исполнения, контроля, завершения.

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

    (рис 4.2) Общая схема управления интеграцией проекта

    Интеграцию проекта обеспечивают три основных документа проекта.

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

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

    (рис 4.3) Основные документы управления проектом

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

    Устав проекта (Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.

    Процесс разработки Устава проекта относится к группе процессов Инициация и осуществляется в фазе (на этапе) проекта внедрения ИС, которая имеет свое специфическое название в каждой методологии внедрения ИС, например, "Предварительное определение проекта", "Определение проекта" - методология внедрения продуктов Microsoft, "Концепция" - методология внедрения ASUP.

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

    Устав проекта содержит следующую информацию:

    1. Название проекта.

    2. Бизнес-цели компании или причины возникновения проекта.

    Формулировка причины фактически дает ответ на вопрос " Зачем выполняется данный проект?".

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

    3. Цели проекта.

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

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

    Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):

  • Конкретные (Specific) - позволяющие сформировать расписание проекта;
  • Измеримые (Measurable) - позволяющие качественно (или количественно) оценить, что результат получен;
  • Достижимые (Achievable) - принципиально реализуемые Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны Заказчика;
  • Приносящие результат (Relevant) - соответствуют ожидаемой Заказчиком пользе;
  • Ограниченные во времени (Time-bound) - реализуемые в ожидаемые Заказчиком временные рамки проекта.
    •

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

    Примеры формулировок целей:

  • Проектирование единых унифицированных бизнес-процессов в Головной компании и дочерних компаниях холдинга.
  • Разработка единого унифицированного ERP-решения, которое предназначено для внедрения в Холдинге, состоящем из Головной компании и 10 дочерних компаний.
  • Разработка инструментальных средств развертывания/тиражирования полученного решения во всех дочерних компаниях Холдинга.
    •

    4. Границы проекта.

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

  • Организационные границы
    •

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

  • Функциональные границы
    •

    Указываются бизнес-направления, бизнес-процессы, которые будут покрываться ИС. Данным пунктом определяются модули ERP-систем.

  • Географические границы
    •

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

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

    5. Содержание проекта (задачи проекта).

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

    Пример описания содержания (задач) проекта

    Автоматизация бизнес-процессов:

  • Управление основными средствами.
  • Учет затрат.
  • Управление персоналом.
    •

    Требования к бизнес-процессам должны включать:

  • Требования законодательства РФ в области бухгалтерского, налогового и статистического учета и отчетности.
  • Требования международных стандартов финансового учета и отчетности.
  • Требования управленческого учета Головной компании Холдинга.
  • Требования внутренней отчетности (внутреннего аудита).
  • Требования ТК РФ, отраслевой отчетности, отчетности Головной компании Холдинга.
    •

    6. Основные предположения и ограничения.

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

    Примеры предположений:

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

    Для составления списка предположений рекомендуется использовать так называемый "мозговой штурм". Неправильные или незадокументированные предположения могут вызвать проблемы во время реализации проекта.

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

    Примеры ограничений:

  • наличие у консультантов Исполнителя сертификатов по управлению проектами, выдаваемых Институтом управления проектами (PMI);
  • увеличение стоимости проекта не более чем на 10%.
    •

    8. Контрольные события и ключевые даты.

    Контрольные события (вехи проекта) - это основные события проекта, контрольные даты получения результатов. Результаты и контрольные события могут совпадать или иметь разные значения. В Уставе приводятся основные вехи проекта. Вехи, указанные в Уставе проекта, будут контролироваться Заказчиком и должны жестко соблюдаться. Необходимо оценивать влияние всех изменений в проекте на соблюдение сроков по данным вехам. Примеры контрольных событий-вех проекта приведены в таблице 4.3.

    Примеры вех проекта по внедрению ИС
    Наименование вехи проекта Ключевые даты
    Конфигурирование программного обеспечения завершено 1 сентября 2008 г.
    Материалы для обучения разработаны 2 ноября 2008 г.
    Прототип разработан 12 декабря 2008 г.
    Тестирование завершено 1 марта 2008 г.
    Программное обеспечение выпущено 20 января 2009 г.

    9. Основные результаты и критерии успеха.

    Результаты проекта - ИС, отдельные модули ИС, входящие в ИС алгоритмы расчета, экранные формы, формы отчетов и документов, получаемые в рамках выполнения проекта.

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

    Приведем пример описания результатов и критериев успеха проекта по внедрению ИС.

    Разработанная ИС должна решить нижеследующие задачи.

    В части Управления Основными Средствами:

  • возможность ведения учета Основных Средств (ОС) Головной компании и дочерних компаний холдинга в соответствии с российским (бухгалтерским и налоговым) законодательством и МСФО;
  • возможность ведения единого реестра основных средств Холдинга;
  • возможность оперативного получения данных об ОС;
  • возможность осуществления контроля по учету и движению объектов ОС.
    •

    В части Управления Персоналом:

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

    В части Учета затрат:

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

    10. Планируемая стоимость проекта.

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

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

    Предварительное описание содержания проекта

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

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

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

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

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

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

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

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

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

  • Планирование содержания.
  • Определение содержания.
  • Создание ИСР.
  • Подтверждение содержания.
  • Контроль изменений содержания.
    •

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

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

    На рис 4.4 представлена схема взаимосвязи процессов управления содержанием проекта.

    (рис 4.4) Взаимосвязь процессов управления содержанием проекта

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

    Планирование содержания

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

    Согласно PMBOK , План управления содержанием проекта (Project Scope Management Plan) - это документ, описывающий, как будут определяться, разрабатываться и проверяться работы, которые необходимо выполнить для получения результата с указанными характеристиками, и задающий действия по управлению содержанием проекта.

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

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

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

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

    Уточнение (определение) содержания

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

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

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

    (рис 4.5) Пример сетевого графика взаимодействия с Заказчиком

    Результат процесса определения содержания:

  • описание содержания проекта,
  • обновленный подробный план управления содержанием проекта,
  • запрос на изменения.
    •

    Рассмотрим результаты процесса определения содержания более подробно.

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

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

    Цели проекта. Цели проекта - это измеримые критерии его успешности, связанные с бизнесом, стоимостью, расписанием и качеством проекта. У каждой цели проекта есть свои атрибуты: название (например, стоимость), единица измерения (например, доллар США) и абсолютное или относительное значение (например, не более 1,5 млн долларов).

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

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

    Границы проекта. Определяют в целом то, что включается в проект, и явно указывают, что в него не входит, чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый результат, услугу или результат входящими в проект. При определении границ проекта необходимо привлекать к работе системного архитектора, консультантов по внедряемой ИС. Как показывает практика, наиболее "узким местом" в определении границ проекта по разработке и внедрению ИС являются разрабатываемые формы отчетов. Если в содержании проекта указать "Разработать отчеты" и не задать в качестве границ проекта количество разрабатываемых отчетов, их наименования, то проект может быть никогда не закончен: у Заказчика может возникать необходимость в получении все новых и новых отчетов. Необходимо задокументировать все решения, связанные с границами проекта.

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

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

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

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

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

    Изначально сформулированные риски. Перечисляются известные риски.

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

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

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

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

    Спецификации проекта. Определяют спецификации, которым должен соответствовать проект.

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

    План управления содержанием проекта (обновления)

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

    Запрошенные изменения

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

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

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

    Создание иерархической структуры работ

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

    Входной информацией для процесса создания ИСР являются описание содержания проекта, план управления содержанием проекта, активы организационного процесса, одобренные запросы на изменение (рис 4.6).

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

    Шаблоны иерархической структуры работ

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

    Стандарт Института управления проектами (PMI) для иерархической структуры работ содержит руководство по созданию, доработке и применению иерархических структур работ. В это руководство включены примеры шаблонов ИСР, которые можно адаптировать под конкретные проекты в конкретной области приложения. На рис 4.6 показана часть шаблона ИСР с несколькими ответвлениями, разбитыми до уровня пакетов работ.

    (рис 4.6) Шаблон иерархической структуры работ с несколькими ответвлениями, разбитыми до уровня пакетов работ [4]

    Декомпозиция

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

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

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

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

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

    Системный подход к составлению ИСР

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

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

    (рис 4.7) Пример иерархической структуры работ, организованной по фазам [9]

    Выходные документы процесса создания ИСР

    Описание содержания проекта (обновления)

    Если одобренные запросы на изменение являются результатом создания ИСР, то в описание содержания проекта включаются эти одобренные изменения.

    Иерархическая структура работ

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

    Словарь ИСР

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

    Базовый план по содержанию

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

    План управления содержанием проекта (обновления)

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

    Запрошенные изменения

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

    Подтверждение содержания

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

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

  • описание содержания проекта;
  • словарь ИСР;
  • план управления содержанием проекта;
  • результаты поставки.
    •

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

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

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

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

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

    Управление изменениями содержания

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

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

    Входная информация процесса:

  • описание содержания проекта;
  • иерархическая структура работ;
  • словарь ИСР;
  • план управления содержанием проекта;
  • отчеты об исполнении;

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

  • одобренные запросы на изменение;

    Одобренный запрос на изменение, оказывающий влияние на содержание проекта, - любое изменение в согласованном базовом плане проекта, ИСР и словаре ИСР.

  • информация об исполнении работ.
    •

    Инструменты и методы

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

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

    Корректировка планов. Одобренные запросы на изменения, оказывающие влияние на содержание проекта, могут повлиять на ИСР и словарь ИСР, описание содержания проекта и план управления содержанием проекта. Эти одобренные запросы на изменения могут потребовать обновления компонентов плана управления проектом.

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

    Выходы процесса

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

    Иерархическая структура работ (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то ИСР редактируется и в новую редакцию включаются эти одобренные изменения.

    Словарь ИСР (обновления). Если одобренные запросы на изменения влияют на содержание проекта, то словарь ИСР редактируется и в новую редакцию включаются эти одобренные изменения.

    Базовый план по содержанию (обновления)

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

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

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

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^