Технологический план-график проекта в MS Project Pro
Ниже приведенная информация является справочным материалом. Подробнее о данном материале и его практическом применении вы можете узнать, просмотрев видео.
Содержание:
- Технологический план-график проекта.
- Правила планирования задач технологического плана-графика проекта.
Технологический план-график проекта
Технологический план-график проекта - это детальная инженерно-календарная модель, которая разрабатывается профильными специалистами по предметной области (экспертами, архитекторами, ведущими разработчиками) под непосредственным руководством Главного инженера проекта (ГИП) или ведущего технического координатора.
В иерархии проектного управления технологический план не создается с нуля: он детально разворачивается на основании ранее утвержденного стратегического (вехового) плана проекта. Его главная цель - жестко и бескомпромиссно отображать реальную технологию реализации инженерных, строительных или ИТ-процессов, принятую в качестве стандарта в компании.
Правила планирования и скользящей декомпозиции задач
Чтобы технологический график оставался «живым» и эффективным инструментом управления, а не превращался в перегруженную и неактуальную простыню из тысяч строк, ГИП и планировщики должны соблюдать строгие методологические правила:
Правило 1. Принцип «набегающей волны» (Rolling Wave Planning)
Методологическое требование:
Декомпозировать до уровня мелких задач необходимо исключительно те работы, которые находятся в непосредственной близости к текущей дате (желательно на ближайшие 1–2 недели).
Работы, которые предстоит выполнить через полгода или год, должны оставаться в виде крупных блоков или вех. Такой подход существенно сокращает временные затраты на первичное планирование и последующее неизбежное перепланирование графика, а также кардинально облегчает проектному офису оперативное решение ресурсных конфликтов на оперативном горизонте.
Правило 2. Глагольная и законченная форма именования работ
Названия задач и работ в технологическом плане не должны быть размытыми существительными (например, недопустимы названия вроде «Устав» или «Дизайн-макет»).
- Название любой работы обязано начинаться с глагола.
- Глагол в названии работ должен иметь совершенную (законченную) форму: «Сделать», «Согласовать», «Разработать», «Смонтировать».
Правильные примеры: «Согласовать устав проекта», «Разработать план управления проектом», «Протестировать модуль авторизации». Это формирует у исполнителей четкое понимание целевого действия и ожидаемого результата.
Правила планирования задач технологического плана-графика проекта
Проект в MS Project Pro — это не просто список задач, а математическая модель. Изменение сроков одной задачи должно автоматически пересчитывать весь график по методу критического пути (CPM). Для этого настраивается безупречная сетевая логика:
- Тотальная связанность: Абсолютно все работы и вехи проекта должны быть связаны логическими зависимостями. В графике не должно быть «повисших» задач.
- Связи только между низкоуровневыми задачами: Запрещено устанавливать связи между суммарными задачами (фазами/этапами). Связывание фаз ломает математическую логику расписания, порождает циклические ошибки и скрывает реальный критический путь. Связи прокладываются только между детальными операциями или вехами.
- Ограничение типов связей: При построении сети используйте преимущественно связь типа «Окончание-Начало» (Finish-to-Start, FS). Это самый естественный и стабильный тип зависимости, когда последующая технологическая операция может начаться только после завершения предыдущей. Сложные типы связей (СС, ОО, СО) и длительные задержки (лага) минимизируются.
Одной из главных ошибок при аудите технологических планов является наличие задач-«сирот» (Orphan Tasks) - работ, у которых отсутствует предшественник или последователь. Из-за них при сдвигах сроков задачи вылетают из общего контура и не влияют на финиш проекта.
Для защиты от этой ошибки применяется правило обязательного замыкания сети:
- В проекте должны физически присутствовать две главные управляющие вехи: «Начало проекта» (длительность 0 дней) и «Конец проекта» (длительность 0 дней).
- Все технологические работы и промежуточные вехи, которые по своей природе не имеют явного предшественника (начинают проект), должны быть жестко связаны с вехой «Начало проекта».
- Все работы и вехи, которые не имеют явного технологического последователя (ничего не активируют после себя), должны быть гарантированно связаны с вехой «Конец проекта».
Соблюдение этого правила гарантирует, что любое изменение длительности или задержка на любом самом мелком участке технологического плана мгновенно и корректно отразится на финальной дате завершения всей программы или проекта.
Перечень основных правил:
- Декомпозировать только ближайшие к текущей дате работы, желательно на ближайшую неделю две. Это сократит время на планирование и перепланирование, и облегчит решение ресурсных конфликтов.
- Название задач и работ проекта должно начинаться с глагола.
- Глагол в название работ должен быть законченной формы «Сделать», «Согласовать», «Разработать». (Согласовать устав
- проекта, Разработать план управления проектом)
- Все работы и вехи проекта должны быть связаны.
- Не устанавливайте связи между задачами.
- В проекте должна присутствовать веха «Начало проекта» и «Конец проекта».
- Все работы и вехи, которые не имеют начала должны быть связаны с вехой «Начало проекта».
- Все работы и вехи, которые не имеют конца, должны быть связаны с вехой «Конец проекта».
- Использовать для связи задач преимущественно связь «окончание-начало»
У вас появились вопросы по настройке автоматического контроля качества расписания (например, по стандарту DCMA 14-Point Assessment) в MS Project Pro или распределению задач ГИПа на сервере? Задавайте свои вопросы в комментариях под видео
Присоединяйтесь к сообществу проектных менеджеров в телеграмм канале "Управление проектами с MS Project" https://t.me/msprojectonline Задать вопросы можно перейдя по ссылке.
Вас могут заинтересовать следующие материалы
Базовые планы проекта в MS Project Pro
Временная шкала в MS Project
