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

Что такое шаблон плана управления проектом?

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

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

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

Проблема в том, что заполняет эти страницы.

Ключевой тест для любого плана управления проектом

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

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

Затем посмотрите, какая часть документа выделена.

В большинстве организаций это от пятнадцати до тридцати процентов. Остальные семьдесят — восемьдесят пять процентов описывают, как организация управляет проектами в целом, и в следующем плане и в том, что будет после него, выглядели бы неизменными.

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

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел «Templates»

Перейдите в раздел Templates из главной навигации.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

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

Шаг 4: Отредактируйте шаблон

Нажмите Edit, чтобы начать изменять выбранный шаблон.

В редакторе вы можете:

• Добавлять новые разделы

• Задавать или обновлять правила форматирования

• Добавить логотип и настроить его положение и связанные параметры

Шаг 5: Сохраните настроенный шаблон

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

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте Preview.

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

С шаблоном плана управления проектом вы можете:

• Экономить часы на планировании: Пропускайте пустую страницу с исчерпывающей структурой PM.

• Охватить все области знаний: Встроенные разделы по объему (scope), срокам, стоимости, качеству и рискам.

• Оставаться в фирменном стиле: Применяйте логотип, шрифты и цвета с помощью бренд-набора Trupeer.

• Синхронизировать стейкхолдеров: Превращайте плотные планы в видеосводки, которые каждый может быстро усвоить.

• Стандартизировать подход в проектах: Используйте один и тот же шаблон для каждого инициативного проекта.

• Достигать глобальных команд: Переводите планы на 65+ языков одним кликом.

Почему большая часть документа подходит для любого проекта

Универсальный контент отсутствует не из-за лени. Он там потому, что шаблон его запрашивает, и потому что управление (governance) ожидает, что по каждой вспомогательной области будут даны ответы.

Поэтому раздел управления объемом (scope management) говорит, что изменения объема будут оформляться как запросы на изменения, оцениваться по влиянию и утверждаться change board. Это правда — и так работает каждый проект в этой организации, но для читателя это не говорит ничего о данном проекте.

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

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

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

Как отделить методологию от плана

Два документа вместо одного.

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

План управления проектом. Только то, что специфично для этого проекта. Каждый раздел задает один вопрос: что здесь отличается?

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

Применение этого правила к существующему плану на шестьдесят страниц обычно оставляет восемь — двенадцать страниц. Это и есть план. И впервые эти страницы действительно стоит читать.

Возникают два возражения, и у обоих есть ответы. Аудиторы и клиенты иногда требуют полный набор вспомогательного контента — в таком случае документ методологии это обеспечивает, а план ссылается на него; аудиторы обычно принимают это, потому что прослеживаемость яснее. И люди переживают, что план выглядит «тонким», — хотя так будет ровно до тех пор, пока кому-то не придется им пользоваться.

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

Скопируйте отсюда. Восемь разделов, восемь — двенадцать страниц, каждый отвечает на вопрос, что именно отличается в этом проекте.

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

Цели и критерии успеха. Что этот проект должен обеспечить — как измеримые показатели, а не как результаты (deliverables), взятые из project brief, а не придуманные заново.

Объем и границы. Что входит, что не входит, и — конкретно — что исключено, хотя люди об этом просили. Ссылайтесь на процесс изменений, а не описывайте его.

Неподвижные ограничения. Даты, окна, заморозки, регуляторные дедлайны, периоды владения или доступа, даты уведомлений по контракту. Любое то, что проект не может сдвинуть, с указанием владельца. Наш IT project plan template охватывает корректное оформление этого, и это тот раздел, который больше всего стоит извлечь в отдельную страницу.

Ресурсы и мощность (capacity). Кто выделен, на какую долю своего времени, и что вместо этого они не делают. Укажите конкретных людей, от доступности которых план действительно зависит.

Подход к закупкам. Что именно покупается, на каком основании, с учетом сроков поставки (lead times). Наш procurement management plan template описывает это как вспомогательный план, когда проекту он действительно нужен.

Риски, специфичные для проекта. Только риски, характерные именно для этого проекта; у каждого — триггер и владелец. Универсальные риски должны быть в постоянном списке рисков методологии.

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

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

Инженер по рельсам, чье окно владения было на странице 41

Kelvedon Rail — это инфраструктурная инженерная компания примерно из 1600 человек, которая ведет около 34 проектов в год сверх порога в 250 тысяч фунтов стерлингов, и каждый из них требовал плана управления проектом.

Шаблон включал 11 вспомогательных планов, а завершенные версии в среднем занимали 68 страниц.

Кто-то провел тест на выделение для 12 из них. Медианное выделенное содержимое: 19 процентов.

Разделы по объему, качеству, коммуникациям и контролю изменений были почти идентичны во всех двенадцати, и в девяти случаях — слово в слово, потому что каждый автор начинал с предыдущего плана. Два из двенадцати все еще содержали название другого проекта в основном тексте.

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

Последствие проявилось в одном проекте. Окно владения путями (track possession window), действительно неподвижная дата, согласованная за месяцы с владельцем инфраструктуры, была зафиксирована на странице сорок один плана и больше нигде. Команда доставки планировала работы на неделю, когда доступ был недоступен. Три недели были потеряны при оценочной стоимости 186 тысяч фунтов.

Информация была задокументирована. Она была утверждена. Она находилась внутри 68 страниц, из которых четыре пятых описывали то, как Kelvedon управляет проектами в целом.

Пересборка дала два документа. Документ методологии примерно на сорок страниц, написанный один раз и принадлежащий проектному офису. И шаблон плана управления проектом из восьми разделов, нацеленный на восемь — двенадцать страниц, где каждый раздел задает только то, что отличается в этом проекте.

В следующих двадцати одном проекте медианная длина плана была 11 страниц, а медианное число открытий после утверждения — 14. Тест на выделение для восьми из них вернул медианное значение 81 процент контента, специфичного для проекта.

Теперь неподвижные ограничения также находятся в одностраничном приложении, извлеченном из плана и разосланном отдельно, потому что урок из окна владения был в том, что важные даты не должны быть «находимыми» только при чтении.

Вспомогательные планы — и какие из них вам действительно нужны

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

Как создать план управления проектом шаг за шагом

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

Сначала запишите неподвижные ограничения. Они определяют, что возможно, и именно этот раздел чаще всего меняется дальше.

Заполняйте каждый оставшийся раздел, отвечая только на вопрос, что здесь отличается. Если честный ответ — «ничего», запишите ссылку и переходите дальше.

Указывайте людей там, где план зависит от доступности конкретного человека, и согласуйте это с ними.

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

Раздел об отклонениях пишите в последнюю очередь — когда вы уже знаете, где этот проект отходит от стандартного подхода.

Затем примените тест на выделение к вашему черновику перед рассылкой. Любое невыделенное — кандидат на удаление.

Ключевые фазы, которые план управления проектом должен охватывать

План должен говорить что-то специфичное для проекта о каждой фазе, и для большинства проектов это «что-то» — коротко.

Инициация. Что это авторизовало и в соответствии с какими критериями успеха.

Планирование. Ограничения, ресурсы и решения по подходу. Здесь находится большая часть контента плана.

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

Мониторинг и контроль. Что будет отслеживаться как необычное именно для этого проекта, а не стандартная периодичность отчетности.

Завершение и передача. Кто получает результат и что ему нужно, чтобы принять его; это описывает наш project handover checklist template, и это стоит согласовать на этапе планирования, а не на этапе завершения.

Фаза, где планы обычно слабее всего, — последняя, потому что она находится дальше всего от момента, когда план пишется. Назвать принимающую команду и их критерии приемки на этапе планирования — это самое ценное, что может содержать раздел завершения.

Распространенные методологии управления проектами и что меняется

Форма плана меняется в зависимости от методологии, и тест на выделение применим ко всем вариантам.

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

Agile. Значительная часть того, что традиционный план документирует, живет в способе работы. План все равно должен содержать неподвижные ограничения, обязательство по ресурсам, подход к закупкам и отклонения. Но ему не нужен план управления объемом (scope management) для объема, который намеренно формируется по мере появления (emergent).

PRINCE2. Документация по инициации проекта выполняет эту роль, а ее структура предписана. Разделение методологии все еще применимо, поскольку PRINCE2 явно ожидает адаптацию (tailoring), и именно адаптацию читателю нужно увидеть.

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

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

Простой или полный: каким должен быть срок плана?

Оба крайних варианта встречаются в том, что люди ищут, а это означает, что вопрос действительно не решен: одни хотят простой шаблон на одну страницу, другие — полный документ плана.

Решение в том, что им нужны разные половины одного и того же. Простой шаблон управления проектом обычно включает график и список задач — это операционный артефакт. Полный план управления проектом — это документ управления (governance). Оба варианта законны, и ни один не заменяет другой.

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

Количество, за которым стоит следить, — не страницы. Это открытия после утверждения, о чем большинство систем документов вам сообщит, и на что почти никто не смотрит.

План управления проектом или план проекта?

Эти термины используют как взаимозаменяемые, и различие стоит сохранить.

A plan управления проектом описывает, как будет управляться проект: подход, ограничения, управление (governance), вспомогательные планы. Это документ управления, который утверждается один раз и пересматривается при изменениях.

A project plan в обычном употреблении обычно означает график: задачи, зависимости, длительности и владельцы. Это операционный артефакт, который обновляется еженедельно.

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

Разделяйте их и обновляйте каждый по своему циклу. Наш IT project plan template охватывает планирование, включая календарь ограничений, а наш project documentation template — какие из получившихся документов стоит сохранять после завершения.

Можно ли получить шаблон плана управления проектом в Excel?

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

Word или Google Docs — для самого плана, который представляет собой текст с описанием решений и утверждается, а не отслеживается.

PDF — для утвержденной версии, экспортированной и с датой. Поскольку план — это то, на что ссылаются, когда что-то оспаривают, замороженная утвержденная версия действительно важна.

В большинстве организаций в итоге план оказывается в документе и к нему привязаны четыре или пять связанных таблиц — это правильная схема. Не работает ни один из крайних вариантов: план целиком в таблице теряет решения, а план целиком в документе означает, что таблицы устаревают.

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

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

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

Trupeer AI полезен для второго. Документ методологии описывает процессы, а процессы меняются: появляется новый инструмент контроля изменений, другой маршрут отчетности, обновленный путь утверждения. Если записать процесс один раз, получается письменная процедура со шагами и экранами, которые уже зафиксированы, поэтому методологию можно поддерживать точной с минимальными затратами, а не «дрейфовать», пока никто ей не доверяет.

Запишите это. Оформите в бренде. Переведите. Trupeer it.

Это важно, потому что все разделение зависит от того, что методология заслуживает доверия. План, который ссылается на методологию, которой никто не верит, начнет пересказывать ее уже в рамках двух проектов. SOP creator охватывает эти процедуры, и они живут в вашем knowledge base с единым брендингом. Инструкции по настройке находятся в document template setup guide.

Часто задаваемые вопросы

Есть ли бесплатный шаблон плана управления проектом в Excel?

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

Есть ли бесплатный шаблон плана управления проектом в Word?

Структура из восьми разделов выше вставляется прямо в Word или Google Docs. Примените тест на выделение к вашему первому черновику перед рассылкой, потому что это упражнение обычно убирает больше, чем добавляет, и приводит к версии, которую люди действительно откроют.

Есть ли бесплатный шаблон плана управления проектом в PDF?

Экспортируйте утвержденный план и сохраните рабочую версию редактируемой. План — это документ, на который ссылаются, когда оспаривают объем или подход, поэтому версия с датой и «замороженная» версия стоит того, чтобы иметь ее рядом с актуальной.

Где найти полный план управления проектом в PDF?

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

Есть ли простой шаблон управления проектом в Excel?

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

Нужна ли мне программа для планов проекта?

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

Кто должен писать план управления проектом?

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

Как часто нужно обновлять план управления проектом?

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