It is not often that government leadership discusses the importance of system engineering or complex system management, but major setbacks for the U.S. Coast Guard’s $24 billion Deepwater program are casting a shadow over the use of lead system integrators on other U.S. Defense Department acquisitions. These setbacks also are highlighting the lack of government system engineering knowledge.
Whether it is an acquisition professional trying to understand engineering principles or a senior executive responsible for engineering decisions, the growing lack of skilled engineering competence within the Defense Department is striking. Deepwater’s effects are rippling outward, affecting the certainty of future contracts and programs in which lead system integrators are being used, such as the Army’s Future Combat Systems (FCS) and the Homeland Security Department’s Secure Border Initiative Network (SBInet).
Engineering systems and their informational subsystems are increasing in size, scope and complexity as a result of new technology developments, which are improving processing power and increasing operational demands. The poor management of system complexity is compounded by the decrease in the number of qualified engineers within the government work force.
But the work force is not the most significant challenge. Today’s engineering systems present difficult design problems for program managers because many existing engineering system frameworks are outdated. In particular, tradeoffs between integrative approaches to system design, combined with multiple highly networked sensors, and weapon systems cannot be made without first understanding which subsystems are beneficial to—or in conflict with—system objectives. The coexistence of integrated systems with networked components and subsystems requires new methods to design and manage large-scale complex engineering systems.
Designing a simple platform that meets a specific operational need is difficult enough. But when the scope of operations or the complexity of the system design exceeds current management and engineering skills, conflicts will emerge between the performance capability of the total system and the ability of individual components to satisfy operational demands, regardless of how well those components perform. Without question, articulating design requirements remains the hardest contractual aspect of system design. However, when the system also has to be adaptive, flexible or modular or when the requirements shift and are modified, program challenges continue to mount, and failure shortly follows.
Urgent-needs statements emanating from
What methods exist to formally link these requirements with resources and methodically solve these programmatic engineering system challenges? What engineering science tools exist that directly link functional requirements with technical solutions for operational purposes?
Total system engineering is an emerging field within leading engineering communities that systematically distinguishes the “what” of the design from the “how” of the technical implementation. The reason for this distinction is that it is easy to jump to a set of technological solutions and state them in a requirement document before really understanding the operational purpose for the design. In addition, as system complexity grows, the ability to understand how the finished system will behave or perform declines.
Without the means to trace relationships reliably between functional requirements or the means to show how interdependent components or subsystems affect each other in the total engineering system, programs will fail—as the Defense Department continuously rediscovers. When an engineering system can define clearly what the design should do in terms of operations, only then can the program manager and lead system integrator determine how and when technical options are selected.
Program risk is mitigated only when the relationships between large numbers of opposing or complementary functional requirements and the negative or positive effects of several technical solutions are understood. While a single technical choice may solve a particular objective, its impact on the entire system may not be known until it is too late. Adding systems on top of or within systems does little to relieve the growing challenges of fielding systems quickly, safely and affordably.
Most program offices are good at clarifying operational needs. But linking those needs to functional requirements, each with its own technology solution within a large, complex engineering system, continues to be problematic. Only when needs are qualitatively translated into wants, and quantitative wants are systematically designed into engineering systems reflective of operational demands, will Defense Department programs consistently succeed. Programs such as the FCS and SBINet offer complex engineering system designs with significant challenges, but a total system engineering approach will encourage executives to maximize value along the entire system process. Unless the Defense Department is able to demystify engineering system complexity properly, programs will continue to make headlines instead of making it into the field.