Explaining the valley of death in defense technology

I’m going to walk though some an excellent set of slides on the “valley of death” problem from Gary Hagan over at DAU. Let’s start by explaining the challenge:

Valley of Death is between the technology labs and the program offices, between RDT&E budget activity 6.3 and 6.4.

The chart nicely shows how the “valley of death” sits organizationally in between the technology labs and the system program offices. This schism coincides with Research, Development, Test & Evaluation (RDT&E) budget activities 6.3 and 6.4. Generally, budget activities 6.1-6.3 represent the Science & Technology activities that includes research and early forms of experimental prototyping. When experimental concepts are going to be put towards operational use, they transition to dedicated system program offices, which will mature technologies. Budget activities 6.4 generally starts the prototyping and 6.5 full-scale development (now called Engineering and Manufacturing Design).

As the chart indicates, “valley of death” is accentuated by a difference in perception. The S&T community at the labs take a technology-push approach. Interesting technologies are pursued on their own merits, believing that operational use cases will make themselves apparent through iterative prototyping and demonstration. The program office community, however, relies on a requirements-pull approach. Technologies from the labs need to be well-defined in an operational context so that requirements can be outlined and budgets authorized. Because there are very few funds available for new technologies without years of budget justification to precede it, the program offices timelines are mismatched with the labs.

Here is a little more detail on the differing environments — leading to differing cultures — of the tech labs and the program offices:

Different perspectives on the challenges from either side of the valley of death. PEO/PMs limited in their authorities.

I think the attributes are self-explanatory. One of the interesting facts is that in the FY2020 base budget request, the S&T accounts 6.1-6.3 represented just 15% of the total RDT&E dollars. So the vast majority of RDT&E funding is spent by the system program offices, characterized by low/minimal risk tolerance and where failure is “not really an option.” Already at such an early stage — before development — the program offices must think about production quantities and must integrate into the bigger strategic picture which requires approvals from many dozens of offices. As the slide indicates, the program offices cannot transition unilaterally or spend funding not tied to particular program elements.

One might think that the environment of the system program office creates probably the correct culture when considering a program transitioning into production and operations. However, such risk aversion due to lock-in effects may be premature for systems entering development. Indeed, a centralized requirements-pull approach has not been very successful in the past. Many of the biggest advances have come from technology-push approaches:

Disruptive technologies have all been from technology push approaches, they were not developed in response to a top-down requirement.

Note that hypersonic technologies languished in the 1990s and early 2000s because there was not a well defined requirement for hypersonics. A similar problem almost killed the F-16 and F-18 programs. There was no conceived requirement for a lightweight fighter — where “lightweight” was synonymous with “low capability” rather than agility and cost-effectiveness. Here is a list from the AMARC 1974 report:

… historically the most successful developments or the most useful operational equipment have not resulted from the “requirements” process… Significant examples can be cited where the establishment actively resisted the introduction of a materiel system (Jeep, Christie Tank, P-51 Fighter Aircraft, SIDEWINDER and the previously mentioned US Army rifles).

Ultimately, new or disruptive systems result from technology-push approaches. Technologists know what the state of the art is, and make reasoned guesses about what direction might be fruitful. Those who executed well then get a chance to see if their product gains user approval. The users can then provide requirements which pulls the technology in one way or another.

Yet the whole process also starts with technologists anticipating what users would find useful based on their interaction with requirements from before. Before working on anything, they should first speak with users about the idea and solicit feedback. And so requirements and technology interact from the earliest stages in a way that can lose distinction.