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

1. Управление проектами. Модуль 4.

2. Лекция 21-22
Управление содержанием проекта (Project Scope)
● Определение содержания
● Критерии приёмки продукта
● Допущения и ограничения поставляемого
продукта.
● Создание ИСР
● Декомпозиция работ по созданию проекта.
● Примеры разбивки проекта на ИСР
● Подтверждение содержания
● Процесс мониторинга содержания проекта и
продукта

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

4. Определение содержания: инструменты и методы
● Анализ продукта
● Преобразование целей продукта в материальные
результаты поставки и требования
● Иерархическая структура продукта
● Системный анализ и инжиниринг
● Метод оптимизации выгод
● Функционально-стоимостной анализ
● Анализ ценности
● Формирование альтернатив
● Методы общего менеджмента (peer-review и т.д.)
● Мозговой штурм
● Анализ альтернатив
● Экспертная оценка
● Семинары с участием модератора

5. Определение содержания: выходы и результаты
● Описание содержания проекта — это
изложение содержания проекта, основных
поставляемых результатов, допущений
● Документирует все содержание, включая
содержание проекта и продукта.
● Детально описывает поставляемые
результаты проекта и работы, которые
необходимо выполнить.
● Формулирует общее понимание содержания
проекта заинтересованными сторонами.
● Может содержать явные исключения из
содержания, что может помочь в управлении
ожиданиями заинтересованных сторон.
● Позволяет команде проекта осуществлять
более детальное планирование
● Направляет работу команды проекта во
время исполнения и предоставляет базовый
план для оценки того, попадают ли запросы
на изменения или дополнительная работа в
границы проекта.

6. Определение содержания: выходы и результаты
Подробное описание содержания проекта либо непосредственно, либо в виде ссылок на
другие документы включает в себя:
● Описание содержания продукта. Последовательно уточняет характеристики продукта,
услуги или результата, описанного в уставе проекта или в документации по требованиям.
● Критерии приемки. Набор условий, которые должны быть выполнены до того, как
поставляемые результаты будут приняты.
● Поставляемый результат. Любой уникальный и поддающийся проверке продукт,
результат или способность оказывать услугу, которые необходимо произвести для
завершения процесса, фазы или проекта. Данные поставляемые результаты могут быть
описаны обобщенно или с высокой степенью детализации.
● Исключения из проекта. Как правило, определяет, что исключено из проекта. Явная
формулировка того, что именно находится вне содержания проекта, помогает управлять
ожиданиями заинтересованных сторон.
● Ограничения. Ограничивающий фактор, влияющий на ход исполнения проекта или
процесса. Ограничения, выявленные в описании содержания проекта, перечисляют и
описывают конкретные внутренние или внешние пределы или ограничивающие условия
проекта, связанные с его содержанием, которые оказывают влияние на исполнение
проекта, например предопределенный бюджет, любые ограничивающие даты или
контрольные события расписания, которые определены заказчиком или исполняющей
организацией.
● Допущения. Фактор в рамках процесса планирования, который считается верным,
реальным или определенным без предоставления доказательств и без демонстрации.

7. Создание ИСР

8. Создание ИСР
Создание иерархической структуры работ (ИСР), она же структурная
декомпозиция работ (СДР), она же Work Breakdown Structure (WBS). — это
процесс разделения поставляемых результатов проекта и работ проекта на
меньшие компоненты, которыми легче управлять. Ключевая выгода данного
процесса состоит в том, что он предоставляет структурированное видение того,
чего необходимо достичь.
Разбиение проекта на более мелкие составляющие необходимо для:
● повышения точности оценок затрат, сроков и потребности в ресурсах;
● определения и фиксации исходного плана для организации контроля
выполнения;
● упрощения распределения ответственности.

9. Зачем нужна ИСР?
ИСР –полезная вещь в планировании проекта и вот почему:
● ИСР – если не единственный, но точно самый эффективный способ наглядно
отразить весь объем проекта.
● ИСР фокусирует внимание не на процессе а на ожидаемом результате, и создает
нужный «посыл».
● В идеале в разработке ИСР участвует заказчик или его представитель и вся
команда, что позволяет а) обеспечить единое понимание результатов проекта и
его объема б) увидеть важность и вклад отдельных элементов в общий результат
● С помощью ИСР можно наглядно обосновать необходимости в финансах или
человеческих ресурсах, так как против конкретного описанного объема
возражать гораздо сложнее, чем против «да что там системку написать, посадите
программиста и все».
● ИСР помогает предотвратить риски и изменения или значительно снизить их
вероятность и влияние, так как именно здесь всплывут многие неочевидные
ранее вещи и «а мы хотели совсем другое» (и так и должно быть, для этого
инструмент и предназначен).
● На уровне ИСР уже можно определить и согласовать контрольные точки проекта
(как для решений о продолжении проекта после очередного этапа, так и для
контроля затрат человеческих и финансовых ресурсов).

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

11. Способы отображение и кодировка
Часто ИСР представляют в виде диаграммы, где нижние уровни
являются декомпозицией верхних.
● таблицы (очень удобный метод отражения)
● ментальной карты (например, в FreeMind)
● иерархической структуры задач (например, в Microsoft Project)
● диаграммы на рыбьих костях.
Все элементы ИСР имеют специальную кодировку, смысл которой
— присвоить каждому элементу уникальный номер.
● Самый верхний уровень имеет код 0 (ноль) и его часто именуют
просто: «проект».
● Элементы первого уровня нумеруются последовательно от 1 до
количества элементов на уровне (обычно не более 7).
● Второй и последующие уровни нумеруется таким образом,
чтобы элемент сохранил ссылку на вышестоящий, например
«1.2.4″

12. Способы отображение и кодировка

13. ИСР. Фазы жизненного цикла

14. ИСР. По результатам проекта

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

16. Степень детализации ИСР
При осуществлении детализации ИСР менеджеру следует
решить, насколько детально и подробно структурировать
работы: какие из них разделять на максимальное число
простых работ, а какие оставить на укрупненном уровне
детализации. Обычно используют 4 уровня
детализации: phases (фаза или этап проекта), activities
(пакет работ), tasks (задача), work unit (операция, единица
работы, т. е работа, которую может выполнить 1 человек
в срок, не превышающий 2 недели). Но на сложных проектах
уровень детализации может достигать 6 и более.
● Для маленьких проектов – 4-40 часов,
● Для средних проектов – 8-80 часов
● Для больших проектов – в зависимости от масштаба, но
желательно не более 300 часов.

17. Степень детализации ИСР
Между тем, существуют критерии, на которые следует обратить внимание при принятии
решения о дальнейшей детализации работ:
● Возможность оценки параметров работы. Если длительность, стоимость или другие
важные параметры работы с трудом поддаются оценке, стоит разделить работу на
составляющие, каждую из которых оценить отдельно. Вероятно, какой-либо параметр
работы не удается точно оценить в силу неопределенности. В этом случае можно
попробовать выделить ту часть работы, которую можно оценить, и ту, которая является
неопределенной.
● Возможность контроля выполнения работы. Если работа имеет несколько
промежуточных результатов, не нужно усложнять ее контроль, а следует разделить ее на
этапы, каждый из которых приводит к определенному результату. Возможно, работа
состоит из нескольких одновременно выполняемых процессов или функций,
контролируемых различным образом. В этом случае ее также следует разделить на
составляющие. Если работа слишком длительна, то следует разделить ее на этапы и
попытаться найти промежуточные результаты для более точного контроля работы.
● Возможность назначения ответственных. Если за работу отвечает не один человек, а
несколько, то, как показывает практика, она может вообще не выполняться. В случае
возникновения так называемой «множественной ответственности», необходимо
разделить работу на составляющие, разграничив круг ответственности каждого из
участников.
● Использование шаблонов – возможно, часть работ планируемого проекта уже ранее была
детализирована, и существующие наработки можно применить в новом проекте.

18. Степень детализации ИСР- agile
● Отражать итерации как способ группировки (каждый
итерация или спринт идут отдельным блоком в ИСР) –
удобно, если результаты спринтов заранее известны.
● Разбивать каждый из результатов на итерации – удобно,
если у вас делается сразу весь объем, а в дальнейшем только
улучшается и детализируется (но тут нужно очень хорошо
понимать объем проекта, что при agile бывает не так часто)
● Использовать обычную ИСР и уточнять ее для каждой
итерации (то есть количество ИСР в итоге будет равно
количествам итераций)
● Просто использовать обычную ИСР и ограничиться этой
степенью детализации.
● Любой другой вариант, дающий вам нужную степень
понимания и детализации.

19. Пример ИСР “Ремонт”

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

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

22. Подтверждение содержания
● Формальное принятие участниками проекта завершенного
содержания проекта и относящихся к нему результатов
поставки
● Проверка результатов поставки для определения полной
готовности каждого из них
● Не следует путать с контролем качества — являющегося
проверкой на соответствие требованиям и проводимого до
поставки

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

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

25. Контроль содержания
● Контроль содержания — то процесс мониторинга статуса проекта и
содержания продукта, а также управления изменениями базового плана по
содержанию. Управление содержанием проекта обеспечивает обработку
всех запрошенных изменений и рекомендованных корректирующих и
предупреждающих действий в рамках процесса осуществления общего
управления изменениями.
● Управление содержанием проекта используется также для управления
фактическими изменениями по мере их появления; оно интегрировано в
остальные процессы управления. Неуправляемые изменения часто называют
«сдвигом содержания проекта». Изменения в любом случае неизбежны, и
поэтому необходим процесс управления изменениями.

26. Контроль содержания- инструменты и выходы
Инструменты
● Анализ отклонений
● Для оценки величины используются метрики и измерения эффективности
проекта
● Важно определение причин отклонения по сравнению с базовым планом по
содержанию и определение корректирующих действий
Выходы:
● Информация об исполнении работ
● Запросы на изменения
● Обновления плана управления проектом
● Обновления базового плана по содержанию. Если одобренные запросы на
изменения оказывают влияние на содержание проекта, то описание
содержания, ИСР и словарь ИСР пересматриваются и выпускаются заново, чтобы
отразить одобренные изменения, в рамках процесса интегрированного контроля
изменений.
● Обновления прочих базовых планов.
● Обновления документов проекта
● Обновления активов процессов организации