Разработка календарного плана проекта

Планирование проекта является обязательным элементом процесса управления проектом. Основным результатом процесса планирования является принятый План проекта.

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

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

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

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

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

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

Разработка Плана проекта, равно как и методологии его создания, целесообразна в случае необходимости:

определения сроков выполнения работ по проекту и выдачи заданий исполнителям;

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

планирования поставок и контрактов в проекте

оптимизации ресурсного обеспечения хода выполнения проекта;

определения схемы и видов коммуникаций по проекту;

идентификации рисков и мер по их упреждению и реагированию;

определения мер по повышению качества в проекте.

Разработка Плана проекта – сложная задача, от правильной реализации которой зависит все дальнейшее развитие проекта.

ГК «Проектная ПРАКТИКА» предлагает специальную услугу, которая может осуществляться по аутсорсинговой схеме, – разработку плановых документов проекта нашими консультантами, работающими на территории компании-заказчика. Состав и количество документов согласуется с Заказчиком и определяется в договоре.

На основе теории управления проектами (в первую очередь, методологии PMB O K) и опыта специалистов нашей группы компании мы выделяем следующие типовые элементы Плана проекта:

детальные календарные планы работ по проекту (в т.ч. планы по ресурсам );

бюджет (смета) проекта;

план поставок и контрактов;

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

масштаба, сложности и специфики проекта,

степени формализации процессов управления в компании,

уровня компетенций руководства конкретного проекта.

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

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

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

Кроме того, аутсорсинговая схема позволяет консультантам ГК «Проектная ПРАКТИКА» полностью «погрузиться» в проблематику Заказчика. т.к. они работают непосредственно в составе проектной команды на территории Заказчика. Это гарантирует высокое качество документов и ускорение выполнения работ.

Сформированный План проекта обеспечит вашей компании:

четкое понимание сроков достижения целей проекта и ключевых событий в проекте;

определение требуемого количества ресурсов (людских, финансовых и т.д.);

формирование перечня задач, направленных на достижение целей проекта, и их сроков;

упорядочивание процессов информационного обмена между участниками проекта;

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

Министерство здравоохранения и социального развития РФ

Министерство сельского хозяйства РФ

«Адамас» столичный ювелирный завод»

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

На Ваши вопросы готов ответить наш эксперт:
Козодаев Михаил Александрович
Директор по консалтингу, PMP (PMI)
+7 (495) 258-06-68, consulting@pmpractice.ru

Планирование проекта является обязательным элементом процесса управления проектом. Основным результатом процесса планирования является принятый План проекта.

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

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

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

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

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

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

Разработка Плана проекта, равно как и методологии его создания, целесообразна в случае необходимости:

определения сроков выполнения работ по проекту и выдачи заданий исполнителям;

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

планирования поставок и контрактов в проекте

оптимизации ресурсного обеспечения хода выполнения проекта;

определения схемы и видов коммуникаций по проекту;

идентификации рисков и мер по их упреждению и реагированию;

определения мер по повышению качества в проекте.

Разработка Плана проекта – сложная задача, от правильной реализации которой зависит все дальнейшее развитие проекта.

ГК «Проектная ПРАКТИКА» предлагает специальную услугу, которая может осуществляться по аутсорсинговой схеме, – разработку плановых документов проекта нашими консультантами, работающими на территории компании-заказчика. Состав и количество документов согласуется с Заказчиком и определяется в договоре.

На основе теории управления проектами (в первую очередь, методологии PMB O K) и опыта специалистов нашей группы компании мы выделяем следующие типовые элементы Плана проекта:

детальные календарные планы работ по проекту (в т.ч. планы по ресурсам );

бюджет (смета) проекта;

план поставок и контрактов;

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

масштаба, сложности и специфики проекта,

степени формализации процессов управления в компании,

уровня компетенций руководства конкретного проекта.

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

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

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

Кроме того, аутсорсинговая схема позволяет консультантам ГК «Проектная ПРАКТИКА» полностью «погрузиться» в проблематику Заказчика. т.к. они работают непосредственно в составе проектной команды на территории Заказчика. Это гарантирует высокое качество документов и ускорение выполнения работ.

Сформированный План проекта обеспечит вашей компании:

четкое понимание сроков достижения целей проекта и ключевых событий в проекте;

определение требуемого количества ресурсов (людских, финансовых и т.д.);

формирование перечня задач, направленных на достижение целей проекта, и их сроков;

упорядочивание процессов информационного обмена между участниками проекта;

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

Министерство здравоохранения и социального развития РФ

Министерство сельского хозяйства РФ

«Адамас» столичный ювелирный завод»

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

На Ваши вопросы готов ответить наш эксперт:
Козодаев Михаил Александрович
Директор по консалтингу, PMP (PMI)
+7 (495) 258-06-68, consulting@pmpractice.ru

PMI, PMBoK

Группа процессов планирования состоит из процессов, осуществляемых для определения общего содержания работ, постановки и уточнения целей и разработки последовательности действий, требуемых для достижения данных целей. В процессах планирования разрабатываются план управления проектом и документация проекта. которые будут использованы для выполнения проекта. Комплексный характер управления проектами порождает цепочки обратной связи для дополнительного анализа. По мере поступления и осмысления большего объема информации или характеристик проекта может потребоваться дополнительное планирование. Значительные изменения, происходящие на протяжении жизненного цикла проекта, приводят к необходимости вновь вернуться к одному или нескольким процессам планирования, а, возможно, и к процессам инициации. Эта последовательная детализация плана управления проектом часто называется «планированием набегающей волной» (“rolling wave planning”), что указывает на то, что планирование и документирование – повторяющиеся и постоянно идущие процессы.

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

Выходы многих процессов планирования, интегрируются для создания плана управления проектом. Любые базовые и вспомогательные планы управления, являющиеся выходами других процессов планирования, являются входами для данного процесса. Кроме того, обновления данных документов могут привести к корректировке плана управления проектом. План управления проектом – это совокупность всех проектных планов .

Блок-схема данных при разработке плана управления проектом

Возможный состав плана управления проектом:

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

Корректировка «плана управления проектом» – осуществляется в течение всего проекта, в ответ на изменившиеся внешние условия, реализовавшиеся риски и т.д. Предсказать, где и когда понадобятся изменения заранее невозможно, посему их не планируют заранее, а осуществляют при помощи механизма «контроля изменений» .

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

• Определение самой процедуры планирования
• Собрать и финализировать требования
• Сформировать концепцию (scope)
• Принять решение «что закупаем»?
• Определить команду
• Создать ИСР (иерархическую структуру работ) (WBS)
• Создать перечень действий (activity list)
• Создать сетевую диаграмму (network diagram)
• Оценить требуемые ресурсы
• Оценить продолжительность действий и стоимость
• Сформировать расписание
• Создать бюджет
• Планировать качество – создать метрики
• Создать план улучшения процессов
• Распределить роли и ответственности
• Создать план коммуникаций

Спланировать управление рисками, идентифицировать риски, качественный анализ, количественный анализ, планировать реагирование на риски.

Многие элементы «планов» уже прорабатывались во время инициации и были включены в устав, то-есть уже создавались грубые (ROM ), высокоуровневые оценки. Они годились для предварительных договоренностей со спонсором, но совершенно не подходят для коммуникаций с командой и контроля выполнения работ.

В ходе планирования первичные оценки последовательно уточняются и корректируются. Здесь очень важным моментом моментом является соотношение проектной документации и договорной.

Каждая организация по-своему строит свою работу по заключению договоров и контрактов. Как правило, наблюдается некий компромисс между необходимостью «подстраховаться» (уточняя планы) и «не работать бесплатно» (ведь пока контракт не подписан, всю вашу деятельность по инициации и планированию проекта оплачивает ваш высший менеджмент).

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

• устав проекта
• состав «плана управления проектом»

Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить конечный результат (продукт).

Для описания всех необходимых работ по проекту нужно: определиться с требованиями и ожиданиями заказчика, разобраться, какие из них реально выполнимы, и что для этого понадобится, то-есть:

Формирование концепции и создание ИСР (WBS ) разделены еще двумя этапами из других областей знаний.

Первый шаг (собрать и финализировать требования) неявно включает в себя два компонента: дальнейшее выявление заинтересованных лиц и собственно сбор требований.

Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе.

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

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

Лучшие проектные практики гласят:

• проект с неудовлетворенными ожиданиями заказчика не является успешным
• проект, результаты которого не используются конечными пользователями, не является успешным

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

Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.

По какому принципу можно отнести того или иного человека к «заинтересованным лицам»:

1. Это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
2. Заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае нельзя пренебрегать их интересами в проекте!).
3. Начальники членов вашей команды.
4. Те, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
5. Последняя группа заинтересованных лиц – наиболее трудна к выявлению, однако порой вклад таких «серых кардиналов» очень велик. В качестве примера можно привести гипотетическую ситуацию, когда сын заказчика является в его глазах авторитетом в сфере информационных технологий и привлекается отцом к принятию принципиальных решений о внедряемых системах. При этом сын не является сотрудником ни одной из участвующих в проекте организаций (или, допустим, вообще еще школьник). Однако высказанные им советы имеют для папы больший вес, чем экспертные заключения его же сотрудников. Возможно, «добраться» до такого «заинтересованного лица» в ходе проекта вам и не удастся, но, знать (или, хотя бы, предполагать его существование) – достаточно важно.

В реестр можно включать большое количество людей – всегда можно классифицировать их по «степени влияния на проект» позднее и работать только с самыми главными. Сейчас важнее никого не забыть (ибо влияние заинтересованного лица не проекте, со временем, может и возрасти).

Далее предстоит выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований .

Выбирая методы, необходимо тщательно взвесить потребности в информации и способности второй стороны ее предоставить.

Из наиболее распространенных можно выделить:

Интервью – является одним из самых надежных методов, он же – самый трудозатратный. Непосредственное общение позволяет собрать наиболее полную и достоверную информацию, а также установить конструктивный рабочий контакт с собеседником. Главный минус – трудозатраты (вам придется тратить свое и чужое время в больших количествах). Кроме того – с некоторыми заинтересованными лицами общение может оказаться невозможным по причине их «статусности» (так, не всегда возможно уговорить топ-менеджмент компании-заказчика уделить вам часок-другой на очной встрече, даже если это в интересах проекта).

Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к заполнению анкет (по принципу «чтобы отстали»).

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

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

После того, как процесс запущен, и требования стали поступать – необходимо фиксировать их. Для этого рекомендуется обзавестись выделенным списком, называть его можно «матрицей требований». Пример такого документа приведен в Приложении3.

Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.

Осуществляя сбор требований и заполняя матрицу, мы не пытаемся с ходу принять решение, «беремся ли мы за их реализацию в данном проекте, или нет». Проще говоря – собираем «все, что есть» (в рамках разумного, конечно). На этом этапе заинтересованным лицам не дается никаких обещаний. Происходит только сбор требований и ожиданий (последние также превращая в требования с помощью авторов). И по мере того, как сбор требований завершается – необходимо приступить к их «балансировке» (т.е. оценке того, что войдет в проект).

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

Многие методологии разработки ПО обосновано считают строгую последовательность «спланировал» – «сделал» – «показал» – «сдал» (без демонстрации промежуточных результатов заинтересованным лицам и регулярной корректировки исходных планов) злом, повышающим риски провала.

Сбор требований в рамках начального планирования должен быть разумно-глубоким и максимально широким. Однако речь не идет о том, что на этом работа с требованиями должна прекратиться, а их список оказаться «фиксирован» до конца проекта. Работа с ожиданиями заказчика, накопление его согласия, корректировка планов в течение всего жизненного цикла проекта – основа проектного управления.

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

Факторы среды предприятия

Факторы среды предприятия, которые могут оказывать влияние на процесс разработки плана управления проектом, включают в себя, среди прочего:

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

Б алансировка требований – отбор требований, реализация которых предполагается в рамках проекта.

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

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

Позже, когда себестоимость и продолжительность работ будет оценена, можно вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то нельзя выбросить подобное требование из реестра (его невыполнение похоронит проект).

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

Де-факто, матрица требований (а также схемы и описания, на которые она ссылается) представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов.

Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, снижается риск «промахнуться мимо ожиданий заказчика» (одновременно и прислушиваясь к ним весь проект, и отсекая невыполнимые). ТЗ может оказать обратный эффект.

Активы процессов организации

Активы процессов организации, которые могут оказывать влияние на процесс разработки плана управления проектом, включают в себя, среди прочего:

• типовые руководящие указания, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения;
• шаблон плана управления проектом – элементы плана управления проектом, которые могут быть обновлены, включают, среди прочего:

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

• процедуры управления изменениями, включающие действия, согласно которым будут модифицироваться официальные стандарты компании, политики, планы и процедуры или любые документы проекта, а также порядок одобрения и подтверждения любых изменений;
• архивы по прошлым проектам (например, базовые планы по содержанию, стоимости, расписанию и измерению исполнения, календари проектов, сетевые диаграммы проекта, реестры рисков, запланированные ответные действия и определенные последствия рисков);
• историческую информацию и базу накопленных знаний;
• базу знаний по управлению конфигурацией, содержащую версии и базовые планы по всем официальным стандартам компании, политикам, процедурам и любым документам проекта.

При разработке плана управления проектом экспертные оценки используются для:

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

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

• выбранный для проекта жизненный цикл и процессы, которые будут применяться в каждой фазе;
• результаты адаптации, полученные от команды управления проектом, а именно:

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

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

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

Базовые планы проекта включают в себя, среди прочего:

• базовое расписание;
• базовый план выполнения стоимости;
• базовый план по содержанию.

Вспомогательные планы включают в себя, среди прочего:

• план управления содержанием ;
• план управления требованиями ;
• план управления расписанием ;
• план управления стоимостью ;
• план управления качеством ;
• план усовершенствования процессов ;
• план управления человеческими ресурсами ;
• план управления коммуникациями ;
• план управления рисками ;
• план управления закупками .

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

План управления проектом: пример - все о PMP, управление проектами, менеджер проекта, проект, экзамен pmp, сертификация pmp, project management profes

План управления проектом (Project Management Plan) - пакет утвержденных формальных документов, в которых указано, как проект будет исполняться и как будет происходить мониторинг и управление проектом. План может быть обобщенным или подробным, а также может включать один или несколько вспомогательных планов управления и другие документы по планированию.

Пример плана управления проектом можно посмотреть по ссылке:

План управления проектом: структура документа

• План управления содержанием
• План управления расписанием
• План управления стоимостью
• План управления качеством
• План совершенствования процессов
• План управления обеспечением проект персоналом
• План управления коммуникациями
• План управления рисками
• План управления поставками
• Список контрольных событий
• Доступность ресурсов
• Базовый план расписания
• Базовый план по стоимости
• Базовый план по качеству
• Реестр рисков

План управления содержанием проекта (Project Scope Management Plan) - документ, описывающий, как будет определяться, разрабатываться и проверяться содержание проекта и как будет создаваться и определяться иерархическая структура работ, а также дающий указания по управлению содержанием проекта. План управления содержанием проекта может быть неформальным и обобщенным или формальным и очень подробным в зависимости от потребностей проекта.

План управления расписанием (Schedule Management Plan) - документ, устанавливающий критерии и операции по разработке и управлению расписанием проекта. План управления расписанием может быть формальным или неформальным, очень подробным или обобщенным в зависимости от потребностей проекта.

План управления стоимостью (Cost Management Plan) - документ, задающий формат и определяющий операции и критерии для планирования, структурирования и управления стоимостью проекта. План управления стоимостью может быть формальным или неформальным, очень подробным или обобщенным в зависимости от требований участников проекта.

План управления качеством (Quality Management Plan) - документ описывающий, каким образом команда управления проектом будет претворять и жизнь политику исполняющей организации в области качества. План управления качеством может быть формальным и неформальным, очень подробным или обобщенным в зависимости от потребностей проекта.

План совершенствования процессов (Process Improvement Plan) - содержит подробные описания шагов аналитического процесса, способствующего идентификации избыточных или не приносящих результатов операций, повышающих стоимость продукта для заказчика.

План управления обеспечением проекта персоналом (Staffing Management Plan) - документ, описывающий способ выполнения требований к ресурсам. План управления обеспечением персоналом может быть неформальным и обобщенным или формальным и очень подробным в зависимости от потребностей проекта. Информация, содержащаяся в плане управления обеспечением персоналом, различается в зависимости от области приложения и размера проекта.

План управления коммуникациями (Communication Management Plan) - документ, описывающий: требования и ожидания от коммуникаций для проекта; как и в каком виде будет происходить обмен информацией; когда и где будут иметь место коммуникации; а также кто несет ответственность за обеспечение каждого типа коммуникаций. План управления коммуникациями может быть формальным или неформальным, очень подробным или обобщенным в зависимости от требований участников проекта.

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

План управления поставками (Procurement Management Plan) - документ, описывающий управление процессами поставки, начиная от разработки документации по поставкам и до закрытия контракта.

Список контрольных событий (Milestone List) - определяет все контрольные события расписания, указывая при этом, является ли событие обязательным (необходимым согласно контракту) или необязательным (основывающимся на требованиях проекта или исторической информации).

Доступность ресурсов (Resource Availability) – документ, содержащий количество и доступность ресурсов, а также даты, на момент наступления которых каждый специальный ресурс может быть активен или использован наилучшим образом.

Базовый план расписания (Schedule Baseline) - утвержденный план с указанными временными фазами (проекта, элементов иерархической структуры работ, пакета работ или плановой операции.

Базовый план по стоимости (Cost Baseline) - бюджет, по которому производится сверка, мониторинг и контроль использования денежных средств всего проекта. Базовый план по стоимости является элементом плана управления проектом. Большинство проектов, особенно большие проекты, имеют несколько базовых планов стоимости или ресурсов, а также базовые планы производства расходных материалов, которые необходимы для расчета различных аспектов эффективности проекта.

Базовый план по качеству (Quality Baseline) – документ, в котором содержатся требования к качеству данного проекта. Базовый план по качеству является частью базового плана исполнения и служит основой для оценки и составления отчетов по исполнению требований качества.

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