Saboteur

deadline - конечный срок сдачи проекта. По какой-то причине этот срок был выбран, и УТВЕРЖДЕН, то есть исполнитель решил что он точно успеет, а заказчик решил, что его этот срок устраивает. Объем работы также был согласован.
Менеджер проекта, тимлид, архитектор - все должны быть не просто крутыми чуваками, которые все знают, но в первую очередь организаторами, которые хорошо представляют возможности людей в своем проекте, и скорость выполнения задач.
Или они изначально рассчитывали, что все сотрудники будут сидеть на работе до упора, а значит это наглая эксплуатация. Или они на самом деле ничего не знают, и отвратительные руководители, которые не умеют грамотно договариваться с заказчиком о реальных сроках и реальной оплате труда.

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

Это целиком и полностью зависит от проекта.
Есть проекты, в которых как минимум одна командировка организовывается для каждого сотрудника (чтобы познакомиться живьем), затем - по потребностям.
Есть проекты, где ездят только бизнес-аналитики и может архитекторы.
Есть, где регулярно ездят и бизнес аналитики и лиды всех команд и девопсы.

Работал во всех трех вышеуказанных типах проектов. В среднем бизнесаналитик и тимлид естественно имеет больше шансов поехать, особенно в случае хорошего знания языка.

https://habrahabr.ru/company/mosigra/blog/113876/
https://habrahabr.ru/company/xmlshop/blog/114014/
https://geektimes.ru/post/258762/
https://geektimes.ru/post/254122/

Судя по всему, единичные экземпляры - не очень реалистично.

Принцип таков. Загруженность работника не должна превышать 70%, иначе он сработается, перегорит и эффективность чрезмерно упадет. Вдобавок риски в случае факапов превратятся в ад, если текучки и так много.
Если работы много - нанимаются дополнительные сотрудники.

Если не выходит, значит вероятность того, что ваш проект скоро провалится - повышается. В мире много проектов и компаний, которые разорились из-за неумения расширяться, либо скатились в УГ, кое-как выживая.

"В нашей государственной, бюджетной организации сменился директор"

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

Методика разработки.

Waterfall: все тщательно планируем, назначаем сроки, разрабатываем, сдаем.

Agile: Примерно планируем, анализируем, назначаем конечный срок, планируем на текущую итерацию, разрабатываем, планируем на текущую итерацию, разрабатываем... , сдаем

Проблемы Waterfall:
Если кто-то слажал, все ждут. Если нужно что-то добавить, очень сложно, потому что фаза планирования была очень долгой и тщательной и что-либо менять значит надо все менять.
Если в плане указано, что сперва делаем это, а потом то, может случиться что некоторые люди, которые будут делать "то", будут какое-то время пинать "огурцы" пока ждут что первые люди сделают "это".
Плюсы Waterfall:
Все спланировано, все точно знают что когда будут делать.

Проблемы Agile:
Люди должны быть достаточно зрелые, чтобы нормально загружать себя работой - Agile в бюрократической среде просто провалится.

Плюсы Agile:
Практически нет простоя ни у кого - все всегда могут занять себя задачами.
В случае появления новых требований, их можно без особого вреда ввести в проект почти на любой стадии. Главное чтобы технически это было возможно (в случае waterfall проблема именно на уровне утверждений и плана, то есть бюрократии)
Адекватное использование рабочей силы - если у кого-то нет текущих задач, его официально можно занять под другие проекты.

Agile это не сверхфича, это инструмент, точнее подход к планированию работы, но им нужно уметь пользоваться.