Критерии DCMA.
3. Минимизация задержек (lag) — не более 5% задач
Третий пункт методики DCMA гласит: не более 5% задач в плане могут содержать задержки (lag). И это не про резервы времени.
Что такое задержка (lag)?
Задержка — это положительный сдвиг между двумя связанными задачами (например, через 2 дня после окончания предыдущей начинается следующая). В MS Project это поле «Задержка» (Lag) в окне связей.
Почему это важно?
Задержка — это вынужденный технологический или организационный перерыв: например, время на остывание бетона, утверждение документации, доставку материалов. Это не резерв на случай рисков.
Однако практика показывает, что задержки часто используют как «скрытые» резервы — искусственно удлиняя сроки без явного обоснования. Это маскирует реальную длительность и снижает прозрачность плана.
Чрезмерное количество задержек усложняет анализ критического пути и делает расписание менее управляемым.
Ключевое правило DCMA: в задержки нельзя включать резервы на риски. Резервы должны быть явными — либо в виде отдельной задачи-буфера, либо учтены в длительности работ.
Как правильно работать с задержками:
Минимизируйте их количество — если в плане более 5% задач с задержками - такой план считается некачественным.
Обосновывайте каждую задержку — только действительно необходимые технологические паузы (например, «сушка краски», «застывание бетона»).
Не используйте задержки для резервирования — для этого заведите отдельные задачи «Буфер проекта» или «Резерв времени».
Вывод: задержки — не инструмент для «запасного времени». Это исключение, а не правило. Качественный план содержит их не более 5%, а все резервы выводятся в отдельные, явно обозначенные элементы расписания.
#DCMA #ProjectManagement #Scheduling #RiskManagement #MSProject #PMO #УправлениеПроектами
«Управление проектами» - канал из категории «Бизнес», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 112 подписчиков суммарно в Telegram и MAX. За последние 19 дней в истории MaxGate учтено 30 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
Критерии DCMA
2. Опережения (lead)
Суть: использование опережений (отрицательного сдвига между задачами) признаётся недопустимым.
Почему:
Опережения — это источник дополнительных рисков. Они означают, что задача-последователь начинается до завершения предшественника, что технически или организационно часто необоснованно.
Они вносят неопределённость: если предшественник задерживается, то опережение либо сжимается (что нарушает технологию), либо просто игнорируется, и план перестаёт быть управляемым.
Вместо опережений следует использовать декомпозицию задач и установление связей типа «Финиш–Старт» между более мелкими работами. Например, вместо опережения на 3 дня между «Разработкой ТЗ» и «Началом кодирования» лучше выделить промежуточные этапы, которые естественно заканчиваются раньше.
DCMA рекомендует стремиться к 0% задач с опережениями. Этот пункт должен быть включён в оценочные показатели качества плана и выявлять строки плана с отрицательными задержками для их последующего устранения.
Критерии DCMA: логика сети
Методология DCMA (Defense Contract Management Agency) насчитывает 14 контрольных точек. Разберём их детально, начнем с п.1.
1. Логика сети (не более 5% исключений)
Суть: каждая задача должна иметь как минимум одного предшественника и одного последователя (кроме первой и последней). Это требование не бюрократическое, а сущностное. 5% это задачи управленченского характера, например запланированные совещания или встречи.
Почему это важно:
Результат задачи-предшественника является необходимым условием для старта задачи-последователя. Без завершения одного задачи нельзя начинать следующую — это база сетевого планирования.
Если между задачами есть «разрывы» (отсутствие связи), календарный план перестаёт отражать реальную последовательность работ. Расчёт сроков становится нереалистичным: система не понимает, от чего зависит длительность, и не может корректно рассчитать критический путь и резервы.
Отсутствие связей маскирует зависимости, создаёт иллюзию параллельности и закладывает ложные ожидания по срокам завершения.
Практический кейс: в ООО «Аэроэкспресс» этот критерий стал одним из первых в системе автоматизированного контроля. Проверка ведётся через фильтр полей «Предшественники»/«Последователи» — все задачи с пустыми значениями считаются нарушением, кроме осмысленных исключений (например, старт или финиш проекта).
Как проверить качество календарного плана проекта
Ранее я обещал рассказать про "тест плана", т.е. как проверить качество плана проекта. В проектном управлении качество плана — это не абстракция, а набор измеримых параметров. Один из наиболее практичных подходов — методология DCMA (Defense Contract Management Agency), включающая 14 точек контроля.
Применение этой методики позволяет снизить количество проблемных мест до единичных случаев.
Критерии DCMA:
1. Логика сети — все задачи должны иметь предшественников/последователей (допустимо не более 5% исключений).
2. Отсутствие опережений — использование опережений (lead) недопустимо, заменяется декомпозицией и связями.
3. Минимизация задержек — не более 5% задач с задержками (lag), без включения резервов.
4. Тип связей — не менее 90% связей типа «Финиш–Старт» (FS).
5. Ограничения задач — не более 5% задач с типом, отличным от «Как можно раньше» (ASAP).
6. Общий резерв — не более 44 рабочих дней (2 мес.) для не более 5% задач.
7. Отрицательный резерв — недопустим.
8. Длительность задачи — не более 44 рабочих дней (требует декомпозиции).
9. Корректность дат — фактические даты не могут быть в будущем.
10. Обеспеченность ресурсами — каждая задача должна иметь назначенный ресурс.
11. Отстающие задачи — не более 5% от базового плана.
12. Тест критического пути — сдвиг критической задачи должен сдвигать срок проекта.
13. Индекс критического пути (CPLI) — целевое значение 1,0, допустимо до 0,95.
14. Индекс выполнения базового плана (BEI) — целевое значение 1,0, допустимо до 0,95.
По сути, готовый чек-лист для повышения надёжности плана проекта. Внедрение даже нескольких пунктов (особенно логика сети, типы связей, ограничения и ресурсы) существенно снижает риски срывов и повышает доверие к плану.
В следующих постах детально обсудим каждый пункт.
