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

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

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

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

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

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

Открыть схему в полном размере ↗

Открыть схему в полном размере ↗

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

Содержание продукта отвечает на вопрос «Чего хочет заказчик?». Организация может запустить отдельный проект для определения содержания продукта или определить его при сборе требований текущего проекта.

Для проекта по разработке ПО содержание продукта может быть сформулировано так: «Новое приложение для управления рабочими процессами, которое отвечает требованиям внутренних и внешних заказчиков». Чтобы проверить, соответствует ли результат содержанию продукта, сопоставьте готовое приложение с требованиями, зафиксированными в документации по требованиям и в описании содержания проекта.

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

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

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

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

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

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

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

Для подготовки плана руководитель проекта должен хорошо понимать содержание. До начала работ определите содержание продукта и проекта. Составление плана управления содержанием — обязательная часть управления проектом.

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

1. Определите требования. Опирайтесь на экономическое обоснование из устава проекта, чтобы проверить, поддерживает ли каждое требование проект.
2. Учитывайте потребности заинтересованных сторон при определении содержания продукта и проекта.
3. Используйте иерархическую структуру работ (WBS), чтобы разделить содержание на более мелкие, управляемые части.
4. Проектируйте процесс с точки зрения заказчика.
5. Измеряйте исполнение по содержанию и при необходимости вносите коррективы в ходе всего проекта.

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

Сбор требований

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

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

Начните с выявления заинтересованных сторон и внесите их в реестр. У проекта может быть несколько сотен заинтересованных сторон, и для разных групп могут потребоваться разные способы сбора предложений. Выделите время и ресурсы на сбор требований до начала работ. Неполный сбор может повлечь дорогостоящие и трудоёмкие изменения. Помочь могут архивные сведения и извлечённые уроки. Выбирайте методы, которые подходят проекту и заинтересованным сторонам. Эти методы также можно использовать для выявления рисков при управлении рисками.

Изучение архивных данных

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

Интервью

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

Фокус-группы

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

Рабочие совещания с фасилитатором

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

Мозговой штурм

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

Метод номинальных групп

После мозгового штурма участники ранжируют лучшие идеи.

Метод Дельфи

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

Интеллект-карты

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

Диаграммы сходства

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

Открыть схему в полном размере ↗

Анкеты и опросы

Анкета собирает ответы на набор вопросов. Анкеты и опросы могут охватить большую группу.

Наблюдение

Понаблюдайте за работой потенциального пользователя продукта.

Прототипы

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

Групповое принятие решений

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

• Единогласие. Все согласны с требованием, поэтому решение принимается легко.
• Единоличное решение. Один человек решает за всю группу. Решение принимается быстро, при этом другие заинтересованные стороны могут с ним не согласиться.
• Абсолютное большинство. Группа принимает решение, которое поддерживает больше половины её участников.
• Относительное большинство. Если ни один вариант не получил абсолютного большинства, группа выбирает вариант с наибольшим числом сторонников.
• Консенсус. Группа приходит к приемлемому для неё решению. Участники, предпочитавшие другой вариант, готовы принять решение, которое поддержало большинство.

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

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

Баланс требований заинтересованных сторон

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

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

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

Разрешение противоречий между требованиями

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

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

Отклоняйте запросы, выходящие за пределы целей проекта или утверждённого устава, даже если они связаны с первоначальной причиной запуска проекта. Любое предлагаемое изменение устава обсудите со спонсором для утверждения. Если стоимость — главное ограничение, запросы, увеличивающие затраты, будут менее вероятны к утверждению. Запросы, сдерживающие затраты без существенного влияния на другие ограничения, скорее будут приняты. Запросы, выходящие за эти рамки, можно рассмотреть для будущего проекта.

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

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

• Какими методами будут выявляться требования?
• Какой анализ потребуется для каждого требования?
• Как будет определяться приоритет требований?
• Как ими будут управлять?
• Как их будут отслеживать?
• Какие сведения должна содержать матрица прослеживаемости требований?

Матрица прослеживаемости требований

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

Матрица прослеживаемости требований — ещё один результат сбора требований. Она связывает требования с целями проекта и/или другими требованиями для поддержки стратегических целей. Используйте её на протяжении всего проекта, чтобы анализировать предлагаемые изменения содержания продукта или проекта.

Открыть схему в полном размере ↗

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

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

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

Анализ продукта

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

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

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

1. Неутверждённые работы. Перечислите запрошенные работы, включение которых так и не было утверждено.
2. Ненужные работы. Уточните границы, которые легко понять неправильно.

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

• Содержание продукта.
• Содержание проекта.
• Результаты поставки.
• Критерии приёмки продукта.
• Операции за пределами содержания.
• Ограничения и допущения.

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

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

Открыть схему в полном размере ↗

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

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

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

Правила создания WBS

1. Привлекайте команду.
2. Завершите первый уровень, прежде чем делить работы дальше.
3. На каждом уровне выделяйте составные части вышестоящего уровня.
4. Сделайте так, чтобы все уровни WBS вместе давали представление о проекте целиком.
5. Включайте только результаты поставки этого проекта.

Пакеты работ и контрольные счета

Результат поставки можно считать пакетом работ, если:

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

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

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

WBS — основа остального планирования проекта. Её наглядная иерархия показывает каждый результат поставки. Операция входит в проект, если связана с работой, включённой в WBS. WBS помогает команде продумать все части проекта, и её можно повторно использовать в других проектах. Показывайте иерархию с помощью WBS, а зависимости между операциями — с помощью сетевой диаграммы расписания.

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

Открыть схему в полном размере ↗

Словарь WBS

Словарь WBS описывает работу по каждому пакету. Это результат создания WBS. Он помогает предотвратить неконтролируемое расширение содержания и даёт всем чёткое описание результата поставки. Словарь может выполнять следующие функции:

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

Открыть схему в полном размере ↗

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

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

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

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

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

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

• Результаты поставки, проверенные в ходе контроля качества.
• Описание содержания, WBS и словарь WBS.
• Матрица прослеживаемости требований.
• Документация по требованиям.

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

• Принятые результаты поставки.
• Запросы на изменения.
• Обновления документов проекта.

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

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

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

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

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