1

Gorilla Systems Engineering versus

Guerilla Systems Engineering Keith A. Taggart, PhDJames WillisSteve 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 was

bringing problems up the management chain– Program management seemed to believe that Systems

Engineering must 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 was spent 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.

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“