Вот, кстати, известная тема - перенос запросов в произвольном порядке.
Иногда на проектах даже требуют самому консультанту определять порядок импорта.
Я всегда недоумевал - зачем это нужно, какой в этом смысл и вообще, как такое приходит в голову.
Это ведь бомба замедленного действия, потом же вообще полная каша может получиться в продуктиве.

Помнится еще приблуда была - Rev-trac. Там запросы объединяются в задачу (проект), которая несется в продуктив как единое целое.
Было дело, работал с ней на 3х системном ландшафте. Для того, чтобы проекты не пересекались, до их открытия делался анализ объектов , которые должны были использоваться, если были конфликты на бумажном этапе, то сроки задач корректировались. Как правило это не приводило к конфликтам. Но если вдруг оказалось, что потребовался объект, которого не было в бумажке, и который есть в другом проекте, а сроки-то уже проставлены, то приходилось заморачиваться. И синтакс дампы могли быть в этом случае. Версии поддерживались на всех системах, поэтому обычно конфликты в продуктиве, если такие были, лечились повторным перезаталкиванием запросов.

Да, это вариант. Но, имхо, при большом объеме разработок вот такие анализы заранее делать конечно можно, но сложно.
Гарантии нет.
Такой подход вполне хорош, на мой взгляд, если разработок немного и есть время поанализировать...

Да и руление сроками - тоже задачка еще та

Полностью согласен. На проекте, о котором я говорил, как раз были вялотекущие разработки.
Есть еще нестандартное решение - собственные Z-надстройки над транспортной системой и различные отчеты для контроля за конфликтами объектов, лично такие вещи не встречал, но знаю делали в небольших количествах. Вроде работало.

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