Базовый план проекта и контрольные точки: пример

Любой план меняется. Вопрос не в том, сдвинутся ли сроки, а в том, заметите ли вы сдвиг вовремя и сможете ли объяснить, откуда он взялся. Для этого в управлении проектами есть два простых инструмента: базовый план и контрольные точки. Первый фиксирует, о чём договорились, вторые — проверяют, идём ли мы по договорённости.

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

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

Базовый план проекта (baseline) — это утверждённая версия плана, зафиксированная в определённый момент: сроки задач, объём работ, плановые трудозатраты и бюджет. С ним сравнивают фактическое выполнение проекта. Текущий план можно и нужно обновлять, а базовый остаётся неизменным, пока руководство официально не утвердит изменения.

Обычно различают три составляющие базового плана:

Базовый план по содержанию — что именно проект должен создать (результаты и структура работ, см. WBS).
Базовый план по срокам — даты начала и окончания задач и вех.
Базовый план по стоимости — утверждённый бюджет с распределением по статьям и периодам.

Без базового плана невозможно ответить на простой вопрос руководителя: «Насколько мы отстаём?» Можно сказать, что проект закончится 30 мая, но без зафиксированной исходной даты непонятно, хорошо это или плохо.

Что такое контрольная точка проекта?

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

Хорошая контрольная точка отвечает на три вопроса:

Что именно должно быть готово? Не «работа над дизайном», а «макеты главной и трёх внутренних страниц утверждены заказчиком».
К какой дате? Дата берётся из базового плана.
Кто подтверждает? Контрольная точка без утверждающего — просто отметка в календаре.

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

Контрольные точки проекта: пример

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

№	Контрольная точка	Критерий достижения	Дата по базовому плану	Кто утверждает
КТ1	Техническое задание утверждено	ТЗ подписано заказчиком, список исключений из объёма зафиксирован	14.02	Заказчик
КТ2	Дизайн утверждён	Макеты главной и типовых страниц согласованы, правок по структуре нет	14.03	Заказчик, маркетинг
КТ3	Тестовая версия готова	Все страницы и форма заявки работают на тестовом сервере	18.04	Руководитель проекта
КТ4	Контент перенесён	Тексты на трёх языках загружены и вычитаны	09.05	Маркетинг
КТ5	Сайт запущен	Сайт открыт по основному домену, аналитика подключена, акт приёмки подписан	30.05	Заказчик

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

Базовый план и факт: как читать отклонения

Смысл базового плана появляется только при сравнении. На каждом контрольном просмотре проекта сравнивайте три вещи:

Что сравнивать	Вопрос	Тревожный сигнал
Сроки	Насколько дата окончания задачи или вехи сдвинулась от базовой?	Сдвиг на критическом пути — значит, сдвигается конец проекта
Объём	Выросли ли плановые часы по сравнению с базовыми?	Часы растут, а сроки не меняются — резерв уже съеден
Стоимость	Соответствуют ли фактические расходы плановым на эту дату?	Расходы опережают выполнение работ

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

Управление изменениями: когда менять базовый план

Самая частая ошибка — переписывать базовый план каждый раз, когда сдвигаются сроки. Тогда проект формально всегда «в графике», но сравнивать больше не с чем. Правило простое: текущий план меняется постоянно, базовый — только по решению.

Рабочий порядок выглядит так:

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

Если изменения добавляются без такого порядка — «это же мелочь», «сделаем заодно», — проект попадает в расползание объёма: работы становится больше, а план и бюджет остаются прежними.

Типичные ошибки

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

Как это сделать в Projektiassistent

В Projektiassistent базовый план и утверждение контрольных точек находятся в блоке «Контроль планирования» на рабочей странице проекта и доступны во всех тарифах. Когда график согласован, нажмите «Зафиксировать базовый план» — система сохранит даты задач и плановые часы. Дальше раздел «Базовый план и факт» показывает задачи со сдвигом относительно базового плана и задачи с увеличенным объёмом, а в списке задач и на диаграмме Ганта появляются соответствующие метки.

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

Если плана ещё нет, начните со структуры и шаблона плана проекта или с пошаговой статьи как составить план проекта.

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

Чем базовый план отличается от текущего плана?

Текущий план отражает актуальные сроки и объём и обновляется по ходу проекта. Базовый план — это зафиксированная утверждённая версия, с которой текущий план сравнивают. Меняют его только по официальному решению.

Чем контрольная точка отличается от задачи?

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

Сколько контрольных точек нужно в проекте?

Обычно одна-две на этап, плюс точки перед ключевыми решениями и платежами. Для проекта длительностью несколько месяцев чаще всего достаточно пяти–восьми.

Итог

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

← Блог