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

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

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

Основные процессы управления содержанием включают в себя:

-Планирование управления содержанием

-Сбор требований- создание Плана управления требованиями

-Определение содержания - разработка подробного описания содержания проекта

-Создание иерархической структуры работ проекта - разбиение проекта на более мелкие и легко управляемые компоненты

-Подтверждение содержания -формальное утверждение результатов

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

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

-Процесс подготовки подробного описания содержания проекта

-Процесс, который позволяет разработать ИСР из подробного описания содержания проекта

-Процесс, который определяет, как ИСР будет строиться и утверждаться

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

План управления содержанием - это компонент плана управления проектом, •

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

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

Содержание проекта - работы, которые необходимо выполнить, чтобы

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

Реализацию содержания проекта руководитель проекта отслеживает по плану управления проектом, описанию содержания проекта и ИСР

Содержание продукта - свойства и функции, которые характеризуют продукт,

услугу или результат

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

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

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

Реестр заинтересованных сторон должен включать:

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

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

-Классификацию заинтересованных сторон: Внешний/внутренний, поддерживающий/нейтральный/препятствующий.

Документированные требования заинтересованных сторон:

-Бизнес-цели и цели проекта отслеживания(трассировки)

-Функциональные и нефункциональные требования

-Требования к качеству

-Влияние на окружение внутри и снаружи исполняющей организации

-Допущения и ограничения требований

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

Определение содержания:

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

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

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

Подробное описание проекта фиксируется в документе «Описание содержания проекта»

Возможны различные названия документы «Описание содержания проекта»: «Цели и задачи проекта», «Определение проекта>> и т.д.

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

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

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

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

1. Описание содержания продукта - характеристика продукта, услуги или результата, для создания которых предпринят проект

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

3. Границы проекта - определяют в целом то, что включается в проект, и в явном виде, какой продукт или услуга не включается в проект

4. Критерии приемки продукта - определяют порядок и критерии приемки готового продукта

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

6. Допущения проекта - события или состояния, которые необходимы для успешного проекта

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

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

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

Документ «Описание содержания проекта» вместе с ИСР составляют базовый план проекта по содержанию.

ИСР создается путем декомпозиции- разбиения основных результатов проекта

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

Нижний уровень ИСР состоит из Пакетов работ- элементов, для которых можно определить их сроки выполнения и стоимость

У каждого пакета работ обязательно должен быть результат

Шаги декомпозиции ИСР:

-Определение основных целей проекта

-Разбиение каждой цели на ее составляющие компоненты

-Проверка необходимости и достаточности степени декомпозиции работ

При проверке уточняется:

-Полностью ли описывают элементы нижнего уровня те элементы, которые они составляют.

-Возможна ли оценка сроков и стоимости для этих элементов(это будет являться окончанием детализации)

РАБОТЫ, НЕ ВКЛЮЧЁННЫЕ В ИСР, НЕ ЯВЛЯЮТСЯ РАБОТАМИ ПРОЕКТА!

Цель декомпозиции:

-Повышение точности оценок по стоимости и срокам проекта

-Определение базиса для измерения и контроля хода выполнения проекта

-Создание чёткого распределения ответственности.

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

На более поздних стадиях декомпозиция будет продолжена и пакеты работ будут детализированы до элементарных работ. Этот процесс необходим для составления расписания и поэтому рассматривается в разделе “Управление сроками”

ИСР - следующий этап разработки и детализации содержания проекта после

создания документа «Описание содержания проекта»

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

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

В качестве основы для декомпозиции можно использовать:

-Жизненный цикл проекта

-Компоненты продукта

-Функциональный подход

-Географический подход

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

ПРИМЕР

Процесс подтверждения содержания- приемка результатов и работ проекта

участниками проекта в соответствии с утвержденным содержанием проекта

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

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

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

Контроль содержания нужен для:

-Отслеживание изменений содержания проекта и продукта

-Оформления этих изменений согласно утвержденной процедуре

-Принятия решений по изменениям проекта и продукта

-Воздействия на факторы, вызывающие изменения.