Процесс Контроля содержания проекта

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

Выходы процесса Валидации содержания проекта

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

1. информация о состоянии исполнения работ
2. принятые продукты
3. запросы на изменение
4. апдейты в реестр вынесенных уроков, матрицу требований, и документацию на требования

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

1. Валидацию можно делать как в конце фазы проекта, для получения формальной приемки продуктов, так и в промежутках, как часть процесса Контроля и мониторинга, для приемки промежуточных продуктов. Так что, содержание валидируется клиентом многократно в течение проекта. В change-driven проектах, это случается в конце каждой итерации, как часть приемки итерации клиентом
2. Есть тонкая разница между Валидацией содержания, и Закрытием проекта или фазы. Валидация это приемка промежуточных продуктов, а Закрытие это финальное закрытие проекта или фазы в целом и списание их из актива
3. Надо понимать, как процесс Валидации содержания связан с процессом Контроля качества:

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

Документация: Базовый план по содержанию

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

1. как идет мой проект, в сравнении с базовыми значениями?
2. какое содержание уже сдано?
3. соответствует ли оно тому, что описано в ИСР, словаре ИСР, содержании?

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

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

Документация: Описание содержания проекта

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

1. Содержание продукта
2. Содержание проекта, включая описание
3. Описание поставок проекта
4. Критерии приемки
5. Что не включается в проект
6. Предположения и ограничения проекта

Содержание проекта

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