Руководство по управлению проектами · Планирование и содержание
План управления проектом: компоненты, шаги и пример
План управления проектом — это утверждённый документ, объясняющий, как проект будет исполняться, отслеживаться, контролироваться и закрываться. Он объединяет планы по содержанию, расписанию, стоимости, рискам, качеству, коммуникациям и другие планы с базовыми планами, относительно которых измеряется прогресс. Это руководство описывает его компоненты, метод из 10 шагов, разобранный пример и структуру, которую можно скопировать.
Главное
- План управления проектом объясняет, как будет вестись проект, а не только что он поставит.
- Он объединяет вспомогательные планы управления (содержанием, расписанием, стоимостью, рисками и др.) с базовыми планами по содержанию, срокам и стоимости.
- Составляйте его на основе утверждённого устава: сначала требования и содержание, затем расписание и бюджет, затем вспомогательные планы.
- Масштабируйте уровень детализации под размер, риски и сложность проекта; небольшому проекту может хватить нескольких страниц.
- Относитесь к нему как к живому документу: обновляйте через управление изменениями и пересматривайте базовый план только при утверждённых изменениях.
Что такое план управления проектом?
A план управления проектом — это формальный утверждённый документ, определяющий, как проект будет исполняться, отслеживаться и контролироваться, а также закрываться. Он объединяет вспомогательные планы управления содержанием, расписанием, стоимостью, качеством, ресурсами, коммуникациями, рисками, закупками и заинтересованными сторонами вместе с базовыми планами, используемыми для измерения результатов.
Формулировка взята из *PMBOK Guide* от PMI, где план управления проектом определяется как документ, описывающий, как проект будет исполняться, отслеживаться и контролироваться, а также закрываться. На практике это свод правил проекта: сюда команда, спонсор и заинтересованные стороны обращаются, чтобы узнать, как принимаются решения, как сообщается о прогрессе и что происходит при изменениях.
Хороший план отвечает на несколько практических вопросов:
- Что мы поставляем и что не входит в содержание?
- Когда будут завершены основные результаты и вехи?
- Сколько это будет стоить и как будут контролироваться расходы?
- Кто выполняет работу и кто какие решения принимает?
- Как мы будем управлять качеством, рисками, проблемами, поставщиками и коммуникациями?
- Что происходит когда кто-то запрашивает изменение?
Обычно его пишет руководитель проекта с участием команды, профильных экспертов и ключевых заинтересованных сторон, а утверждает спонсор или управляющий совет проекта. Его разработка — ключевая деятельность в рамках управление интеграцией проекта, поскольку он связывает воедино все остальные области знаний.
План управления проектом и другие проектные документы
Понятия «план проекта», «план управления проектом» и «расписание» часто используют как взаимозаменяемые. Они пересекаются, но это не одно и то же. В таблице ниже показано, как соотносятся основные стартовые документы.
| Документ | Основная цель | Уровень детализации | Типичный ответственный |
|---|---|---|---|
| Устав проекта | Санкционирует проект и назначает руководителя проекта | Верхнего уровня, 2–4 страницы | Спонсор |
| Документ инициации проекта (PID) | Базовый документ PRINCE2 для санкционирования и ведения проекта | Подробный | Руководитель проекта, утверждает управляющий совет проекта |
| План управления проектом | Объясняет, как проект будет исполняться, отслеживаться, контролироваться и закрываться | Подробный, масштабируется под проект | Руководитель проекта, утверждает спонсор |
| Расписание проекта | Упорядоченные операции, длительности, зависимости и даты | Подробный только в части сроков | Руководитель проекта или специалист по планированию |
| Техническое задание (SOW) | Описывает работу, которую поставщик выполнит по контракту | Подробный в части контрактных работ | Покупатель и поставщик |
| «План проекта» (неформально) | Часто так называют расписание или краткий сводный план | Различается | Руководитель проекта |
Ключевое различие в том, что устав говорит, что проект существует и зачем, а план управления проектом говорит, как он будет реализован. Расписание — лишь одна часть плана. Если вы работаете в среде PRINCE2, PID играет роль, сходную с планом управления проектом, но также содержит экономическое обоснование и структуру команды управления проектом.
Почему план управления проектом важен
Написание плана требует времени, поэтому вполне резонно спросить, что он даёт. По нашему опыту, польза заключается не столько в самом документе, сколько в размышлениях и договорённостях, к которым он вынуждает прийти заранее.
- Общее понимание: спонсор, команда и заинтересованные стороны согласуют содержание, приоритеты и способы работы до того, как будут потрачены деньги.
- Основа для измерения прогресса: без утверждённых базовые планы по содержанию, срокам и стоимости нельзя сказать, опережает ли проект график, отстаёт ли или превышает бюджет.
- Более быстрые решения: роли, лимиты согласования и пути эскалации согласованы заранее, поэтому проблемы не застревают, пока люди выясняют, кто принимает решение.
- Контроль изменений: определённый процесс управление изменениями защищает проект от неконтролируемого расширения содержания.
- Меньше сюрпризов: планирование рисков, качества и закупок заранее выявляет проблемы, пока их ещё дёшево исправить.
- Более простой онбординг: новые члены команды и поставщики могут прочитать один документ, а не собирать картину из писем и протоколов совещаний.
Компоненты плана управления проектом
Самый распространённый перечень компонентов взят из 6-й редакции *PMBOK Guide*, где описаны три группы: вспомогательные планы управления, базовые планы и дополнительные компоненты. Последующие редакции перешли к структуре принципов и доменов эффективности и сделали больший акцент на адаптации, но перечень 6-й редакции остаётся практичным ориентиром при решении, что должен охватывать ваш план.
Вспомогательные планы управления
Каждый вспомогательный план объясняет, как будет управляться одна область проекта. В небольшом проекте несколько из них могут занимать по абзацу; в крупном каждый может быть отдельным документом, на который ссылается основной план.
| Вспомогательный план | Что объясняет |
|---|---|
| План управления содержанием | Как содержание будет определяться, подтверждаться и контролироваться; см. содержание проекта |
| План управления требованиями | Как требования будут собираться, приоритизироваться, отслеживаться и изменяться |
| План управления расписанием | Метод планирования сроков, инструмент, единицы, частота обновления и пороги отклонения по срокам |
| План управления стоимостью | Как затраты оцениваются, бюджетируются и контролируются; см. план управления стоимостью |
| План управления качеством | Стандарты качества, метрики, проверки, приёмочный контроль и ответственность |
| План управления ресурсами | Как люди, оборудование и материалы привлекаются, распределяются и высвобождаются |
| План управления коммуникациями | Кто получает какую информацию, когда, в каком формате и от кого; см. план коммуникаций |
| План управления рисками | Как риски выявляются, оцениваются, закрепляются за владельцами и пересматриваются; см. управление рисками проекта |
| План управления закупками | Что будет закупаться, типы контрактов и как поставщики отбираются и управляются |
| План вовлечения заинтересованных сторон | Как каждая группа заинтересованных сторон будет вовлекаться и информироваться |
Базовые планы
Базовые планы — это утверждённые версии содержания, расписания и стоимости. Они меняются только через формальное управление изменениями, и фактические результаты сравниваются с ними.
| Базовая версия | Состоит из | Используется для измерения |
|---|---|---|
| Базовый план по содержанию | Описание содержания, иерархической структуры работ и словарь WBS | Выполняется ли нужная работа |
| Базовое расписание | Утверждённое расписание с датами начала и окончания | Отклонения по срокам и отставание |
| Базовый план по стоимости | Утверждённый бюджет, распределённый по времени, без управленческого резерва | Отклонения по стоимости и тенденции расходов |
Вместе эти три плана образуют базовый план для измерения исполнения, с которым сравнивает управление освоенным объёмом.
Дополнительные компоненты
В 6-й редакции *PMBOK Guide* также перечислены компоненты, описывающие ведение проекта в целом:
- План управления изменениями: как изменения запрашиваются, оцениваются, утверждаются и регистрируются.
- План управления конфигурацией: как идентифицируются и контролируются версии результатов и документов.
- Описание жизненного цикла проекта: фазы, через которые пройдёт проект.
- Подход к разработке: предиктивный, адаптивный (Agile) или гибридный, и почему.
- Управленческие обзоры: когда спонсор или управляющая группа будут рассматривать прогресс и принимать решения о продолжении.
Как составить план управления проектом за 10 шагов
Приведённый ниже порядок следует логике, которой пользуется большинство практиков: согласовать, что вы поставляете, затем когда и за сколько, затем как вы будете управлять всем остальным. На деле вы будете возвращаться назад, когда последующие шаги выявят проблемы в предыдущих, и это нормально.
1. Начните с утверждённого устава и экономического обоснования
Прочитайте устав проекта и экономическое обоснование. Отметьте цели, укрупнённое содержание, фиксированные даты, диапазон бюджета, известные риски и любые ограничения. Всё в плане должно им соответствовать. Если что-то в уставе нереалистично, обсудите это со спонсором сейчас, а не прячьте в плане.
2. Определите заинтересованные стороны и соберите требования
Перечислите всех, на кого влияет проект или кто может на него повлиять, затем соберите и приоритизируйте их требования. Помогают интервью, воркшопы и анализ существующих процессов. Фиксируйте требования, чтобы впоследствии можно было проследить связь каждого из них с результатом.
3. Определите содержание и постройте иерархическую структуру работ
Составьте описание содержания с чёткими включениями, исключениями, результатами и критериями приёмки. Затем декомпозируйте результаты в иерархической структуры работ , пока каждый пакет работ не станет достаточно мал для оценки и назначения. Наш бесплатный шаблон WBS даёт исходную структуру.
4. Выберите жизненный цикл и адаптируйте подход
Решите, будет ли проект предиктивным, Agile или гибридным, какие у него будут фазы и сколько формальности нужно каждой области. Двухмесячный внутренний проект и двухлетняя регулируемая программа не должны иметь одинаковый уровень документации.
5. Составьте расписание
Превратите пакеты работ в операции, упорядочьте их с учётом зависимостей, оцените длительности и определите критический путь. Добавьте вехи для ключевых решений и передач. Наше руководство по планирование расписания проекта разбирает каждый шаг.
6. Оцените затраты и сформируйте бюджет
Оцените стоимость каждого пакета работ с помощью таких методов, как оценка по аналогам, параметрическая оценка или оценка «снизу вверх», затем добавьте резерв на выявленные риски. Сведите оценки в распределённый по времени бюджет проекта и согласуйте управленческий резерв со спонсором.
7. Спланируйте ресурсы, роли и ответственность
Подтвердите, кто будет выполнять работу, когда эти люди доступны и какое оборудование или материалы нужны. Используйте матрицу RACI , чтобы показать, кто исполняет, кто отвечает, с кем консультируются и кого информируют по каждому основному результату и решению.
8. Спланируйте качество, риски, коммуникации, закупки и вовлечение заинтересованных сторон
Напишите вспомогательные планы. Установите стандарты качества и приёмочный контроль, проведите воркшоп по рискам и заведите реестр рисков, согласуйте ритм и каналы отчётности, решите, что и как закупать, и спланируйте вовлечение каждой группы заинтересованных сторон.
9. Определите управление изменениями, базовые планы и отчётность
Опишите, как запрашиваются и утверждаются изменения, кто что может утверждать (например, руководитель проекта — до определённой суммы, спонсор — свыше неё) и как фиксируются решения. Установите базовые планы по содержанию, срокам и стоимости и согласуйте формат отчётности о прогрессе, например еженедельный отчёт о статусе.
10. Проверьте, утвердите и дайте старт
Пройдите план вместе со спонсором и ключевыми заинтересованными сторонами, учтите замечания и получите формальное утверждение. Затем проведите стартовое совещание, чтобы вся команда понимала цели, план и свою роль в нём. План, который прочитал только руководитель проекта, никого не направит.
Пример плана управления проектом
Приведённый ниже пример иллюстративный и упрощённый. Он показывает, как могла бы выглядеть каждая часть плана для внутреннего проекта среднего масштаба: переезда команды из 120 человек в новый офис.
| Раздел | Пример записи |
|---|---|
| Цель | Перевезти всех сотрудников и оборудование в новый офис к 28 февраля, допустив не более одного рабочего дня перебоев для каждой команды. |
| Содержание | Включает планировку помещений, настройку ИТ и сети, мебель, перевозку и информирование сотрудников. Исключает отделку здания, которую выполняет арендодатель. |
| Результаты | Утверждённая планировка; работающие сеть и телефоны; установленная мебель; сотрудники переехали; старый офис освобождён. |
| Расписание | Планирование — октябрь–ноябрь; установка ИТ — январь; переезды — в течение трёх выходных в феврале. Критический путь проходит через монтаж сети. |
| Бюджет | Базовый план по стоимости — £180 000 плюс резерв £15 000 в распоряжении руководителя проекта; управленческий резерв — в распоряжении спонсора. |
| Ресурсы и роли | Руководитель проекта, ответственный от службы эксплуатации, ответственный от ИТ, компания-перевозчик. Спонсор: операционный директор. Матрица RACI для каждого результата. |
| Качество | Сеть протестирована и принята ИТ до переезда любой команды; список недоделок закрыт в течение 10 рабочих дней. |
| Риски | Задержка монтажа сети (высокий): еженедельные сверки с поставщиком и резервная дата. Сопротивление сотрудников (средний): заблаговременный показ планировки. |
| Коммуникации | Письмо всем сотрудникам раз в две недели; еженедельная сводка для спонсора; брифинги команд за две недели до каждого переезда. |
| Закупки | Перевозка и мебель — по конкурентным предложениям трёх поставщиков; контракты с фиксированной ценой. |
| Контроль изменений | Руководитель проекта утверждает изменения до £2 000 и двух дней; свыше — решает спонсор. |
| Завершение | Передача службе эксплуатации, итоговый отчёт по затратам и сессия по извлечённым урокам в течение месяца после последнего переезда. |
Обратите внимание: каждая запись конкретна и измерима. «Минимальные перебои» превращаются в «не более одного рабочего дня на команду», а «держать людей в курсе» — в конкретный канал и периодичность.
Структура плана управления проектом
Используйте эту структуру как оглавление своего документа. Удалите или объедините неприменимые разделы и ссылайтесь на отдельные документы, если они уже есть.
- Управление документом: версия, дата, автор, утверждающие лица и история изменений.
- Обзор проекта: предыстория, цели и критерии успеха из устава.
- Содержание: описание содержания, исключения, результаты, критерии приёмки и WBS.
- Подход к разработке и жизненный цикл: фазы, методы и решения по адаптации.
- Расписание: перечень вех, сводная диаграмма Ганта и правила управления расписанием.
- Бюджет: базовый план по стоимости, резерв, финансирование и правила контроля затрат.
- Организация: роли, обязанности, RACI и права принятия решений.
- Управление ресурсами: персонал, оборудование и материалы.
- Управление качеством: стандарты, проверки и приёмка.
- Управление рисками: подход, шкалы, владельцы и цикл пересмотра; ссылка на реестр рисков.
- Коммуникации: заинтересованные стороны, сообщения, каналы и периодичность.
- Закупки: что будет закупаться и как управляются поставщики.
- Вовлечение заинтересованных сторон: подход к каждой ключевой группе.
- Управление изменениями и конфигурацией: процесс, пороги и записи.
- Мониторинг и отчётность: отчёты о статусе, обзоры и ключевые метрики.
- Завершение: приёмка, передача и извлечённые уроки.
- Приложения: детальное расписание, оценки, реестры и шаблоны.
Наш бесплатный шаблон плана проекта даёт готовую структуру в Sheets, Excel и PDF. Дополните его шаблон реестра рисков, шаблон плана коммуникаций и шаблон матрицы RACI для вспомогательных разделов.
Насколько подробным должен быть план?
Фиксированного объёма нет. Правильный уровень детализации — такой, при котором команда может работать, не спрашивая постоянно, как что делать, а спонсор видит, что именно утверждает. Ориентировочно:
| Тип проекта | Типичный план | Что сделать кратким |
|---|---|---|
| Небольшой, с низким риском (недели, несколько человек) | Несколько страниц или одна страница в общем рабочем пространстве: цели, содержание, вехи, бюджет, роли, главные риски | Детальные планы закупок, конфигурации и качества |
| Средний (месяцы, одна команда или поставщик) | Основной документ умеренного объёма с расписанием, бюджетом и реестром рисков в приложениях | Вспомогательные планы могут быть отдельными разделами |
| Крупный или регулируемый (год и более, много поставщиков) | Основной план со ссылками на отдельные вспомогательные планы и реестры | Повторы: ссылайтесь, а не копируйте |
Задайте о каждом разделе два вопроса: заметит ли кто-нибудь его отсутствие и примет ли кто-то из-за него другое решение? Если на оба вопроса ответ «нет», удалите его.
Планы управления проектом в Agile- и гибридных проектах
Agile-команды тоже планируют, но иначе. Вместо того чтобы заранее фиксировать детальное содержание, они фиксируют видение, рамки сроков и бюджета и способы работы, а затем детально планируют по одному релизу или спринту за раз. Иногда это называют планированием набегающей волной.
- Зафиксируйте: цели, систему управления, лимиты бюджета, вехи релизов, роли, критерии готовности и способ вовлечения заинтересованных сторон.
- Оставьте гибким: детальное содержание, которое находится в приоритизированном бэклоге продукта, а не в фиксированном базовом плане по содержанию.
- Замените: детальную диаграмму Ганта — дорожной картой продукта и планом релизов; формальные запросы на изменение содержания — приоритизацией бэклога владельцем продукта.
Гибридные проекты часто сочетают оба подхода: предиктивный план для оборудования, контрактов или нормативных вех и Agile-поставку для ПО или контента.
Поддержание плана в актуальном состоянии
Утверждённый план — это базовый план, а не окончательный ответ. Проекты меняются, и план должен меняться вместе с ними контролируемым образом.
- Используйте управление изменениями: до утверждения оценивайте влияние каждого изменения на содержание, сроки, стоимость, качество и риски, затем обновляйте затронутые разделы.
- Пересматривайте базовый план только при утверждённом изменении: не сдвигайте базовый план втихую, чтобы скрыть отставание; отклонение — полезная информация.
- Проводите пересмотр в установленные моменты: на каждой контрольной точке фазы, после крупных изменений и не реже раза в месяц в длительных проектах.
- Ведите контроль версий: фиксируйте в разделе управления документом, что изменилось, когда, почему и кто это утвердил.
- Сообщайте людям: изменённый план, о котором никто не знает, создаёт столько же проблем, сколько отсутствие плана.
Типичные ошибки в плане управления проектом
| Ошибка | Чем вредит | Что делать вместо этого |
|---|---|---|
| Расписание считается всем планом | Риски, качество, коммуникации и изменения остаются без управления | Охватите каждый компонент, хотя бы кратко |
| Копирование шаблона без адаптации | Длинные документы, которые никто не читает, с неприменимыми разделами | Масштабируйте каждый раздел под размер и риски проекта |
| Написание плана в одиночку | Оценки нереалистичны, и команда не чувствует сопричастности | Планируйте вместе с теми, кто будет выполнять работу |
| Расплывчатые цели и содержание | Споры о том, что значит «готово» | Используйте измеримые цели и явные исключения |
| Нет резерва | Первый же реализовавшийся риск срывает бюджет или срок | Добавьте резерв на основе реестра рисков |
| Нет порогов для изменений | Каждое мелкое изменение эскалируется, а крупные проскальзывают незамеченными | Установите чёткие лимиты согласования |
| План откладывается в архив после утверждения | План всё больше расходится с реальностью | Пересматривайте и обновляйте его через установленные интервалы |
| Нет формального утверждения | Заинтересованные стороны впоследствии отрицают, что соглашались с содержанием или бюджетом | Фиксируйте утверждение с именами и датами |
Инструменты для создания и ведения плана
Многие команды пишут описательные части плана в документе, а расписание, задачи, риски и бюджет ведут в ПО для управления проектами. ПО упрощает поддержание плана в актуальном состоянии: зависимости обновляются автоматически, дашборды показывают прогресс относительно базового плана, и все видят одну и ту же версию.
Сравнивая инструменты для планирования работ, ищите диаграммы Ганта с зависимостями и базовыми планами, представления ресурсов или загрузки, настраиваемые поля для рисков и проблем, а также дашборды отчётности. Wrike, лучший инструмент в нашем рейтинге, предлагает интерактивные диаграммы Ганта с зависимостями и общие дашборды начиная с тарифа Team, что подходит командам, ведущим несколько проектов одновременно, а более лёгкие инструменты подходят для простых планов. Наше руководство по ПО для диаграмм Ганта и полный рейтинге инструментов управления проектами помогут сделать выбор.
После утверждения плана следующая задача — превратить его в расписание, которому сможет следовать команда.
Бесплатные шаблоны по этой теме
Частые вопросы
Что такое план управления проектом?
План управления проектом — это формальный утверждённый документ, описывающий, как проект будет исполняться, отслеживаться и контролироваться, а также закрываться. Он объединяет вспомогательные планы для таких областей, как содержание, расписание, стоимость, качество, риски и коммуникации, а также базовые планы по содержанию, срокам и стоимости.
Каковы основные компоненты плана управления проектом?
Согласно 6-й редакции *PMBOK Guide*, план включает вспомогательные планы управления (содержанием, требованиями, расписанием, стоимостью, качеством, ресурсами, коммуникациями, рисками, закупками и вовлечением заинтересованных сторон), базовые планы (по содержанию, срокам и стоимости) и дополнительные компоненты, такие как планы управления изменениями и конфигурацией, жизненный цикл и подход к разработке.
В чём разница между планом проекта и планом управления проектом?
В повседневной речи «план проекта» часто означает расписание или краткое описание того, что будет поставлено. План управления проектом шире: он объясняет, как будет вестись весь проект, включая процессы контроля содержания, стоимости, качества, рисков, коммуникаций и изменений.
Расписание проекта — это то же самое, что план управления проектом?
Нет. Расписание показывает операции, длительности, зависимости и даты. Это один из компонентов плана управления проектом, который также охватывает содержание, стоимость, качество, ресурсы, риски, коммуникации, закупки и изменения.
Какие три базовых плана входят в план управления проектом?
Базовый план по содержанию, базовое расписание и базовый план по стоимости. Вместе они образуют базовый план для измерения исполнения, с которым сравнивается фактический прогресс. См. наше руководство по базовый план проекта.
Что такое вспомогательные планы?
Вспомогательные планы — это части плана управления проектом, объясняющие, как управляется конкретная область, например план управления рисками, план управления коммуникациями или план управления стоимостью. В небольших проектах это могут быть короткие разделы; в крупных — часто отдельные документы.
Кто разрабатывает план управления проектом?
Его разработку возглавляет руководитель проекта, работая с командой, профильными экспертами и ключевыми заинтересованными сторонами. Оценки и планы реалистичнее, когда в их создании участвуют те, кто будет выполнять работу.
Кто утверждает план управления проектом?
Обычно спонсор проекта, иногда вместе с управляющим комитетом или другими ключевыми заинтересованными сторонами. Формальное утверждение превращает план и его базовые планы в точку отсчёта для измерения результатов.
Какого объёма должен быть план управления проектом?
Такого, какой нужен проекту, и не больше. Небольшому проекту с низким риском может хватить нескольких страниц, а крупному или регулируемому проекту обычно нужен основной документ со ссылками на отдельные вспомогательные планы и реестры.
Как часто нужно обновлять план управления проектом?
Всякий раз, когда его затрагивает утверждённое изменение, и при плановых пересмотрах, например на контрольных точках фаз. В длительных проектах пересматривайте его не реже раза в месяц, чтобы он соответствовал тому, как проект ведётся на самом деле.
Нужен ли Agile-проектам план управления проектом?
Agile-проектам по-прежнему нужны согласованные цели, система управления, лимиты бюджета, роли и способы работы, но детальное содержание находится в бэклоге продукта и планируется от релиза к релизу. План становится легче и адаптивнее, но не исчезает.
В чём разница между уставом проекта и планом управления проектом?
Именно устав проекта официально санкционирует проект и определяет его назначение, укрупнённое содержание и полномочия руководителя проекта. План управления проектом создаётся после него и подробно объясняет, как проект будет реализован и как будет контролироваться.
Какие инструменты можно использовать для создания плана управления проектом?
Для описательных разделов подойдёт текстовый редактор или общий документ, а ПО для управления проектами с диаграммами Ганта, дашбордами и реестрами помогает поддерживать в актуальном состоянии расписание, риски и бюджет. Наш бесплатный шаблон плана проекта — хорошая отправная точка.