База знаний
Claims & споры ·18 июня 2026 г. ·9 мин

Concurrent Delay по FIDIC: принцип time but no money

Как анализировать параллельные задержки по FIDIC 2017, почему EOT не всегда означает компенсацию затрат и зачем проверять Particular Conditions.

concurrent delaytime but no moneyEOTFIDIC 2017delay analysis

Concurrent delay - одна из самых чувствительных тем в delay claims. Она возникает, когда задержка, относимая к риску Заказчика, и задержка, относимая к риску Подрядчика, влияют на завершение работ в один и тот же период.

Практический результат часто описывают формулой: time but no money. Подрядчик может получить продление срока, чтобы избежать delay damages, но не получить компенсацию prolongation costs за тот же период.

Это не механическое правило для всех случаев. Его нужно применять осторожно, через контракт, Particular Conditions и факты.

Что является настоящей concurrent delay

Не каждая “одновременная проблема” является concurrent delay.

Для настоящей параллельной задержки обычно нужны:

  • два или более независимых события;
  • разные risk owners;
  • влияние на дату завершения или критический путь;
  • совпадение влияния во времени;
  • отсутствие возможности сказать, что одно событие фактически поглотило другое.

Если событие Заказчика произошло в тот же месяц, что и проблема Подрядчика, но не влияло на критический путь, это не обязательно concurrent delay.

Почему это важно для денег

EOT защищает Подрядчика от ответственности за просрочку. Но money claim требует отдельного основания.

Если в тот же период Подрядчик сам задерживал критический путь, Заказчик может сказать: даже без нашего события вы бы все равно не завершили вовремя. Тогда логика “time but no money” становится коммерчески значимой.

Результат:

  • EOT может быть предоставлен;
  • delay damages могут быть сняты или уменьшены;
  • prolongation costs могут быть отклонены или сокращены.

FIDIC 2017 и Particular Conditions

В FIDIC 2017 вопрос concurrent delay может быть отнесен к правилам, установленным в Particular Conditions. Поэтому нельзя анализировать параллельную задержку только по General Conditions.

Перед подготовкой claim нужно проверить:

  • есть ли специальная оговорка о concurrent delay;
  • как контракт определяет critical delay;
  • допускается ли apportionment;
  • какие методы delay analysis предписаны;
  • как оформляются notices и particulars;
  • есть ли специальные требования МФО или Заказчика.

Если Particular Conditions молчат, команда обычно обращается к применимому праву, практике проекта и аналитическим протоколам вроде SCL Protocol.

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

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

Полезны:

  • windows analysis;
  • time impact analysis;
  • as-planned vs as-built только как вспомогательный инструмент;
  • contemporaneous programme updates;
  • event-by-event critical path review.

Слабая стратегия - нарисовать общий as-built график в конце проекта и заявить, что “все задерживали всех”. Это не объясняет causation.

Как вести records

Concurrent delay почти невозможно разобрать без contemporaneous programme records.

Нужны:

  • регулярные обновления программы;
  • narrative к каждому обновлению;
  • logs по доступу, approvals, drawings, RFI;
  • records собственных ресурсов Подрядчика;
  • evidence по мобилизации, procurement и subcontractors;
  • решения о resequencing;
  • переписка по mitigation.

Особенно важно фиксировать не только события Заказчика, но и собственные проблемы проекта. Попытка скрыть contractor delay обычно разрушает доверие к анализу.

Практический подход к claim

Хороший concurrent delay analysis не спорит лозунгами. Он отвечает по периодам:

  1. Какой critical path действовал в window?
  2. Какое событие Заказчика влияло на этот path?
  3. Какая contractor delay существовала в тот же период?
  4. Были ли события независимыми?
  5. Как Particular Conditions распределяют последствия?
  6. Почему заявленный relief логичен именно для этого window?

Такой подход лучше, чем общий спор “кто виноват в проекте”.

FAQ

Concurrent delay всегда означает time but no money?

Нет. Это распространенный практический результат, но не универсальная догма. Контракт, Particular Conditions, применимое право и факты могут дать иной результат.

Можно ли получить деньги при concurrent delay?

Иногда возможно, если можно отделить compensable delay, доказать самостоятельный cost impact или показать, что contractor delay не была критической в соответствующий период. Но это требует сильной доказательной базы.

Что важнее всего в concurrent delay claim?

Качественные contemporaneous programme updates и честное event-by-event объяснение. Без них анализ быстро становится ретроспективной позицией.

Bridge Consult помогает проверять delay submissions, Particular Conditions и records по concurrent delay до того, как позиция уйдет Инженеру, DAAB или в арбитраж.

Sources and further reading

Bridge Consult

Материал подготовлен экспертами Bridge Consult — практикующей командой по контрактам FIDIC, claims и проектам МФО. Нужна помощь по реальному контракту?

Запросить консультацию