Pentagon’s number-two officer vows to fix software acquisition ‘nightmare’

Best listening experience is on Chrome, Firefox or Safari. Subscribe to Federal Drive’s daily audio interviews on Apple Podcasts or PodcastOne.

The new vice chairman of the Joint Chiefs of Staff said the Defense Department needs to fix its requirements processes — not just its acquisition procedures — if it’s going to make real progress toward buying and building software as quickly as Silicon Valley does.

And as of now, according to Gen. John Hyten, the process is a “nightmare across the board.”

At the suggestion of the Defense Innovation Board, Ellen Lord, the undersecretary of Defense for acquisition and sustainment has promised to create a software-specific acquisition pathway for DoD systems.

But Hyten told an audience at the Center for Strategic and International Studies that changing DoD’s buying procedures won’t solve the problem if it’s still stuck with a requirements process that takes too long, and was built for tanks and aircraft carriers.

In his capacity as the chairman of Joint Requirements Oversight Council, Hyten is largely in control of that process — known as the Joint Capabilities Integration and Development System (JCIDS). He believes it’s stuck in the industrial age.

“Here’s the way we write requirements today: We write requirements for a product that say, ‘I want that built and delivered in 10 years. I want it cyber-secure, deliver everything perfect in 10 years.’ If you do that based on a threat at the beginning of the process, you get a capability to defeat the threat that was 10 years ago. And in cyber, you’re already out of date tomorrow. Not five years from now, tomorrow,” he said. “So how do I move fast in that structure? I think you have to basically go back to a threat-based view of the world.”

Risk aversion driving decision-making upward

Hyten said the requirements problem is symptomatic of a broader trend in DoD acquisition over the last several decades as the department has become more and more sensitive to risks of failure in its acquisition programs, and behaved accordingly. He said too many engineering decisions have been moved upward into various Pentagon meeting rooms, all but guaranteeing that DoD will move more slowly than its adversaries.

At the urging of Congress, DoD and the military services have already started pushing key acquisition milestone decisions to lower levels of the chain of command. Hyten said the department needs to undertake a similar effort for its requirements-setting processes.

And he thinks the Joint Staff can do that without any major re-writes to existing policy, because the JCIDS process and the Federal Acquisition Regulation already contain a high degree of flexibility if the department decides to take advantage of it.

“If you want to go fast, all the authorities are right there. They’re written down. They’re allowed. All you have to do is get the bosses to say, ‘Yes, go do that,’” he said.  “However, in setting up the structure over the years, whether it’s the acquisition side or the requirements side, we have set up this very bureaucratic, risk-averse structure that tells people that there’s a right way to go through the process to achieve success without failing at the end. But in almost every case, those answers are very slow.”

Hyten said he hasn’t yet devised what a less risk-averse requirements process will look like, but his nascent project to create one is operating under a working title of “process requirements,” as opposed to product-centric requirements.

“I don’t know enough now to say what we’re going to do, but the one thing I know is that when it comes to 21st century capabilities — all heavily dependent on software — the current process that we have for building software is horrible,” he said.

For pure IT acquisitions, the department already has a process called the “IT Box” that lets it delegate requirements decisions to the lowest possible level. The Army, for instance, has already adopted it in ways that let it conduct acquisitions for defensive cyber systems in 30 days or less.

Hyten said that sort of delegation involves not just authority, but accountability. And if DoD is going to succeed in making it more widespread, it needs to prepare its lower-level acquisition managers to assume those higher levels of responsibility.

“We’ve been training our people not to buy things, not to understand what a good contract is. Our engineers need to know as much about the system as the contractors do. It’s not that way because we’ve trained them on the process to get programs done, not on how to buy things,” he said. “We can’t just say you have the authority and responsibility if we haven’t trained you in that way. One of the greatest things that happened to me as a young officer is that my boss made me go out in the contractor plant and learn how to buy and build satellites … I walk into a contractor plant now, and I can tell the good and the bad just by looking at it. That’s hugely beneficial to an operator. So we have got to get after this.”

Hyten said the department will be able to tell whether its efforts to delegate decisions downward are succeeding when program managers are spending at least as much time in their contractors’ production facilities as they are in meetings in Washington.

“If you want to see a military person go fast, all you have to do is give them authority and responsibility. And then when they fail, well, you have to fire them and go find somebody else,” he said. “But isn’t that the way America works? Why does that sound so strange?”

Empowering a single leader of software development

In his remarks, Hyten emphasized that wherever DoD’s requirements failings have caused programs to move too slowly, they’ve been problems of the department’s own making: Congress has already given the department plenty of latitude to delegate decisions and move quickly.

In its study of software acquisition last year, the Defense Innovation Board took a somewhat different view. The panel acknowledged Congress has given DoD enough running room to devise a better pathway for software procurement if it tries hard enough, but said lawmakers also need to rework the current “spaghetti path” of acquisition law, which they called “difficult and often inefficient” for software.

But the DIB and Hyten agree on one other major point: successful software development requires that a single leader be empowered to make the decisions that will let a project succeed or fail, and then be held accountable for the results.

In recent years, Hyten said, that’s been nearly impossible. To illustrate the point, he recalled instances in which he was grilled during Congressional hearings by the late Sen. John McCain.

“I really do miss Sen. McCain. But I remember him screaming at me one time about a major acquisition program that was not doing well: ‘Who are you holding accountable? Who are you going to fire?’ And I said, ‘Senator, the problem is that it’s a committee in the Pentagon. And you don’t hold a committee accountable for something,’” he said. “I’m not going to fire the colonel, because it’s not his or her fault. That would be wrong. You can’t do that unless they have the authority and the responsibility.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.