Gorilla Systems Engineering versus Guerilla Systems Engineering

1. Gorilla Systems Engineering versus Guerilla Systems Engineering Keith A. Taggart, PhD James Willis Steve Dam, PhD Presented to the INCOSE SE DC Meeting, May 14 2012

2. Definitions and Characteristics • In the rather artificial world of systems engineering there are a couple of interesting types of inhabitants: Gorillas and Guerillas

3. Implications • We do NOT intend to imply that Guerilla Systems Engineering is “Better” than Gorilla Systems Engineering • We only mean to point out some interesting characteristics of the two and speculate on the implications these may have for the future • The analogies are not exact but are rather meant to be thought provoking

4. Gorillas Systems Engineers • Gorillas are the BIG guys: the US Government and the “uber” integrators, the primes • These are the organizations and their members who produce or cause to be produced large complex and / or complicated systems • They use the standard system engineering approach described by the “V” (or equivalent) • a standard set of artifacts (requirements, architectures, interface control documents, and so on) • and a limited set of relatively expensive tools to create and configuration manage these artifacts

5. How Gorillas Seem to Work • On a typical program hundreds (if not thousands) of people work on Systems Engineering. • Tools include: • Requirements management • Architecture development and management • Custom data bases • Computer modeling • Computer aided design • To mention the basics • The processes used are invariably proprietary • Always certified, as in CMMI Level n (Usually 3 or higher) • Always involve large number of approval boards • Always involve large scale program reviews • In the Department of Defense there are specified artifacts, reviews and milestones that must be adhered to • DoD 5000 and so on

6. Observations About Gorilla Systems Engineering (1 of 2) • We offer some observations based on large programs on which we have worked that used Gorilla Systems Engineering: • Failure was not an option (though often a result) nor wasbringing problems up the management chain • Program management seemed to believe that Systems Engineeringmust not last into production, should not last into testing, and preferably not too far into development. This was probably due to high costs associated with large Systems Engineering efforts. • Changes to requirements caused considerable disruption during the entire course of these large programs • Linking architecture and requirements is difficult if they are built and managed with separate tools (usually the case)

7. Observations About Gorilla Systems Engineering (2 of 2) • We offer more observations based on large programs on which we have worked that used Gorilla Systems Engineering: • Geographical and organizational diversity made integration really, really hard • There were at least two sides to every interface and they never seemed to agree on the documentation • No one seemed to know how to define what constitutes a design • Nobody seemed to understand how software and hardware designs were to be integrated • Process often overshadowed results • More time wasspent arguing about process and tools than about results • Too many review boards spoiled the product(s)

8. Guerilla Systems Engineering • Guerilla Systems Engineering tries to deal with the reality of the jungle full of Gorillas and accomplish something helpful • It focuses on some aspect of the process that is failing and tries to move outside of the process using small, well integrated teams of experts to make progress

9. Observations about Guerilla Systems Engineering (1 of 2) • Some of the authors have participated in Guerilla Systems Engineering and offer some observations: • Guerillas are born of desperation • Guerillas will only be tolerated for a limited time with a very limited focus • Roadblocks will be thrown up at every opportunity • Stealth is essential but impossible • Too much visibility will cause the Guerillas’ early demise • Operating outside of the process will cause their early demise

10. Observations about Guerilla Systems Engineering (2 of 2) • Some of the authors have participated in Guerilla Systems Engineering and offer more observations: • Guerillas have a very limited lifetime so they concentrate on analyzing specific critical capabilities and showing sufficiency of end-to-end performance for a relevant set of threads. • Guerillas have very limited resources so they have to use inexpensive and widely available integrated and automated tools • Guerillas always “lose” in the long run but one case with limited success in the area of design is known

11. BUT… • Guerilla Systems Engineering characteristics may be more appropriate in the budget constrained future of systems engineering: • Sponsors will not want to pay for large SE efforts • New approaches to program development such as “Agile”, “IT Box”, and wider integration into an existing “SoS” will probably require both more focus and more flexibility. • Capability analysis and “sufficiency” over many capabilities is becoming more important than optimization of a few “critical” capabilities • Systems Engineering teams must become smaller and more agile to respond to these trends • Systems Engineering tools must become more inexpensive, accessible, flexible, and automated to support these teams.

12. Conclusions • Future system engineering efforts, if tolerated at all, will have to operate more like Guerillas than Gorillas • A major impediment to Guerillas has been the lack of an inexpensive widely available integrated tool set to allow small groups of organizationally and geographically dispersed experts to match and exceed the work of an army of Gorillas • The SPEC Innovations Lifecycle Modeling Language (LML) and tool is designed to empower future Guerillas to succeed. See the following SEDC talks: • “Lifecycle Modeling – A Quick Overview of a New Methodology for Simple, Rapid Development, Operations and Support” • “Lifecycle Modeling - Application to Software Development“