Следовательно, более половины руководителе проектов просто некомпетентны? ))
А Agile успешен за счет отсутствия сроков, бюджета и размытой цели?

С долей юмора, конечно, пишу. Но лишь с долей.

Именно) У нас есть мужик,  руководивший стройками энергетических объектов много лет. В абсолютном большинстве на старте работы называет в разговорах срок раза в 2-3 больший, чем планируется заказчиком и руководителями работ. И практически всегда его оценка гораздо ближе к истине.

Здорово, если он называет срок, который согласуют. У меня другая ситуация: Заказчик хочет к указанному сроку, и его мои ограничения не волнуют. Руководитель не хочет потерять контракт и продавливает срок Заказчика.
А конечный потребитель!=Заказчик и отклонение от ТЗ приходит инцидентом.

Подскажите тогда, пожалуйста, чем будете руководствоваться вы, если задача звучит примерно следующим образом. Есть очень большое количество задач, оцененных разработчиком в часах с той или иной погрешностью. Задачи - в рамках одного проекта, могут иметь блокировки (одну задачу нельзя делать, пока не будет закончена другая). Суммарная оценка, скажем, в районе 5тыс. часов. Есть команда разработчиков. Достаточно большая по численности (около 10 чел), но разбитая на подкоманды для гибкости и более эффективного взаимодействия. Задачи нужно выполнить к определенному сроку (для конкретики, конец года). Просрочка недопустима, перенос срока невозможен (это b2g🤷🏿‍♀️).  Есть большое количество факторов, влияющих на процесс, которые могут возникнуть с той или иной вероятностью, навскидку много набежит, в реальности больше. Например:
1)Отпуска    
2)Больничные    
3)Текучка    
4)Инциденты    
5)Стабилизации    
6)Внутренние работы по улучшению стабильности продукта (написание новых тестов, починка старых)    
7)Неотложные работы, инициируемые Заказчиком (скрипты, выгрузки, срочные улучшения)
8)Аттестации (включение времени на аттестационные задачи, работа аттестующих)    
9)Контроль сборок    
10)Работы по оценке задач    
11)Консультации аналитики, специалистов девопс    
12)Внутренние обучения    
13)Затраты времени, связанные с вовлечением новых разработчиков в рабочий процесс (помощь, обучение)    
14)Риски, связанные с оценкой задач    
15)Риски, связанные с изменением постановки задач (аналитика, пожелания Заказчика)    
16)Ожидание ответов от второй стороны в задачах по интеграции.
Вопрос: как максимально точно определить, потянет ли команда в текущем составе столь большой объем задач к указанному сроку? Причем определить надо здесь и сейчас - т.е. не поэтапно, а сейчас сказать заранее, потянет, или нужно принимать какие-то меры.  Понимаю, что гибкостью тут не пахнет. Но, возможно, есть что-то полезное и для такой проблемы.

Следовательно, более половины руководителе проектов просто некомпетентны? ))
А Agile успешен за счет отсутствия сроков, бюджета и размытой цели?

С долей юмора, конечно, пишу. Но лишь с долей.

Здорово, если он называет срок, который согласуют. У меня другая ситуация: Заказчик хочет к указанному сроку, и его мои ограничения не волнуют. Руководитель не хочет потерять контракт и продавливает срок Заказчика.
А конечный потребитель!=Заказчик и отклонение от ТЗ приходит инцидентом.

Если бы дело было в компетенции руководителей, картина была бы другая.

Agile более успешен потому что не пытается делать вид, что есть возможность предусмотреть всё и вся в комплексных (в лучшем случае, в сложных) доменах. Да, это требует коррекции задач, а, иногда, и целей, по пути.