- •Проекты и программы как объекты управления. Существующие трактовки понятия проект. Признаки проекта. Разновидности и классификация проектов и программ. (Глава 1 pmBoK 5)
- •Жизненный цикл и фазы проекта. Общая структура жизненного цикла проекта. (Глава 2 pmBoK 5)
- •Участники проекта. Состав участников проекта. Роль и функции основных участников проекта. (Глава 2 pmBoK 5)
- •Заинтересованные стороны проекта (Project Stakeholders). Их роль и значение в управлении проектом. (Глава 2,п.2.2, Глава 13 pmBoK 5)
- •Матрица распределения ответственности в проекте. Основные правила распределения обязанностей и ответственности в проекте. (Глава 9 pmBoK 5)
- •Стадии процесса управления проектом по временным параметрам. Основные задачи стадий процесса управления проектом по временным параметрам. (Глава 6 pmBoK 5)
- •Методы критического пути (Critical Path Method, cpm) и критической цепи (Critical Chain Method, ccm) и их применение в управлении проектами. (Глава 6, п.6.6.2.2 и 6.6.2.3 pmBoK 5)
- •Управление стоимостью и финансами проекта. Роль и значение процессов управления стоимостью и финансами в проекте. Основные инструменты управления финансами в проекте. (Глава 7 pmBoK 5)
- •Метод освоенного объема и его применение в управлении проектами. Основные показатели метода освоенного объема. (Глава 7, п.7.4.2 pmBoK 5)
- •Стадии процесса управления стоимостью и финансами проекта. Основные задачи стадий процесса управления стоимостью и финансами проекта. (Глава 7 pmBoK 5)
Матрица распределения ответственности в проекте. Основные правила распределения обязанностей и ответственности в проекте. (Глава 9 pmBoK 5)
уществуют различные форматы документирования распределения ролей и сфер ответственности членов команды. Большинство форматов относятся к одному из трех типов (рис. 9-4): иерархический, матричный и текстовый. Кроме того, некоторые назначения по проекту указываются во вспомогательных планах, например в планах управления рисками, качеством или коммуникациями. Независимо от того, какой метод используется, цель всегда одна — добиться того, чтобы для каждого пакета работ был назначен однозначный ответственный за его исполнение и чтобы каждый член команды четко понимал свою роль и сферу ответственности. Например, для представления ролей высокого уровня можно использовать иерархический формат, текстовый формат лучше подходит для подробного документирования сфер ответственности. Иерархические диаграммы. Для отображения должностей и отношений в графическом формате сверху вниз можно использовать структуру традиционной организационной диаграммы. Одним из способов обобщенного представления сфер ответственности высокого уровня является иерархическая структура работ (ИСР), основное назначение которой заключается в разделении поставляемых результатов проекта на пакеты работ. Организационная структура работ (OBS) похожа на ИСР, но организована не по поставляемым результатам проекта, а в соответствии с имеющейся структурой подразделений организации (отделов, групп или команд). Под каждым отделом указан список операций проекта или пакеты работ. Таким образом, конкретный функциональный отдел может узнать обо всех своих обязанностях по проекту (например, отдел информационных технологий или отдел закупок), изучив свою часть OBS. Иерархическая структура ресурсов (resource breakdown structure, RBS) дает иерархическое представление ресурсов по категории и типу, используемых для облегчения планирования и контроля работ проекта. Каждый более низкий уровень представляет более подробное описание ресурса. Последним уровнем иерархии является уровень с самым лаконичным описанием, достаточным для того, чтобы его можно было использовать вместе с иерархической структурой работ (ИСР) для планирования, мониторинга и контроля работы. Иерархическая структура ресурсов может быть полезна при контроле стоимости проекта и может использоваться согласно системе бухгалтерского учета, действующей в организации. Она также может содержать другие категории ресурсов, помимо человеческих.
Содержание проекта и управление содержанием проекта. Роль и значение процессов управления содержанием в проекте. Стадии процесса управления содержанием проекта. Основные задачи стадий процесса управления содержанием проекта.
Содержание проекта. Работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с заданными свойствами и функциями. Термин «содержание проекта» иногда включает в себя содержание продукта. Процессы, используемые для управления содержанием проекта, а также обеспечивающие их выполнение инструменты и методы могут различаться в зависимости от проекта. Базовым планом проекта по содержанию являются одобренная версия описания содержания проекта, иерархическая структура работ (ИСР) и соответствующий словарь ИСР. Базовый план может быть изменен только с помощью формальных процедур контроля изменений и используется как база для сравнения при исполнении процессов подтверждения содержания и контроля содержания, а также других процессов контроля. 5.1.2 Планирование управления содержанием: инструменты и методы
5.1.2.1 Экспертная оценка
Экспертная оценка — это суждение, полученное от знающих и опытных сторон. Экспертное заключение могут давать как группы, так и отдельные лица, имеющие специальное образование, знания, навыки, опыт или подготовку в области разработки планов управления содержанием.
5.1.2.2 Совещания
Команды проекта могут участвовать в совещаниях проекта по разработке плана управления проектом. Среди участников таких совещаний могут быть руководитель проекта, спонсор проекта, определенные участники команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за какие-либо процессы управления содержанием, и, при необходимости, другие лица.
5.1.3 Планирование управления содержанием: выходы
5.1.3.1 План управления содержанием
План управления содержанием — компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. План управления содержанием — это основной вход процесса разработки плана управления проектом и остальных процессов управления содержанием. Компоненты плана управления содержанием включают в себя: • процесс подготовки подробного описания содержания проекта; • процесс, который позволяет создавать ИСР из подробного описания содержания проекта; • процесс, который определяет, как ИСР будет поддерживаться и одобряться; • процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта; • процесс контроля обработки запросов на изменения в отношении подробного описания содержания проекта. Этот процесс напрямую связан с процессом интегрированного контроля изменений (раздел 4.5). План управления содержанием может быть формальным и неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта.
5.1.3.2 План управления требованиями
План управления требованиями — это компонент плана управления проектом, описывающий способы анализа, документирования требований и управления ими. Взаимосвязи между фазами, описанные в разделе 2.4.2.1, существенно влияют на порядок управления требованиями. Руководитель проекта выбирает наиболее эффективный тип взаимосвязей для проекта и документирует данный подход в плане управления требованиями. Многие компоненты плана управления требованиями основаны на этом типе взаимосвязей.
Компоненты плана управления требованиями могут включать в себя, среди прочего: • порядок планирования, отслеживания и составления отчетов о действиях в отношении требований; • действия по управлению конфигурацией, такие как порядок инициирования изменений продукта, порядок анализа воздействий, их выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений; • процесс приоритезации требований; • используемые метрики продукта и обоснование их использования; • структуру отслеживания, т. е. какие параметры требований будут отражены в матрице отслеживания.
5.2 Сбор требований
Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержанием проекта, включая содержание продукта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-4. На рис. 5-5 показана диаграмма потоков данных процесса. На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или возможности, которым должен соответствовать проект или которые должен иметь продукт, услуга или результат, чтобы удовлетворить соглашению или другой формальной предписанной спецификации. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и зарегистрированы со степенью детализации, достаточной для того, чтобы их включить в базовый план по содержанию и измерять после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и иногда закупок основывается на данных требованиях. Разработка требований начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), в реестре заинтересованных сторон (раздел 13.1.3.1) и в плане управления заинтересованными сторонами (раздел 13.2.3.1).
Многие организации подразделяют требования на различные типы, например бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние — к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя: • Бизнес-требования, описывающие высокоуровневые потребности организации в целом, например проблемы или благоприятные возможности организации, а также причины, по которым проект был предпринят. • Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон. • Требования к решению, описывающие свойства, функции и характеристики продукта, услуги или результата, который удовлетворит бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования: ○ Функциональные требования описывают поведение продукта. Примеры включают в себя процессы, данные и взаимодействия с продуктом. ○ Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д. • Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем. • Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект. • Требования к качеству, включающие в себя любое состояние или критерий, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту.
Структурная декомпозиция проекта (WBS) как основа определения содержания проекта и инструмент управления проектом. Методы разработки WBS. Планирование методом набегающей волны. (Глава 5 PMBoK 5)
ИСР — это иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов. ИСР организует и определяет общее содержание проекта и отображает работы, указанные в текущем одобренном описании содержания проекта.
Запланированные работы содержатся в элементах ИСР самого нижнего уровня, которые называются пакетами работ. Пакет работ может использоваться для группировки операций, на уровне которых составляется расписание работ и проводится их оценка, осуществляется мониторинг и контроль. В контексте ИСР «работа» означает продукты или поставляемые результаты работ, являющиеся результатами операций, но не сами операции. 5.4.2.1 Декомпозиция
Декомпозиция — это метод, предполагающий разбиение содержания и поставляемых результатов проекта на более мелкие и легко управляемые элементы. Пакет работ — это элемент работ, расположенный на самом низком уровне иерархической структуры работ, для которого возможна оценка стоимости и длительности, а также управление ими. На уровень декомпозиции зачастую влияет степень контроля, необходимого для эффективного управления проектом. Уровень детализации пакетов работ различается в зависимости от масштаба и сложности проекта. Декомпозиция всей совокупности работ проекта до пакетов работ обычно включает в себя следующие операции: • определение и анализ поставляемых результатов и соответствующих работ; • структурирование и организацию ИСР; • декомпозицию верхних уровней ИСР на детализированные компоненты более низких уровней; • разработку и присвоение идентификационных кодов компонентам ИСР; • проверку приемлемости степени декомпозиции поставляемых результатов. 5.4.2.2 Экспертная оценка
Экспертная оценка часто используется для анализа информации, необходимой для декомпозиции поставляемых результатов проекта до меньших компонентов с целью создания эффективной ИСР. Такая экспертная оценка и экспертиза применяются в отношении технических деталей содержания проекта и используются для устранения разногласий по поводу наилучшего разбиения всего содержания проекта. Данную экспертизу могут предоставлять как группы, так и отдельные лица, имеющие специальное образование, знания, опыт или подготовку по аналогичным проектам или областям бизнеса. Экспертную оценку также можно получить в виде предварительно определенных шаблонов, помогающих эффективно разложить на компоненты типовые поставляемые результаты. Такие шаблоны могут использоваться в конкретной отрасли или дисциплине или могут быть созданы в процессе работы над подобными проектами. Руководитель проекта в сотрудничестве с командой проекта определяет окончательную декомпозицию содержания проекта до отдельных пакетов работ, которые будут использоваться для эффективного управления работами проекта. Структура ИСР может создаваться с помощью различных подходов. Некоторые популярные методы включают принцип нисходящего анализа, использование руководящих указаний конкретных организаций и применение шаблонов ИСР. Во время интеграции подкомпонентов можно использовать принцип восходящего анализа. Структура ИСР может быть создана в различных формах, например: • в качестве второго уровня декомпозиции используются фазы жизненного цикла проекта, на третьем уровне расположены поставляемые результаты, относящиеся к проекту и продукту, как показано на рис. 5-12; • в качестве второго уровня декомпозиции используются основные поставляемые результаты, как показано на рис. 5-13; • используются подкомпоненты, которые могут разрабатываться организациями, не входящими в команду проекта, например работающими по договору. В таких случаях продавец разрабатывает поддерживающую договор ИСР как часть работы по договору. Для декомпозиции компонентов ИСР верхнего уровня требуется разделение работ по каждому поставляемому результату или подкомпонентам на основополагающие элементы, где компоненты ИСР представляют собой поддающиеся проверке продукты, услуги или результаты. ИСР может быть структурирована в виде схемы, организационной диаграммы или другим методом, отражающим иерархическое разбиение. Проверка правильности декомпозиции требует удостоверения в том, что компоненты ИСР низкого уровня — это именно те компоненты, которые необходимы и достаточны для создания соответствующих поставляемых результатов более высокого уровня. Различные поставляемые результаты могут иметь различные уровни декомпозиции. Работы по некоторым поставляемым результатам достаточно декомпозировать всего лишь до следующего уровня, чтобы достичь уровня пакетов работ, однако для других могут потребоваться дополнительные уровни декомпозиции. По мере декомпозиции работ до более глубоких уровней детализации возможность планирования, управления и контроля работ расширяется. Однако чрезмерная декомпозиция может привести к непродуктивным управленческим трудозатратам, неэффективному использованию ресурсов, снижению эффективности выполнения работ и сложности консолидации данных различных уровней ИСР.
Декомпозиция может оказаться невозможной для поставляемых результатов или подкомпонентов, которые будут выполняться в далеком будущем. Команда управления проектом обычно дожидается согласования поставляемого результата или подкомпонента, чтобы иметь возможность разработать соответствующие детали ИСР. Этот метод иногда называют «планированием методом набегающей волны».
ИСР отображает все работы, связанные с продуктом и проектом, включая работы по управлению проектом. Все содержание работ на самых нижних уровнях должно сворачиваться в более высокие уровни, чтобы ничего не было пропущено и не выполнялась лишняя работа. Иногда это называют «правилом 100 %».
Для получения дополнительной информации по ИСР обратитесь к Практическому стандарту по иерархическим структурам работ – Второму изданию (Practice Standard for Work Breakdown Structures – Second Edition) [7]. Этот стандарт содержит конкретные отраслевые примеры шаблонов ИСР, которые могут быть адаптированы к конкретным проектам в определенных прикладных областях.
5.4.3 Создание ИСР: выходы
5.4.3.1 Базовый план по содержанию
Базовый план по содержанию — это одобренная версия описания содержания, иерархической структуры работ (ИСР) и связанного с ними словаря ИСР, которая может быть изменена только с помощью формальных процедур контроля изменений и используется как основа для сравнения. Он является компонентом плана управления проектом. Компоненты базового плана по содержанию включают в себя: • Описание содержания проекта. Описание содержания проекта включает в себя изложение содержания проекта, основных поставляемых результатов, допущений и ограничений. • ИСР. ИСР — это иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов. Каждый нисходящий уровень ИСР включает все более подробное определение работ проекта. ИСР окончательно оформляется с помощью отнесения каждого пакета работ к тому или иному контрольному счету и присвоения каждому пакету работ уникального идентификатора по коду учета. Данные идентификаторы предоставляют структуру для иерархического суммирования информации о стоимости, расписании и ресурсах. Контрольный счет — это элемент управления, посредством которого содержание, бюджет, фактическая стоимость и расписание объединяются и сравниваются с освоенным объемом для измерения исполнения. Контрольные счета помещаются в выбранных точках управления в ИСР. Каждый контрольный счет может включать один или несколько пакетов работ, но каждый пакет работ должен быть привязан только к одному контрольному счету. Контрольный счет может включать в себя один или несколько пакетов планирования. Пакет планирования — это компонент иерархической структуры работ, отнесенный к контрольному счету, с известным содержанием работ, но без детальных операций расписания. • Словарь ИСР. Словарь ИСР — это документ, в котором содержится подробная информация о поставляемых результатах, операциях и расписании в отношении каждого компонента в ИСР. Словарь ИСР представляет собой документ, который дополняет ИСР. Информация в словаре ИСР включает в себя, среди прочего: ○ идентификатор кода учета, ○ описание работ, ○ допущения и ограничения, ○ ответственную организацию, ○ контрольные события расписания, ○ связанные операции расписания, ○ требуемые ресурсы, ○ оценки стоимости, ○ требования к качеству, ○ критерии приемки, ○ технические ссылки, ○ информацию по соглашениям.
5.4.3.2 Обновления документов проекта
Документы проекта, которые могут быть обновлены, включают в себя, среди прочего, документацию по требованиям, которая может потребовать обновления для включения в свой состав одобренных изменений. Если в результате процесса создания ИСР появляются одобренные запросы на изменения, может потребоваться обновление документации по требованиям для включения в ее состав одобренных изменений. 6.2.2.2 Планирование методом набегающей волны
Планирование методом набегающей волны — это метод итеративного планирования, при котором работа, которую надо будет выполнить в ближайшей перспективе, планируется подробно, в то время как далеко отстоящая работа планируется с меньшей степенью детализации. Это одна из форм последовательного уточнения. Таким образом, работа может существовать на разных уровнях детализации в зависимости от того, на какой стадии жизненного цикла проекта она находится. Во время раннего стратегического планирования, когда информация еще недостаточно определена, пакеты работ могут быть декомпозированы до известного уровня детализации. По мере поступления информации о предстоящих в ближайшей перспективе событиях может быть проведена декомпозиция пакетов работ до операций.
Управление проектом по временным параметрам. Роль и значение процессов управления проектом по временным параметрам. Основные инструменты управления проектом по временным параметрам. (Глава 6 PMBoK
Планирование управления расписанием: инструменты и методы
6.1.2.1 Экспертная оценка
Экспертная оценка, основанная на исторической информации, предоставляет ценные данные о среде и информацию из предыдущих подобных проектов. Также экспертная оценка может указать на необходимость сочетания методов и указать, как урегулировать различия между ними.
Для разработки плана управления расписанием следует использовать суждения, основанные на компетентности в прикладной области, области знаний, сфере деятельности, отрасли и т. д., соответствующих выполняемой операции.
6.1.2.2 Аналитические методы
Процесс планирования управления расписанием может включать в себя выбор стратегических средств для оценки проекта и составления его расписания, например методологию, инструменты и методы составления расписания, подходы по оценке, форматы и программное обеспечение для управления проектом. План управления расписанием также может подробно описывать способы быстрого прохода или сжатия (раздел 6.6.2.7) расписания проекта, например параллельное исполнение работ. Подобно другим решениям в отношении расписания, влияющим на проект, эти решения могут оказывать воздействие на риски проекта. Организационные политики и процедуры могут влиять на выбор методов составления расписания в рамках данных решений. Методы могут включать в себя, среди прочего, планирование методом набегающей волны (раздел 6.2.2.2), опережения и задержки (раздел 6.3.2.3), анализ альтернатив (раздел 6.4.2.2) и методы анализа исполнения расписания (раздел 6.7.2.1).
6.1.2.3 Совещания
Команды проекта могут проводить совещания по планированию для разработки плана управления расписанием. Среди участников таких совещаний могут быть руководитель проекта, спонсор проекта, определенные члены команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за планирование или исполнение расписания, и, при необходимости, другие лица.
6.1.3 Планирование управления расписанием: выходы
6.1.3.1 План управления расписанием
Компонент плана управления проектом, устанавливающий критерии и действия по разработке, мониторингу расписания и контролю за ним. План управления расписанием может быть формальным или неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта и включает в себя соответствующие контрольные пороги.
Например, план управления расписанием может устанавливать следующие аспекты: • Разработка модели расписания проекта. Указываются методология и инструмент составления расписания, которые будут использоваться для разработки модели расписания проекта. • Степень точности. Указывается приемлемый диапазон, который будет использоваться в рамках реалистичной оценки длительности операций. Он может включать в себя возможные потери. • Единицы измерения. Для каждого ресурса определяются все единицы, которые будут использоваться в ходе измерений (например, человеко-часы, человеко-дни, недели для оценки времени или метры, литры, тонны, километры, кубические ярды для количественной оценки). • Связь между процедурами организации. В ИСР (раздел 5.4) указаны рамки плана управления расписанием, которые обеспечивают соответствие оценкам и разработанным расписаниям. • Актуализация модели расписания проекта. Определяется процесс, используемый для обновления статуса проекта и записи прогресса проекта в модели расписания во время исполнения проекта. • Контрольные пороги. Для мониторинга исполнения расписания могут определяться пороги отклонений, что позволяет установить заранее согласованную величину вариации, при отклонении от которой становится необходимо предпринимать некоторые действия. Пороги обычно выражаются в виде процентных отклонений от параметров, установленных в базовом плане. • Правила измерения исполнения. Устанавливаются правила измерения исполнения для управления освоенным объемом (EVM) или для других физических измерений. Например, план управления расписанием может оговаривать: ○ правила расчета процента выполнения; ○ контрольные счета, на которых измеряется управление прогрессом и расписанием; ○ методы измерения освоенного объема (например, базовые планы, фиксированная формула, процент выполнения и т. д.), выбранные к применению (дополнительную информацию см. в Практическом стандарте управления освоенным объемом (Practice Standard for Earned Value Management)) [9]; ○ измерение исполнения расписания, например отклонение по срокам (ОСР) и индекс выполнения сроков (ИВСР), используемые для оценки величины отклонения от первоначального базового расписания. • Форматы отчетности. Определяются форматы и частота составления различных отчетов по расписанию. • Описания процессов. Документируется описание каждого процесса управления расписанием.
