Skip to main content

Technical Papers

Synchronizing Systems Engineering and Implementation in Lean-Agile Programs

Robert Maione
Techna Systems Inc.

Mark A. Wilson
Strategy Bridge International, Inc.

Download the Paper
Abstract. In traditional system development programs, high-level statements of capability and mission needs are elaborated and functionally decomposed, and then systematically allocated to discrete program segments or subsystems. Functional decomposition continues to be a classic systems engineering technique to define and manage the development of large systems, but this approach can create issues in systems that are being developed using Lean-Agile methods. Lean-Agile developers typically adopt a “time box” perspective, where the goal is incremental delivery of system capability on a predictable schedule. In other words, Lean-Agile developers may adopt a development rhythm with increments of rapidly evolving capability delivered every 10-12 weeks, while the SE team stays focused on the progress of the overall system as it was originally planned and defined. This divergence of both pace and perspective can lead to misunderstandings between systems engineers and developers or worse, disconnects between what the systems engineers think the developers are building and what developers are actually building.

Communication suffers when Lean-Agile developers and program systems engineers operate in separate organizational “silos” instead of working together as a cohesive team. Day-to-day implementation decisions with potential impact to overall system capability can become buried within lower level engineering and development documents that are hard to synthesize to support timely program decisions. In our work with large programs employing Lean-Agile development strategies, we discovered an approach that maintains systematic collaboration between developers and the SE team. In our approach, we explicitly measure and communicate incremental delivery of value using a new level of abstraction that we call Mission Value Threads (MVTs). MVTs directly link system requirements and their associated SE artifacts to Lean-Agile development team backlogs and design documentation. This paper describes how to use MVTs to manage value delivery while fostering better collaboration between developers and systems engineers.

Governing Systems Engineering as an Enterprise Competence
A Benchmark Study with Pertinence to the US Department of Defense

William P Mullins
Energy Services Consultant

Mark A. Wilson
Strategy Bridge International, Inc

Download the Paper
Abstract. DoD is reinvigorating SE capabilities so that “system of systems” structures can now be engineered. A benchmarking review reports approaches to the achievement of SE competence in a Research, Development and Engineering Center. For SE competence management most SE organizations contacted reflect tailoring to local and historical conditions more than the effects of integrated development. Current SE governance practices are analyzed here on a continuum between composite models termed the “Strong Form Model” and the “Methods Model.” Systems-engineered Competence Development Plans appear to be in order to address growing dynamic complexity inherent in the “system of systems” environment.

Addressing the System of Systems Challenge

Dr. John Boardman
Elipsis, Inc.

Mark A. Wilson
Strategy Bridge International, Inc

Allen Fairbairn
John Boardman Associates, Ltd.

Download the Paper

Abstract. The top-down systems engineering strategies that worked well in the 20th century do not adequately address the complexity and interdependencies of today's higher-order systems that often must operate seamlessly with huge and disparate legacy systems. Soft management issues, such as organizational culture, also play a vital role in the organization's system of systems, often called the extended enterprise. Strategy must be formulated—and appropriate deployment mechanisms designed—for the system of systems level.

System of Systems (SoS) has become a popular buzz word among systems engineering practitioners, but what does it really mean? Some professional literature traces the origins of SoS to problems with systems that “nobody owns,”1 while the U.S. Department of Defense has recognized that Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) systems must be seamlessly integrated with weapons systems in order to achieve optimal SoS effects. This paper offers an explanation of key SoS concepts and proposes some useful practices that the authors have found useful to address the complexities of large-scale integration of SoS assets across the extended enterprise (EE).

The Work Breakdown Structure in the Systems Engineering Process

Mark A. Wilson
Strategy Bridge International, Inc

Frederick J. Manzer
Strategy Bridge International, Inc.

Download the Paper
Abstract. Many textbooks, handbooks, standards, and guidance documents approach the Work Breakdown Structure (WBS) exclusively from a project management perspective. This may result in the systems engineering team overlooking the WBS as a key systems engineering artifact, or worse—a WBS that does not serve to effectively integrate the technical and programmatic elements of the project. This paper examines the WBS and addresses how, when structured and used appropriately, the WBS documents the overall system architecture and integrates the elements of the project to provide the insight necessary for the analysis and decisions required for effective systems management.

Optimizing Resource Allocation Decisions

Mark A. Wilson
Strategy Bridge International, Inc

Download the Paper

Abstract. The paper explains how the analytical hierarchy process (AHP) theory of decision-making can be used to create justifiable, traceable resource allocation decisions in a resource-constrained organizational environment. By thinking about the decision as a six step process of: (1) framing the decision to be made, (2) identifying alternatives, (3) modelling-evaluating the trade study, (4) choosing an alternative, (5) conducting sensitivity analysis, and (6) implementing the selected alternative, key stakeholders can better understand how to reliably and repeatably make justifiable, traceable resource allocation decisions in the context of an enterprise systems framework.

The Impact of Fear on Project Success

Frederick J. Manzer
Strategy Bridge International, Inc.

Download the Paper
Abstract. Have you ever thought “...this will never work, but if I tell management they’ll fire me”? Have you suppressed information, such as a growing estimate at completion, to prevent unwanted attention, criticism, or help? Would you pad an estimate to ensure your ability to meet promised numbers even when things do not go as planned? These may be legitimate responses to the reality of life in your organization, but they are destructive to the people, the project, and the organization. These “fear” responses substitute self- protection for the honest communication that brings long term success.