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

I УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА: ПРОЦЕССЫ ПЛАНИРОВАНИЯ 1. Цель и ключевые составляющие управления содержанием проекта. Планирование управления содержанием Управление содержанием проекта включает в себя процессы, требуемые для обеспечения того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. Управление содержанием проекта непосредственно связано с определением и контролем того, что включено и что не включено в проект. На рис. 1 представлена общая схема процессов управления содержанием проекта, которые включают в себя следующее: 1. Планирование управления содержанием — процесс создания плана управления содержанием, документирующего, каким образом содержание проекта будет определяться, подтверждаться и контролироваться. 2. Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. 3. Определение содержания — процесс разработки подробного описания проекта и продукта. 4. Создание иерархической структуры работ (ИСР) — процесс разделения поставляемых результатов проекта и работ проекта на меньшие компоненты, которыми легче управлять. 5. Подтверждение содержания*—процесс формализованной приемки полученных поставляемых результатов проекта. 6. Контроль содержания **— процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию. Данные процессы взаимодействуют друг с другом и с процессами из других областей знаний. В контексте проекта термин «содержание» может обозначать: • Содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат. • Содержание проекта. Работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с заданными свойствами и функциями. Термин «содержание проекта» иногда включает в себя содержание продукта. *, ** - данные процессы рассматриваются в рамках Темы III (Лекция 1) Процессы, используемые для управления содержанием проекта, а также обеспечивающие их выполнение инструменты и методы могут различаться в зависимости от проекта. Базовым планом проекта по содержанию являются одобренная версия описания содержания проекта, иерархическая структура работ (ИСР) и соответствующий словарь ИСР. Базовый план может быть изменен только с помощью формальных процедур контроля изменений и используется как база для сравнения при исполнении процессов подтверждения содержания и контроля содержания, а также других процессов контроля. Выполнение содержания проекта измеряется относительно плана управления проектом. Реализация содержания продукта измеряется относительно требований к продукту. Процессы управления содержанием проекта должны быть хорошо интегрированы с процессами всех остальных областей знаний, чтобы работы проекта привели к созданию заданного содержания продукта. Рис. 1. Общая схема управления содержанием проекта Планирование управления содержанием Планирование управления содержанием — процесс создания плана управления содержанием, документирующего, каким образом содержание проекта будет определяться, подтверждаться и контролироваться. Ключевая выгода данного процесса состоит в том, что он предоставляет руководство и указания относительно управления содержанием проекта на протяжении всего проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 2. На рис. 3 показана диаграмма потоков данных процесса. Рис. 2. Планирование управления содержанием: входы, инструменты и методы, а также выходы Рис. 3. Диаграмма потоков данных планирования управления содержанием План управления содержанием — компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. Разработка плана управления содержанием и детализация содержания проекта начинается с анализа информации, содержащейся в уставе проекта, последних одобренных вспомогательных планов плана управления проектом, исторической информации, которая содержится в активах процессов организации и других соответствующих факторов среды предприятия. Данный план помогает снизить риск расползания содержания проекта. Планирование управления содержанием: входы План управления проектом Одобренные вспомогательные планы плана управления проектом используются для создания плана управления содержанием и оказывают влияние на подход, применяемый для планирования содержания и управления содержанием проекта. Устав проекта Устав проекта используется для предоставления контекста проекта, необходимого для планирования процессов управления содержанием. Он предоставляет высокоуровневое описание проекта и характеристики продукта из описания работ проекта. Факторы среды предприятия Факторы среды предприятия, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего: • организационную культуру, • инфраструктуру, • управление персоналом, • ситуацию на рынке. Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего: • политики и процедуры, • историческую информацию и базу накопленных знаний. Планирование управления содержанием: инструменты и методы Экспертная оценка Экспертная оценка — это суждение, полученное от знающих и опытных сторон. Экспертное заключение могут давать как группы, так и отдельные лица, имеющие специальное образование, знания, навыки, опыт или подготовку в области разработки планов управления содержанием. Совещания Команды проекта могут участвовать в совещаниях проекта по разработке плана управления проектом. Среди участников таких совещаний могут быть руководитель проекта, спонсор проекта, определенные участники команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за какие-либо процессы управления содержанием, и, при необходимости, другие лица. Планирование управления содержанием: выходы План управления содержанием План управления содержанием — компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. План управления содержанием — это основной вход процесса разработки плана управления проектом и остальных процессов управления содержанием. Компоненты плана управления содержанием включают в себя: • процесс подготовки подробного описания содержания проекта; • процесс, который позволяет создавать ИСР из подробного описания содержания проекта; • процесс, который определяет, как ИСР будет поддерживаться и одобряться; • процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта; • процесс контроля обработки запросов на изменения в отношении подробного описания содержания проекта. Этот процесс напрямую связан с процессом интегрированного контроля изменений. План управления содержанием может быть формальным и неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта. План управления требованиями План управления требованиями — это компонент плана управления проектом, описывающий способы анализа, документирования требований и управления ими. Взаимосвязи между фазами существенно влияют на порядок управления требованиями. Руководитель проекта выбирает наиболее эффективный тип взаимосвязей для проекта и документирует данный подход в плане управления требованиями. Многие компоненты плана управления требованиями основаны на этом типе взаимосвязей. Компоненты плана управления требованиями могут включать в себя, среди прочего: • порядок планирования, отслеживания и составления отчетов о действиях в отношении требований; • действия по управлению конфигурацией, такие как порядок инициирования изменений продукта, порядок анализа воздействий, их выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений; • процесс приоритезации требований; • используемые метрики продукта и обоснование их использования; • структуру отслеживания, т. е. какие параметры требований будут отражены в матрице отслеживания. 2. Сбор требований: сущность, инструменты и методы. Документация по требованиям Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержанием проекта, включая содержание продукта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 4. На рис. 5 показана диаграмма потоков данных процесса. Рис. 4. Сбор требований: входы, инструменты и методы, а также выходы Рис. 5. Диаграмма потоков данных сбора требований На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или возможности, которым должен соответствовать проект или которые должен иметь продукт, услуга или результат, чтобы удовлетворить соглашению или другой формальной предписанной спецификации. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и зарегистрированы со степенью детализации, достаточной для того, чтобы их включить в базовый план по содержанию и измерять после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и иногда закупок основывается на данных требованиях. Разработка требований начинается с анализа информации, содержащейся в уставе проекта, в реестре заинтересованных сторон и в плане управления заинтересованными сторонами. Многие организации подразделяют требования на различные типы, например бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние—к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя: • Бизнес-требования, описывающие высокоуровневые потребности организации в целом, например, проблемы или благоприятные возможности организации, а также причины, по которым проект был предпринят. • Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон. • Требования к решению, описывающие свойства, функции и характеристики продукта, услуги или результата, который удовлетворит бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования: • Функциональные требования описывают поведение продукта. Примеры включают в себя процессы, данные и взаимодействия с продуктом. • Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д. • Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем. • Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект. • Требования к качеству, включающие в себя любое состояние или критерий, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту. Сбор требований: входы План управления содержанием План управления содержанием разъясняет то, как команда проекта будет определять, какой тип требований необходимо собрать для проекта. План управления требованиями План управления требованиями задает процессы, используемые в рамках процесса сбора требований для определения и документирования потребностей заинтересованных сторон. План управления заинтересованными сторонами План управления заинтересованными сторонами используется для понимания требований заинтересованных сторон к коммуникациям и уровня их вовлечения с целью оценки и адаптации к уровню участия заинтересованных сторон в действиях в отношении требований. Устав проекта Устав проекта используется для предоставления высокоуровнего описания продукта, услуги или результата, позволяющего разработать детальные требования. Реестр заинтересованных сторон Реестр заинтересованных сторон используется для определения заинтересованных сторон, которые могут предоставить информацию о требованиях. Реестр заинтересованных сторон также включает в себя важнейшие требования и основные ожидания заинтересованных сторон, которые они могут иметь в отношении проекта. Сбор требований: инструменты и методы Интервью Интервью представляют собой формальный или неформальный подход, используемый для получения информации у заинтересованных сторон путем прямого разговора с ними. Обычно в ходе интервью задают подготовленные и непосредственно возникающие вопросы и записывают ответы. Интервью часто проводятся на индивидуальной основе между интервьюером и интервьюируемым, но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых. Проведение интервью с опытными участниками проекта, спонсорами и другими представителями руководства, а также экспертами по предметной области может помочь в выявлении и определении характеристик и функций желаемых продуктов (поставляемых результатов). Интервью также помогают в получении конфиденциальной информации. Фокус-группы Фокус-группы позволяют собрать вместе заранее выбранных заинтересованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отношения к предложенному продукту, услуге или результату. Подготовленный модератор направляет интерактивное обсуждение группы, построенное так, чтобы оно было более разговорным, чем индивидуальное интервью. Семинары с участием модератора Семинары с участием модератора (facilitated workshops) представляют собой сфокусированные обсуждения, объединяющие ключевые заинтересованные стороны с целью определения требований к продукту. Семинары используются в качестве основного метода, позволяющего быстро определить межфункциональные требования и урегулировать различия между требованиями заинтересованных сторон. В силу особенностей формата групповой работы, хорошо скоординированные обсуждения помогают развить доверие, выстроить отношения и наладить общение между участниками, что может привести к повышению уровня согласия между заинтересованными сторонами. Кроме этого, проблемы могут быть обнаружены и решены быстрее, чем при индивидуальных обсуждениях. Например, в области разработки программного обеспечения используются семинары с участием модератора под названием «Совместная разработка/проектирование приложений» (joint application development/design, JAD). Данные обсуждения с участием модератора сконцентрированы на том, чтобы собрать вместе бизнес-экспертов по предметной области и команду разработчиков для улучшения процесса разработки программного продукта. В производственных отраслях существует «Развертывание функций качества» (quality function deployment, QFD) — это еще один пример семинара с участием модератора, который помогает определить критически важные характеристики для разработки нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (voice of the customer, VOC). Затем данные потребности объективно сортируются и приоритезируются, а также устанавливаются цели для их достижения. Во время семинаров по требованиям зачастую разрабатываются пользовательские истории — краткие текстовые описания требуемой функциональности. Пользовательские истории описывают заинтересованную сторону, которая получает пользу от свойства продукта (роль), что заинтересованной стороне необходимо достичь (цель) и пользу для заинтересованной стороны (мотивацию). Пользовательские истории широко используются в рамках гибких (agile) методов. Методы группового творчества Для выявления требований к проекту и продукту могут организовываться различные групповые мероприятия. Ниже представлены некоторые из методов группового творчества: • Мозговой штурм. Метод, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к проекту и продукту. Хотя сам по себе мозговой штурм не включает голосование или приоритезацию, его часто используют с другими методами группового творчества, которые предусматривают данные процессы. • Метод номинальных групп. Метод, расширяющий мозговой штурм путем процесса голосования, используемого для ранжирования наиболее полезных идей для последующего мозгового штурма или приоритезации. • Построение ассоциативных карт. Метод, в котором идеи, возникшие во время отдельных сессий мозгового штурма, объединяются в одну карту с целью отражения общности и различий в понимании и для генерирования новых идей. • Диаграмма сходства. Метод, позволяющий классифицировать большое количество идей по группам с целью обзора и анализа. • Анализ решений на основе множества критериев. Метод, использующий матрицу решений для обеспечения систематического аналитического подхода к установлению критериев, таких как уровни рисков, неопределенность и определение ценности, для оценивания и ранжирования многочисленных идей. Методы группового принятия решения Метод группового принятия решений — это процесс оценки различных альтернатив с ожидаемым результатом в форме будущих действий. Данные методы могут быть использованы для создания, классификации и приоритезации требований к продукту. Существуют различные методы принятия группового решения, например: • Единогласие. Принятие решения посредством согласия каждого с единым курсом действий. Один из способов достижения единогласия — это метод Дельфи, при котором группа выбранных экспертов отвечает на вопросы анкет, а также высказывает мнение относительно ответов, полученных в течение каждого раунда сбора требований. Для обеспечения анонимности доступ к ответам имеет только модератор. • Большинство. Решение, которое принимается при поддержке более чем 50 % участников группы. Наличие в группе нечетного количества участников может обеспечить принятие решения и исключить ситуацию равного количества голосов. • Относительное большинство. Выбирается решение самого большого блока в группе, даже если не достигнуто большинство голосов. Данный метод обычно используется, когда предлагается более двух вариантов для выбора. • Диктатура. Данный метод предполагает, что одно лицо принимает решение за всю группу. Все данные методы группового принятия решений можно применять в рамках методов группового творчества, которые используются в процессе сбора требований. Анкеты и опросы Анкеты и опросы представляют собой письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. Опросы и/или анкеты лучше всего подходят для работы с различными по составу аудиториями, когда требуется быстрый сбор информации, когда респонденты территориально распределены и где допускается применение статистического анализа. Наблюдения Наблюдения предоставляют непосредственный способ рассмотрения отдельных лиц в окружающей их обстановке, а также того, как они исполняют свои обязанности или задачи и выполняют процессы. Наблюдения особенно полезны для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают отчетливо изложить свои требования. Наблюдение также известно как «рабочая тень» (job shadowing). Оно обычно осуществляется внешним наблюдателем, следящим за тем, как бизнес-эксперт выполняет свою работу. Также наблюдения могут осуществляться «наблюдателем-участником», который фактически исполняет процесс или процедуру, чтобы узнать, как они выполняются, и выявить скрытые требования. Прототипы Прототипирование представляет собой метод получения предварительных отзывов относительно требований путем предоставления рабочей модели ожидаемого продукта, прежде чем создавать продукт в действительности. Поскольку прототипы реальны, это позволяет заинтересованным сторонам экспериментировать с моделью конечного продукта, а не ограничиваться обсуждением абстрактных представлений своих требований. Прототипы поддерживают концепцию последовательного уточнения в итеративных циклах создания экспериментальных моделей, проведения экспериментов пользователем, формирования отзывов и пересмотра прототипа. После проведения достаточного числа циклов обратной связи, требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к фазе проектирования или создания. Раскадровка (storyboarding) — это метод прототипирования, использующий последовательность или навигацию в рамках серии изображений или иллюстраций. Раскадровка используется в различных проектах во многих отраслях, например при создании фильмов, в рекламе, педагогическом проектировании, в проектах гибкой (agile) разработки и других проектах разработки программного обеспечения. При разработке программного обеспечения в раскадровке используются экспериментальные модели, чтобы продемонстрировать возможности навигации по веб-страницам, экранам или другим интерфейсам пользователей. Бенчмаркинг Бенчмаркинг — это сравнение используемых или запланированных к использованию практик, таких как процессы и операции, с практиками сопоставимых организаций для выявления лучших практик, генерирования идей в отношении улучшений и предоставления основы для измерения эффективности и результативности. Во время бенчмаркинга возможно сравнение как внутренних, так и внешних организаций. Контекстные диаграммы Контекстные диаграммы являются примером модели содержания. Контекстные диаграммы визуально отображают содержание продукта, показывая бизнес-систему (процесс, оборудование, компьютерную систему и т. д.) и то, как люди и другие системы (действующие лица) взаимодействуют с ней. Контекстные диаграммы демонстрируют входы бизнес- системы, действующих лиц, обеспечивающих вход, выходы бизнес-системы и действующих лиц, получающих выход. Анализ документов Анализ документов используется для выявления требований путем анализа существующей документации и идентификации информации, которая имеет отношение к требованиям. Существует множество документов, которые можно проанализировать для выявления надлежащих требований. Примеры документов, подлежащих анализу, включают в себя, среди прочего: бизнес-планы, маркетинговые материалы, соглашения, запросы предложений, действующий порядок процессов, логические модели данных, репозитории бизнес-правил, документацию по прикладному программному обеспечению, документацию по бизнес-процессам или интерфейсам, сценарии использования, другую документацию по требованиям, журналы проблем, политики, процедуры и нормативную документацию, такую как законы, кодексы или предписания и т. д. Сбор требований: выходы Документация по требованиям Документация по требованиям описывает, каким образом отдельные требования соответствуют бизнес-потребности в проекте. Требования могут быть сначала описаны высокоуровнево, а затем постепенно детализироваться по мере поступления новой информации о них. До включения в базовый план требования должны стать однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для ключевых заинтересованных сторон. Формат документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до более тщательно проработанных форм, содержащих резюме для руководства, подробные описания и приложения. Компоненты документации по требованиям могут включать в себя, среди прочего: Бизнес-требования, включая: ◦ цели организации и проекта для возможности отслеживания; ◦ бизнес-правила для исполняющей организации; ◦ руководящие принципы организации. • Требования заинтересованных сторон, включая: ◦ воздействие на другие области организации; ◦ воздействие на другие субъекты внутри или за пределами исполняющей организации; ◦ требования к коммуникациям и отчетности для заинтересованных сторон. • Требования к решению, включая: ◦ функциональные и нефункциональные требования; ◦ требования соответствия технологиям и стандартам; ◦ требования к поддержке и обучению; ◦ требования к качеству; ◦ требования к отчетности и т. д. (требования к решению могут быть документированы в виде текста, моделей или используя оба метода). • Требования к проекту, такие как: ◦ уровни обслуживания, производительности, безопасности, соответствия и т.д.; ◦ критерии приемки. • Требования к переходу. • Допущения, зависимости и ограничения в отношении требований. Матрица отслеживания требований Матрица отслеживания требований — это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов. Применение матрицы отслеживания требований помогает удостовериться, что каждое требование добавляет бизнес-ценность, связывая требование с целями организации и проекта. Это позволяет отслеживать требования на протяжении жизненного цикла проекта, что помогает удостовериться в том, что требования, одобренные в документации по требованиям, выполнены в конце проекта. Наконец, матрица отслеживания требований обеспечивает структуру для управления изменениями содержания продукта. Отслеживание включает в себя, среди прочего, отслеживание требований в следующих аспектах: • бизнес-потребности, а также благоприятные возможности, цели и задачи организации; • цели проекта; • содержание проекта/поставляемые результаты ИСР; • проектирование продукта; • разработка продукта; • стратегия и сценарии тестирования; • детализация от высокоуровневых до более детальных требований. Параметры, связанные с каждым требованием, могут быть зафиксированы в матрице отслеживания требований. Данные параметры помогают определить ключевую информацию относительно требований. Типичные параметры, используемые в матрице отслеживания требований, могут включать в себя: уникальный идентификатор, текстовое описание требования, обоснование включения в список требований, владельца требования, источник, приоритет, версию, текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено) и дату статуса. Дополнительные параметры, позволяющие удостовериться, что требование удовлетворяет заинтересованные стороны проекта, могут включать в себя также стабильность, сложность и критерии приемки. На рис. 6 представлен пример матрицы отслеживания требований с включенными в нее параметрами требований. Рис. 6. Пример матрицы отслеживания требований Библиографический список к Лекции №1 (Тема 1): 1. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 2. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. I УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА: ПРОЦЕССЫ ПЛАНИРОВАНИЯ 3. Базовый план по содержанию: описание содержания; иерархическая структура работ (ИСР); словарь ИСР 3.1. Определение содержания: элементы, инструменты и методы Определение содержания — процесс разработки подробного описания проекта и продукта. Ключевая выгода данного процесса состоит в том, что он описывает границы продукта, услуги или результата путем определения того, какие из собранных требований будут включены в содержание проекта и какие исключены из него. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 7. На рис. 8 показана диаграмма потоков данных процесса. Рис. 7. Определение содержания: входы, инструменты и методы, а также выходы Рис. 8. Диаграмма потоков данных определения содержания Поскольку в проект невозможно включить все требования, выявленные в процессе сбора требований, в ходе процесса определения содержания из документации по требованиям, полученной в рамках процесса сбора требований, отбираются окончательные требования к проекту. Затем создается подробное описание проекта, а также продукта, услуги или результата. Подготовка подробного описания содержания проекта чрезвычайно важна для успеха проекта и основывается на основных поставляемых результатах, допущениях и ограничениях, документированных во время инициации проекта. Содержание проекта определяется во время планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты и добавляются или актуализируются по мере необходимости. Процесс определения содержания может быть в высокой степени итеративным. В проектах с итеративным жизненным циклом высокоуровневое видение разрабатывается для всего проекта, но подробное содержание определяется последовательно в процессе каждой итерации, а детализированное планирование следующей итерации осуществляется по мере выполнения работ в отношении текущего содержания и поставляемых результатов проекта. Определение содержания: входы План управления содержанием План управления содержанием — это компонент плана управления проектом, задающий действия по разработке, мониторингу и контролю содержания проекта. Устав проекта Устав проекта предоставляет высокоуровневое описание проекта и высокоуровневые характеристики продукта. Кроме того, он содержит требования к одобрению проекта. Если в исполняющей организации не применяется устав проекта, необходимо получить или подготовить аналогичную информацию, которую следует использовать в качестве основы для подробного описания содержания проекта. Организации, которые не разрабатывают формальный устав проекта, обычно проводят неформальный анализ для выявления информации, необходимой для дальнейшего планирования содержания. Документация по требованиям Документация используется для отбора требований, которые будут включены в проект. Активы процессов организации Активы процессов организации могут воздействовать на определение содержания. Примеры включают в себя, среди прочего: • политики, процедуры и шаблоны описания содержания проекта; • архивы предыдущих проектов; • извлеченные уроки из предыдущих фаз или проектов. Определение содержания: инструменты и методы Экспертная оценка Экспертная оценка часто используется для анализа информации, необходимой для разработки описания содержания проекта. Подобная оценка и экспертиза применяются в отношении любых технических деталей. Такая экспертиза предоставляется любым лицом или группой лиц, обладающими специальными знаниями или подготовкой, и доступна из множества источников, включающих в себя, среди прочего, следующие: • другие подразделения в рамках организации; • консультанты; • заинтересованные стороны, в том числе заказчики или спонсоры; • профессиональные и технические ассоциации; • промышленные группы; • эксперты по предметной области. Анализ продукта Анализ продукта может стать результативным инструментом для проектов, поставляемым результатом которых является продукт, в отличие от услуги или результата. В каждой прикладной области существует один или несколько общепринятых методов перевода высокоуровневых описаний продукта в описание осязаемых поставляемых результатов. Анализ продукта включает в себя методы, такие как иерархическое разбиение продукта, системный анализ, анализ требований, системная инженерия, функционально-стоимостной анализ и анализ ценности Формирование альтернатив Формирование альтернатив — это метод, используемый для разработки как можно большего количества возможных вариантов для определения различных подходов к выполнению работ проекта. Может применяться множество методов общего менеджмента, таких как мозговой штурм, латеральное мышление, анализ альтернатив и т. д. Семинары с участием модератора Участие в данных интенсивных рабочих обсуждениях ключевых сторон с различными ожиданиями и/или специализирующихся в различных областях помогает достичь межфункционального и общего понимания целей и границ проекта. Определение содержания: выходы Описание содержания проекта Описание содержания проекта — это изложение содержания проекта, основных поставляемых результатов, допущений и ограничений. Описание содержания проекта документирует все содержание, включая содержание проекта и продукта. В нем детально описаны поставляемые результаты проекта и работы, которые необходимо выполнить для получения этих поставляемых результатов. Описание содержания проекта также формулирует общее понимание содержания проекта заинтересованными сторонами. Оно может содержать явные исключения из содержания, что может помочь в управлении ожиданиями заинтересованных сторон. Оно позволяет команде проекта осуществлять более детальное планирование, направляет работу команды проекта во время исполнения и предоставляет базовый план для оценки того, попадают ли запросы на изменения или дополнительная работа в границы проекта. Степень и уровень детализации, с которой описание содержания проекта определяет работу, которая будет выполнена, и работу, которая исключена, могут помочь определить, насколько хорошо команда управления проектом может контролировать содержание всего проекта. Подробное описание содержания проекта либо непосредственно, либо в виде ссылок на другие документы включает в себя: • Описание содержания продукта. Последовательно уточняет характеристики продукта, услуги или результата, описанного в уставе проекта или в документации по требованиям. • Критерии приемки. Набор условий, которые должны быть выполнены до того, как поставляемые результаты будут приняты. • Поставляемый результат. Любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Поставляемые результаты также включают в себя вспомогательные результаты, такие как отчеты и документы по управлению проектом. Данные поставляемые результаты могут быть описаны обобщенно или с высокой степенью детализации. • Исключения из проекта. Как правило, определяет, что исключено из проекта. Явная формулировка того, что именно находится вне содержания проекта, помогает управлять ожиданиями заинтересованных сторон. • Ограничения. Ограничивающий фактор, влияющий на ход исполнения проекта или процесса. Ограничения, выявленные в описании содержания проекта, перечисляют и описывают конкретные внутренние или внешние пределы или ограничивающие условия проекта, связанные с его содержанием, которые оказывают влияние на исполнение проекта, например предопределенный бюджет, любые ограничивающие даты или контрольные события расписания, которые определены заказчиком или исполняющей организацией. Когда проект выполняется в рамках соглашения, положения этого соглашения, как правило, являются ограничениями. Информация об ограничениях может быть указана в описании содержания проекта или в отдельном журнале. • Допущения. Фактор в рамках процесса планирования, который считается верным, реальным или определенным без предоставления доказательств и без демонстрации. Также описывается потенциальное воздействие данных факторов в случае, если они окажутся ошибочными. Команды проектов часто выявляют, документируют и подтверждают допущения в рамках проводимого ими процесса планирования. Информация о допущениях может быть указана в описании содержания проекта или в отдельном журнале. Хотя устав проекта и описание содержания проекта иногда воспринимаются как материалы, в определенной степени дублирующие друг друга, они различаются уровнем детализации. Устав проекта содержит высокоуровневую информацию, а описание содержания проекта — подробное описание элементов содержания. Данные элементы последовательно уточняются в течение проекта. В таблице 1 описаны некоторые из основных элементов каждого документа. Таблица 1 Элементы устава проекта и описания содержания проекта Обновления документов проекта Документы проекта, которые могут быть обновлены, включают в себя, среди прочего: • реестр заинтересованных сторон, • документацию по требованиям, • матрицу отслеживания требований. 3.2. Создание ИСР: сущность, значение, инструменты и методы. Словарь ИСР. Создание иерархической структуры работ (ИСР) — это процесс разделения поставляемых результатов проекта и работ проекта на меньшие компоненты, которыми легче управлять. Ключевая выгода данного процесса состоит в том, что он предоставляет структурированное видение того, чего необходимо достичь. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 9. На рис. 10 показана диаграмма потоков данных процесса. Рис.9. Создание ИСР: входы, инструменты и методы, а также выходы Рис. 10. Диаграмма потоков данных создания ИСР ИСР — это иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов. ИСР организует и определяет общее содержание проекта и отображает работы, указанные в текущем одобренном описании содержания проекта. Запланированные работы содержатся в элементах ИСР самого нижнего уровня, которые называются пакетами работ. Пакет работ может использоваться для группировки операций, на уровне которых составляется расписание работ и проводится их оценка, осуществляется мониторинг и контроль. В контексте ИСР «работа» означает продукты или поставляемые результаты работ, являющиеся результатами операций, но не сами операции. Создание ИСР: входы План управления содержанием План управления содержанием определяет процедуру создания ИСР из подробного описания содержания проекта, а также порядок поддержки и одобрения ИСР. Описание содержания проекта Описание содержания проекта описывает работы, которые будут исполнены, и исключенные работы. В нем также перечислены и описаны конкретные внутренние или внешние пределы или ограничивающие условия, которые могут повлиять на исполнение проекта. Документация по требованиям Подробная документация по требованиям важна для понимания того, что должно быть произведено в качестве результата проекта и что необходимо сделать, чтобы реализовать проект и предоставить его конечные продукты. Факторы среды предприятия Отраслевые стандарты ИСР, имеющие отношение к характеру проекта, могут использоваться в качестве внешних справочных материалов в ходе создания ИСР. Например, в инженерных проектах можно использовать стандарт ISO/IEC 15288 «Системная инженерия. Процессы жизненного цикла систем», чтобы создать ИСР для нового проекта. Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс создания ИСР, включают в себя, среди прочего: • политики, процедуры и шаблоны для ИСР; • архивы предыдущих проектов; • извлеченные уроки из предыдущих проектов. Создание ИСР: инструменты и методы Декомпозиция Декомпозиция — это метод, предполагающий разбиение содержания и поставляемых результатов проекта на более мелкие и легко управляемые элементы. Пакет работ — это элемент работ, расположенный на самом низком уровне иерархической структуры работ, для которого возможна оценка стоимости и длительности, а также управление ими. На уровень декомпозиции зачастую влияет степень контроля, необходимого для эффективного управления проектом. Уровень детализации пакетов работ различается в зависимости от масштаба и сложности проекта. Декомпозиция всей совокупности работ проекта до пакетов работ обычно включает в себя следующие операции: • определение и анализ поставляемых результатов и соответствующих работ; • структурирование и организацию ИСР; • декомпозицию верхних уровней ИСР на детализированные компоненты более низких уровней; • разработку и присвоение идентификационных кодов компонентам ИСР; • проверку приемлемости степени декомпозиции поставляемых результатов. На рис. 11 показана часть ИСР с некоторыми ответвлениями ИСР, декомпозированными до уровня пакетов работ. Экспертная оценка Экспертная оценка часто используется для анализа информации, необходимой для декомпозиции поставляемых результатов проекта до меньших компонентов с целью создания эффективной ИСР. Такая экспертная оценка и экспертиза применяются в отношении технических деталей содержания проекта и используются для устранения разногласий по поводу наилучшего разбиения всего содержания проекта. Данную экспертизу могут предоставлять как группы, так и отдельные лица, имеющие специальное образование, знания, опыт или подготовку по аналогичным проектам или областям бизнеса. Экспертную оценку также можно получить в виде предварительно определенных шаблонов, помогающих эффективно разложить на компоненты типовые поставляемые результаты. Такие шаблоны могут использоваться в конкретной отрасли или дисциплине или могут быть созданы в процессе работы над подобными проектами. Руководитель проекта в сотрудничестве с командой проекта определяет окончательную декомпозицию содержания проекта до отдельных пакетов работ, которые будут использоваться для эффективного управления работами проекта Рис. 11. Пример декомпозиции ИСР до пакетов работ Структура ИСР может создаваться с помощью различных подходов. Некоторые популярные методы включают принцип нисходящего анализа, использование руководящих указаний конкретных организаций и применение шаблонов ИСР. Во время интеграции подкомпонентов можно использовать принцип восходящего анализа. Структура ИСР может быть создана в различных формах, например: • в качестве второго уровня декомпозиции используются фазы жизненного цикла проекта, на третьем уровне расположены поставляемые результаты, относящиеся к проекту и продукту, как показано на рис. 12; • в качестве второго уровня декомпозиции используются основные поставляемые результаты, как показано на рис. 13; • используются подкомпоненты, которые могут разрабатываться организациями, не входящими в команду проекта, например работающими по договору. В таких случаях продавец разрабатывает поддерживающую договор ИСР как часть работы по договору. Рис. 12. Пример ИСР, организованной по фазам Рис. 13. Пример ИСР по основным поставляемым результатам Для декомпозиции компонентов ИСР верхнего уровня требуется разделение работ по каждому поставляемому результату или подкомпонентам на основополагающие элементы, где компоненты ИСР представляют собой поддающиеся проверке продукты, услуги или результаты. ИСР может быть структурирована в виде схемы, организационной диаграммы или другим методом, отражающим иерархическое разбиение. Проверка правильности декомпозиции требует удостоверения в том, что компоненты ИСР низкого уровня — это именно те компоненты, которые необходимы и достаточны для создания соответствующих поставляемых результатов более высокого уровня. Различные поставляемые результаты могут иметь различные уровни декомпозиции. Работы по некоторым поставляемым результатам достаточно декомпозировать всего лишь до следующего уровня, чтобы достичь уровня пакетов работ, однако для других могут потребоваться дополнительные уровни декомпозиции. По мере декомпозиции работ до более глубоких уровней детализации возможность планирования, управления и контроля работ расширяется. Однако чрезмерная декомпозиция может привести к непродуктивным управленческим трудозатратам, неэффективному использованию ресурсов, снижению эффективности выполнения работ и сложности консолидации данных различных уровней ИСР. Декомпозиция может оказаться невозможной для поставляемых результатов или подкомпонентов, которые будут выполняться в далеком будущем. Команда управления проектом обычно дожидается согласования поставляемого результата или подкомпонента, чтобы иметь возможность разработать соответствующие детали ИСР. Этот метод иногда называют «планированием методом набегающей волны». ИСР отображает все работы, связанные с продуктом и проектом, включая работы по управлению проектом. Все содержание работ на самых нижних уровнях должно сворачиваться в более высокие уровни, чтобы ничего не было пропущено и не выполнялась лишняя работа. Иногда это называют «правилом 100 %». Создание ИСР: выходы Базовый план по содержанию Базовый план по содержанию — это одобренная версия описания содержания, иерархической структуры работ (ИСР) и связанного с ними словаря ИСР, которая может быть изменена только с помощью формальных процедур контроля изменений и используется как основа для сравнения. Он является компонентом плана управления проектом. Компоненты базового плана по содержанию включают в себя: • Описание содержания проекта. Описание содержания проекта включает в себя изложение содержания проекта, основных поставляемых результатов, допущений и ограничений. • ИСР. ИСР — это иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов. Каждый нисходящий уровень ИСР включает все более подробное определение работ проекта. ИСР окончательно оформляется с помощью отнесения каждого пакета работ к тому или иному контрольному счету и присвоения каждому пакету работ уникального идентификатора по коду учета. Данные идентификаторы предоставляют структуру для иерархического суммирования информации о стоимости, расписании и ресурсах. Контрольный счет — это элемент управления, посредством которого содержание, бюджет, фактическая стоимость и расписание объединяются и сравниваются с освоенным объемом для измерения исполнения. Контрольные счета помещаются в выбранных точках управления в ИСР. Каждый контрольный счет может включать один или несколько пакетов работ, но каждый пакет работ должен быть привязан только к одному контрольному счету. Контрольный счет может включать в себя один или несколько пакетов планирования. Пакет планирования — это компонент иерархической структуры работ, отнесенный к контрольному счету, с известным содержанием работ, но без детальных операций расписания. • Словарь ИСР. Словарь ИСР — это документ, в котором содержится подробная информация о поставляемых результатах, операциях и расписании в отношении каждого компонента в ИСР. Словарь ИСР представляет собой документ, который дополняет ИСР. Информация в словаре ИСР включает в себя, среди прочего: о идентификатор кода учета, о описание работ, о допущения и ограничения, о ответственную организацию, о контрольные события расписания, о связанные операции расписания, о требуемые ресурсы, о оценки стоимости, о требования к качеству, о критерии приемки, о технические ссылки, о информацию по соглашениям. Обновления документов проекта Документы проекта, которые могут быть обновлены, включают в себя, среди прочего, документацию по требованиям, которая может потребовать обновления для включения в свой состав одобренных изменений. Если в результате процесса создания ИСР появляются одобренные запросы на изменения, может потребоваться обновление документации по требованиям для включения в ее состав одобренных изменений. 4. Концепция гибкого управления проектами (agile) в рамках управления содержанием проекта Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке проектов, программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD. Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом. Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки. Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе. Как минимум, она включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных. Не все проекты могут быть структурированы таким образом, чтобы быть реализованными по классическому проектному подходу. Приведем пример: приготовление одного блюда идеально ложится в классический подход, а вот вовремя приготовить и подать ужин из четырёх блюд будет практически невозможно, если придётся каждый раз ждать окончания приготовления одного блюда, чтобы приступить к приготовлению другого. И в таком случае применяется Agile. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на рис. 14. Таким образом, инициация и верхнеуровневое планирование проводятся для всего проекта, а последующие этапы: разработка, тестирование и прочие проводятся для каждого мини-проекта отдельно. Это позволяет передавать результаты этих мини-проектов, так называемые, инкременты, быстрее, а приступая к новому подпроекту в него можно внести изменения без больших затрат и влияния на остальные части проекта. Рис. 14. Схема работы по Agile Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова. Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям. Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, Lean и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам. Основные идеи Agile: • люди и взаимодействие важнее процессов и инструментов; • работающий продукт важнее исчерпывающей документации; • сотрудничество с заказчиком важнее согласования условий контракта; • готовность к изменениям важнее следования первоначальному плану. Принципы, которые разъясняет Agile Manifesto: • удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения; • приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта); • частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); • тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; • проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; • рекомендуемый метод передачи информации — личный разговор (лицом к лицу); • работающее программное обеспечение — лучший измеритель прогресса; • спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок; • постоянное внимание улучшению технического мастерства и удобному дизайну; • простота — искусство не делать лишней работы; • лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; • постоянная адаптация к изменяющимся обстоятельствам. Сильные стороны Agile Самое главное достоинство Agile – его гибкость и адаптивность. Он может подстроиться под практически любые условия и процессы организации. Именно это обуславливает его нынешнюю популярность и то, сколько систем для различных областей было создано на его основе. Одна из основных идей Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании полностью перестраивают свои системы управления проектами. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога. Слабые стороны Agile Как часто бывает, слабые стороны являются отражением сильных. В случае с Agile, гибкость может приводить к потере фокуса. Отсутствие чёткого процесса и процедур, разбиение проекта на подпроекты и частые изменения, при отсутствии чёткого направления со стороны руководства может привести к потере ориентиров и понимания того, что важно, а что вторично. Чтобы этого избежать можно создать и закрепить собственный метод на основе Agile и прописать в нём чёткие процессы и процедуры. А можно применить уже готовые фреймворки – такие как Scrum, Kanban или Lean. Библиографический список к Лекции №2 (Тема 1): 3. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 4. Ободовский П.А. Методология гибкого управления проектами «Agile» // V Республиканский научно-практический семинар молодых ученых «Проблемы и перспективы современной науки» [Электронный ресурс] URL: http://media.miu.by/files/store/629/2-ObodovskiP.pdf (дата обращения 28.02.2017) 5. Популярные системы управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие [Электронный ресурс] URL: http://sbs7.ru/populyarnyie-sistemyi-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/ (дата обращения 28.02.2017) 6. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. II УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА: ПРОЦЕССЫ ПЛАНИРОВАНИЯ 1. Цель и ключевые составляющие управления сроками выполнения проекта. Планирование управления сроками Управление сроками проекта включает в себя процессы, необходимые для того, чтобы обеспечить своевременное выполнение проекта. На рис. 1 приведена общая схема следующих процессов управления сроками проекта: 1. Планирование управления расписанием — процесс, устанавливающий политики, процедуры и документацию по планированию, разработке, управлению, исполнению и контролю за расписанием проекта. 2. Определение операций — процесс идентификации и документирования конкретных действий, которые необходимо выполнить для создания поставляемых результатов проекта. 3. Определение последовательности операций — процесс определения и документирования связей между операциями проекта. 4. Оценка ресурсов операций — процесс оценки типа и количества материалов, человеческих ресурсов, оборудования или расходных материалов, требуемых для выполнения каждой операции. 5. Оценка длительности операций — процесс оценки количества рабочих периодов, требуемых для завершения отдельных операций с учетом оценки ресурсов. 6. Разработка расписания—процесс анализа последовательностей операций, их длительностей, потребностей в ресурсах и ограничений расписания для создания модели расписания проекта. 7. Контроль расписания *— процесс мониторинга статуса операций проекта для актуализации прогресса проекта и управления изменениями базового расписания с целью соответствия плану. * - данный процесс рассматривается в рамках Темы IV (Лекция 1) Рис. 1 Общая схема управления сроками проекта 2. Календарное планирование проекта. Планирование управления расписанием. Планирование управления расписанием — процесс, устанавливающий политики, процедуры и документацию по планированию, разработке, управлению, исполнению и контролю за расписанием проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет руководство и указания относительно управления расписанием проекта на протяжении всего проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 2. На рис. 3 показана диаграмма потоков данных процесса. Рис. 2 Планирование управления расписанием: входы, инструменты и методы, а также выходы Рис. 3 Диаграмма потоков данных планирования управления расписанием План управления расписанием является компонентом плана управления проектом. План управления расписанием может быть формальным или неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта и включает в себя соответствующие контрольные пороги. План управления расписанием определяет порядок составления отчетов о возможных потерях, связанных с расписанием, и порядок их оценки. План управления расписанием может обновляться, чтобы отражать изменения в порядке управления расписанием. План управления расписанием — это важный вход для процесса разработки плана управления проектом. Планирование управления расписанием: входы План управления проектом План управления проектом содержит информацию, используемую для разработки плана управления расписанием, которая включает в себя, среди прочего: • Базовый план по содержанию. Базовый план по содержанию включает в себя описание содержания проекта и детали иерархической структуры работ (ИСР), используемые для определения операций, оценки длительности операций и управления расписанием. • Прочую информацию. Для разработки расписания используются решения из плана управления проектом в отношении стоимости, риска и коммуникаций, связанных с расписанием. Устав проекта Устав проекта определяет укрупненное расписание контрольных событий и требования к одобрению проекта, которые окажут влияние на управление расписанием проекта. Факторы среды предприятия Факторы среды предприятия, которые оказывают влияние на процесс планирования управления расписанием, включают в себя, среди прочего: • организационную структуру и культуру, которые могут оказывать влияние на управление расписанием; • наличие ресурсов и навыки, которые могут оказывать влияние на планирование расписания; • программное обеспечение для управления проектом, предоставляющее инструмент составления расписания и альтернативные возможности управления расписанием; • опубликованную коммерческую информацию, например, информацию о продуктивности ресурсов, которая зачастую доступна в коммерческих базах данных; • системы авторизации работ организации. Активы процессов организации Активы процессов организации, которые оказывают влияние на процесс планирования управления расписанием, включают в себя, среди прочего: • используемые инструменты мониторинга и отчетности; • историческую информацию; • инструменты контроля расписания; • существующие формальные и неформальные политики, процедуры и руководящие указания, связанные с контролем расписания; • шаблоны; • руководящие указания в отношении закрытия проекта; • процедуры контроля изменений; • процедуры контроля риска, включая категории рисков, определение вероятностей и воздействий, а также матрицу вероятности и воздействия. Планирование управления расписанием: инструменты и методы Экспертная оценка Экспертная оценка, основанная на исторической информации, предоставляет ценные данные о среде и информацию из предыдущих подобных проектов. Также экспертная оценка может указать на необходимость сочетания методов и указать, как урегулировать различия между ними. Для разработки плана управления расписанием следует использовать суждения, основанные на компетентности в прикладной области, области знаний, сфере деятельности, отрасли и т. д., соответствующих выполняемой операции. Аналитические методы Процесс планирования управления расписанием может включать в себя выбор стратегических средств для оценки проекта и составления его расписания, например методологию, инструменты и методы составления расписания, подходы по оценке, форматы и программное обеспечение для управления проектом. План управления расписанием также может подробно описывать способы быстрого прохода или сжатия расписания проекта, например параллельное исполнение работ. Подобно другим решениям в отношении расписания, влияющим на проект, эти решения могут оказывать воздействие на риски проекта. Организационные политики и процедуры могут влиять на выбор методов составления расписания в рамках данных решений. Методы могут включать в себя, среди прочего, планирование методом набегающей волны, опережения и задержки, анализ альтернатив и методы анализа исполнения расписания. Совещания Команды проекта могут проводить совещания по планированию для разработки плана управления расписанием. Среди участников таких совещаний могут быть руководитель проекта, спонсор проекта, определенные члены команды проекта, определенные заинтересованные стороны, любые лица, отвечающие за планирование или исполнение расписания, и, при необходимости, другие лица. Планирование управления расписанием: выходы План управления расписанием Компонент плана управления проектом, устанавливающий критерии и действия по разработке, мониторингу расписания и контролю за ним. План управления расписанием может быть формальным или неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта и включает в себя соответствующие контрольные пороги. Например, план управления расписанием может устанавливать следующие аспекты: • Разработка модели расписания проекта. Указываются методология и инструмент составления расписания, которые будут использоваться для разработки модели расписания проекта. • Степень точности. Указывается приемлемый диапазон, который будет использоваться в рамках реалистичной оценки длительности операций. Он может включать в себя возможные потери. • Единицы измерения. Для каждого ресурса определяются все единицы, которые будут использоваться в ходе измерений (например, человеко-часы, человеко-дни, недели для оценки времени или метры, литры, тонны, километры, кубические ярды для количественной оценки). • Связь между процедурами организации. В ИСР указаны рамки плана управления расписанием, которые обеспечивают соответствие оценкам и разработанным расписаниям. • Актуализация модели расписания проекта. Определяется процесс, используемый для обновления статуса проекта и записи прогресса проекта в модели расписания во время исполнения проекта. • Контрольные пороги. Для мониторинга исполнения расписания могут определяться пороги отклонений, что позволяет установить заранее согласованную величину вариации, при отклонении от которой становится необходимо предпринимать некоторые действия. Пороги обычно выражаются в виде процентных отклонений от параметров, установленных в базовом плане. • Правила измерения исполнения. Устанавливаются правила измерения исполнения для управления освоенным объемом (EVM) или для других физических измерений. Например, план управления расписанием может оговаривать: • правила расчета процента выполнения; • контрольные счета, на которых измеряется управление прогрессом и расписанием; • методы измерения освоенного объема (например, базовые планы, фиксированная формула, процент выполнения и т. д.), выбранные к применению; • измерение исполнения расписания, например отклонение по срокам (ОСР) и индекс выполнения сроков (ИВСР), используемые для оценки величины отклонения от первоначального базового расписания. • Форматы отчетности. Определяются форматы и частота составления различных отчетов по расписанию. • Описания процессов. Документируется описание каждого процесса управления расписанием. 3. Операция проекта: сущность и параметры. Контрольные события. Определение операций: инструменты и методы. Определение операций — процесс определения и документирования конкретных действий, которые необходимо выполнить для создания поставляемых результатов проекта. Ключевая выгода данного процесса состоит в том, чтобы разделить пакеты работ на операции, представляющие собой основу для оценки, составления расписания, исполнения, мониторинга и контроля работ проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 4. На рис. 5 показана диаграмма потоков данных процесса. Рис. 4 Определение операций: входы, инструменты и методы, а также выходы Рис. 5 Диаграмма потоков данных определения операций Подразумевается, что определение и планирование операций расписания в данном процессе проводятся таким образом, который обеспечивает достижение целей проекта. В процессе создания ИСР определяются поставляемые результаты самого нижнего уровня ИСР — пакеты работ. Пакеты работ обычно декомпозируются на более мелкие компоненты, называемые операциями, которые описывают трудозатраты, необходимые для выполнения пакета работ. Определение операций: входы План управления расписанием Основной вход из плана управления расписанием — это установленный уровень детализации, необходимый для управления работой. Базовый план по содержанию При определении операций детально рассматриваются ИСР, поставляемые результаты, ограничения и допущения проекта, которые документируются в базовом плане по содержанию. Факторы среды предприятия Факторы среды предприятия, которые оказывают влияние на процесс определения операций, включают в себя, среди прочего: • организационную структуру и культуру, • опубликованную в коммерческих базах данных коммерческую информацию, • информационную систему управления проектами (PMIS). Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс определения операций, включают в себя, среди прочего: • базу накопленных знаний, содержащую историческую информацию относительно списков операций, использованных в предыдущих подобных проектах; • стандартизованные процессы; • шаблоны, которые содержат стандартный список операций из предыдущего проекта или его часть; • существующие формальные и неформальные, связанные с планированием политики, процедуры и руководящие указания, такие как методология составления расписания, которые учитываются при определении операций. Определение операций: инструменты и методы Декомпозиция Декомпозиция — это метод, используемый для разбиения содержания и поставляемых результатов проекта на более мелкие и более управляемые элементы. Операции представляют собой трудозатраты, необходимые для выполнения пакета работ. В процессе определения операций конечные выходы определяются как операции, а не как поставляемые результаты, как это происходит в процессе создания ИСР. Список операций, ИСР и словарь ИСР могут разрабатываться последовательно или параллельно, при этом основой разработки окончательного списка операций служат ИСР и словарь ИСР. Каждый пакет работ в ИСР разделяется на операции, необходимые для получения поставляемых результатов этого пакета работ. Участие членов команды в процессе декомпозиции может привести к получению лучших и более точных результатов. Планирование методом набегающей волны Планирование методом набегающей волны — это метод итеративного планирования, при котором работа, которую надо будет выполнить в ближайшей перспективе, планируется подробно, в то время как далеко отстоящая работа планируется с меньшей степенью детализации. Это одна из форм последовательного уточнения. Таким образом, работа может существовать на разных уровнях детализации в зависимости от того, на какой стадии жизненного цикла проекта она находится. Во время раннего стратегического планирования, когда информация еще недостаточно определена, пакеты работ могут быть декомпозированы до известного уровня детализации. По мере поступления информации о предстоящих в ближайшей перспективе событиях может быть проведена декомпозиция пакетов работ до операций. Экспертная оценка Экспертиза при определении операций может проводиться членами команды проекта или другими экспертами, имеющими опыт и навыки разработки подробных описаний содержания проектов, ИСР и расписаний проектов. Определение операций: выходы Список операций Список операций — это исчерпывающий перечень, включающий все операции расписания, требуемые для данного проекта. В список операций также входят идентификатор операции и описание содержания работ по каждой операции, подробное настолько, чтобы члены команды проекта понимали, какие работы необходимо провести. Каждая операция должна иметь уникальное название, которое описывает ее место в расписании, даже если это название операции рассматривается вне контекста расписания проекта. Параметры операций Операции, отличные от контрольных событий, имеют определенную длительность, во время которой выполняется работа данной операции. Они также могут иметь ресурсы и стоимость, связанные с данной работой. Параметры операции расширяют ее описание путем определения ряда компонентов, связанных с каждой операцией. Компоненты каждой операции формируются с течением времени. На первоначальных стадиях проекта они могут включать в себя идентификатор операции, идентификатор ИСР и обозначение или название операции, а по его завершении — коды и описание операции, перечни предшествующих и последующих операций, логические связи, опережения и задержки, требования к ресурсам, ограничивающие даты, ограничения и допущения. Параметры операций могут быть использованы для определения лица, ответственного за выполнение работ, географического региона или места выполнения работ, календаря проекта, который включает данную операцию, и типа операции, например, операция с уровнем трудозатрат (level of effort, LOE), операция с дискретными трудозатратами и операция с распределяемыми трудозатратами. Параметры операций используются для разработки расписания, а также для отбора, упорядочения и разнообразных сортировок запланированных операций в отчетах. Количество параметров различается в зависимости от прикладной области. Список контрольных событий Контрольное событие — это важный момент или событие проекта. Список контрольных событий — это список, определяющий все контрольные события проекта и показывающий, является ли контрольное событие обязательным (например, требуемым согласно договору) или необязательным (например, основывающимся на исторической информации). Контрольные события подобны регулярным операциям расписания: они имеют аналогичную структуру и параметры, но обладают нулевой длительностью, поскольку представляют собой момент времени. 4. Взаимосвязь операций. Определение последовательности операций: методы Определение последовательности операций — процесс определения и документирования связей между операциями проекта. Ключевая выгода данного процесса состоит в том, что он определяет логическую последовательность работы с целью достижения наибольшей эффективности с учетом всех ограничений проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 6. На рис. 7 показана диаграмма потоков данных процесса. Рис. 6 Определение последовательности операций: входы, инструменты и методы, а также выходы Рис. 7 Диаграмма потоков данных определения последовательности операций Каждая операция и контрольное событие, кроме первых и последних, должны быть связаны по крайней мере с одной предшествующей операцией с логической связью финиш-старт или старт-старт и по крайней мере с одной последующей операцией с логической связью финиш-старт или финиш-финиш. Логические связи должны способствовать составлению реалистичного расписания проекта. Иногда бывает необходимо использовать время опережения или задержки между операциями для поддержания реалистичного и достижимого расписания проекта. Определение последовательности может быть выполнено с помощью программного обеспечения для управления проектом, а также автоматизированными или ручными методами. Определение последовательности операций: входы План управления расписанием В плане управления расписанием указываются метод и инструмент составления расписания, используемые в рамках проекта и определяющие последовательность операций. Список операций Список операций содержит все операции расписания, предусмотренные для данного проекта, последовательность которых подлежит определению. На определение последовательности операций могут оказать влияние зависимости и другие ограничения. Параметры операций Параметры операций могут описывать необходимую последовательность событий или определенные связи с предшествующими либо с последующими операциями. Список контрольных событий Список контрольных событий может включать в себя расчетные даты конкретных контрольных событий, которые могут оказывать влияние на определение последовательности операций. Описание содержания проекта Описание содержания проекта содержит описание содержания продукта, которое включает в себя характеристики продукта, способные повлиять на определение последовательности операций, такие как физический план завода, который должен быть сооружен, или интерфейсы подсистем в проекте, связанном с программным обеспечением. На определение последовательности операций также может оказать влияние другая информация из описания содержания проекта, включая поставляемые результаты, ограничения и допущения проекта. Хотя данные влияния часто очевидны в списке операций, как правило, для обеспечения точности проводится проверка описания содержания продукта. Факторы среды предприятия Факторы среды предприятия, которые оказывают влияние на процесс определения последовательности операций, включают в себя, среди прочего: • государственные и промышленные стандарты, • информационную систему управления проектами (PMIS), • инструмент составления расписания, • корпоративные системы авторизации работ. Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс определения последовательности операций, включают в себя, среди прочего, проектные архивы из корпоративной базы знаний, используемые в методологии составления расписания, существующие формальные и неформальные связанные с планированием политики, процедуры и руководящие указания, например, методологию составления расписания, которые учитываются при определении логических связей, и шаблоны, которые могут облегчить подготовку сетей операций проекта. Информация о соответствующих параметрах операций в шаблонах также может содержать дополнительную описательную информацию, полезную при определении последовательности операций. Определение последовательности операций: инструменты и методы Метод диаграмм предшествования Метод диаграмм предшествования (precedence diagramming method, PDM) — метод, используемый для составления модели расписания, в которой операции представлены узлами и графически связаны одной или несколькими логическими связями, которые показывают последовательность выполнения операций. Операции в узлах (activity-on-node, AON) — один из методов представления диаграммы предшествования. Данный метод используется в большинстве пакетов программного обеспечения для управления проектом. PDM включает в себя четыре типа зависимостей, или логических связей. Предшествующая операция — операция, логически находящаяся перед зависимой операцией в расписании. Последующая операция — зависимая операция, логически находящаяся после другой операции в расписании. Эти связи определены ниже и представлены на рис. 8: • Финиш-старт (finish-start, FS). Логическая связь, при которой старт последующей операции зависит от финиша предшествующей операции. Пример: церемония награждения (последующая операция) не может быть начата, пока не закончится гонка (предшествующая операция). • Финиш-финиш (finish-finish, FF). Логическая связь, при которой финиш последующей операции зависит от финиша предшествующей операции. Пример: создание документа (предшествующая операция) должно быть закончено до завершения его правки (последующая операция). • Старт-старт (start-start, SS). Логическая связь, при которой старт последующей операции зависит от старта предшествующей операции. Пример: выравнивание бетонной поверхности (последующая операция) не может начаться до начала заливки фундамента (предшествующая операция). • Старт-финиш (start-finish, SF). Логическая связь, при которой финиш последующей операции зависит от старта предшествующей операции. Пример: первая смена службы охраны (последующая операция) не может закончиться, пока не начнется вторая смена службы охраны (предшествующая операция). В методе диаграмм предшествования чаще всего используется связь предшествования типа «финиш-старт». Связь «старт-финиш» используется редко, но рассматривается здесь для полноты списка типов связей метода диаграмм предшествования. Определение зависимостей Зависимости характеризуются следующими описанными далее параметрами: обязательная или дискреционная, внутренняя или внешняя. Зависимость может иметь четыре параметра, но одновременно могут применяться только два из них следующими способами: обязательные внешние зависимости, обязательные внутренние зависимости, дискреционные внешние зависимости или дискреционные внутренние зависимости. • Обязательные зависимости. Обязательные зависимости — это такие зависимости, которые требуются по закону или договору или являются неотъемлемым свойством данной работы. Обязательные зависимости часто подразумевают физические ограничения, например в строительном проекте, где невозможно возвести наземную конструкцию до сооружения фундамента, или в проекте, связанном с электроникой, где прототип должен быть создан до того, как он будет протестирован. Обязательные зависимости также иногда называют «жесткой логикой» или жесткими зависимостями. Технические зависимости могут не быть обязательными. Команда проекта определяет, какие зависимости являются обязательными, во время процесса определения последовательности операций. Обязательные зависимости не следует путать с ограничениями расписания в инструменте составления расписания. • Дискреционные зависимости. Дискреционные зависимости иногда также называют «предпочтительной логикой», «предпочитаемой логикой» или «мягкой логикой». Дискреционные зависимости устанавливаются на основе передовых методов организации работ в определенной прикладной области или в рамках необычного аспекта проекта, где предпочтительна особенная последовательность, хотя могут существовать и другие приемлемые последовательности. Дискреционные зависимости должны быть полностью задокументированы, так как они могут создавать необоснованные общие временные резервы и могут ограничить последующие варианты составления расписания. При применении методов быстрого прохода должен проводиться анализ этих дискреционных зависимостей и рассматриваться необходимость их модификации или устранения. В ходе процесса определения последовательности операций команда проекта определяет, какие зависимости являются дискреционными. • Внешние зависимости. Внешние зависимости включают связь между операциями проекта и операциями вне проекта. Эти зависимости обычно не поддаются контролю со стороны команды проекта. Например, в проекте по разработке программного обеспечения операция тестирования может зависеть от поставки аппаратного обеспечения сторонней организацией, а в некоторых строительных проектах подготовительные работы на участке можно начинать только после выдачи официального подтверждения, что строительство не нанесет ущерба окружающей среде. В ходе процесса определения последовательности операций команда управления проектом выявляет внешние зависимости. • Внутренние зависимости. Внутренние зависимости включают в себя связь предшествования между операциями проекта и обычно поддаются контролю со стороны команды проекта. Пример внутренней обязательной зависимости — команда не может испытать прибор, пока он не будет собран. В ходе процесса определения последовательности операций команда управления проектом выявляет внутренние зависимости. Опережения и задержки Опережение — это временной интервал, на который может быть сдвинуто исполнение последующей операции относительно предшествующей на более ранний срок. Например, в проекте по строительству нового офисного здания озеленение может быть запланировано на 2 недели раньше завершения составления перечня недоделок. Это может быть представлено в виде связи «финиш-старт» с 2-недельным опережением (см. рис. 9). В программном обеспечении для составления расписания опережение зачастую представлено как отрицательное значение задержки. Задержка — количество времени, на которое необходимо задержать последующую операцию относительно предшествующей. Например, команда технических специалистов может приступить к редактированию проекта большого документа через 15 дней после начала его написания. Это может быть представлено в виде связи «старт-старт» с 15-дневной задержкой (см. рис. 9). Команда управления проектом определяет зависимости, которые могут потребовать опережения или задержки для точного определения логической связи. Использование задержек и опережений не должно заменять логики расписания. Операции и связанные с ними допущения должны документироваться. Определение последовательности операций: выходы Диаграммы сети расписания проекта Диаграмма сети расписания проекта—графическое отображение логических связей, также называемых зависимостями, между операциями расписания проекта. На рис. 10 изображена диаграмма сети расписания проекта. Диаграмма сети расписания проекта может быть составлена вручную или с помощью программного обеспечения для управления проектом. Она может включать в себя все детали проекта или содержать только одну или несколько суммарных операций. Диаграмма может дополняться сводной описательной частью, в которой описан основной подход, применявшийся для определения последовательности операций. Любые необычные последовательности операций в рамках сети должны быть полностью описаны в описательной части. Рис. 10. Диаграмма сети расписания проекта Обновления документов проекта Документы проекта, которые могут быть обновлены, включают в себя, среди прочего: • списки операций, • параметры операций, • список контрольных событий, • реестр рисков. 5. Оценка ресурсов операций: инструменты и методы Оценка ресурсов операций — процесс оценки типа и количества материалов, человеческих ресурсов, оборудования или расходных материалов, требуемых для выполнения каждой операции. Ключевая выгода данного процесса состоит в том, что он определяет типы, количество и характеристики ресурсов, требуемых для выполнения операции, что позволяет выполнить более точную оценку стоимости и длительности. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 11. На рис. 12 показана диаграмма потоков данных процесса. Рис. 11. Оценка ресурсов операций: входы, инструменты и методы, а также выходы Рис. 12. Диаграмма потоков данных оценки ресурсов операций Процесс оценки ресурсов операций тесно координируется с процессом оценки стоимости. Например: • Команда проекта в сфере строительства должна быть знакома с местными строительными нормами и правилами. Эти знания могут быть получены у местных представителей. Однако в том случае, когда местная рабочая сила не имеет опыта применения нетрадиционных или специализированных строительных технологий, наиболее результативным способом получения знаний о местных строительных нормах и правилах будет приглашение консультанта за дополнительную плату. Команда проекта в области автомобилестроения должна быть знакома с передовыми методами автоматизированной сборки. Для приобретения требуемых знаний можно воспользоваться услугами приглашенного консультанта, отправить проектировщика на семинар по вопросам робототехники или включить в команду проекта представителя производственного сектора. Инструменты и методы Экспертная оценка Экспертная оценка часто необходима для того, чтобы оценить связанные с ресурсами входы этого процесса. Такую оценку может дать любое лицо или группа лиц, имеющие специальную подготовку в области планирования и оценки ресурсов. Анализ альтернатив В отношении многих операций расписания существуют альтернативные методы их реализации. К ним относится использование ресурсов с различными уровнями способностей или навыков, машин различных габаритов или типов, различных инструментов (ручных или автоматизированных), а также принятие решений «производить, арендовать или покупать» в отношении ресурсов. Опубликованные оценочные данные Некоторые организации регулярно публикуют данные о производительности и единичные расценки ресурсов по широкому спектру рабочих профессий, материальных средств и оборудования по различным странам и регионам отдельных стран. Оценка «снизу вверх» Оценка «снизу вверх» — метод оценки длительности или стоимости проекта путем консолидации оценок компонентов ИСР более низкого уровня. Когда операция не может быть оценена с достаточной степенью уверенности, работы операции разделяются на более мелкие элементы. Проводится оценка потребностей в ресурсах. Затем эти оценки объединяются в общую величину по каждому ресурсу операции. Операции могут иметь или не иметь зависимости между собой, которые могут повлиять на применение и использование ресурсов. Если зависимости имеются, то эта специфика использования ресурсов отражается в оценочных требованиях операции и фиксируется документально. Программное обеспечение для управления проектом Такое программное обеспечение для управления проектом, как инструмент составления расписания, способно оказать помощь в планировании, организации и управлении пулами ресурсов, а также в разработке оценок ресурсов. В зависимости от возможностей программного обеспечения можно определять иерархические структуры ресурсов, доступность ресурсов, стоимость ресурсов и разнообразные ресурсные календари, способствующие оптимизации использования ресурсов. Библиографический список к Лекции №1 (Тема II): 1. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 2. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. II УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА: ПРОЦЕССЫ ПЛАНИРОВАНИЯ 6. Оценка длительности операций: инструменты и методы Оценка длительности операций — процесс оценки количества рабочих периодов, требуемых для завершения отдельных операций с учетом оценки ресурсов. Ключевая выгода данного процесса состоит в том, что он предоставляет количество времени, необходимое для завершения каждой операции, что является важным входом для процесса разработки расписания. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 13. На рис. 14 показана диаграмма потоков данных процесса. Рис. 13 Оценка длительности операций: входы, инструменты и методы, а также выходы Рис. 14 Диаграмма потоков данных оценки длительности операций При оценке длительности операций используется информация о содержании работ операции, требуемых типах ресурсов, оценках количества ресурсов, а также ресурсных календарях. Входы в виде оценок длительности операций исходят от одного или нескольких членов команды проекта, в наибольшей степени знакомых с характером работ определенной операции. Оценка длительности постепенно уточняется, и процесс учитывает качество и доступность данных на входе. Например, по мере выполнения инженерно-конструкторских работ по проекту данные становятся более детальными и определенными, при этом повышается точность оценок длительности. Таким образом, можно считать, что с течением времени оценка длительности постепенно становится более точной, а ее качество повышается. Процесс оценки длительности операций требует, чтобы были оценены трудоемкость работ и количество доступных ресурсов, необходимых для выполнения операции. Эти оценки используются для примерной оценки числа рабочих периодов (длительности операции), необходимых для выполнения операции в рамках соответствующих календарей проекта и ресурсных календарей. Для каждой оценки длительности операции документируются все данные и допущения, которые использовались при оценке длительности. Инструменты и методы Экспертная оценка Экспертная оценка, основанная на исторической информации, может предоставить информацию об оценке длительности или о рекомендованной максимальной длительности операций из предыдущих подобных проектов. Также экспертная оценка может быть использована для определения необходимости использования различных методов оценок и способов согласования различий между ними. Оценка по аналогам Оценка по аналогам — метод оценки продолжительности или стоимости операции или проекта с использованием исторических данных аналогичной операции или проекта. Оценка по аналогам подразумевает использование таких параметров, как длительность, бюджет, размер, вес и сложность из предыдущих подобных проектов в качестве основы для оценки тех же параметров или измерений будущего проекта. При оценке длительности данный метод опирается на фактическую длительность предыдущих подобных проектов в качестве основы для оценки длительности текущего проекта. Этот подход, позволяющий оценивать общую величину, иногда адаптируется в зависимости от известных различий в сложности проекта. Зачастую оценка длительности по аналогам используется для оценки длительности проекта, когда объем детальной информации о проекте ограничен. Как правило, оценка по аналогам обходится дешевле и занимает меньше времени, чем другие методы, но при этом она обычно оказывается и менее точной. Оценки длительности по аналогам могут применяться ко всему проекту или к его частям, а также могут использоваться вместе с другими методами оценки. Оценка по аналогам оказывается наиболее достоверной в тех случаях, когда предыдущие операции схожи по сути, а не только по форме, а члены команды проекта, подготавливающие оценки, обладают необходимым опытом. Параметрическая оценка Параметрическая оценка — метод оценки, использующий алгоритм для вычисления стоимости или длительности на основе исторических данных и параметров проекта. Параметрическая оценка использует статистические связи между историческими данными и прочими переменными (например, площадью в квадратных метрах в строительстве) для расчета оценки параметров операции, таких как стоимость, бюджет и длительность. Длительность операций может быть количественно определена путем умножения количества работ, которые необходимо выполнить, на количество рабочего времени, затрачиваемое на производство единицы работы. Например, длительность операции в конструкторском проекте оценивается путем умножения количества чертежей на количество рабочих часов, требуемых для создания одного чертежа; или длительность прокладки кабеля — путем умножения количества метров кабеля на количество рабочих часов, необходимых для прокладки одного метра. Например, если выделенный ресурс способен за час проложить 25 метров кабеля, длительность, требуемая для прокладки 1 000 метров, будет составлять 40 часов (1 000 метров разделить на 25 метров в час). Данный метод может обеспечивать более высокую степень точности в зависимости от опыта и данных, заложенных в основу модели. Параметрические оценки сроков могут применяться ко всему проекту или к его частям вместе с другими методами оценки. Оценка по трем точкам Точность оценок длительности операций по одной точке может быть улучшена путем рассмотрения неопределенностей оценок и рисков. Данная концепция происходит из метода оценки и анализа программ (program evaluation and review technique, PERT). Для определения приблизительного диапазона длительности операции PERT использует три оценки: • Наиболее вероятная (tM). Длительность операции определяется с учетом предварительного выделения ресурсов, их производительности, реалистичной оценки их доступности для выполнения данной операции, зависимостей от других участников, а также с учетом прерываний в работе. • Оптимистичная (tO). Длительность операции основывается на анализе наиболее благоприятного сценария для операции. • Пессимистичная (tP). Длительность операции основывается на анализе наиболее неблагоприятного сценария для операции. Будучи зависимой от предполагаемого распределения значений в диапазоне трех оценок, ожидаемая длительность, tE, рассчитывается по формуле. Две наиболее распространенные формулы—треугольное распределение и бета-распределение. Формулы: • Треугольное распределение. tE = (tO + tM + tP) / 3 • Бета-распределение (из традиционного метода PERT). tE = (tO + 4tM + tP) / 6 Оценки длительности, основанные на трех точках с предполагаемым распределением, предоставляют данные по ожидаемой длительности и проясняют диапазон неопределенности ожидаемой длительности. Методы группового принятия решений Групповые методы, такие как мозговой штурм, метод Дельфи или метод номинальных групп, полезны тем, что вовлекают членов команды, чтобы повысить степень точности оценки и причастности к получаемым результатам оценки. Вовлечение в процесс оценки структурированной группы сотрудников, близко связанных с техническим исполнением работ, обеспечивает получение дополнительной информации и выполнение более точной оценки. Кроме того, вовлечение сотрудников в процесс оценки усиливает их стремление соответствовать полученным оценкам. Анализ резервов Оценки длительности могут включать в себя резервы на возможные потери (иногда называемые «резервами времени» или «буферами») в рамках расписания проекта для учета неопределенности расписания. Резервы на возможные потери — это оценочная длительность в рамках базового расписания, выделенная для идентифицированных рисков, которые были приняты и в отношении которых разработаны меры реагирования с целью их снижения или меры реагирования на возможные потери. Резервы на возможные потери ассоциируются с «известными неизвестными», которые могут оцениваться для учета этого неизвестного количества доработки. Резерв на возможные потери может выражаться в процентах от оценочной длительности операции, в фиксированном числе рабочих периодов или может быть рассчитан с помощью методов количественного анализа, например, имитации методом Монте-Карло. Резервы на возможные потери могут быть отделены от отдельных операций и объединены в буферы. По мере поступления более точной информации о проекте резервы на возможные потери могут быть использованы, сокращены или исключены. Возможные потери должны быть четко определены в документации по расписанию. Также можно сформировать оценки величины управленческого резерва времени проекта. Управленческие резервы — это указанная часть длительности проекта, зарезервированная для целей управленческого контроля и сохраненная для выполнения непредвиденной работы, находящейся в пределах содержания проекта. Управленческие резервы связаны с «неизвестными неизвестными», которые могут оказать влияние на проект. Управленческий резерв не включен в базовое расписание, но является частью общих требований к длительности проекта. В зависимости от условий договора, использование управленческих резервов может потребовать изменения базового расписания. 7. Разработка расписания проекта: ключевые понятия, методы. Концепция гибкого управления проектами (agile) в рамках управления сроками проекта. Разработка расписания — процесс анализа последовательностей операций, их длительностей, потребностей в ресурсах и ограничений расписания для создания модели расписания проекта. Ключевая выгода данного процесса состоит в том, что путем ввода операций, длительностей, ресурсов, доступности ресурсов и логических связей расписания в инструмент составления расписания создается модель расписания с запланированными датами выполнения операций проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 15. На рис. 16 показана диаграмма потоков данных процесса. Рис. 15. Разработка расписания: входы, инструменты и методы, а также выходы Рис. 16. Диаграмма потоков данных разработки расписания Разработка приемлемого расписания проекта зачастую является итеративным процессом. Модель расписания используется для определения запланированных дат старта и финиша операций и контрольных событий проекта, основываясь на точности входов. Разработка расписания может потребовать проведения анализа и проверки оценок длительности и ресурсов для создания модели расписания проекта, чтобы определить одобренное расписание проекта, способное служить в качестве базового плана, по которому будет проходить отслеживание исполнения. После определения дат старта и финиша операции, персонал проекта, назначенный на определенные операции, должен оценить назначенные ему операции и подтвердить, что даты старта и финиша не приведут к конфликту с ресурсными календарями или с назначенными операциями в рамках других проектов или задач и, таким образом, являются действительными. Пересмотр модели расписания и поддержание ее реалистичности продолжается на всем протяжении проекта по мере выполнения работ. Для получения более подробной информации относительно составления расписания см. Практический стандарт разработки расписания (Practice Standard for Scheduling). Разработка расписания: входы План управления расписанием План управления расписанием определяет метод и инструмент составления расписания, используемый для создания расписания, а также метод расчета расписания. Список операций Список операций определяет операции, которые будут включены в модель расписания. Параметры операций Параметры операций включают данные, используемые для создания модели расписания. Диаграммы сети расписания проекта Диаграммы сети расписания проекта содержат логические связи предшествующих и последующих операций, которые будут использоваться для расчета расписания. Требования к ресурсам операций Требования к ресурсам операций определяют типы и количество ресурсов, необходимых для каждой операции, используемой для создания модели расписания. Ресурсные календари Ресурсные календари содержат информацию о доступности ресурсов в ходе исполнения проекта. Оценки длительности операций Оценки длительности операций включают количественные оценки наиболее вероятного числа рабочих периодов, требуемых для выполнения операций, которые будут использоваться для расчета расписания Описание содержания проекта Описание содержания проекта содержит допущения и ограничения, которые могут оказывать воздействие на разработку расписания проекта. Реестр рисков Реестр рисков содержит данные обо всех идентифицированных рисках и их характеристиках, которые оказывают влияние на модель расписания. Назначения персонала проекта Назначения персонала проекта определяют ресурсы, назначенные на каждую операцию. Иерархическая структура ресурсов Иерархическая структура ресурсов содержит данные, по которым можно провести анализ ресурсов и составить отчеты в рамках организации. Факторы среды предприятия Факторы среды предприятия включают в себя, среди прочего: • стандарты; • каналы коммуникаций; • инструмент составления расписания, который будет использоваться в рамках разработки модели расписания. Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс разработки расписания, включают в себя, среди прочего: методологию составления расписания и календарь (календари) проекта. Разработка расписания: инструменты и методы Анализ сети расписания Анализ сети расписания представляет собой метод создания модели расписания проекта. В нем применяются разнообразные аналитические методы, такие как метод критического пути, метод критической цепи, анализ сценариев «что если» и методы оптимизации ресурсов, позволяющие рассчитать даты раннего и позднего старта и финиша незавершенных частей операций проекта. Некоторые пути в сети могут иметь точки схождения или расхождения, которые можно выявить и использовать в анализе сжатия расписания и других видах анализа. Метод критического пути Метод критического пути — метод, используемый для оценки минимальной длительности проекта и определения степени гибкости расписания на логических путях в сети в рамках модели расписания. Метод анализа сети расписания позволяет рассчитать даты раннего старта и финиша, а также даты позднего старта и финиша для всех операций без учета ресурсных ограничений путем проведения анализа прямого и обратного прохода по сети проекта. В данном примере самый длительный путь включает в себя операции A, C и D, и поэтому последовательность A-C-D является критическим путем. Критический путь—это последовательность операций, представляющая собой самый длительный путь в расписании проекта, который определяет самую короткую возможную длительность проекта. Полученные даты раннего старта и финиша не обязательно являются расписанием проекта; они скорее указывают периоды времени, в рамках которых может быть выполнена операция, используя параметры, введенные в модель расписания, связанные с длительностью операций, логическими связями, опережениями, задержками и другими известными ограничениями. Метод критического пути используется для расчета степени гибкости расписания на логических путях в сети в рамках модели расписания. На любом пути в сети степень гибкости расписания оценивается количеством времени, на которое может быть отложена или продлена операция расписания с раннего старта без просрочки даты завершения проекта или нарушения ограничений расписания, и это время называется «общим временным резервом». Критический путь CPM обычно характеризуется нулевым общим временным резервом на критическом пути. При определении последовательности методом диаграмм предшествования критические пути могут иметь положительный, нулевой или отрицательный общий временной резерв, в зависимости от применяемых ограничений. Любая операция на критическом пути называется операцией критического пути. Положительный общий временной резерв возникает, когда обратный проход рассчитывается из ограничения расписания, указанного позже даты раннего финиша, которая была рассчитана в рамках расчета прямого прохода. Отрицательный временной резерв возникает, когда ограничение в отношении поздних дат нарушено длительностью и логикой. В сетях расписания может существовать несколько околокритических путей. Многие пакеты программного обеспечения позволяют пользователю определить параметры, используемые для оценки критического пути (путей). Для создания путей в сети с нулевым или положительным общим временным резервом может потребоваться адаптация длительности операций (если есть возможность предоставить больше ресурсов или обеспечить меньшее содержание), логических связей (если связи изначально были дискреционными), опережений, задержек и других ограничений расписания. После подсчета общего временного резерва пути в сети также может быть определен свободный временной резерв — промежуток времени, на который можно задержать выполнение операции расписания без задержки раннего старта любых последующих операций и без нарушения ограничений расписания. Например, свободный временной резерв операции B составляет 5 дней (см. рис. 17). Метод критической цепи Метод критической цепи (CCM) — метод разработки расписания, позволяющий команде проекта размещать буферы на любом пути в расписании, чтобы учесть ограниченность ресурсов и неопределенности, связанные с проектом. Он разработан из метода критического пути и учитывает воздействия распределения, оптимизации, выравнивания ресурсов, а также неопределенность в отношении длительности операции на критическом пути, определенном методом критического пути. Метод критической цепи включает в себя понятия буферов и управления буферами. Метод критической цепи использует операции, длительность которых не включает в себя пределы безопасности, логические связи и доступность ресурсов со статистически определенными буферами, включающими в себя суммарные пределы безопасности операций в определенных точках проекта на пути расписания проекта для учета ограниченных ресурсов и неопределенности, связанной с проектом. Критический путь с ресурсными ограничениями известен как «критическая цепь». Метод критической цепи добавляет буферы длительности в виде операций, не предусматривающих выполнения работ, для управления неопределенностью. Один из буферов, расположенный в конце критической цепи (см. рис. 18), известен как проектный буфер и защищает целевую дату финиша от задержек на критической цепи. Дополнительные буферы, известные как «питающие буферы», располагаются в каждой точке, в которой в критическую цепь входят цепи взаимосвязанных операций извне критической цепи. Питающие буферы, таким образом, защищают критическую цепь от отставания по входящим цепям. Размер каждого буфера должен учитывать неопределенность длительности цепи зависимых операций, ведущих к данному буферу. Как только буферные операции расписания определены, операции расписания планируются на максимально поздние плановые даты старта и финиша. Таким образом, вместо управления общим временным резервом путей в сети метод критической цепи концентрируется на управлении оставшимися длительностями буферов, сопоставляя их с оставшейся длительностью цепей операций. Методы оптимизации ресурсов Примеры методов оптимизации ресурсов, которые можно использовать для корректировки модели расписания, учитывая спрос на ресурсы и предложение ресурсов, включают в себя, среди прочего: Выравнивание ресурсов. Метод регулирования дат старта и финиша операций с учетом ограничений ресурсов в целях уравновешивания спроса на ресурсы с доступным предложением. Выравнивание ресурсов может быть использовано, когда общие или критически важные необходимые ресурсы доступны только в определенное время или только в ограниченном количестве или при переназначении ресурсов, например, когда ресурс был назначен для выполнения двух или более операций в один и тот же период времени (см. рис. 19), или для поддержания использования ресурсов на постоянном уровне. Выравнивание ресурсов зачастую может приводить к изменению первоначального критического пути, обычно к его увеличению. Сглаживание ресурсов. Метод, корректирующий операции модели расписания таким образом, чтобы требования к ресурсам проекта не превышали определенные предустановленные лимиты. В отличие от выравнивания ресурсов при их сглаживании критический путь проекта не меняется, и дата окончания не может быть отсрочена. Другими словами, операции могут быть отложены только в рамках их свободного или общего временного резерва. В связи с этим, сглаживание ресурсов не может оптимизировать все ресурсы. Методы моделирования Примеры методов моделирования включают в себя, среди прочего: • Анализ сценариев «что если». Анализ сценариев «что если» — процесс оценки сценариев с целью прогнозирования их воздействия, положительного или отрицательного, на цели проекта. Это анализ вопроса: «Что произойдет, если ситуация будет развиваться по сценарию «Х»?» В этом случае выполняется анализ сети расписания, при котором с помощью модели расписания просчитываются различные сценарии (например, задержка поставки основных компонентов, увеличение длительности отдельных инженерных операций) или моделируется влияние непредвиденных внешних факторов (например, забастовка или изменение процедуры лицензирования). Результаты анализа «что если» могут использоваться для оценки выполнимости расписания проекта при неблагоприятных условиях и для составления планов на случай возможных потерь и планов реагирования для преодоления или смягчения последствий неожиданных ситуаций. • Имитация. Имитация включает в себя расчет различных длительностей проекта при использовании различных допущений о длительностях операций, обычно используя распределения вероятностей, полученные из оценок по трем с целью учета неопределенности. Наиболее известен метод Монте- Карло, в котором распределение вероятных значений длительности операции определяется для каждой операции и используется для вычисления распределения вероятных конечных результатов всего проекта. Опережения и задержки Опережения и задержки — это уточнения, вносимые во время анализа сети для разработки жизнеспособного расписания путем корректировки времени старта последующих операций. Опережения используются в ограниченном ряде обстоятельств, чтобы ускорить последующую операцию с учетом предшествующей. Задержки используются в ограниченном ряде обстоятельств, когда процессам необходим установленный период времени между предшествующими и последующими операциями без воздействия на работу или ресурс. Сжатие расписания Методы сжатия расписания используются для сокращения длительности расписания без сокращения содержания проекта, чтобы соответствовать временным ограничениям, ограничивающим датам или иным целям расписания. Методы сжатия расписания включают в себя, среди прочего: • Сжатие. Метод, используемый для сокращения длительности расписания за счет добавления ресурсов с учетом минимизации дополнительных затрат на уменьшение длительности. Примеры сжатия включают в себя одобрение сверхурочной работы, привлечение дополнительных ресурсов или плату за ускорение поставки для операций на критическом пути. Сжатие эффективно только для тех операций на критическом пути, где дополнительные ресурсы способны сократить длительность операции. Сжатие не всегда создает жизнеспособную альтернативу и может привести к увеличению рисков и/или стоимости. • Быстрый проход. Метод сжатия расписания, заключающийся в том, что операции или фазы, которые в обычной ситуации выполнялись бы последовательно, выполняются параллельно на протяжении по крайней мере некоторой части их длительности. Примером является строительство фундамента здания до подготовки всех архитектурных чертежей. Быстрый проход может привести к доработкам и увеличению риска. Быстрый проход применим только в том случае, когда операции могут накладываться одна на другую для сокращения длительности проекта. Инструмент составления расписания Автоматизированные инструменты составления расписания включают в себя модель расписания и облегчают процесс составления расписания, генерируя даты старта и финиша на основе информации об операциях, диаграммах сети, ресурсах и длительностях операций, используя анализ сети расписания. Инструмент составления расписания может быть использован в сочетании как с различными программными приложениями для управления проектом, так и с ручными методами. Разработка расписания: выходы Базовое расписание Базовое расписание — одобренная версия модели расписания, которая может быть изменена только с помощью формальных процедур контроля изменений и используется как база для сравнения с фактическими результатами. Оно принимается и одобряется заинтересованными сторонами проекта как базовое расписание с базовыми датами старта и финиша. В ходе мониторинга и контроля одобренные базовые даты сравниваются с фактическими датами старта и финиша с целью установления отклонений. Базовое расписание является компонентом плана управления проектом. Расписание проекта Выходами модели расписания являются представления расписания. Расписание проекта — выход модели расписания, представляющий взаимосвязанные операции с запланированными датами, длительностями, контрольными событиями и ресурсами. Расписание проекта содержит, по меньшей мере, плановый старт и плановый финиш для каждой операции. Если планирование ресурсов проводится на ранней стадии, расписание проекта остается предварительным до подтверждения выделения ресурсов и утверждения расчетных старта и финиша. Обычно этот процесс происходит не позднее, чем будет разработан план управления проектом. Может быть также разработано целевое расписание проекта с определенным целевым стартом и финишем для каждой операции. Расписание проекта может быть представлено в укрупненном виде, иногда называемом укрупненным расписанием или расписанием контрольных событий, или же в детальном виде. Хотя расписание проекта может быть представлено в форме таблицы, чаще всего используется графическое представление в одном из следующих форматов: • Линейчатые диаграммы. Диаграммы, относящиеся к расписанию, называемые также диаграммами Ганта, в которых операции перечислены на вертикальной оси, даты приведены на горизонтальной оси, а длительности операций показаны в виде горизонтальных полос, расположенных в соответствии с датами старта и финиша. Линейчатые диаграммы сравнительно легко читаются и часто используются для представления информации руководству. Для контроля и управления коммуникациями используются и отображаются в линейчатых диаграммах укрупненные суммарные операции, иногда называемые гамаками, длящиеся между контрольными событиями или объединяющие несколько взаимозависимых пакетов работ. Примером может служить часть укрупненного расписания, показанного на рис. 20 в структурированном формате ИСР. • Диаграммы контрольных событий. Данные диаграммы аналогичны линейчатым диаграммам, но показывают только запланированные даты начала или завершения получения основных результатов и ключевые внешние события. Пример части расписания контрольных событий приведен на рис. 20. • Диаграммы сети расписания проекта. Эти диаграммы обычно представлены в формате диаграммы «операции в узлах», показывающей операции и связи без использования временной шкалы и иногда называемой чисто логической диаграммой, или представлены в формате диаграммы сети расписания, привязанной к временной шкале, которая иногда называется логической линейчатой диаграммой (показана для детального расписания на рис. 19). Данные диаграммы, содержащие информацию о датах операций, обычно показывают как логику сети проекта, так и операции критического пути проекта. Этот пример также показывает способ планирования каждого пакета работ в виде ряда связанных операций. Другое представление сетевой диаграммы проекта — это логическая диаграмма, привязанная к временной шкале. Данная диаграмма включает в себя временную шкалу и полоски, представляющие длительность операций и логические связи. Она оптимизирована таким образом, чтобы показывать связи между операциями, когда на одной оси диаграммы в последовательности может отображаться любое количество операций. Рис. 20. Примеры представлений расписания проекта На рис. 20 показаны примеры представлений расписания выполняемого проекта, в которых отражается состояние на момент времени, когда регистрируется статус проекта, который иногда также называется отчетной датой или статусной датой. Для модели расписания простого проекта на рис. 20 отражены следующие представления расписания: 1) расписание контрольных событий в виде диаграммы контрольных событий, 2) укрупненное расписание в виде линейчатой диаграммы и 3) детальное расписание в виде диаграммы сети расписания проекта. На рис. 19 также наглядно показаны связи между тремя разными уровнями представления расписания. Данные расписания Данные расписания для модели расписания проекта — это совокупность информации для описания и контроля расписания. Данные расписания включают в себя, по меньшей мере, контрольные события расписания, операции расписания, параметры операций и документацию по всем выявленным допущениям и ограничениям. Количество дополнительных данных различается в зависимости от прикладной области. Информация, часто предоставляемая в качестве поддерживающих деталей, включает в себя, среди прочего: • требования к ресурсам на данный период времени, часто в форме гистограмм ресурсов; • альтернативные расписания, такие как оптимистичные и пессимистичные, с выравниванием и без выравнивания ресурсов, с ограничивающими датами и без них; • учтенные в расписании резервы на возможные потери. Данные расписания могут включать в себя такие элементы, как гистограммы ресурсов, проекции денежных потоков и расписания заказов и поставок. Календари проекта Календарь проекта определяет рабочие дни и смены, доступные для выполнения запланированных операций. Он отделяет временные периоды в виде дней или части дней, которые доступны для выполнения запланированных операций, от недоступных временных периодов. Для одной модели расписания может потребоваться более одного календаря проекта, чтобы выделить различные рабочие периоды для некоторых операций при составлении расписания проекта. Календари проекта могут обновляться. Обновления плана управления проектом Элементы плана управления проектом, которые могут быть обновлены, включают в себя, среди прочего: • базовое расписание; • план управления расписанием. Обновления документов проекта Документы проекта, которые могут быть обновлены, включают в себя, среди прочего: • Требования к ресурсам операций. Выравнивание ресурсов может иметь существенное воздействие на предварительные оценки типов и количества необходимых ресурсов. Если анализ выравнивания ресурсов изменяет требования к ресурсам проекта, то требования обновляются. • Параметры операций. Параметры операций обновляются для включения в свой состав пересмотренных требований к ресурсам и любых других изменений, вызванных процессом разработки расписания. • Календари. Календарь каждого проекта может включать в себя составные календари, календари проекта, отдельные ресурсные календари и т. д. в качестве основы для составления расписания проекта. Реестр рисков. Реестр рисков может нуждаться в обновлении для отражения благоприятных возможностей или угроз, осознанных в результате допущений, принятых для составления расписания. Концепция гибкого управления проектами (agile) в рамках управления сроками проекта (см. тему I п. 4 и тему IV п. 1). Библиографический список к Лекции №2 (Тема II): 3. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 4. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. III УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА: ПРОЦЕССЫ МОНИТОРИНГА И КОНТРОЛЯ 1. Цикл процесса управления содержанием проекта. См. тему I п.1. 2. Подтверждение содержания: составляющие, инструменты и методы. Подтверждение содержания — процесс формализованной приемки полученных поставляемых результатов проекта. Ключевая выгода данного процесса состоит в том, что он обеспечивает объективность процесса приемки и повышает вероятность приемки конечного продукта, услуги или результата путем подтверждения каждого поставляемого результата. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 1. На рис. 2 показана диаграмма потоков данных процесса. Рис. 1. Подтверждение содержания: входы, инструменты и методы, а также выходы Рис. 2. Диаграмма потоков данных подтверждения содержания Проверенные поставляемые результаты, полученные в процессе контроля качества, проверяются заказчиком или спонсором, чтобы гарантировать, что они выполнены удовлетворительно, и что поставляемые результаты были формально приняты заказчиком или спонсором. В ходе данного процесса выходы, полученные в результате процессов планирования в области знаний управления содержанием проекта, например документация по требованиям или базовый план по содержанию, а также данные по исполнению работ, полученные из процессов исполнения из других областей знаний, являются основой для подтверждения и окончательной приемки. Процесс подтверждения содержания отличается от процесса контроля качества в том плане, что подтверждение содержания в основном связано с приемкой поставляемых результатов, а контроль качества в основном ориентирован на правильность поставляемых результатов и соблюдение требований к качеству, заданных для поставляемых результатов. Контроль качества, как правило, проводится до подтверждения содержания, однако эти два процесса могут выполняться и параллельно. Подтверждение содержания: входы План управления проектом План управления проектом включает план управления содержанием и базовый план по содержанию. План управления содержанием описывает процедуру формальной приемки полученных поставляемых результатов проекта. Базовый план по содержанию включает одобренную версию описания содержания, иерархической структуры работ (ИСР) и связанного с ними словаря ИСР, которая может быть изменена только с помощью формальных процедур контроля изменений и используется как основа для сравнения. Документация по требованиям В документации по требованиям перечислены все требования к проекту, продукту и другие виды требований к проекту, продукту и другие виды требований для проекта и продукта, а также критерии их приемки. Матрица отслеживания требований Матрица отслеживания требований связывает требования с их происхождением и отслеживает их на протяжении жизненного цикла проекта. Проверенные поставляемые результаты Проверенные поставляемые результаты—это поставляемые результаты проекта, полученные и проверенные на правильность в рамках процесса контроля качества. Данные об исполнении работ Данные об исполнении работ могут включать в себя степень соответствия требованиям, количество несоответствий, серьезность несоответствий или количество циклов подтверждения, исполненных в тот или иной период времени. Подтверждение содержания: инструменты и методы Инспекция Инспекция включает в себя такие действия, как измерение, обследование и подтверждение, позволяющие определить, соответствуют ли работы и поставляемые результаты требованиям к продукту и критериям его приемки. Инспекции иногда называются «проверками», «проверками продукта», «аудитами» или «сквозным контролем». В некоторых прикладных областях данные различные термины имеют более узкий и специфический смысл. Методы группового принятия решений Данные методы используются для принятия решения, когда подтверждение выполняется командой проекта и другими заинтересованными сторонами. Подтверждение содержания: выходы Принятые поставляемые результаты Поставляемые результаты, соответствующие критериям приемки, получают формальное утверждение и одобрение заказчика или спонсора. Формальная документация, полученная от заказчика или спонсора, подтверждающая формальную приемку заинтересованной стороной поставляемых результатов проекта, передается в процесс закрытия проекта или фазы. Запросы на изменения Полученные поставляемые результаты, которые не были формально приняты, документируются с указанием причин, по которым они не были приняты. Такие поставляемые результаты могут потребовать запроса на изменение для исправления дефекта. Запросы на изменения проходят проверку и направление в соответствии с процессом интегрированного контроля изменений. Информация об исполнении работ Информация об исполнении работ включает в себя информацию о прогрессе проекта, например, работа над какими поставляемыми результатами уже началась, ее прогресс, какие поставляемые результаты уже закончены или какие уже приняты. Данная информация документируется согласно процедуре, и сообщается заинтересованным сторонам. Обновления документов проекта Документы проекта, которые могут быть обновлены в результате процесса подтверждения содержания, включают в себя любые документы, определяющие продукт или сообщающие о статусе завершенности продукта. Подтвержденные документы проекта могут потребовать одобрения от заказчика или спонсора в виде подписей или визирования. 3. Изменение содержания проекта. Контроль содержания. Контроль содержания — процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию. Ключевая выгода данного процесса состоит в том, что он позволяет придерживаться базового плана по содержанию на протяжении всего проекта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 3. На рис. 4 показана диаграмма потоков данных процесса. Рис. 3 Контроль содержания: входы, инструменты и методы, а также выходы Рис. 4 Диаграмма потоков данных контроля содержания Контроль содержания проекта обеспечивает обработку всех запрошенных изменений и рекомендованных корректирующих воздействий или предупреждающих действий в рамках процесса интегрированного контроля изменений. Контроль содержания проекта используется также для управления фактическими изменениями по мере их появления, при этом он интегрирован с остальными процессами контроля. Неконтролируемое расширение содержания продукта или проекта без учета влияния на сроки, стоимость и ресурсы называется расползанием содержания. Изменения в любом случае неизбежны, и поэтому для каждого проекта необходим процесс контроля изменений в том или ином виде. Контроль содержания: входы План управления проектом Следующая информация, содержащаяся в плане управления проектом, используется для контроля содержания: • Базовый план по содержанию. Базовый план по содержанию сравнивается с фактическими результатами, для того чтобы определить, требуются ли изменения, корректирующие воздействия или предупреждающие действия. • План управления содержанием. Разделы плана управления содержанием описывают, как будет осуществляться мониторинг и контроль содержания проекта. • План управления изменениями. План управления изменениями определяет процесс управления изменениями проекта. • План управления конфигурацией. План управления конфигурацией определяет те элементы, которые являются конфигурируемыми, элементы, которые требуют формального контроля изменений, а также процесс контроля изменений таких элементов. • План управления требованиями. Данный план является компонентом плана управления проектом, он описывает способы анализа, документирования требований и управления ими. Документация по требованиям Требования должны быть однозначными (измеримыми и проверяемыми), отслеживаемыми, полными, непротиворечивыми и приемлемыми для ключевых заинтересованных сторон. Надлежащим образом документированные требования облегчают выявление отклонений в согласованном содержании проекта или продукта. Матрица отслеживания требований Матрица отслеживания требований помогает выявить воздействие какого-либо изменения или отклонения от базового плана по содержанию на цели проекта. Данные об исполнении работ Данные об исполнении работ могут включать в себя количество полученных запросов на изменение, количество принятых запросов или количество выполненных поставляемых результатов и т. д. Активы процессов организации Активы процессов организации, которые могут оказывать влияние на процесс контроля содержания, включают в себя, среди прочего: • существующие формальные и неформальные политики, процедуры и руководящие указания, связанные с содержанием и контролем; • используемые шаблоны и методы мониторинга и отчетности. Контроль содержания: инструменты и методы Анализ отклонений Анализ отклонений — это метод определения причины и степени различий между базовым планом и фактическим исполнением. Измерения исполнения проекта используются для оценки величины отклонения от первоначального базового плана по содержанию. Важные аспекты контроля содержания проекта включают в себя определение причины и степени отклонения от базового плана по содержанию и принятие решений о необходимости корректирующих воздействий или предупреждающих действий. Контроль содержания: выходы Информация об исполнении работ Полученная информация об исполнении работ включает в себя взаимосвязанную и увязанную с контекстом информацию о том, как содержание проекта исполняется в сравнении с базовым планом по содержанию. Она может включать в себя категории полученных изменений, выявленные отклонения содержания и их причины, их воздействие на расписание или стоимость, а также прогноз в отношении будущего исполнения содержания. Данная информация является основой для принятия решений в отношении содержания. Запросы на изменения Анализ исполнения содержания может привести к появлению запроса на изменение базового плана по содержанию или других компонентов плана управления проектом. Запросы на изменения могут включать в себя предупреждающие действия, корректирующие воздействия, исправление дефектов или запросы на усовершенствования. Запросы на изменения проходят проверку и направление в соответствии с процессом интегрированного контроля изменений. Обновления плана управления проектом Обновления плана управления проектом могут включать в себя, среди прочего: • Обновления базового плана по содержанию. Если одобренные запросы на изменения оказывают влияние на содержание проекта, то описание содержания, ИСР и словарь ИСР пересматриваются и выпускаются заново, чтобы отразить одобренные изменения, в рамках процесса интегрированного контроля изменений. • Обновления прочих базовых планов. Если одобренные запросы на изменения оказывают влияние не только на содержание проекта, но и на сам проект, соответствующий базовый план по стоимости и базовые расписания пересматриваются и выпускаются заново, чтобы отразить одобренные изменения. Обновления документов проекта Документы проекта, которые могут быть обновлены, включают в себя, среди прочего: • документацию по требованиям, • матрицу отслеживания требований. Обновления активов процессов организации Активы процессов организации, которые могут быть обновлены, включают в себя, среди прочего: • причины отклонений, • выбранные корректирующие воздействия и причины выбора, другие виды уроков, извлеченных в ходе контроля содержания проекта. Библиографический список к Лекции №1 (Тема III): 5. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 6. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с. IV УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА: ПРОЦЕССЫ МОНИТОРИНГА И КОНТРОЛЯ 1. Контроль расписания: составляющие, инструменты и методы. Управление изменениями расписания проекта. Контроль расписания — процесс мониторинга статуса операций проекта для актуализации прогресса проекта и управления изменениями базового расписания с целью соответствия плану. Ключевая выгода данного процесса состоит в предоставлении средств, которые дают возможность распознать отклонения от плана и предпринять корректирующие воздействия и предупреждающие действия, и таким образом минимизировать риски. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 1. На рис. 2 показана диаграмма потоков данных процесса. Рис. 1 Контроль расписания: входы, инструменты и методы, а также выходы Рис. 2 Диаграмма потоков данных контроля расписания Для обновления модели расписания необходима информация о фактическом исполнении на текущую дату. Любое изменение базового расписания проекта может быть одобрено только посредством процесса интегрированного контроля изменений. Контроль расписания как компонент процесса интегрированного контроля изменений связан с: • определением текущего статуса расписания проекта; • влиянием на факторы, вызывающие изменения расписания; • определением фактов изменения расписания проекта; • управлением фактическими изменениями по мере их возникновения. В случае применения какого-либо гибкого (agile) подхода контроль расписания связан с: • определением текущего статуса расписания проекта путем сравнения общего количества выполненной и принятой работы с оценками работ, завершенных в течение прошедшего временного цикла; • выполнением ретроспективного анализа (запланированного анализа для документации извлеченных уроков) с целью корректировки и улучшения процессов при необходимости; • изменением приоритетов плана оставшихся работ (бэклог); • определением уровня производительности, при котором поставляемые результаты производятся, подтверждаются и принимаются (скорость) в определенный для каждой итерации период времени (согласованная длительность рабочего цикла, как правило, две недели или месяц); • определением фактов изменения расписания проекта; • управлением фактическими изменениями по мере их возникновения. Контроль расписания: входы План управления проектом План управления проектом включает в себя план управления расписанием и базовый план расписания. План управления расписанием описывает порядок управления расписанием и его контроля. Базовое расписание используется для сравнения с фактическими результатами, чтобы определить, требуются ли изменения, корректирующие воздействия или предупреждающие действия. Расписание проекта Расписание проекта — это самая свежая версия с комментариями об обновлениях, завершенных и начатых операциях на указанную отчетную дату. Данные об исполнении работ Данные об исполнении работ—это информация о прогрессе проекта, например данные о том, какие операции начались, об их прогрессе (например, фактическая длительность, оставшаяся длительность и физический процент выполнения) и о том, какие операции закончились. Календари проекта Для одной модели расписания может потребоваться более одного календаря проекта с целью выделения различных временных периодов для некоторых операций при составлении прогнозов в отношении расписания. Данные расписания Данные расписания будут оценены и обновлены в рамках процесса контроля расписания. Активы процессов организации Активы процессов организации, которые оказывают влияние на процесс контроля расписания, включают в себя, среди прочего: • существующие формальные и неформальные политики, процедуры и руководящие указания, связанные с контролем расписания; • инструменты контроля расписания; • используемые методы мониторинга и отчетности. Контроль расписания: инструменты и методы Анализ исполнения При проведении анализа исполнения измеряется, сравнивается и анализируется исполнение расписания, например, фактические даты старта и финиша, процент выполнения и оставшаяся длительность выполняемых работ. Могут применяться различные методы, среди прочего, следующие: • Анализ тенденций. В ходе анализа тенденций изучается исполнение проекта с течением времени с целью определения того, ухудшается оно или улучшается. Методы графического анализа представляют собой ценность в плане понимания исполнения на текущую дату и сравнения с целями будущего исполнения в виде дат завершения. • Метод критического пути. Сравнение прогресса на протяжении критического пути может оказаться полезным при определении статуса расписания. Отклонение на критическом пути будет иметь непосредственное воздействие на дату завершения проекта. Оценка прогресса операций на путях, близких к критическому, может оказаться полезной при определении риска расписания. • Метод критической цепи. Сравнение объема оставшегося буфера с объемом буфера, необходимым для обеспечения соблюдения срока завершения, может оказаться полезным при определении статуса расписания. Сравнивая необходимый и имеющийся буфер, можно определить, уместно ли корректирующее воздействие. • Управление освоенным объемом. Измерения выполнения сроков, такие как отклонение по срокам (ОСР) и индекс выполнения сроков (ИВСР), используются для оценки величины отклонения от первоначального базового расписания. Отклонение полного временного резерва и отклонения от раннего финиша также являются важными элементами планирования, позволяющими оценить выполнение сроков проекта. Важные аспекты контроля расписания проекта включают в себя определение причины и степени отклонения относительно базового расписания, оценку последствий этих отклонений для будущих работ и принятие решений о необходимости корректирующих воздействий или предупреждающих действий. Например, большая задержка любой операции, находящейся не на критическом пути, может оказывать незначительное воздействие на общее расписание проекта, но в то же время гораздо меньшая задержка критической или околокритической операции может потребовать немедленных действий. Для проектов, в которых не применяется управление освоенным объемом, может быть выполнен аналогичный анализ отклонений путем сравнения запланированных дат старта и финиша с фактическими датами старта и финиша для определения различий между базовым расписанием и фактическим исполнением проекта. Будущий анализ может быть выполнен для определения причины и степени отклонения от базового расписания и необходимых корректирующих воздействий или предупреждающих действий. Программное обеспечение для управления проектом Программное обеспечение для управления проектом, позволяющее составлять расписание, предоставляет возможность сравнивать плановые даты с фактическими для сообщения об отклонениях и прогрессе относительно базового расписания и прогнозировать влияние изменений на модель расписания проекта. Методы оптимизации ресурсов Методы оптимизации ресурсов включают в себя составление расписания операций и планирование использования ресурсов, необходимых для выполнения этих операций, с учетом как доступности ресурсов, так и сроков проекта. Методы моделирования Методы моделирования используются для рассмотрения разнообразных сценариев, управляемых с помощью мониторинга рисков, с целью приведения модели расписания в соответствие с планом управления проектом и одобренным базовым планом. Опережения и задержки Адаптация опережений и задержек проводится в рамках анализа сети для поиска способов приведения отстающих операций проекта в соответствие с планом. Например, в проекте по строительству нового офисного здания начало работ по благоустройству территории может быть запланировано до завершения наружных работ путем увеличения времени опережения в связи между задачами. Или, например, команда по разработке документации может приступить к редактированию проекта большого документа сразу после его создания за счет устранения или уменьшения времени задержки. Сжатие расписания Методы сжатия расписания используются для поиска способов приведения отстающих операций проекта в соответствие с планом, используя быстрый проход или сжатие расписания для оставшихся работ. Инструмент составления расписания Данные расписания обновляются и накапливаются в модели расписания для отражения фактического прогресса проекта и оставшихся работ, которые необходимо выполнить. Инструмент составления расписания и вспомогательные данные расписания используются в сочетании с ручными методами или с другим программным обеспечением для управления проектом для проведения анализа сети расписания и создания обновленного расписания проекта. Контроль расписания: выходы Информация об исполнении работ Рассчитанные индикаторы исполнения сроков проекта ОСР и ИВСР для компонентов ИСР, в частности для пакетов работ и контрольных счетов, документируются и сообщаются заинтересованным сторонам. Прогнозы в отношении расписания Прогнозы в отношении расписания — оценка или прогноз условий и событий в будущем проекта на основании информации и знаний, доступных на момент прогнозирования. Прогнозы обновляются и составляются повторно на основании информации об исполнении работ, предоставляемой в ходе исполнения проекта. Эта информация основывается на предыдущем и ожидаемом будущем исполнении проекта, а также включает в себя индикаторы исполнения освоенного объема, которые могут воздействовать на проект в будущем. Запросы на изменения Анализ отклонений по срокам, а также анализ отчетов об исполнении, результаты измерений исполнения и модификации содержания или расписания проекта могут приводить к составлению запросов на изменения базового расписания, базового плана по содержанию и/или других компонентов плана управления проектом. Запросы на изменения обрабатываются с целью проведения проверки и представления в рамках процесса интегрированного контроля изменений. Предупреждающие действия могут включать в себя рекомендованные изменения для устранения или уменьшения вероятности отрицательных отклонений по срокам. Обновления плана управления проектом Элементы плана управления проектом, которые могут быть обновлены, включают в себя, среди прочего: • Базовое расписание. Изменения базового расписания производятся в ответ на одобренные запросы на изменения, связанные с изменениями содержания проекта, ресурсами операций или оценками длительности операций. Базовое расписание может обновляться для отражения изменений, вызванных методами сжатия расписания. • План управления расписанием. План управления расписанием может обновляться для отражения изменений порядка управления расписанием. • Базовый план по стоимости. Базовый план по стоимости может обновляться для отражения изменений, вызванных методами сжатия. Обновления документов проекта Документы проекта, которые могут быть обновлены, включают в себя, среди прочего: • Данные расписания. Могут создаваться новые диаграммы сети расписания проекта для отображения одобренных оставшихся длительностей и модификаций расписания. В некоторых случаях задержки расписания проекта могут быть настолько серьезными, что может понадобиться разработка нового целевого расписания с прогнозируемыми датами старта и финиша для предоставления реалистичных данных, используемых для руководства работами и измерения прогресса. • Расписание проекта. Может быть создано обновленное расписание проекта на базе модели расписания, заполненного обновленными данными расписания, для отражения изменений расписания и управления проектом. • Реестр рисков. Также могут обновляться реестр рисков и включенные в него планы реагирования на риски с учетом рисков, которые могут возникнуть вследствие применения методов сжатия расписания. Обновления активов процессов организации Активы процессов организации, которые могут быть обновлены, включают в себя, среди прочего: • причины отклонений; • выбранные корректирующие воздействия и причины; другие виды уроков, извлеченных в ходе контроля расписания проекта. Библиографический список к Лекции №1 (Тема IV): 7. Коваленок Т.П. Управление проектами: учеб. пособие - СПб. : ПГУПС, 2011. - 73 с. 8. Руководство к Своду знаний по управлению проектами. Project Management Institute (USA). - 5-е изд. - Москва: Олимп-Бизнес, 2014. – 586 с.