The title of this post is slightly misleading. The Department of Defense (DoD) doesn’t just influence systems engineering practice, it practically dictates it. And the reason is simple: The DoD acquires more types of systems and more complicated systems than any other organization in the world¹

You can’t buy an anti-aircraft gun, a nuclear submarine, or a spy satellite from a catalog; complex military systems are necessarily bespoke, created to the specific demands of the customers. To obtain such systems, the DoD implements the defense acquisition system, an involved and highly regulated process for determining exactly what those demands are and obtaining a capability which meets them within the available budget. Though there are many players and moving parts, the heart of this process is systems engineering.

Most large defense systems are created by a prime contractor, which has competed with other contractors on price, schedule, solution capability, and experience to demonstrate that they’re the best company for the job. You might hear in the news about a big new DoD contract and picture the contractor going off to do the work, coming back in a couple of years with new airplanes or missiles or whatever rolling off the production lines. The reality is that the government has a pretty significant amount of oversight and control over systems engineering projects. Most projects are overseen by a single government office specializing in the type of system; need an attack helicopter? You’ll want to get in touch with the Apache Project Office, under Army Program Executive Office Aviation. Submarine-launched ballistic missile? Navy Strategic Systems Programs. Fighter jet? F-35 Joint Program Office². Communications satellite? Air Force Military Satellite Communications Systems Directorate. You get the picture.

These offices are staffed by a mix of bureaucrats, engineers, and domain experts, often former users of the system or similar systems. Though the prime contractor gets their name on the system, it is the program office which sets the acquisition approach, shapes the capability, and shepherds the system through the acquisition and into the hands of the users. Program offices are supported in this task by a large network of government resources. Federal regulations as well as DoD-specific policies provide rules for contracts and project management, dictate the gates at which decisionmakers approve continued investment, require reporting of key data to government databases and to Congress, and more. The acquisition process and guidelines provide a roadmap for executing every step of a project. Moreover, the DoD created Defense Acquisition University to offer accredited, graduate-level courses, ongoing professional development, and a one-stop shop for practical acquisition tools to its workforce; DAU.mil is a publicly-accessible treasure trove of acquisition knowledge.

All of this to say that the DoD is well-organized when it comes to system acquisitions and contracting. These policies and guidance put constraints on program offices in the interest of fair contracting and responsible stewardship of taxpayer dollars. They also empower the program office with both legal authority and soft power to oversee every step of the process. If the government wants things done a certain way, they can specify it in the system requirements, incorporate it into the contract, or provide the contractor with non-obligatory recommendations. On a day-to-day basis, the program office makes such suggestions to ensure that its priorities for the system are being addressed and to provide the contractor with relevant information that would assist in the project.

At a higher level, both the executive and legislative branches of government have influence over acquisitions and may implement reforms or develop initiatives that affect the way acquisitions work. For example, the Clinger-Cohen Act of 1996 addressed the development of information systems in a number of ways, including mandating that federal agencies create a Chief Information Officer role and streamlining the acquisition of certain types of information systems. In 2015, the Under Secretary of Defense for Acquisition, Technology, and Logistics released Better Buying Power 3.0 (pdf), a 35-page memo with guidance for improving innovation and affordability in a number of ways across DoD acquisitions. It is these types of initiatives which can have significant impact on system engineering practice well beyond the DoD.

A recent example is Human Systems Integration (HSI), a systems engineering discipline which considers the human as a subsystem on-par with any other hardware or software subsystem in order to factor the human costs and capabilities into system design. HSI grew out of the Army Manpower and Personnel Integration (MANPRINT) initiative and is now required for all of the services by acquisition regulations. HSI is becoming a standard part of engineering practice; the International Council on Systems Engineering (INCOSE) has an HSI Working Group and has incorporated HSI into the INCOSE Systems Engineering Handbook while SAE International has an HSI committee and is preparing to release a comprehensive HSI standard.

HSI is a somewhat unique case because it was “homegrown” by the DoD. Most other engineering initiatives start elsewhere–commercial companies, professional organizations, academia, and/or think tanks–but become entrenched once adopted by the DoD. Model-based systems engineering (MBSE) is a great example. The DoD didn’t come up with the concept, but, through a series of working groups and reports, has embraced it and even expanded on it with DoD-specific architecture frameworks. This supports an ecosystem of industrial and academic MBSE solutions and development; DoD customization, case studies, and approaches make their way into textbooks, seminars, handbooks, software tools, etc., thus entrenching the DoD’s MBSE methods into systems engineering practice.

In short, the DoD supports and exerts influence over an extremely robust systems engineering community. Thus, any initiatives implemented by the DoD inevitably make their way into systems engineering practice in other industries.

Do you have an example of DoD impacting SE practice? Perhaps a counterexample?

1. Space agencies may be a close second for complexity, but certainly not for number of systems, dollars spent, or volume of production. Auto, aviation, and industrial manufacturers have a larger production volume and arguably more types of systems, but lower complexity and more commonality across types.
2. A rare attempt at a multi-service project office, as of 2018 slated to be dissolved into separate Navy, Air Force, and Marine Corps offices each managing their service’s variant