Jeff Child, Editor-in-Chief, COTS Journal


After a turbulent path through Congress, the National Defense Authorization Act for Fiscal Year 2017 (NDAA) finally passed the Congress with veto-proof majorities in both houses. But the fight to reform defense acquisition is ongoing, with most stakeholders acknowledging that the taxpayers need to get more for their dollar when it comes to defense spending. The issues are the same as ever: unexpected rises in program costs, slipping of schedules and technology not meeting maturity levels. There’s never any lack of new theories or initiatives aimed at improving things, but for me it’s the ones that take an engineering perspective that catch my eye.

Because you all as COTS Journal readers are engineers or technical decision makers of some kind, the expression “the devil’s in the details” is something you well understand. In recent GAO report looked at how detailed systems engineering done prior to product development are a good indicator positioning a program for success. In the report GAO’s analysis of nine case studies identified the factors that frame the challenge posed by a given weapon system’s requirements. The nine programs were the KC-46A Tanker Modernization Program, Global Positioning System III Satellites, Small Diameter Bomb Increment I, Integrated Air and Missile Defense, Paladin Integrated Management, F-35 Lightning II Program, Joint Light Tactical Vehicle, CH-53K Heavy Lift Replacement Helicopter and the P-8A Poseidon Multi-mission Maritime Aircraft Increment I.

The analysis showed that programs with even modest requirements and early detailed systems engineering had better outcomes. For example, the Small Diameter Bomb Increment I program, which delivered within cost and schedule estimates, had an incremental approach, mature technologies, a derivative design, and detailed systems engineering before development began. Programs that began with more challenging requirements and insufficient systems engineering reported worse outcomes. The F -35 Lightning II for example—which has encountered significant cost and schedule problems—began development with a single- step approach, a highly complex design, immature technologies, and little systems engineering.

The GAO’s analysis of the nine selected programs supported identified four key factors that shine a light on both challenges posed by a system’s top-level capability requirements and the related risk. Although those four factors were not the only ones they considered, the GAO found they were prominent and observable early in their case study programs. Those four factors are

Acquisition approach: This indicates whether a program intends to take an incremental, evolutionary approach or a single-step approach to meet all capability requirements. An incremental approach reduces risk by developing and delivering a product in a series of enhanced interim capabilities until final capability is reached. In contrast, a single-step approach increases risk by attempting to deliver the final capability all at once without any interim capabilities.

Technology status: This is the extent to which the critical technologies for a proposed system are mature at the start of product development. Technologies are ready for inclusion in a product development program when they have been demonstrated in a realistic, operational environment (Technology Readiness Level (TRL) 7), proving that they can work as intended. Demonstrating technologies in an operational environment provides a higher level of technology understanding and reduces risk prior to starting product development.

Design maturity: This factor is the extent to which a proposed system’s design is either derived from an existing commercial or DoD system—whether operational or prototype—or is new and unprecedented. Designs derived from existing systems, whether commercial or DoD, by nature have more knowledge available when product development begins, thus reducing risk. In contrast, unprecedented designs are by nature more complex and inherently higher risk.

System interdependency: This indicates the extent to which a system relies on another system or group of systems being developed and managed separately to provide its required capabilities. DoD acquisition guidance says that—although DoD programs should not be acquired in isolation—a program office developing a more independent system generally has more control over requirements, schedule, funding, and interfaces, among other factors. In contrast, a program office developing a system that is more dependent on other systems—like a system of systems —generally has less control, thus making its requirements more challenging to achieve and increasing risk.

There’s no doubt that the products and technologies developed by our military embedded computing industry offer solutions that feed squarely into the challenges described above. The demand for higher technology readiness has helped fuel demand for prepackaged and prequalified subsystems as primes find themselves without the time or the DoD funding to develop a prototype subsystem themselves. As TRL becomes a more significant part of military requirements, suppliers in our industry are crafting solutions with that specifically in mind.

One final thought: My sincere thank you to all you in our industry for your support of COTS Journal in 2016. Here’s wishing you all Happy Holidays and a healthy, prosperous New Year in 2017. And most importantly, please join me and RTC Group in thanking all of our nation’s servicemen and women who serve in harm’s way. Especially at this time of year, they are in our thoughts and in our hearts always.