Here is Rear Adm. Selby, chief of naval research, speaking with Vago Muradian:
I’m really pushing back at the idea of requirements. I think the requirements mindset is still probably the appropriate mindset for a platform: a big complex ship; submarine; aircraft carrier; high-end fighter. You still need the requirements, take the time, engineering, and discipline to get that right. But when it comes to smaller — whether it’s autonomous system, or a sensor, or a software system that goes on a platform — I think it’s a different mindset. And requirements, by definition, kind of constrain us. I think we need to throw out the requirements mindset for things other than the highly complex platforms and think more in terms of defining the problem. This means you got to roll up your sleeves, get with the operators, scientists, engineers, folks in the building like OPNAV folks who will get the money — get together and define the problem. Really crisply refined. Then present that to the ecosystem for solutions. To your point, a lot of those solutions already exist, and they’re not in the government. They’re in the commercial sector.
Selby talked a little bit about the genesis of the Unmanned Integrated Battle Problem 21 exercise earlier this year that tested out a number of autonomous systems and other technologies. He mentioned later that these unmanned systems actually require more manpower because of all the challenges operating it, but as they get better he expects that to decrease and perhaps you could have a single person controlling multiple vessels.
Selby continues to the challenges he’s facing scaling these experiments into a repeatable process and transitioning prototypes:
I’m now thinking about what’s next, how much quicker can I get there, and how do I make this sustainable — part of my longer term budgeting process. That’s the challenge. Like anything else, you got to POM for things. Here’s a story. I come in last summer [summer of 2020], and by the time I come to the job POM ’22 was pretty much in the oven as it were. So they were like, ‘Admiral, congratulations, you’re the new guy. You can start influencing POM ’23.’ I was like, ‘What? POM ’23? I’ll probably be retired in POM ’23. What are you talking about? I’m not waiting until ’23.’ But we were able to do some things.
So that’s the mentality. This is part of the frustration I have. I want to reimagine naval power. I love it, everyone is excited about it. Then you try to go do it, and you’re told, ‘Oh Admiral, you gotta wait until ’23.’
While I agree completely with RADM Selby here, there is nothing in the current acquisition process that prevents taking exactly this approach. It’s a self-inflicted wound that the Navy (and the other services) can’t stop doing to themselves.
In theory, _threshold_ requirements are supposed to reflect the bare minimum that the system has to be capable of in order to have military utility. In most cases, the individual threshold requirements should often be set at a point less capable than the legacy platform — because the legacy platform is better than minimally useful in many dimensions. The _objective_ requirements then establish priorities among better-than-minimal capabilities and specific levels of performance at which significant jumps in capability could be expected. The offerors then have flexibility to choose where in that space of useful designs they want to make their pitches, and the Service can do experimentation and prototyping to figure out which combinations of features are most useful (and which are simply impossible at the moment).
That’s not what we do. We set the thresholds at the objectives (to justify funds for a new platform) and set the objectives at violates-the-laws-of-physics. We award the contract to the offeror who comes closest to being able to claim with a straight face that the system is feasible and affordable, and then spend 10 years of SDD trying to mature the necessary technologies to make that design work. By then, it’s probably obsolete.
So don’t blame the idea of Requirements — every system has no-kidding requirements that must be met. The ship has to float; the communications have to be reliable and secure enough to use in battle; the gun has to often hit what it aims at; etc. Blame the people who eliminate the design trade space before the program even starts, by abusing the requirements process.
PS — Note that devolving acquisition authority to the Services will only make this worse. OSD is not the source of the bad requirements, but does occasionally push back against them.