In July 1954 the Scientific Advisory Board had recommended developing an alternative missile to the Atlas. This recommendation was motivated by fear that the pressurization required to maintain the Atlas’s structural integrity might collapse under stress—an unfounded fear, as it turned out. The more conventional alternative, the XSM–68 Titan, offered greater prospects for “growth” and would create a secondary source for subsystems as a hedge against failure in the Atlas program.
From the start, General Schriever recognized that the ICBM program warranted an exceptional approach. He borrowed a page from the Manhattan Project of World War II and contracted with the ablest firms available for production of the major subsystems. Each major subsystem of the Atlas and the Titan had a separate associate contractor as insurance against any one of the contractors’ failing. Major subsystems included guidance, propulsion, nose cone, and airframe.
That was from Jack Neufeld’s article, “Bernard A. Schriever: Challenging the Unknown.” Here’s a bit more:
Upon assuming command of ARDC, General Schriever introduced concurrency in weapon system development and acquisition, the concept that had served so well in the Ballistic Missiles Division to compress acquisition time and get operational systems into the hands of combat units more quickly. Under this management approach, Air Force headquarters initiated the conceptual phase of a new weapon, systems centers provided acquisition management, and the using commands refined the system during its operational phase. In December 1959, Dudley C. Sharp became Secretary of the Air Force and suggested expanding the concept to all weapon and support systems.
It’s interesting that system analysis (paper designing of plans) and concurrency (starting production tooling and processes before design is finalized) used to go hand-in-hand in the 1950s. By the end of the 1950s, the RAND systems analysis crew sided with the economists — Armen Alchian, Kenneth Arrow, Jack Hershleifer, Burton Klein — that a phased approach was better. Do not start production until after it is thoroughly tested.
However, there is something to the argument that you want some concurrency, because its hard to know what designs are producible at scale. This is what Elon Musk argued about his starlink satellite effort. Certainly devsecops for software products is indicative of concurrency. But concurrency seems to only work when you throw out systems analysis, (i.e., the long-range planning of technical objectives and costs) and proceed on a more trial-and-error basis (i.e., MVP, test, iterate). And so perhaps the best combination of ideas isn’t systems analysis + stage gate (what we have now), but instead what we should want is iterative builds + concurrency.
Leave a Reply