The new administration’s extended transition process has led to an unusual circumstance in which there are literally zero politically-appointed acquisition officials anywhere in the Defense Department. Such a scenario might seem like an unlikely time for DoD to make major changes to the way it buys information technology, but that’s exactly what the career civil servant who’s currently leading the department’s vast acquisition apparatus hopes to do over the next year.

James MacStravic, who’s currently performing the duties of undersecretary of Defense for acquisition, technology and logistics says he plans to spend the next year trying to drive out what he calls “the stupid” from DoD’s IT buying practices. By that, he mostly means the department’s tendency to apply processes that were designed for complex weapons systems – including massive, slow delivery increments and exhaustive testing procedures – to commercial IT.

“We do not have instructions, we do not have governance mechanisms that are informed by the current state of practice — never mind the current state of the art,” he told a conference hosted by AFCEA’s northern Virginia chapter last week. “What we’re going to try to do over the next year, hopefully with the assistance of industry, is change those models.”

The notion that DoD needs to break away from its habit of applying strict major defense acquisition program rules to software acquisitions is certainly not a new one. Indeed, when Frank Kendall, the last Senate-confirmed AT&L undersecretary rewrote the department’s main acquisition guidebook four years ago, he emphasized that DoD’s acquisition gatekeepers would need to let managers “tailor” their strategies to fit whatever they happened to be buying.

The document – DoD instruction 5000.02 – even included a separate section to help model how IT programs can be managed, acknowledging that they are different from tanks and destroyers, especially in the sense that most of the design and construction has already been done by commercial industry.

“But I’ve not yet met the program that uses that model,” MacStravic said. “And it’s because people see the model as prescriptive rather than descriptive.”

The department has taken steps to address that problem with regard to the subset of IT systems that can be characterized as “business systems” by removing them from its primary acquisition instruction altogether. In February, the department published a new instruction, specific to business IT, stressing that those acquisitions are overwhelmingly about organizational change management, not designing or modifying software.

“The most important thing you can do in procuring a business system or an [enterprise resource planning system] is knowing what your requirement is,” MacStravic said. “That’s the functional community’s job, not the acquisition community’s job. We can structure the conversation in a way that helps inform acquisition choices, but we’re not building anything – it’s already been built. However, the model we were using was assuming you were designing something from scratch. People were being inspected that way, and of course they were failing. They were trying to comply with a model that wasn’t effective, and so I, the chief information officer and the deputy chief management officer signed an instruction that said, ‘Can you please stop doing that?’”

MacStravic said the department needs to devolve its current policies and oversight functions when it comes to IT procurements. Congress already took a step in that direction when, in the 2017 Defense authorization bill, it completely abolished the concept of “Major Information Automation Systems,” which until now has dictated a separate regime of approval requirements for any IT procurement of more than $40 million per year.

DoD is in the process of unwinding the regulations the department has built up on its own around MAIS procurements before the repeal officially takes effect at the end of September, but MacStravic would like to go even further.

“My plan is to get rid of everything that’s not a statute, and physics will drive,” he said. “Each of the services, each of the systems commands and each of the warfare centers is going to have to write their own damn regulations, because they at least will understand the context in which those regulations are appropriate. We will still have a framework that’s explainable to the people who send us money, but we need to do it with a minimum amount of acquisition oversight.”

MacStravic said that’s because it’s virtually impossible for the Defense Department to craft rules for IT procurements with any hope that they will remain relevant by the time program managers have to deal with them. The danger, he said, is that what appears to be a best practice in one year turns into an immutable policy once it’s written down – whether or not its still applicable to the technology landscape two or three years later – serving only to throw sand in the gears of the acquisition process.

“It’s even worse if that policy becomes a regulation, which means somebody someplace is going to make you do this unless you can convince them otherwise. But even then, it’s just us, we’ll have a lot of fights and drink a lot of coffee and get over it. But what happens when Congress finds it? They turn it into a law,” he said. “They’ll give me a waiver, but I’ve got to write an inch of paper to justify a waiver. Right now, to make a Milestone B decision on a major acquisition program, I have to sign up to 20 waivers in order to not conform to a statutory requirement that may or may not be relevant to the actual problem I was facing. A best practice on a hardware system has migrated into a statutory requirement on every system. I need those relieved, and the more I can pull those down so we can make contextually-appropriate decisions that relate to the technical and operational changes we’re actually facing, the more we’ll see acquisition agility.”

MacStravic said his attitude toward the regulatory regime around IT procurements was partly driven by his experience as a senior DoD official who oversaw the Air Force’s procurement of the OCX program, the ground control software for an upcoming generation of GPS satellites which ran into major cost and schedule overruns after the military imposed strict testing requirements that traditionally accompany a major hardware program. The program was eventually restructured late last year following a breach of the Nunn-McCurdy Act.

“Those requirements were not appropriate to the technology,” he said. “We’ve modeled them after, ‘I’m building a box,’ and the fact is I’m building something else. While it’s hard to manufacture, inspect validate and test something when you’re building a hardware system, what we learned with OCX was that on software, you can do it 20 times a day – not once every six months, as the contractor had been doing until the point we relieved him of the stupid. By using modern software development and automation tools, it’s possible to build in and validate the functionality and information assurance as you’re doing the software, and our whole procurement model didn’t reflect that. So, we asked for something stupid, we got something stupid, it was expensive, and it didn’t arrive.”

Return to DoD Reporter’s Notebook

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