Такое устройство системы управления проектом позволяет распределить принятие ключевого решения. Аналогично, в разработке ПО решение о релизе за последние 20 лет "расползлось" от единоличного решения технического директора или директора по разработке (Ашманов, 2008) до множества коммитов каждого отдельного разработчика в Git.
Итак, между крушением "Титаника" и выходом статьи 'The Project Manager' в 1959 г. одновременно с прагматическим и семиотическим поворотом [ссылка на мою статью] происходит смена парадигмы проектного менеджмента, возникают методы проектирования, которые забирают часть ответственности за принятие ключевого решения в инженерном проекте с главного разработчика и проектного менеджера. Эффекты этого изменения превосходят всяческие ожидания - сменяется подход к управлению проектными рисками, возникает понятие осознанного принятия рисков, manageble risks. Если в эпоху Великих географических открытий отправка корабля в далёкое путешествие была ставкой на удачу, gamble risk, и даже капитан "Титаника" воспринимал ситуацию столкновения корабля с айсбергом как что-то несущественное (Schröder-Hinrichs et al., 2012), какую-то небольшую ставку, которую стоит принять, чтобы поставить рекорд по скорости пересечения Атлантики, то катастрофа "Челленджера" рассматривалась уже исключительно через призму контрфактуальности, причинно-следственных связей (сноска подробнее про контрфактуальность и причинно-следственные связи см. (Клейнберг С., 2017; de Mesquita and Fowler, 2021)) и рассуждений в стиле "этого можно было бы избежать, если бы ..." (R. P. Feynman, 1986; “Rogers Commission Report”, 1986). Методы проектирования снизили величину риска, "размазав" принятие ключевого решения, и повысив повторяемость и воспроизводимость ситуаций принятия решения. Риски из статических стали динамическими, ими стало можно управлять, что, конечно, очень понравилось представителям страховых компаний и банков (Cooper et al., 2005; Gehner, 2008).

Ключевым моментом методического поворота стало 1 ноября 1968 года, день, в который Министерство обороны США выпустило первую версию стандарта по иерархическим структурам работ MIL-STD-881 Work Breakdown Structures for Defense Materiel Items (Иерархические структуры работ для изделий военного применения). Он был обязателен для применения во всех стратегических программах и в проектах с бюджетом больше 10 млн. долларов США. Разработчиком стандарта был штаб командования систем военно-воздушных сил авиабазы Эндрюз, Вашингтон, округ Колумбия, дирекция стоимостного анализа, отдел стоимостной информации и управленческих систем. Если открыть этот стандарт, то можно легко убедиться, что ни о каком разукрупнении работ в этом стандарте речи не идет. "Иерархические структуры работ (ИСР) обеспечивают согласованный и явно описанный подход, который способствует:
а. Более эффективной управленческой и технической основе планирования и корректному назначению ответственных за управленческие и технические решения государственных структур, вовлеченных в реализацию проектов, и подрядчиков
б. Более согласованному контролю и менее противоречивой отчетности о ходе работ в проектах и текущем статусе, а также о занятости ресурсов, стоимостных оценках, текущих расходах и закупочных процессах
в. Учету экономических и других эффектов на всем жизненном цикле изделия, включая стадии разработки, производства, ввода в эксплуатацию, применения по назначению и выводу из эксплуатации при принятии технических и управленческих решений."