Базовый план проекта и как его разработать

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

Что такое базовый план проекта

Базовый план проекта (Baseline или Performance Management Baseline) или базовый план исполнения проекта – это сводные данные об объеме, сроках и стоимости проекта, согласованных на этапе планирования, на основе которого в процессе выполнения проекта отслеживается его прогресс.

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

В базовый план проекта включаются следующие базовые планы:

  • Базовый план cодержания проекта (Scope Baseline) – это согласованное описание объема проекта и иерархическая структура работ проекта (Work Breakdown Structure) плюс словарь WBS, если он есть.
  • Базовый календарный план проекта (Schedule baseline) – это согласованный план-график проекта, включая даты начала и окончания каждой задачи.
  • Базовый план стоимости проекта (Cost Baseline) – это согласованный бюджет проекта, разбитый по фазам проекта.

Зачем нужен базовый план проекта

Базовый план проекта нужен:

  1. На старте – для однозначного согласования объема, стоимости и длительности проекта со всеми заинтересованными лицами.
  2. В ходе проекта – для контроля «здоровья» проекта. При отклонении от базового плана по любому из направлений РМ понимает, что что-то пошло не так и может предпринять какие-то действия, чтобы вернуть проект на путь истинный.

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

Разработка базового плана проекта – это неотъемлемая часть разработки плана управления проектом.

Если выделить только кусок про базовые планы, последовательность разработки будет выглядеть так:

  • Разрабатывается описание содержания проекта или видение проекта (что будет в итоге на выходе проекта?);
  • Принимаются решения о том, что именно будет приобретаться (в том числе какие работы “как сервис”), а что – делаться силами команды;
  • Создается WBS (ИСР) проекта, декомпозирующая результат проекта на управляемые куски. Это наш будущий базовый план содержания проекта;
  • Для каждой работы в WBS определяется набор задач для ее выполнения (что нужно сделать, чтобы получить данный конкретный результат?);
  • Строятся зависимости между задачами (для выполнения задачи 5 должны быть выполнены задачи 2 и 4);
  • Определяется, какие знания и навыки нужны для выполнения каждой задачи (обратите внимание, что пока речь не о членах команды, а о компетенциях!);
  • Оцениваются длительность и стоимость выполнения каждой задачи (наконец-то началась знакомая всем часть, правда?);
  • Определяется критический путь проекта (теперь мы знаем, сколько всего времени нужно на весь проект);
  • Разрабатывается календарный план проекта (если на предыдущих шагах все сделано верно – то достаточно будет задать начальную или конечную дату и получить результат). Это наш будущий базовый календарный план проекта;
  • Определяется стоимость проекта (во сколько же обойдется этот конечный результат). Это наш будущий базовый план стоимости проекта;
  • Все эти три плана долго и нудно балансируются в рамках работы с рисками, планирования коммуникаций и работы со стейкхолдерами, назначения конкретных людей на конкретные задачи и проч. На выходе получается некий промежуточный вариант, который всех более-менее устраивает и позволяет достичь целей проекта в рамках установленных органичений.

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

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

Можно ли менять базовый план проекта

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

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

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

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

B MS Project, кстати, есть возможность сохранения до 10 базовых планов, а также промежуточных планов, чтобы потом можно было проанализировать.

Удачи в планировании и выполнении базового плана с первой попытки!

 

Давайте не теряться - подпишитесь прямо сейчас!

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

А также
И не забудьте оставить комментарий :) мне важно ваше мнение!
Комментарии (5)
  1. Аноним

    Ну чисто технически в ms project есть возможность сохранить базовый ПЛАН ГРАФИК проекта, что на самом деле не совсем то же что базовый план в целом. Хотя его и можно сделать достаточно близким.
    Ну и ещё – чисто имхо на ИТ проектах базовые планы работают не очень хорошо.

    1. Yulia Bazhanova

      Это тот случай, когда содержание важнее оболочки=)) Будет это проджет, эксель или что-то еще – не так важно, если РМу этого достаточно для управления.
      Насчет базовых планах на ИТ-проектах – опять же, смотря как использовать. Пихать туда каждый мелкий CR и генерить по 50 планов в ходе проекта – да, так себе идея. Но он отлично подходит для того, чтобы зафиксировать состояние на старте или при каких-то системных изменениях. Как и для того, чтобы аргументировать потом “а почему мы не в сроке, мы же тут только в приказном порядке вот этот кусок добавили”.

  2. Аноним

    > на этапе планирования, которые на основе которого в процессе выполнения проекта
    mistakes?

    1. Yulia Bazhanova

      Спасибо, поправила все комменты по опечаткам!=)) Когда пишу сразу в блог, а не в Word – иногда не проверяю, и вот к чему это приводит. Ну что ж, lessons learned=))

  3. Yulia Bazhanova

Оставьте комментарий