ПЛАНИРОВАНИЕ ПРОЕКТА

Группа процессов планирования Оценка длительности операций Разработка расписания Оценка стоимости плана управления человеческими ресурсами Определение заинтересованных сторон План обмена информацией Идентификация рисков Проведение качественного анализа рисков Проведение количественного анализа рисков Планирование реагирования на риски Планирование требований Осуществление закупок Е.Л.Разова Управление проектами 2

Операции процессов планирования (1 из 2) Разработку плана управления проектом Выявление, определение и доработку содержания и стоимости проекта Разработку расписания операций проекта в рамках самого проекта Оценку ресурсов, рабочих периодов и стоимости ресурсов, которые необходимы для завершения операций проекта Е.Л.Разова Управление проектами 3

Операции процессов планирования (2 из 2) Разработку планов по работе с рисками, от планирования управления рисками до планирования реагирования на риски Определение релевантных стандартов качества Определение и документирование ролей и обязанностей Определение информационных и коммуникационных потребностей заинтересованных сторон Определение того, что необходимо закупить или приобрести, когда и как Е.Л.Разова Управление проектами 4

Цели процессов планирования (1 из 3) Используются командой управления проектом для успешного планирования и управления проектом в организации Помогают собирать информацию из многочисленных источников, каждый из которых обладает своим уровнем компетенции и доверия Учитывают комплексный характер управления проектами и поддерживают цепочки обратной связи для дополнительного анализа при получении новой информации Способствуют планированию проекта во время осуществления многочисленных процессов Е.Л.Разова Управление проектами 5

Цели процессов планирования (2 из 3) Команда управления проектом использует группу процессов планирования для успешного планирования и управления проектом в организации Е.Л.Разова Управление проектами 6 Группа процессов планирования способствует планированию проекта во время осуществления многочисленных процессов

Цели процессов планирования (3 из 3) Серьезные изменения на протяжении жизненного цикла проекта вызывают необходимость пересмотра одного или нескольких процессов планирования или, возможно, нескольких процессов инициации Е.Л.Разова Управление проектами 7

Процессы планирования (1 из 2) Разработка плана управления проектом Сбор требований Определение содержания Создание иерархической структуры работ Определение операций Определение последовательности операций Оценка длительности операций Разработка расписания Е.Л.Разова Управление проектами 8

Процессы планирования (2 из 2) Оценка стоимости Определение бюджета Планирование качества Разработка плана управления человеческими ресурсами Определение заинтересованных сторон План обмена информацией Идентификация и анализ рисков, планирование реагирования на риски Планирование требований Осуществление закупок Е.Л.Разова Управление проектами 9

ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ Е.Л.Разова Управление проектами 10

План управления проектом Цели разработки плана управления проектом: Определить процессы и документацию управления Координировать процессы и документацию управления Интегрироваться базовые и второстепенные планы Основной принцип разработки плана управления проекта – подгонка (tailoring): определить, какие группы и процессы наиболее подходят для управления конкретным проектом Е.Л.Разова Управление проектами 11

Входы Устав проекта Факторы внешней бизнес-среды Активы процессов организации PMIS (Project Management Integration System) – система, используемая для документирования плану управления проектом и второстепенных планов, обеспечивающая процесс обратной связи и проверки документации; инструмент обеспечения автоматизации, сбора и описания данных и помощи для мониторинга процессов управления расписанием, бюджетом; веб-интерфейс Е.Л.Разова Управление проектами 12

PM план Описывает, интегрирует и координирует базовые и второстепенные планы для процессов, выбранных для управления проектом. Нужен, чтобы определить, как проект исполнится, мониторится, контролируется, закрывается; какие документы и процессы при этом используются; Каков порядок изменения в документах и процессах в ходе реализации проекта Е.Л.Разова Управление проектами 13

Структура PM плана Перечни процессов, используемые для реализации каждой фазы проекта Жизненный цикл проекта и каждой фазы проекта Методы выполнения работ проекта для достижения результата План управления изменениями, описывающий методы мониторинга и контроля изменений Управление конфигурацией Методы контроля исполнения базовых планов Потребности заинтересованных сторон в коммуникациях и технологии удовлетворения этих потребностей Управление пересмотром содержания и конфликтами Е.Л.Разова Управление проектами 14

Второстепенные планы План управления содержанием План управления требованиями План управления расписанием План управления стоимостью План управления качеством План управления коммуникациями План управления рисками План управления закупками Е.Л.Разова Управление проектами 15

Прочие документы Список ключевых событий Ресурсный календарь Базовый план содержания (требований) Базовой план расписания Базовый план бюджета Базовый план качества Реестр рисков Е.Л.Разова Управление проектами 16

Базовые планы исполнения Должна быть четкая разница между планом проекта и базовым планом исполнения Базовый план исполнения меняется лишь время от времени, и то только, главным образом, в ответ на принятие изменений в содержании и результате проекта Проекты имеют три базовых плана исполнения Базовый план содержания (требований) Базовый план расписания Базовый план бюджета Их часто называют базовыми планами Е.Л.Разова Управление проектами 17

Базовые планы Базовый план содержания (scope baseline) Базовый план расписания (schedule baseline) Базовый план бюджета (cost baseline) Е.Л.Разова Управление проектами 18

СБОР ТРЕБОВАНИЙ Е.Л.Разова Управление проектами 19

Требования Условия, которые должны быть соблюдены. Критерии, которым продукт/услуга/результат должны соответствовать, чтобы удовлетворить требования и цели проекта Е.Л.Разова Управление проектами 20

Основные определения Потребности - это операции, услуги, продукты и результаты, которые полезны, необходимы или желаемы Требования - формально задокументированное описание потребностей спонсора, которые должны быть удовлетворены проектом Исключения - заявления от том, что не включено в данный проект Спецификации - детальные описания характеристик, которые должны быть реализованы Базовый план - сходные данные, в соответствии с которыми планируется и контролируется выполнение операций проекта: состоит из элементов соглашения и плена управления проектом; как только базовый план создан, он переходит под действие управления изменениями Результаты – результат деятельности, который должен быть поставлен в соответствии с соглашением Е.Л.Разова Управление проектами 21

Цели сбора требований Цель сбора требований - определить и документировать ожидания и потребности спонсора, заказчика и заинтересованных сторон, чтобы обеспечить достижение целей проекта. Требования являются основанием для разработки WBS Е.Л.Разова Управление проектами 22

Выработка и утверждение требований происходит во время… Разработки предложения Начала проекта Принятия на себя ведения уже запущенного проекта (переутверждение) Переоценки требований по проекту (промежуточный проект) Е.Л.Разова Управление проектами 23

Этапы процесса выработки требований клиента 1. Сбор информации о потребностях клиента и заинтересованных лиц 2. Распределение этих потребностей по двум категориям: требования и исключения 3. Утверждение требований 4. Утвержденные требования используются в качестве принятого базового плана требований для проекта Е.Л.Разова Управление проектами 24

Сбор информации о потребностях Для сбора информации о потребностях необходимо: Прочитать всю проектные документы, такие как контракт, документы о достижении взаимопонимания сторон, технические задания и любые другие документы, в которых также могут содержаться требования Опросить спонсора Определить приоритетность или количественные параметры ответов спонсора на поставленные вопросы; данный анализ должен помочь вам определить реальные потребности для вашего проекта Е.Л.Разова Управление проектами 25

Инструменты и технологии для сбора требований (1 из 2) Интервью Фокус-группы (собрание профильных специалистов) Рабочие группы (собрание разноотраслевых специалистов) Технологии творческих групп (мозговой штурм, номинальная группа, mind mapping) Е.Л.Разова Управление проектами 26

Инструменты и технологии для сбора требований (2 из 2) Технологии выработки группового решения, использующие 4 методики: единодушие большинство (решение поддерживает более 50% группы) плюрализм (решение поддерживает самая крупная подгруппа, если большинство не достигнуто) диктатура Опросы и исследования (для больших групп) Наблюдения (за ходом работы) Прототипирование и эксперимент Е.Л.Разова Управление проектами 27

Документы, где присутствуют требования: Потребности бизнеса Требования бизнес-среды Цели проекта Функциональнее требования (спецификация) Нефункциональные требования (не описывают сам продукт) Требования по качеству Критерии приемки Правила бизнеса Требования по поддержке и обучению Допущения и ограничения Е.Л.Разова Управление проектами 28

План управления требованиям Зависит от типа связи фаз проекта: Последовательная связь – требования для последующих фаз определяются после того, как работа по предшествующей фазе завершена. Перекрывающаяся связь – требования должны быть определены на ранних стадиях жизненного цикла проекта Е.Л.Разова Управление проектами 29

Структура плана управления требованиями Как планируется прослеживать действия с требованиями Как планируется запрашивать, отслеживать, анализировать требования Как требования будут приоритезироваться Какие метрики будут использоваться для отслеживания требований Матрица прослеживаемости (Traceability Matrix) Е.Л.Разова Управление проектами 30

Матрица прослеживаемости (Traceability Matrix) IDОписание требования источникприорит ет Сценарий проверки Статус 001Требование первичное Цели проекта ВОдобрение пользователя Одобрено Е.Л.Разова Управление проектами 31

При выработке требований вы можете задать следующие вопросы: Как вы думаете, почему мы делаем этот проект? Какова ваша роль в бизнесе и в проекте? Как проект влияет на вашу роль? Какие функции и результаты вам необходимы? Кто ваши заинтересованные стороны? Какое финансовое влияние данный проект имеет на вашу организацию? Выработка требований клиента (1 из 2)

Выработка требований клиента (2 из 2) В состоянии ли существующая инфраструктура поддерживать ваши потребности? Какая внешняя поддержка вам необходима? Ваше определение успеха? Как долго он продолжается? Имеются ли в разработке или употреблении подобные продукты? Каковы ваши критерии завершения проекта? Е.Л.Разова Управление проектами 33

Потребность = Требование = Содержание проекта Потребность = Требование другого проекта Потребность = Исключение Сценарии превращения потребностей в «требования» и «исключения»

Вопросы для включения требований: Является ли данная потребность частью изначальной цели проекта? Является ли данная потребность новой функцией или характеристикой, которая не была включена в первоначальную цель проекта? Была ли стоимость реализации данной потребности включена в первоначальную оценку стоимости? Всякая потребность, которая не является требованием, считается исключением. Условия включения потребностей в требования проекта

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

Базовый план требований - это документ, содержащий требования, утвержденные спонсором, заинтересованными лицами и ключевыми членами команды проекта Базовый план определяет, что хочет спонсор и что согласилась выполнить команда проекта Он может быть изменен только в том случае, если данное изменение было одобрено спонсором, заинтересованными сторонами и менеджером проекта Создание базового плана требований (1 из 2)

Создание базового плана требований - один из способов осуществления контроля над содержанием проекта, который позволяет избежать разрастания содержания проекта Медленное разрастание содержания происходит тогда, когда требования проекта продолжают изменяться; если содержание проекта выйдет из- под контроля, вы никогда не сможете завершить проект; происходит постоянный выход за рамки расписания и расходы растут Одной из ваших важнейших задач в качестве менеджера проекта является четкая работа с базовым планом требований Создание базового плана требований (2 из 2)

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

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

Неясные требования: Это основной источник трудностей. Чем уникальнее проект, тем выше риск возникновения неясных или неточных требований. Требования динамичны и изменчивы, так как они определяются отношением к текущей ситуации Вы должны направлять процесс и работать в плотном взаимодействии со спонсором для определения четких требований Преждевременные решения: Ответы, которые даются до того, как будут заданы все нужные вопросы, могут привести к преждевременным и неверным решениям Некоторые типичные трудности, возникающие при сборе требований (1 из 2)

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

Всегда проводите идентификацию, анализ и утверждение требований Убедитесь, что задаёте правильные вопросы, чтобы понять, как проект вписывается в бизнес-стратегию руководства Применяйте систематичный подход Четко формулируйте требования, обеспечьте подписание документа с требованиями персоналом проекта и клиентом/спонсором проекта Согласуйте процесс определения требований между командой проекта и клиентом/спонсором проекта Ключевые идеи

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

БАЗОВЫЙ ПЛАН СОДЕРЖАНИЯ Е.Л.Разова Управление проектами 45

Содержание плана управления содержанием Процессы, используемые для разработки перечня работ по проекту (project scope statement) Процессы для разработки WBS Описание верификации результатов и их приемки Процесс контроля запросов на изменения содержания проекта Е.Л.Разова Управление проектами 46

Определение содержания Е.Л.Разова Управление проектами 47 scope Project scope Product scope

Перечень работ по проекту (Project Scope Statement) Это: цели проекта; детальное описание результатов проекта (project deliverables); работы, которые необходимо осуществить для получения этих результатов. Это НЕ: Цели проекта (project objectives) – измеримые критерии, используемые для измерения успешности проекта Е.Л.Разова Управление проектами 48

Перечень работ по проекту (Project Scope Statement) Задача: обеспечить единое понимание всеми заинтересованными сторонами содержания проекта; обеспечить согласие между заказчиком и исполнителем о том, какие работы по проекту должны быть реализованы и что каждый получит в результате проекта; обеспечить определение и последовательную разработку работ проекта, создать основу для внесения изменений в проект Е.Л.Разова Управление проектами 49

Структура Project Scope Statement Содержание продукта Критерии приемки продукта Результаты проекта (Project Deliverables) – измеримые выходы, результаты, которые должны быть созданы, чтобы проект или фаза проекта считались завершенными. Исключения в проекте Ограничения проекта Допущения проекта Е.Л.Разова Управление проектами 50

Ограничения проекта Е.Л.Разова Управление проектами 51 качество содержание стоимость расписание

Ограничения проекта (1 из 2) Ограничения по времени Ограничения по стоимости Ограничения по содержанию Ограничения по качеству Ограничения по расписанию (нужные ресурсы должны приходить вовремя, работы должны выполняться последовательно и вовремя) Е.Л.Разова Управление проектами 52

Ограничения проекта (2 из 2) Ограничения по ресурсам: Доступность ключевых ресурсов (люди) внешних внутренних Доступность материальных ресурсов Ограничения по технологии Административные ограничения: Политики и стандарты организации Решения руководства Е.Л.Разова Управление проектами 53

Допущения проекта Допущение – это то, что мы полагаем как имеющее место быть. Допущения должны идентифицироваться, документироваться и обновляться. Выявления новых допущений и конкретизация старых – одна из форм последовательной разработки Е.Л.Разова Управление проектами 54

Источники допущений проекта Е.Л.Разова Управление проектами 55 допущения Допущения менеджера проекта Допущения заинтересованных сторон

Типичные допущения Доступность ключевых ресурсов (люди) Сроки поставок Доступность товаров/продуктов Доступность подрядчиков Точность плановой документации по проекту Адекватная работа членов команды проекта Дата подписания контракта Дата старта проекта / фазы проекта Е.Л.Разова Управление проектами 56

ИЕРАРХИЧЕСКАЯ СТРУКТУРА РАБОТ Е.Л.Разова Управление проектами 57

Иерархическая структура работ (WBS) Иерархическая структура работ (WBS) – ориентированная на результат (предмет поставки) иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и получения необходимых результатов; с ее помощью структурируется и определяется все содержание проекта WBS – базовое соглашение между заинтересованными сторонами и командой проекта в отношении содержания проекта Е.Л.Разова Управление проектами 58

WBS - это основа проекта с точки зрения планирования, оценки, составления бюджета, финансирования, составления расписания и отчетов о статусе проекта, управления рисками, оценки эффективности и управления изменениями; фокусирует внимание на целях проекта Разработка начинается в тот момент, когда определены и согласованы со спонсором результаты и содержание проекта может быть описано в планировании проекта в измеряемых и абстрактных единицах трудоемкости Разработка иерархической структуры работ (WBS) (1 из 2)

WBS ориентируется как внутренние, так и внешние результаты проекта. Работы – не указанные в WBS, не входят в содержание проекта. Каждый последующий (по убыванию) уровень представляет все более детализированное определение работ проекта. Разработка иерархической структуры работ (WBS) (2 из 3)

Разработка иерархической структуры работ (WBS) (3 из 3) WBS используется в проекте в качестве инструмента коммуникации, она растет и развивается вместе с проектом, начиная с самого первого дня. При пересмотре плана проекта WBS также должна быть пересмотрена Одобренное детальное описание содержания проекта и связанная с ним WBS и каталог WBS представляют собой базовый план по содержанию проекта Е.Л.Разова Управление проектами 61

Служит шаблоном для других проектов и используется для достижения общего подымания содержания проекта Обеспечивает единый архив данных для рабочих элементов проекта Обеспечивает помощь в создании четкой структуры распределения обязанностей в работе, ресурсов и затрат Обеспечивает помощь в определении областей риска Значимость WBS (1 из 2)

Значимость WBS (2 из 2) Обеспечивает логическую структуру для каталогизации всех рабочих элементов Обеспечивает стандартные рамки, которые могут быть использованы для разработки подобных проектов, помогая в процессе разработки плана и позволяя проводить сопоставительные анализы по завершении проекта Е.Л.Разова Управление проектами 63

Входы WBS Устав проекта Документированные требования Содержание работ по проекту Активы процессов организации Е.Л.Разова Управление проектами 64

Декомпозиция Декомпозиция – разбиение результатов на более мелкие, легче управляемые составляющие работы, которые: легко планировать легко выполнять легко мониторить и контролировать легко завершать Е.Л.Разова Управление проектами 65 Каждый последующий уровень WBS – более детальное описание предыдущего

Задачи декомпозиции Благодаря декомпозиции работ в WBS: Проще оценить стоимость, время и необходимые ресурсы для каждого отдельного компонента Проще осуществлять мониторинг и контроль изменений Позволяет сравнивать текущий проект к другими проектами или фазами Проще назначать ресурсы (исполнителей) с различным уровнем квалификации Е.Л.Разова Управление проектами 66

5 шагов в процессе декомпозиции 1. Идентифицировать высокоуровневые результаты работы 2. Создать верхний уровень WBS из высокоуровневых результатов 3. Декомпозировать компоненты WBS на низшие уровни (результаты декомпозиции должны быть измеримыми, материальными, поверяемыми) 4. Установить идентификационные коды (порядковые номера) для каждого компонента WBS 5. Верифицировать WBS на полноту, четкость, достаточность компонентов Е.Л.Разова Управление проектами 67

Пакеты работ Запланированные работы, находящиеся на самом нижнем уровне WBS и называемые пакетами работ. Пакет работ – результат или элемент работ проекта, расположенный на самом низком уровне каждого ответвления иерархической структуры работ. Это часть работы о который мы знаем, как она может быть включена в расписание. Именно в этой точке возможно рассчитать стоимость работ и срок их выполнения, определить критерии выполнения и конкретного исполнителя Е.Л.Разова Управление проектами 68

Пакеты работ: Имеют внешний или внутренний результат Внутренние результаты используются самим проектом Внешние результаты поставляются клиенту или спонсору Дают определенные и конкретные продукты или результаты Имеют четкие и поддающиеся верификации критерии завершенности Равны сумме непосредственных операций на следующем, более высоком уровне Могут быть переданы под исключительную ответственность одной стороны, подразделения организации или лица Характеристики пакетов работ

Виды WBS (1 из 5) Е.Л.Разова Управление проектами 70

Виды WBS (1 из 5)

Е.Л.Разова Управление проектами 72

Виды WBS (1 из 5) Е.Л.Разова Управление проектами 73

Виды WBS (1 из 5) Е.Л.Разова Управление проектами 74

Формат WBS Проект Фаза A Задача 1 Подзадача 1 Фаза BФаза M Задача n Подзадача x Операция 1 Операция y Е.Л.Разова Управление проектами 75

Способы создание WBS 1. Основные результаты – 1 уровень декомпозиции; подпроекты и работы по их достижению - нижние уровни. 2. Подпроекты – первый уровень декомпозиции (для каждого подпроекта PM делает свою WBS). 3. Проектные фазы – первый уровень декомпозиции, результаты фаз – следующий уровень Е.Л.Разова Управление проектами 76

Уровни WBS Количество уровней WBS зависит от сложности проекта. 1-й уровень – уровень проекта (имя проекта) 2-й уровень – первый уровень декомпозиции Нижний уровень – уровень пакета работ. Задача– довести декомпозицию до такого уровня, чтобы один пакет работ мог быть назначен одному СП/группе людей/исполнителю Е.Л.Разова Управление проектами 77

Результаты и мероприятия Мероприятия обычно НЕ включаются в WBS. В WBS ВСЕГДА включаются результаты Е.Л.Разова Управление проектами 78 Мероприятия - глаголы Результаты - существительные

Думая о результатах деятельности, мыслите существительными Убедитесь, что в текущем базовом плане каждому результату (предмету поставки) соответствует свой результат деятельности Начните с самого высокого уровня WBS Используйте подход "сверху вниз для определения всех подрезультатов деятельности для каждого результата деятельности Создайте WBS, следуя в направлении сверху вниз к результатам деятельности Рекомендации для создания WBS на уровне пакетов работ (1 из 2)

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

Каталог WBS Каталог иерархической структуры работ – документ, описывающий каждый элемент в иерархической структуре работ, включая: Краткое описание содержания или технического задания Определенные результаты (предметы поставки) Список имеющих к ним отношение операций Список контрольных событий Е.Л.Разова Управление проектами 81

Каталог иерархической структуры работ - документ, описывающий каждый элемент в иерархической структуре работ (WBS) Для каждого элемента WBS в каталоге присутствует: краткое описание содержания или технического задания определенные результаты (предметы поставки) список имеющих к ним отношение операций список контрольных событий Подготовка каталога WBS (1 из 2)

Подготовка каталога WBS (2 из 2) Может включать в себя: ответственную организацию даты начала и окончания работ требуемые ресурсы оценку стоимости номер для начисления затрат контрактную информацию требования в отношении качества технические рекомендации для повышения эффективности работы Е.Л.Разова Управление проектами 83

Вначале соберите все текущие материалы по базовому плану и информацию связанную с проектом, такую как: Документ, содержащий определение проекта Технические требования Технические предложения Предложения поставщиков Проведите семинар с ключевыми людьми Рекомендации по разработке WBS (1 из 2)

Рекомендации по разработке WBS (2 из 2) Сконцентрируйте внимание только на уровне 2 или 3 WBS Используйте стикеры, а не флипчарты, белую доску или инструмент планирования на ПК Передайте ответственность подчиненным, которые должны отвечать за конкретный пакет работ Задокументируйте каждый пакет работ, в том числе укажите критерии его завершенности Е.Л.Разова Управление проектами 85

Как поддерживается, хранится и распределяется WBS? Будет ли использоваться инструмент планирование проекта? Какие стандарты нумерации используются? Что делать с дополнительными расходами, связанными с проектом? Должны ли все пакеты работ одного уровня быть сопоставимы по своим размерам и значимости? Какие вопросы необходимо задать при создании WBS (1 из 2)

Должны ли все ветви иерархии быть разработаны до одинакового уровня? Может ли каждая из операций более низкого уровня быть передана под ответственность лица или организации приблизительно на 40 часов? Может ли каждая рабочая операция быть измерена с точки зрения ее близости к стадии завершения? Имеется ли согласие со стороны организации или лица, которые несут ответственность за пакет работ или операцию? Какие вопросы необходимо задать при создании WBS (2 из 2)

Проведите оценку результатов со всеми ключевыми членами команды, чтобы убедиться в поддержке и согласии всех сторон - Убедитесь, что WBS охватывает все пакеты работ и что учтены все факторы стоимости, связанные с проектом (непосредственные и дополнительные) Оцените, как используется и поддерживается WBS во время проекта Оцените результаты, применив два подхода - "сверху вниз" и "снизу-вверх" Экспертиза/Утверждение WBS

Сверху вниз Снизу вверх Встречается ли более 10 операций на одном уровне? Схожи ли операции по длительности и трудоемкости? Может ли быть передана ответственность по операциям? Все ли результаты (предметы поставки) представлены? Можно ли назвать операции управления проектами полными? Может ли ответственность быть передана отдельному лицу? Можно ли определить критерии завершенности? Может ли пакет работ быть точно оценен? Позволяет ли размер пакета работ управлять им и контролировать его? Экспертиза/Утверждение WBS

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

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