Improve the Systems-Engineering Acquisition Process

Assistant Secretary of the Navy for Research, Development, and Acquisition James Geurts is changing the acquisition paradigm, and one of his key tenets is decentralization.¹ His goal is to push authority and accountability to the lowest capable level to create a more agile workforce and minimize bureaucratic delays. With these goals realized, it will be possible for the acquisition workforce to make faster and more relevant decisions and deliver better products to the fleet.

With the foundation for a decentralized acquisition workforce in place, focus must shift to improving the systems-engineering acquisition process. The current process ostensibly enables a harmonious relationship between government and industry partners and ensures that every facet of the design process is collaborative, efficient, and adds value. But it has become too cumbersome and now increases the time it takes to develop new systems and deliver them to the fleet, often well behind schedule.² A technical environment must be cultivated to promote the uninhibited flow of information that results in an optimized piece of technology, procured at a fair price, and delivered to the fleet on time. This is achievable by more rapidly incorporating the tenets of model-based systems engineering into current processes.

The Old Process

The current systems-engineering acquisition process is a top-down, technical control process, designed to create overarching stakeholder requirements to influence the bottom-up portion of the process.³ This is often depicted as the traditional systems-engineering “V” shown in Figure 1, in which decomposition of a proposed piece of technology occurs on the left side of the V and realization occurs on the right. What makes this process too slow is the laborious interaction that occurs between the contractor and government at every step.

Consider the first step—Stakeholder Requirements Definition. In an acquisition program, the government generates requirements and provides them to the contractor as a written document for review. The contractor reviews the requirements—sometimes for months—and then returns an edited version of the document to the government with inputs. This iterative process can continue for many more months before both parties reach agreement. The rest of the systems engineering proceeds in similar fashion: slow, and often for many more months, with each step in the V completed in sequence. The government can no longer afford to acquire technology using such sluggish methods, especially when new technology, methods, and practices exist to streamline the process.

Model-Based Systems Engineering

Model-based systems engineering leverages available technology to streamline collaboration between the government and contractor and more rapidly ensure fielded technologies match initial design requirements. It shifts from a document-centric process to a more collaborative and expedient one. According to the International Council on Systems Engineering, this is accomplished using computer modeling to represent the system under design, then using the model to complete the same steps of the traditional systems engineering V (design, analysis, verification, validation, etc.).⁵

In 2015, Naval Air Systems Command in Patuxent River, Maryland, contracted the Stevens Institute of Technology (in New Jersey) to assess the technological feasibility of engineering transformation through a model-based systems-engineering approach. The study concluded that model-based systems engineering can reduce the typical development time by 25 percent.⁶ The company SpaceX has been quite successful using model-based systems engineering to innovate and accelerate development of key components of its rocket program.

Changing the entire process will not happen immediately. The only way model-based systems engineering can become the standard is if engineering leaders at the lowest level take advantage of the decentralized environment Secretary Geurts is creating and make it a priority to imbed tenets of model-based systems engineering into daily workflows.

Changing the Culture

Enabling a culture in which model-based systems engineering thrives requires personnel to understand the process and have access to a high-bandwidth, up-to-date information technology (IT) infrastructure.

With decentralization comes the responsibility to self-educate and develop oneself as an engineer of the future. Engineers cannot only rely on tenant commands to provide educational opportunities. Instead, members of the acquisition workforce should strive to be experts within their domains and understand what technological advances must be learned and adopted to meet future challenges.

While continuing education is largely an individual responsibility, the financial burden does not have to be. Opportunities abound for engineers to find relevant and subsidized continuing education. For example, Naval Air Systems Command routinely sponsors students for the Naval Postgraduate School master’s program in systems engineering, in which novel concepts such as model-based systems engineering are taught. And the command’s systems-engineering transformation team provides education on cutting-edge capabilities and provides end-user licenses for advanced software and tools.

Abandon the Navy–Marine Corps Intranet

When new engineers arrive at systems commands, they should expect to work with modern computers on a modern IT network with the bandwidth and speed needed to host the latest engineering tools. Instead, the Navy asks the acquisition workforce to deliver relevant technologies using the archaic and limited infrastructure of the Navy–Marine Corps Intranet (NMCI). This is like asking a fighter pilot to fly at supersonic speeds in a World War II–era, propeller-driven aircraft—it cannot be done.

The Department of the Navy should abandon NMCI—and the plans for its replacement, the Next Generation Enterprise Networks Re-compete—and instead follow precedents set by the Defense Innovation Unit, the U.S. Naval Academy, and the Navy’s Operational Testing and Evaluation Force, which have all opted for commercial-off-the-shelf IT solutions. At first glance, using commercial solutions to handle sensitive government material appears risky. But with advances in virtual private networks and sophisticated cyber protection tools, commercial solutions can be as resilient as NMCI, but with significant performance improvements.

With transformative change also comes risk. Change to paradigms and processes will likely entail both successes and failures. Still, acquisition leaders must promote a culture that can recognize the benefits of failure. As Elon Musk made clear to SpaceX in the early development of the Falcon I rocket, “Failure is an option here. If things are not failing, you are not innovating.”⁷

Leaders at the highest level must encourage those at the most junior levels to take prudent and informed risks to improve engineering processes. Over time, if enough of the workforce begins to make changes within their domains, improved processes will become the convention and part of the acquisition culture.