Chapter 1: The Discipline of Systems Engineering

Overview
The elements of systems engineering that will be explored in this chapter include:
§ origination
§ evolution
§ impact on the business
§ organization

Systems engineering is a discipline that provides structured processes necessary to

manage projects that require performance from many disciplines in order to achieve
their objectives. In Sections 1.1 and 1.2, this chapter first explores the origination and
evolution of the discipline of systems engineering, the resulting terminology changes,
and standards development. There is a long history associated with the development of
the processes, with a convergence of techniques that have led to a formal designation
of an integrated discipline. This evolution is continuing. The future
of systems engineering will be fully discussed in Chapter 8.

In Section 1.3, the application of the systems engineering discipline within an

organization is discussed. Section 1.4 describes an overview of systems engineering,
including the system and system-of-systems approaches. A case study demonstrating
the application of systems engineering processes is provided in Section 1.5. The
purpose of each case study in this book is to demonstrate
that systems engineering processes and practices are a natural controlling mechanism
associated with projects across all fields and disciplines. And awareness of the natural
alignment of activities to the established systems engineering processes, when
appropriately applied, can increase the probability of achieving a successful
outcome. Systems engineering processes can be used in most every scenario to
develop and implement a roadmap that will lead to successful outcomes and that meets
the desires of the key stakeholders. The stakeholder group includes the customers as
well as any other key individuals who have a vested interest in the project. Although
specific systems engineering activities were not consciously planned into the project,
the case study in this chapter demonstrates the natural inclination to categorize and
organize in a methodical way in order to increase the potential of achieving success.
The focus of these cases provides an opportunity to review an activity that would not
typically be chosen to represent systems engineering such as is found in other texts;
however, these cases well represent standard systems engineering processes in use.
This provides the reader with a greater understanding of the applicability of these
processes to their own situations, which may fall outside of the typical organizational
examples.

Finally, a summary checklist of the key concepts is available in Section 1.6 to assist
learning. Apply Now exercises, which allow for the immediate application of the
information in this chapter, are included in Section 1.7.

Chapter Roadmap
Chapter 1 focuses on systems engineering as a discipline. It specifically:
§ explains how systems engineering emerged as a discipline
§ describes the evolution of the systems engineering discipline
§ explores the impact of systems engineering within businesses
§ uses a case study to demonstrate the application of systems engineering
processes
§ provides a summary checklist of the key concepts to assist learning
§ provides Apply Now exercises to assist in the application of the concepts from
the chapter to a real situation

1.1 Origination of Systems Engineering

This section explains how the systems engineering discipline originated and how it
overlaps systems thinking.
§ Systems engineering originally emerged from a need to achieve better project
outcomes.
§ It began as a way to view the interactions of various engineering disciplines as
they were related to a single project or product.
§ It takes into formal consideration the stakeholders’ vision.
§ Systems engineering forms a holistic and synergistic perspective of the product.
§ It has led to formal education programs and implementation standards.

One of the ways that ideas have been brought to life in the world has been through
invention. Interested persons throughout time have attempted to create new products
through trial and error. They had a great idea and put it to the test. Ideas that were
successful in a prototype form were then produced in larger quantities. Early in the
technology age, these inventions were seen as remarkable and interesting creations,
mostly unavailable to the average person. Communications about the new object and
what it could do were limited to the media reach and the budget of the individual
inventor. In some cases, even if the new product was of interest outside a small and
local community, the costs to produce the item would limit its production and distribution
to a small population. As the technological age advanced, engineering took over the
majority of duties from the individual inventor. Inventors were expected to focus on early
research and development (R&D), whereas engineers took the design and created
production versions that could be mass produced at a lower cost.

For the greater part of the technological age, inventions typically were of the mechanical
and analog electronic forms. The move to digital technology was revolutionary. Where
analog technology simply converted a signal in its original form, digital technology
sampled the signal, converted it to numerals, and then stored it in a digital device.
During the output phase, the numbers are transformed into voltage waves that
approximate the original signal. Conversely, the analog signal is read as recorded,
amplified and projected directly through a speaker or other output device. With the
conversion to digital technology, the signal was not subjected to degradation and could
be compressed. This allowed more information to be stored on smaller media, which
opened up a new paradigm and radically changed the nature of invention and
production. Opportunities for new products that could be designed, mass produced, and
then made available to the general population at reasonable cost meant that the focus
would change from the initial state of invention to production efficiencies.

Although the processes that ultimately make up systems engineering were practiced in
various forms throughout history, the first documented use of an approach that took
the system into consideration was in Bell Telephone Laboratories. Their use
of "systems engineering" as a term to reflect their methods was documented in the
1940s.1 Bell Laboratories was involved in military action optimization studies during
World War II. Scientists and engineers there were using operations research methods,
specifically optimization modeling using calculus, linear algebra, and other techniques,
as well as stochastic processes such as queuing theory and probability theory. It was
not until 1962, however, that "Arthur Hall published his first book
on systems engineering: A Methodology for Systems Engineering. Hall was an
executive at Bell Laboratories and was one of the people who were responsible for the
implementation of systems engineering at the company."2 During the same era, the
RAND Corporation, ideated by a newly formed United States Air Force, developed a
process for systems analysis that would become an important part of
the systems engineering discipline. Systems analysis is an approach that reviews a
problem in logical steps, and describes the system thoroughly and explicitly. Using
computing resources to perform systems analysis and optimization modeling provides a
solid scientifically based approach for performing systems engineering.

From the 1950s through the 1970s, the digital revolution spawned unexpected and
inconceivable growth in industry. The act of inventing proliferated through every
discipline, and those who utilized technology, particularly digital technology, found
tremendous opportunities. Evolution over time from simple systems engineered
primarily from mechanical hardware and electronics to complicated systems integrating
multiple engineering disciplines became the norm. Complicated, but not complex,
designs were developed and used to manufacture the majority of products. The speed
at which products were brought to market increased exponentially. The ability to think of
an idea; conceptualize a design; develop a prototype; test, verify, and validate the
performance of the capability; and produce the design to specifications all formed the
basis for movement to the design-build-test method of engineering that was popular
during this era.

The design-build-test method of engineering provided the structure for the engineer to
research the area of interest, develop a solution based on known requirements, create
the prototype, and test it. However, this method did not, as part of its standard process,
provide for consideration of the contribution of other disciplines (such as software
development that was inserted into hardware), or provide a way for the stakeholders to
articulate their needs and validate that the product met their needs. It was not
until project development started crossing disciplines on a regular basis that the
limitations of a traditional engineering process started to emerge.
A systems engineering concept was beginning to be developed. There was a "growing
sense of a need for, and possibility of, a scientific approach to problems of organization
and complexity in a 'science of systems' per se."3
The United States Department of Defense and the National Aeronautics and Space
Administration (NASA) were early adopters of this integrated approach to development,
driven out of necessity to complete large, complicated products to support war fighting
and space exploration. Indeed, most people think of the NASA Apollo Program when
they think of "classic systems engineering." "The task … was daunting and complicated,
it involved breaking the underlying goal into multiple sections or manageable parts that
participating agencies and companies could work with and comprehend. These various
parts then had to be reintegrated into one whole solution, and as a result, careful
attention and management involving extensive testing and verification was necessary.
The complex nature of these tasks made systems engineering a suitable
tool for designing such systems. It was the principles of systems engineering that
resulted in the rigorous system solution, which contributed to Apollo's overall success."4

The first attempts to teach systems engineering concepts occurred in the 1950s by Bell
Laboratories, but with limited success. By the 1980s, strong demands to meet the
needs of the industries interested in developing and implementing an
integrated systems approach drove universities in the United States to offer the
requisite courses that ultimately produced a pipeline of specialist engineers. Graduates
of these courses were following a rigorous approach designed to facilitate major
programs. Military standards were also being implemented within government-funded
programs, helping to form the foundation for the systems engineering concepts that are
in place today.
Once the digital age evolved into what is known as the information age during the
1980s, and projects became, more often than not, interdisciplinary and
complex, systems engineering truly became a necessity for successful project
execution. These projects generally involved the heavy integration of software. Many of
the engineering projects that covered the mechanical, civil, and safety, disciplines or
software-enabled systems required integration over networks. Businesses had to
rethink how they operated. Stakeholders had more choices and had the ability to shift
their loyalties and purchase power from one company to another and from one product
to another. They demanded more participation in the development as well. Systems
engineering became sought after by these organizations as a way to help meet their
stakeholder's needs and improve their organizational performance.5
Projects that required careful integration of project elements from multiple disciplines
needed a better way to ensure that they achieved the expected results within the cost,
schedule, and scope anticipated by the stakeholders. Projects were becoming more and
more complicated and spanned all areas of business, such as platform-related products
(e.g., aircraft), infrastructure products (e.g., bridges and buildings), information-dense
products associated with command and control activities, and enterprise systems
distributed across organizations and, in some cases, other companies and countries. All
of these independent pieces of the system needed to be brought together at the right
time, in the right place, to maximize the effectiveness of the system as a whole. The
approach needed to be holistic and synthesizing. And it needed to focus on the desires
of the stakeholder. With the application of systems engineering comes the stakeholder
focus throughout the project.6 The more complicated the project became, the more it
was liable to be diverted (unintentionally) from the stakeholders' desired vision.
The need to understand and correctly identify what stakeholders wanted, to convert that
vision into a straightforward functional architecture, and then to be able to decompose
that functional architecture into a physical architecture that could be modeled and tested
in order to ensure the best design to meet the stakeholders' expectations were met was
an imperative. This top-down approach was called "systems" engineering
for organizational-level implementation, or "system" engineering for activities associated
with a single project. This approach envisioned incorporating work from across all
contributing disciplines instead of through individual downstream disciplines, such as
mechanical or electrical engineering, with a focus on ensuring that stakeholders
received what they needed from a project. It was seen as a holistic approach that
fundamentally would provide a whole system in its complete form to the stakeholders.

Systems engineering added tremendous value to the project management methods. It

was holistic in nature and spanned the life cycle of the system. It focused on
stakeholders—both their needs and their perceptions of the provided holistic system.
And perhaps most importantly, it took into consideration all disciplines that contribute to
the performance of the system as a whole, regardless of in which disciplines the
elements of the system originate.7The key processes in this new discipline included
understanding the end state desired by the stakeholders, synthesizing, optimizing,
implementing, proving, and then sustaining the solution. These activities are generally
divided into stages of a life cycle so that each stage can be practically organized and
managed to successful conclusion.

1.2 Evolution of the Systems Engineering Discipline

This section describes how the systems engineering concept evolved and obtained a
formal status as a defined discipline.
§ The descriptions of the terms "system," "system engineer," "systems engineer,"
"system engineering," and "systems engineering" were formalized to ensure a
common reference and understanding across disciplines.
§ Systems engineering has developed into a certificate- and degree-awarding
formal discipline.

Once the need for a concerted effort in understanding and effecting projects from
a system perspective was acknowledged, it was a natural next step for a disciplinary
approach to be crystalized and formalized. The desire was to create a formula that
could be used repetitively to minimize risk and increase the probability of successful
outcomes for all systems projects.

Over time, papers were written and presented; books outlining techniques became
common; and organizations formed to codify terminology, set standards, and define
approaches. In addition, more and more undergraduate- and graduate-level degree
programs, educational coursework and certifications, conferences, training seminars,
and internships became available. The formal job title of System or Systems Engineer
was instituted as a valid title for recruitment, although there was, and still is, a wide
variation of descriptions as to the role that is performed. And even though the discipline
of systems engineering has come far and is now considered part of the mainstream job
market, the actual position descriptions can still be far removed from the descriptions
found in the standards documentation. There is a long way to go before convergence
occurs, where a clear position description in the workforce matches the description of
the anticipated work of a systems engineer that is documented in the standards.

As it is anticipated that projects will continue to become more

complex, systems engineering is expected to become more important over time. The
anticipated future evolution of the discipline will be outlined in Chapter 8.

1.2.1 Terminology

In order to effectively communicate the requirements of performance in this emerging

discipline, definitions needed to be established that would be accepted by the
broader engineering community and would appropriately convey the intended roles of
the systems engineer on the project. A common reference and understanding was
needed. "The language used by engineers and the language used to describe what they
conceive, make, and do is changing. Engineers used to talk about things like force,
shape, size, tolerance, modulus, voltage, temperature, precision, construction, and
speed. Of course, they still do, but today, they are even more likely to talk about scale,
scope, state, complexity, integration, architecture, resilience, evolution, affordability, and
social context."8 The necessity to speak a common language led to a common
description of the terms "system," and "system engineering." These have been
formalized and documented in systems engineering standards.

Whenever more than one item is connected in some way (through process, physical
connections, or wireless connections, for example), the definition of a system can be
used to describe the whole entity.9 Further, this entity may often achieve greater
performance as a whole system, than what can be achieved individually by the
parts.10 Components can refer to elements, sub-elements, or actual component-level
products that interact to create a system desired by the stakeholders. "The results
include system-level qualities, properties, characteristics, functions, behavior, and
performance. The value added by the system as a whole, beyond that contributed
independently by the parts, is primarily created by the relationship among the parts; that
is, how they are interconnected."11 A description of a system will include everything that
is required to make the system function in its intended environment, and nothing more.

System(s) engineering is described as a multidisciplinary approach, based on

established quantitative principles, that provides for addressing and meeting
stakeholder needs in the formation, design, and production of a solution within
established costs and schedule and within acceptable risk parameters.12

It is an interactive, cross-disciplinary, top-down, iterative, and methodical approach to

the life cycle of a systems project. Systems engineering "is an approach and a discipline
that puts an activity into context and reviews all aspects of performance from a systemic
perspective. As a discipline, it provides structure and methods to define and
organize projects, to integrate activities and ensure that interfaces are correctly
identified and addressed, ensures testing of components and systems are completed,
manages risks and reviews, and performs configuration management to ensure that
design changes are tracked and implemented methodically so the current configuration
is always known."13

1.2.2 Standards

Standards, which can be used as established methods for accomplishing tasks within a
discipline and for which quality (compliance) can be measured, are important in
promoting effectiveness, managing risks, and increasing the probability of success
in projects of all types. Implementation of sound systems engineering practices is meant
to minimize unexpected emergent behaviors and reduce complexity. There are many
applicable standards across multiple disciplines that could be applied
to systems engineering processes. Some routinely are used for that purpose, including
those from such standards-generating organizations as the Institute of Electrical and
Electronics Engineering (IEEE), the International Organization for Standardization
(ISO), the American National Standards Institute (ANSI), the Department of Defense
Military Standards (DoD MIL-STD-xxx), the International Electro technical Commission
(IEC), the Electronic Industries Alliance (EIA), the Society of Automotive Engineers,
International (SAE®), and the International Council on Systems Engineering (INCOSE).
INCOSE was founded in 1990. It hosts the largest membership of systems
engineering practitioners to date. It is also a certification-granting organization.
"INCOSE champions the art, science, discipline, and practice of systems engineering."14

Other standards-generating organizations have their own or similar terminology and

processes, including the following:
§ International Association of Project Managers (IAPM)15
§ Association for Project Management (APM)16
§ International Project Management Association (IPMA®)17
§ Project Management Institute (PMI)18

Some organizations combine efforts to set standards that are overarching as well, such
as:
§ "ISO/IEC JTC1/SC7 (Information Technology, Systems and
Software Engineering)"19
§ An international standard, ISO/IEC/IEEE 15288, which has been established as
an inclusive set of process standards that can be used
across engineeringdisciplines.20

These standards, along with many others, have been developed that offer sometimes
consistent, but often conflicting, overlapping, and sometimes incompatible or
inconsistent guidance. This overlap may cause risk in systems projects because
different discipline practitioners are implementing what appear to be the same
processes. In particular, there are noted overlaps between software engineering (IEEE
SW Engineering standards) and information technology (IEEE CS) vocabulary and
processes, and the project management and systems engineering standards-generating
organizations' vocabulary and management processes. As systems engineering is an
overarching, top-down effort, this can be problematic in that processes can drive action
and design at the lowest levels of the project before the project is ready. This in turn
drives risk and increases the potential for catastrophic failure of the project.

Efforts are being made to try to bring standards in line to minimize the risk wherever an
overlap with the systems engineering discipline has been noted. In 2011, an initiative
sponsored by the United States DoD and led by the Stevens Institute of Technology, in
collaboration with the Naval Postgraduate School and other professional agencies,
created a wiki-based collection of materials called the Guide to
the Systems Engineering Body of Knowledge (SEBoK). This documentation was viewed
as "a living authoritative guide that discusses knowledge relevant
to Systems Engineering."21 "The three SEBoK steward organizations—the International
Council on Systems Engineering (INCOSE), the Institute of Electrical and
Electronics Engineering Computer Society (IEEE-CS), and the Systems
Engineering Research Center (SERC) provide the funding and resources needed to
sustain and evolve the SEBoK and make it available as a free and open resource to
all."22 The SEBoK governance and Editorial Board took the lead on outlining the explicit
issues with the overlaps and is actively working with the stakeholders to drive a positive
change, which could ultimately benefit all projects.

1.3 Organizational Implementation of Systems Engineering

This section describes the following considerations for organizational implementation
of systems engineering:
§ Implementation of systems engineering into organizations requires commitment
to the discipline as a whole to be successful.
§ Determining the best strategy for implementing and performing systems
engineering is an organizational leadership decision.
§ Systems engineering can increase the probability of project success in any
domain.

1.3.1 Organizational Structure and Culture

Depending on the existing structure of the organization, different levels of autonomy in

implementing systems engineering will be available. Generally, the larger an
organization is, the more difficult it is to implement significant changes to the structure
because the number of stakeholders that are involved increases exponentially.
Obtaining stakeholder buy-in and support becomes a major challenge to overcome. In
addition to size of the organization, the way it is funded and legally structured may add
additional constraints to restructuring. For example, organizations that obtain their
funding from governmental bodies may be subjected to more stringent organizational
controls than companies that obtain their funding from the private sector. And
organizations in highly regulated fields, such as the medical or financial domains, may
be required to obtain additional approvals for changes to their organizational structure.

Organizational structure and culture can impact the implementation

of systems engineering and the resulting successes. "Virtually every significant
business or enterprise that creates products or services benefits from performing a wide
variety of systems engineering activities to increase the value that those products and
services deliver to its owners, customers, employees, regulators, and other
stakeholders."23 However, it is often the case that more established organizations that
saw great successes with the traditional design-build-test downstream engineering often
find it difficult to implement changes that were necessary to implement a cross-
discipline systems engineering function. As systems engineering, by its nature, spans
disciplines,24 the execution often becomes problematic, because there are firmly
established and often embedded processes that must be replaced.

Implementing systems engineering into an organization requires an understanding of

the business processes, governance model, supplier management, etc. If an
organization is new to systems engineering, an evaluation of all the interfaces
associated with each systems engineering process must be mapped against each
process owned by another department/division, to ensure that the hand-offs between
the systems engineer and those departments that do the detailed work are known and
addressed before the official implementation begins.

Although the systems engineering discipline has been established to be applicable

across all industries and includes processes written independent of any domain, its
application in different specialized business areas (e.g., information technology firms,
financial industry, medical industry, etc.) might require tailoring of the process rigor to
address specialized languages and vocabulary.

Taking the time and effort to install a systems engineering discipline into an organization
is well worth the effort. In trying to quantify the return on investment (ROI) from
implementing systems engineering processes on projects, research has shown clear
and compelling evidence that systems engineering efforts have a definite, discernible
impact on the probability of the achievement of successful project outcomes. Indeed,
research on impacts on success rates on projects that
implement systems engineering shows clear evidence that the value achieved is worth
the investment.25 Associations and institutions from various disciplines have conducted
research during the last decade that confirms the existence of evidence that the use
of systems engineering makes a valuable contribution to project success.26

1.4 Overview of the Systems Engineering Discipline

This section provides a high-level overview of systems engineering to orient the reader
on the basic structure of the discipline, as a starting point. The way
that system engineering fits and adds value to a project will be discussed in depth
in Chapter 2. The specific processes that are used to perform systems engineering will
be reviewed in Chapters 3 and 4. Chapter 5 provides information on applying success
measurements to track progress. Chapter 6 discusses how to tailor the processes to
assure that the appropriate rigor is applied to different project types.
§ Systems engineering is an overarching, top-down, integrated approach to
managing a project.
 § Systems engineering views a project from the life cycle perspective—that is, the
end-to-end life of the project from conception through to closure, disposal, or
restoration to its natural or original form.
§ With experience on more complex projects, systems engineers started
referencing "systems thinking" ideas to explain emergence.
§ The discipline of systems engineering, when applied to a complex project,
requires additional discipline and rigor.
§ A system-of-systems approach provides the strongest defense against undesired
emergent behavior.

1.4.1 System Approach

The system approach is a holistic, top-down approach. This means that instead of
starting from a known capability and designing upward to a more integrated capability,
one must look at the intended purpose of the design and decompose the parts of the
design into manageable sections—all while keeping a firm perspective on how
everything fits together. Systems engineering integrates all required design disciplines
and specialty groups by creating and implementing a structured process that
overarches the entire life cycle. Figure 1.1 shows a representation of a system.

Figure 1.1: System Representation

The design disciplines include software and hardware engineering, reliability and
maintainability, human factors (usability), environmental, safety and security,
manufacturing/production, support, and many others. It is an interdisciplinary approach,
combining resources and integrating them in a manner to fulfill a stated and defined
need and to accomplish a specific mission or function. When describing a system, one
can envision multiple parts coming together into a whole to perform a function. The
description implies interactions of some form, although the connection of parts may be
static. Complexity enters the picture when parts of the system have life cycles and
purposes outside of one system but are still relied upon by that system for its overall
purpose.27 "When properly implemented, systems engineering will:

§ Provide a structured process for integrating and linking requirements, schedule,

decision milestones, and verification.
§ Enable the project team to work to a single, integrated set of requirements and
processes.
§ Enable integration of the system at the requirements and design stages rather
than waiting until hardware and software is available.
§ Reduce unplanned and costly reengineering necessary to resolve omissions and
integration difficulties.
§ Enables the project team to sense, anticipate, and prepare for continuing change
in an orderly manner."28

It has been shown time and again that risk to the project compounds dramatically if the
appropriate level of systems engineering rigor is not implemented. It can be expected to
a high degree of certainty that if the appropriate rigor is not followed, the project will take
longer, cost more, and will not meet the required technical specifications, ultimately
leading to a dissatisfied set of stakeholders.

The systems engineering life cycle model focuses on every phase of a project from
concept development to the capability's end-of-life state. It starts at the concept
development phase in which the context of the project, the concept of operations, a
functional definition, and system requirements definition are formed between
the systems engineer and the stakeholders. From there, a system definition
evolves. A system definition requires the elaboration of the functional view to a physical
architecture, which is further decomposed into elements and sub-element
definitions. For each of these, from the element and sub-element areas down to the
component level, the life cycle of the elements will be reviewed, and trade space and
feasibility analysis requirements will be identified for scheduling with
the project manager. A definition of the system and/or its elements is generally modeled
or simulated, to optimize the production, operations, and maintenance design. During
this development phase, the systems engineer also performs the critical activities of
arranging and managing all pertinent technical reviews and performing configuration
management on the technical areas.

It is important to note that it is the system engineer's responsibility to ensure that

the project manager, who has responsibility for the overall project, is kept informed and
is part of the approval process for all changes, reviews, etc. The project manager
performs the appropriate change management activities for cost, schedule, and scope
changes for which the systems engineer will be providing input. During the production
phase, the systems engineer will then ensure that with test, verification, and validation,
the requirements are fully met and the stakeholders are fully satisfied. This is the phase
that brings the system into service.

The system is then operated and supported, during which time the systems engineer
oversees maintenance and repair activities and upgrades, which may, if not carefully
planned and implemented, cause unintended consequences to other parts of
the system. The systems engineer will also evaluate and complete an analysis of
systemic performance issues, working with the appropriate responsible disciplines to
fully resolve and restore the system to its functioning level. Finally, upon notification of
closure requirements, the systems engineer will ensure that the integrated parts of
the system, particularly of a complex project with independent elements, are taken
down gracefully.

Within each of these overarching life cycle phases, specific detailed processes provide
the structure to collect the information that is necessary to ensure that
the system capability comes together as a whole and can function in a way that meets
the anticipated use. These processes consider all of the different disciplines that impact
the system, including all engineering disciplines, human resources, quality, acquisition
and procurement, infrastructure, operations, and maintenance. These processes will be
fully described in Chapters 3 and 4.

1.4.2 System-of-Systems Approach

Systems can be complicated or complex, but a system-of-systems is always complex.

When a project is complex, its structure differs from traditional projects in a few
predictable ways. A complex project will have some elements that have operational
and/or managerial independence from the main system. In other words, if an element of
a system can operate independent of the system, if it is not necessary for its existence
independent of the system, but when integrated into the system provides significant
value added, then it is a system-of-systems (see Figure 1.2).

A system-of-systems output can be unpredictable. Systems engineers appreciate that

the combined elements of a system may not behave as a sum of the parts, but may
demonstrate what is often referred to as "emergent behavior." Emergent behavior refers
to the inputs which, when applied together, do not equal the expected outputs (actual
outputs are different than expected) due to the effect of some unknown force. It reflects
the fact that just the simple aspect of adding multiple parts together does not in fact
predict what the additive performance is anticipated to be. There are many reasons that
this occurs. There are performance impacts from the interconnections between
elements. There may also be impacts from overlapping or duplicative associated
processes. Learning algorithms embedded in sub elements can affect performance in
unpredictable ways as well. As technology continues to evolve and become more
interrelated and complex, heightening risks and system unpredictability, research
continues in the area of understanding emergent behavior in an effort to try to mitigate
those risks and better predict system behavior.29
Figure 1.2: System-of-Systems Representation

A complex system's behavior, as a whole, does not equal the sum of its parts. It will
exhibit emergent behavior. This means that the system, its elements, and its sub-
elements can be drivers of, as well as exposed to, unpredictable outcomes as a
collective. It is the relationship between the elements that provide the expected and
desired, as well as undesirable, outcomes. This relationship between the elements
drives the risk as well. Through the current understanding of complex systems, it is
clear that when dealing with a system-of-systems project, the risk is greater, and
therefore the rigor and contingencies applied are more significant.

Systems science, complexity theory, chaos theory, and operations research all try to
explain the behavior of systems. Systems science research is a field that appeals to
the systems engineer, as it matches the cross-discipline, across-life–cycle, holistic
approach that systems engineering favors. Both systems science
and systems engineering aim to resolve complexity and enable better
predictions.30 Systems thinking, on the other hand, describes a method of thinking
through a problem and then resolving it effectively through analysis. It involves
observing a situation and then carefully assessing all of the inputs that are effecting the
situation in an attempt to determine system performance.31
From systems science it is understood that the system behavior can be explained by its
elements. The premise in systems science is that one can understand the behavior
of systems by understanding the individual parts that make up that system.32 It
proposes predictability in behavior of the system as a whole based on the behavior at
the elemental level. Chaos theory focuses on nonlinearity and the appearance of
seemingly unrelated consequences to even the smallest change. Complexity theory
emerged from systems and chaos theory and is focused on the application of structure
in organizational projects. It recognized emergent behavior but did not provide a
method for addressing the emergence. Operations research methods attempt to provide
a quantitatively rigorous prediction that can be applied to minimize risks of complex
behavior. These theoretical concepts and tools provide ideas about how to think about
complex projects. However, they do not provide structures to reduce the risks of the
complexity. This is where systems engineering adds its value.
Systems engineering did not evolve from scientific systems thinking.
As systems engineering evolved and projects became more complex, systems
engineers began looking for ways to understand and predict the behavior of
the systems. Systems engineering organizations and practitioners look to the sciences
to find ways to explain the observable, apparently nonlinear behavior and to use that
knowledge to add structure that may minimize the threats caused by the unpredictable
outcomes.

Project complexity challenges that systems engineers are attempting to address are the
areas of high risk that can often make a project unmanageable. These high-risk areas
are:
§ the constantly evolving introduction of new technologies at an ever-increasing
pace
§ dynamic conditions in the global economic and political environments that affect
suppliers and other partnering and funding situations
§ changes in strategies and priorities within partnering organizations
§ the extension of expected product life cycles through capability expansion or
revisions that keep it alive
§ radical changes in technology that cause the early demise of existing capability
that may be relied upon for overall success
§ the level of involvement of partnering organizations within the same country and
organizations within other countries
§ different contracting arrangements that are not conducive to effective systems
engineering (e.g., letters of agreement, in-kind or contributed effort, etc., which
are extremely difficult to control, particularly if the requirements being provided to
those organizations are not refined, or if they are early in the product life cycle
[research and development area—a high risk project phase])
§ cultural differences, communications challenges, and clarity in requirements and
understanding from both the stakeholders and the project as to what exactly is to
be delivered
§ the level of concurrent evolution in the elements and sub-elements, such as
redesign and modification, revisions to address errors and problems, and
adaptations to increase capabilities
The incredible moving parts of these complex projects must all be coordinated and
synchronized, organized, and synthesized if there is any hope to complete a
working system. As a design is maturing, resilience and robustness need to be built in
at every level, so unforeseen, unplanned (unknown— unknowns) disruptions to the
performance specifications of the individual parts do not catastrophically impact the
evolving system as a whole. This can be accomplished by clearly understanding the
interoperability model in which the system operates, to build in as much compatibility
and modularity as possible and to minimize the interfaces and interoperability that will
be impacted by the above actions (version changes, heavy use, design modifications,
etc.). The approach used in systems engineering to address complex projects is to use
processes that can help predict, from a synergistic, integrated perspective, any potential
emergent behavior early enough in the project to mitigate the risks. It is far too common
in system-of-systems projects to miss schedule, have significantly increased costs, and
to underperform on scope. In addition, it is common to place blame for
failing systems elements onto another part of the system without actively trying to
identify the true cause of the failure and then take responsibility for fixing that failure. It
is therefore an imperative for this type of project to actively manage
with systems engineering rigor. These processes will be fully described in Chapters
3 and 4.

The phenomenon of system-of-systems project underperformance can be attributed to

several actions. First, the organizations involved and responsible for the performance of
activities in support of this type of project needs to be motivated to the purpose,
especially as the purpose of the project is sometimes at cross-purposes with the
organization's strategic goals or vision, which may support several complex projects or
programs. A system-of-systems project requires that every organizational unit
responsible for the performance of its part of the system is in agreement with the
larger system owners as to what their responsibilities are and how they will go about
performing according to those requirements. In addition, the organization's leaders need
to accept the responsibilities of the interfaces and any breakdown that might be
attributed to the interfaces for which they are engaged. There are some risks that
cannot be mitigated from within the project. They must be addressed in a way to set
the project up for success. These include managerial and leadership constructs.

Element and sub-element systems of a defined system-of-systems project can be

bound managerially throughout a lengthy continuum from loosely coupled to tightly
coupled. If an element and sub elements of a defined system-of-systems project is
tightly coupled, then it is centrally managed, and the operations modes of the element
and sub-elements favor the system-of-systems project's central managed purpose. In
other words, if a choice must be made within an independently operating element or
sub-element organization as to priorities, the priorities of the system-of-
system project will be the highest priority. If an element and sub-elements are loosely
coupled, there will be a lack of that central management authority, no enforcement of
compliance, and standards are employed at the whim of the external organizational
leadership. This type of arrangement drives the risk on the project to the point where the
probability of successfully executing the project with the original cost, schedule, and
scope is almost nonexistent. This is because the less tightly coupled a system-of-
systems project is, the higher the level of 'volunteerism' in performing the objective is
required, and the limited control that can be effected on the project, and therefore, the
higher the risk to the project because other higher priority requirements will inevitably
and always usurp the volunteer efforts. Uncoupled or loosely coupled element and sub-
element systems generally prescribe lower priority to the needs of the system-of-
systems project and higher priority to the needs associated with performance as an
independent unit.

The fact that organizational units often do not have leadership in place that can make
decisions for the entire (cross-organizational) system-of-systems project drives the need
to have formal agreements in place, with agreed-upon measures of performance
(MOP); to have an inclusive decision-making Board in place that includes
all project organizations; and, most importantly, to have agreed-upon consequences,
ramifications, and alternative plans in the event of element and sub-element
nonperformance.

Having structures in place will increase the probability that performance and cross-
organizational issues are resolved. However, it will not entirely remove risk. This is due
to the fact that in addition to the already-existing emergent behavior risk, organizations
that are performing additional work outside of the specific project will inevitably evolve
and make impactful changes that will trigger unintended consequences for the system.
Key considerations with any system-of-systems project is the autonomy of the
constituent parts, where continued evolution continues within the unique organization,
unrelated to the system-of-systems project, but impacting it because of known or
unknown interfaces. Concepts for managing a system-of-systems project are not any
different from a complex project; however, more rigor must be implemented to decrease
the risk and increase the probability of success.

1.5 Case Study: Trans-Greenland Expedition

1.5.1 Structure and Purpose

The purpose of each case study in this book is to demonstrate that systems engineering
processes and practices are a natural controlling mechanism associated
with projects across all fields and disciplines, and that consciously being aware of the
natural alignment of activities to systems engineering processes when appropriately
applied can increase the probability of a successful outcome. Systems engineering
processes can be used in most every scenario to develop and implement a roadmap
that will lead to successful outcomes and that meet the desires of the key stakeholders.
In this next case study, although specific systems engineering activities were not
consciously planned into the project, it demonstrates the natural inclination to categorize
and organize in a methodical way in order to increase the potential of achieving
success.

The focus of this case provides an opportunity to review an activity that would not
typically be chosen to represent systems engineering such as is found in other texts;
however, it well represents standard systems engineering process use. This provides
the reader with a greater understanding of the applicability of these processes to their
own situations, which may fall outside of the typical organizational examples. All case
study quotes are from interviews held with the individual presenting the background. In
this next case, the interview was held with Sue Stockdale, and all quotes are attributed
to her.

1.5.2 Project Charter and Plan

In 1999, a team of four explorers, including British polar explorer, Sue Stockdale,
embarked on an expedition to ski coast to coast across the Greenland Ice Cap in less
than one month. Stockdale was highly qualified for the expedition. She was the "first
British woman to ski to the Magnetic North Pole in 1996 during an expedition led by
David Hempleman Adams."33 Also in 1996, she served as Raleigh International Deputy
Expedition Leader for three months in Chile and then as a member of the staff on the
ship Professor Khromov on a trip to Antarctica in support of a UNESCO expedition. In
1998, Stockdale joined an international expedition to the Geographical North Pole.34 Her
experiences on these extreme adventures served as a solid knowledge base from
which to prepare for this new expedition, which would be at least as physically and
mentally demanding as her previous experiences. "The Arctic is an extreme
environment and the price for failure can be death."35

They started on April 27th from Kangerlussuaq, Greenland, in the west coast fjords. The
terrain that would be crossed included a badly crevassed section of glacial terrain
starting at the ice sheet edge (Point 660), then a relatively flat expanse of ice cap, an
ascent to the summit in the center of the ice cap at a height of around 2600 meters
(∼8,530 ft.), and then a descent from the ice cap back to sea level to Isortoq, a remote
Inuit village on the east coast. From there they would fly by helicopter to Tasiilaq, and
then to Kulusuk before returning home.

Each adventurer's physical fitness level was critical. They would be required to hike in
the snow and ski in both downhill and Nordic styles, all while pulling a sled, commonly
referred to as a sledge or pulk, which weighed in at around ∼60 kg (132 lbs) at the start.
The sledge contained all their necessary food, fuel, clothing, and equipment. They
would also require skills in extreme Arctic camping in up to −45 degrees Celsius (−49
degrees Fahrenheit). This expedition would require them to have the strength and
mental stamina to continue under any circumstances for up to 30 days without outside
assistance.

1.5.2.1 Infrastructure
The expedition team was surrounded by the one element that they could not survive
without: water. However, they needed to boil the snow/ice in order to make it drinkable.
The fuel was the limiting factor as to how much water they would actually be able to
consume.
They did not have to carry out human waste but were allowed to bury it. That allowed a
reduction in their carry weight of materials. Carrying out human waste would have
ultimately offset the weight they reduced through food and fuel consumption, to some
degree.

1.5.2.2 Human Resources

The team members of this Trans-Greenland expedition included two males and two
females from different countries (Norway/Germany/UK). They had not met face to face
as a group prior to the expedition, although everyone knew at least one other person.

During the three-month planning phase, almost all communications (e.g., conference
calls, faxes, and emails) were preparatory and factual, focusing on the logistics and
plans of the expedition. To optimize their communications, they decided to use a
common language, English. This was a helpful strategy that facilitated the planning
process; however, the practice of only using English did not proliferate throughout all
communications, which was discovered during the expedition when it became apparent
that all of the medical supplies were identified in Norwegian—a mistake that could have
cost someone's life.

Human factors can often make or break an expedition. One person can drive everyone
to achieve great things, or he or she can bring everyone down to a point of despair.
Group cohesiveness is important, and respect for one another's contributions and gifts
is paramount. With this expedition, there was not one specific individual who held the
role of leader. The expedition was more of a collaboration of experts, which made it
slightly more complex and challenging. The team did not have enough time to develop
the knowledge of who brought what skill sets and expertise to the experience.

While everyone was trying to establish their own place in the team, conflicts emerged.
This made for some uneasy times during the first week when each individual was
pulling the maximum weight on his or her sledge, over the most treacherous terrain, and
while trying to find his or her sustainable group daily speed/distance.

Stockdale remembers, "To know what capabilities a team has, each individual must
understand their own strengths and weaknesses. This point was reinforced to me very
clearly on the expedition in Greenland. After a few days it became clear that there were
varying skiing abilities in the team. Terje Fardal, the Norwegian, was extremely strong
and fit and was always out in front. He was closely followed by the Norwegian woman
and the German photographer. That left me, the Brit, at the back struggling to keep up! I
initially felt annoyed because having completed three previous polar expeditions, I knew
the sort of pace that one must keep to. After a while my annoyance turned to despair,
as the others seemed able to cope, so I began to focus on failure rather than success
and naturally my skiing performance suffered. At the end of the day, inside the tent,
nothing was said. The next day Fardal did raise the issue of our skiing speed and as a
team we had to come up with a solution. He suggested that he could take some of the
weight from my sledge so that I could ski more quickly. I had to face up to my weakness
but in doing so I would be helping the entire team to succeed. This was a tough lesson.
It takes courage to recognize a weakness in yourself, admit it, and then do something
about it."
Over the course of the expedition, the team's natural skills did emerge. Fardal was
technical minded and practical with his hands. He was able to solve issues with broken
and/or malfunctioning equipment. The German, who was the photographer of the group,
also became the dominant navigator. Janne Sogn, the female Norwegian, was a
physical therapist and therefore naturally focused on the well-being and health of the
expedition participants. Stockdale's role was motivation and teamwork. Everyone had a
unique role that was based on his or her own natural abilities. However, that did not
mean that everything always went smoothly. Stockdale explains, "As the stress and
exhaustion of skiing up to twelve hours a day began to take hold, the behavior of the
team members changed. On one particularly tough day, after six hours of skiing in −40
degrees Celsius, my teammate suggested that we should stop because I was looking
tired. I was incensed because I felt fine, but he would not admit it was actually him.
Everyone else knew what the real issue was and so we decided to stop. Later inside the
tent when he felt relaxed, he admitted he had not been entirely honest and that he was
feeling vulnerable because he could not keep up."

One of the ideas they incorporated right from the beginning was to swap tents every
night. They thought that this one action would help to mitigate any risk associated with
social challenges brought on by the expeditions, such as a small group like this being
together for an entire month under very challenging physical conditions. This approach
would help them cope with small irritations associated with diverse personalities and
ensure that no socially detrimental behaviors, such as forming cliques or ostracizing
other team members, were able to take hold. An agreed-upon exit criteria for the
expedition was that they would all leave as friends! So, they could not let the journey
destroy their camaraderie.

1.5.2.3 Closure Phase

As a closure phase to this expedition, Stockdale set up a motivational talk less than a
week after her return to assist in her assimilation back into normalcy. Having a goal set
she felt was an important step. "Everything seems different. After spending a month in
the stark white Arctic environment, the 'greenness' of the plant life around you is just
overwhelming," says Stockdale. "There is such an unbelievable difference. You have a
new appreciation for nature."

1.5.3 Stakeholder Engagement and Communications Management

The primary stakeholders in this expedition were the expedition participants. The
success or failure of the project to cross Greenland would not have major implications
on anyone outside of the team. Other than Fardal, the other participants did not have
spouses or children anxiously awaiting their return. They had sponsors, and those
sponsors did have requirements. They wanted high-quality photos, preferably of
extreme conditions, and they wanted comments on the dehydrated food that was
provided. The manufacturer of the skis wanted feedback on the performance of the
equipment. Because of the isolation of Greenland from the wider world, where internet
availability is not common, any contact with sponsors and other stakeholders (such as
family and friends) required waiting until the expedition was complete.
1.5.3.1 Decision Management
Decision management is an important systems engineering process. This expedition
team developed an effective way to manage their decision making: following Tuckman's
"storming, forming, and norming" performance model of group performance evolution.
According to Stockdale, they first experienced some personality clashing, which then
evolved into a functioning team, and then ultimately exhibiting group norms. The team's
subject matter expertise became evident over time. However, the team then looked to
the subject matter expert to make a recommendation, which they would then agree on
or debate. Safety was more important than getting there and was always the primary
consideration. Stockdale explains, "Around day 26, the ice we were about to cross
looked iffy. We were heading downhill and it looked nondescript but very smooth and
almost too easy. The waypoints took us on a route that looked very old and more
difficult and out of the way. Upon discussion, the team agreed that although the
potential route looked sensible, it seemed safer to follow the waypoints, just as we had
done up to that point. There was no way to tell what was under that ice and it just didn't
make sense to risk it."

1.5.4 Scope Management

As this expedition was unsupported, all necessities were required to be transportable on

the sledge. Obviously, weight was a considerable issue. "When you have to drag a
sledge for a month weighing around 60 kg, you think carefully about what is inside it.
Every item is selected to be adaptable—socks become gloves, empty food bags
become rubbish sacks, even the pages of a book can have other uses!" Stockdale
exclaims.

Their basic equipment included their sledge, tent, snow pegs, sleeping bags
appropriate for the harsh negative-Celsius conditions; inflatable and foam sleeping
mattresses and repair kit; stoves, cookware, and eating/drinking cup/bowl/utensils; fuel;
maps/global positioning system(GPS)/compass and extra batteries, snow shovels,
alpine ski touring or Nordic skis and boots, ski poles, lightweight harness, jumar clip
(ascending device), climbing carabiners, lightweight ice axe, ropes and knowledge to
self-rescue from a crevasse; full winter clothing, including water and windproof jacket
and trousers, insulated down jacket, face mask, expedition gloves/mitts/hat/balaclava,
lightweight crampons, 100% UV sunglasses and/or snow goggles, insulated water
bottles, toiletries, knife, and food.

Food was the most variable element to consider for weight. It needed to be nutritious,
dense in calories, and filling, but be as light as possible. Ensuring that the food, most of
which was dehydrated, did not get wet or succumb to the environment was an
imperative. To break the monotony, the team allowed themselves the luxury once a
week of sharing a dehydrated chocolate mousse dessert, which they would look forward
to for days and then argue as to "who got to lick the spoon and the bowl!"

Fuel requirements were calculated by the number of days of the expedition plus the
number of times they would cook, along with how long they would burn the fuel at a
time, considering what was needed to cook food, melt snow for water,
and for psychological comfort and warmth.

The team also needed to have a way to cope with needed repairs as well as
communicate with the outside world, in the event of an emergency. For this they had a
satellite telephone, medical kit and emergency flares, and some basic repair materials.
In addition to this basic equipment, sponsors requested that certain untested ski
equipment be incorporated and field tested during the expedition. One expedition
participant, a Norwegian ski race manager, had expertise in this area and agreed to
carry out a comparative test of ski bases. The team also brought along kites to
experiment with, which added weight to the sledges.

1.5.4.1 Architectural Design

The architectural design of this expedition was quite simple. The Trans-Greenland
Expedition was designed as a transit of the Kangerlussuaq to Isortoq route—a well-
traveled, well-marked, and way-pointed path. There was no official trail over the ice, but
previous expeditions had supplied explicit GPS coordinates to follow.

The team would start on the west coast because it provided a port of easier access,
flights were less costly and more readily available, and gear could be shipped less
expensively. The east coast exit would require helicopter transits; the cost and schedule
risk would be minimized because the weight of their equipment would be less at the end
of the expedition, once food and fuel was used. The start was planned at the time of
year when the risk of weather and traveling over the snow and ice would be minimized.

The plan was to ski approximately eight hours a day, taking a five-minute break every
hour. The lead skier would track the time on a watch. Strict adherence to the schedule
was kept in order to keep up the progress, keep from becoming chilled, and ensure
excessive food was not consumed. All food and fuel had been carefully measured to
last up to 30 days. It was expected that during the beginning of the expedition, when the
sledges were the heaviest, the speed and distance of travel would be reduced, and that
toward the end of the expedition this time and distance could be made up.

From an overarching design-synthesis perspective, each individual activity that led up to

the whole of the experience was important. And as in most complex systems, the
outcomes can be different from what would be expected. As Stockdale explains, "The
biggest thing you must remember is that regardless of how well everything is working
that you have planned, every day you don't know what you are going to face, not even
every hour. Accept that every day is likely to be different. Things that will be static—an
hour of skiing, etc.—give a certain stability to a chaotic experience. What you will
encounter is unknown, but you can control that you will ski for an hour. Control the
controllables. Be in the moment; only control what you can control. Only focus on
yourself, because you cannot control others, or their experiences."

1.5.4.2 Integration and Interface Management

Because the expedition was self-contained, and everyone was responsible for their own
gear and progress, they had few integration and interface requirements. At the end of
the expedition at Isortoq, they needed to coordinate a flight by helicopter to Tasiilaq,
and then to Kulusuk, before returning home. There were only two flights per week out of
Isortoq. So the integration and interface requirement had to do with timing associated
with their arrival into the town. If they arrived too early, they would have to wait, and
then food and fuel became an issue. If they arrived too late, room for the team and gear
on the helicopter might already have been claimed by other expeditions, and they might
be forced to wait for the next flight. When they ended, they had two days to wait and
finally concluded the expedition on day 30, when they were transported to Tasiilaq.

1.5.5 Schedule Management

The Trans-Greenland four-person expedition took place in the April/May time frame
when the weather was more predictable and warmer but not too warm, which would
cause snow melt issues along the west coast. The team would cross the Greenland Ice
Cap, a distance of approximately 540 km (335.54 miles) in a time frame of 22 to 35
days under 24-hour daylight.

1.5.6 Acquisition Management

Supplies for the expedition were purchased by the team members and either brought
with them or shipped to the start location. Some supplies, such as fuel, required
purchase at the starting location in Kangerlussuaq because of restrictions from shipping
carriers. One team member, based in Greenland, took responsibility for obtaining the
materials required in Kangerlussuaq.

1.5.7 Risks and Opportunity Management

Risks associated with this expedition were discussed and fairly well understood based
on the team members' previous experience in arctic adventures. They monitored these
risks carefully throughout the expedition, realized some of them, and experienced some
that they had not considered as serious threats. The risks they identified fell into the
categories of weather, terrain, wildlife, gear, overall health, and speed/distance.

The 1999 April–May weather proved to be very challenging, with a major storm that hit
them with whiteouts, blizzards, and gales, in temperatures that went down to −35
degrees Celsius. Although the expedition team was appropriately equipped, the ferocity
of the storm required them to take extreme measures to survive. A number of other
expeditions attempting to cross the Inland Ice were not so lucky, suffering from the
extreme conditions and requiring evacuation.36 As Stockdale describes, "The weather
changes very fast in the Arctic, which can mean the ice opening up in front of you, or
temperatures rapidly dropping. Sometimes we had to make decisions quickly about
whether to change route, stop, or carry on, and almost always with limited information.
Being able to act on imperfect information requires an acceptance of risk and
sometimes getting it wrong. The question we always asked was, 'What is the worst that
can happen?' and if we could accept the consequence, we would take the action."

On May 9th, day 13 of the expedition, the risk tolerance would be tested. The team by
chance met up with "a Denmark/Norway two-person team who were crossing from the
east coast with dogs to collect a party on the west coast. On the highest point of the
Inland Ice they had encountered extreme weather conditions including −38 degrees
Celsius temperatures and wind. They were frostbitten and in indication of the severity of
the weather, this experienced team lost several dogs due to the low temperatures on
each leg of the journey and also ran low on food and fuel."37 During this fortuitous
encounter, they were advised to secure their tent with extra poles to guard against
collapse from the strong winds because it was not survivable if they were exposed
directly to the weather, from the lack of ability to breathe in the cold and wind. This was
disheartening news as they were heading up to the high point, at 2600 meters (∼8,530
ft.). When the storm hit with a vengeance, however, they were prepared. They took their
extra set of tent poles, putting two sets up for strength, had everyone get into that single
tent, and prepared for the worst. A full 36 hours were spent inside the tent, with little
food and water, until the storm subsided. Stockdale explained that they "just prayed that
the wind would die and the tent would remain upright."38

The first few days of the trip took the expedition team through a section with glacial
terrain and crevasses or deep cracks and fissures in the ice. These crevasses are
sometimes several meters long and must be carefully navigated. They can be extremely
deep (sometimes up to 45 meters), wide (up to 20 meters), with walls that are vertical
sheer cliffs. The four teammates were roped together, and the rope had to be kept taut.
This was in the event that one of them fell into a crevasse. The expectation was that if
one fell, then the others would arrest the fall and hold fast while the victim used his or
her personal knowledge and equipment to pull himself or herself back out. None of the
team members had experience in crevasse self-rescue, and they were only provided
instruction cards on how to take steps to survive. Stockdale's position was, "Don't rely
on the process alone! Melting snow—underwater streams—whatever it is, use previous
expedition's experiences to avoid risk."

The risks from wildlife encounters were low, although there was a potential to encounter
polar bears along the west and east coasts. The team felt that the risk was low enough
that no unique mitigation was considered necessary. In the event of an encounter, they
anticipated using their flare gun to scare the animal away. In this way, they would just
use their standard safety equipment, if necessary. In reality, the only wildlife encounters
the expedition team members had were with birds and an Arctic Fox.

Carrying minimal supplies to repair or replace and limited duplication, with the weight
restrictions, meant that gear risk was generally high. Stockdale mentions that she was
unable to obtain her ski boots, a critical piece of equipment, in sufficient time to try them
on for fit and had to ship them directly to the starting location, which was due to the
supplier having a limited supply of the boots readily available. This vastly increased the
risk to the project if they did not fit, because it would be exceptionally difficult to find a
replacement. This was a high risk, which ultimately was not realized. In addition, her
sledge was borrowed from another adventurer. His only request was that she send him
a postcard upon completion of the expedition. This suited her well; however, the sledge
was not in the condition it needed to be in for the expedition, and she was required to
commission some changes through a local saddler company, who was willing to
sponsor her on the trip in exchange for the work.

Fuel was purchased at the expedition start location and was carefully
measured for each day. The team had factored in enough fuel to cook their meals and
melt their daily water, with some left over for general heating purposes. On the first day,
one of the tops to the fuel can came loose and they lost about a half-day's worth of fuel.
The discovery that the fuel had been lost was sobering and alarming. It was
necessary for the team to make the decision to carefully monitor and use the remaining
fuel in the most conservative way so as not to run out of this critical resource before
they finished the expedition.

On the first day, two hours after analyzing the ramifications and new requirements
associated with the fuel incident, one of the shafts on a sledge broke. Both of these
individual, isolated issues actually affected the ability of the entire team to move
forward. The team worked together, and their emerging subject matter expert on
equipment, Fardal, executed a fix that would allow the team to continue.

Another piece of critical gear was the GPS. As this device required batteries, they would
only switch it on in the morning and in the evening to determine their position. The rest
of the time they would ski on the compass bearing. The compass was worn on the lead
skier and would always be visible to that person. This was an accurate and reasonable
approach, and Stockdale confirmed that they "pretty much always knew where they
were." However, they did need to keep the spare sets of batteries in their clothing next
to their bodies to keep them warm so they would not discharge.

A piece of equipment that they chose to bring but did not end up using (and which
actually added weight [and risk]) was a kite. Several past expeditions employed these
kites to cover significant distances using the wind, similar to the sport of windsurfing.
However, the use of kites would require experience and expertise in packing,
unpacking, and sailing, with the kite in an environment where the wind speeds and
direction can be unpredictable. They were unable to use the kite throughout the
expedition so, in effect, it was excess baggage.

Finally, the introduction of a significant equipment risk was made when a sponsor
requested testing of ski equipment during the expedition. The skis are critical
equipment, and the level of risk was high, even though Fardal was a professional
Norweigian ski race manager and highly qualified to carry out a comparative test of ski
bases. "Between them the party had two pairs of conventional waxable skis, one pair of
non-wax fish-scale and one pair which had a section of synthetic 'skin' let into the
base."39 The tests were performed as planned, and no risk was realized.

Without a doubt, injury, illness, or any other inability to be able to perform physically was
a major risk to the overall expedition. Even if one of the team fell victim, the others
would also be put in danger as they adapted and addressed the situation. They
managed this risk by carefully determining their ski distances, taking a break every
hour, and monitoring their health and fitness. Stockdale explained, "At the beginning, we
were skiing 22–25 km (13.67–15.53 miles), however after 11 days, we realized that at
that pace we were going to run out of food! We needed to move faster. This is difficult to
do when you already feel that you are performing at your absolute maximum. So in
order to make this change, we needed to mentally reframe our approach. We all knew
that we could ski for eight hours with five-minute breaks because we had been moving
at that pace. So we agreed to take our five-minute breaks after an hour and fifteen
minutes rather than every hour. This would extend our distance (and hours) per day in
an imperceptible way." This helped tremendously, and they were able to achieve much
longer distances, including the longest day—40 km (24.85 miles)—near the end.

Speed and distance were key success criteria of this expedition, but everyone was not
in agreement. Fardal expected to finish in 22 to 25 days. Everyone else felt that the
crossing would likely take 32 to 35 days. It ultimately took them 28 days, which they
achieved mostly due to, as Stockdale expressed, "their desire for fresh food!"

1.5.8 Quality Management

The expedition team agreed on two criteria from the outset: (1) that the experience
needed to be about the journey, and (2) that they needed to end as friends. According
to Stockdale, "It was the hardest expedition she had ever done—the sledge was heavy,
the weather challenging. Being in the Arctic reminds you how insignificant you are."

For this expedition, the measurements that mattered came in daily quantities. They
included the fuel levels, the battery levels, and the distance completed, including the
number of hours that it took to do so. It also included the confirmation of their GPS
coordinates, and the amount of food they had remaining at any given time.

1.5.9 Test, Verification, and Validation

Two test/verification/validation activities were required during the expedition.

These systems engineering processes provide the structure to assure that performance
of a project or system meets the specified purpose. In this case study, there were two
products that would be brought along. One was on the critical ski equipment. The
results of the ski performance testing were provided to the sponsor. One test with the
kites was performed during the expedition, when the weather was good; however, the
team actually ended up going slower, so they abandoned the idea of using the kite.

1.5.10 Governance

The primary changes that required agreement and implementation during the expedition
were the restriction of fuel, the increased speed/length of daily skiing, and the actions
required to survive the storm. Changes were discussed and agreed upon by all team
members, although as Stockdale described, "Who shouted the loudest, might have at
first 'won,' but over time individual expertise evolved and emerged and then those team
members became the subject matter experts that others would defer to."
1.5.11 Outcomes and Lessons Learned

The Trans-Greenland Expedition was a success and met all of its outcomes. Some of
the major lessons learned include:
§ "As we got more and more exhausted, it would have been easy to criticize one
another's weaknesses. Instead we decided to focus on strengths and make sure
we used the best person for the task, regardless of their role in the team."
§ "We learned to let go of the expectation that you had to be good at everything,
which made us really value strengths in others that were not in ourselves and
made for a far better working environment."
§ "Not to get too upset about why things happen or what people say. Don't take
things personally. There will be days when people will annoy you. Keep in mind
you have to make it work for a month, not forever. In our case, we were all there
to get this expedition to work. We didn't have to make it work forever."
§ "There is value in blind naiveté. Sometimes, you may not have any real clue as to
what all the risks are; it is worth it to move ahead with conviction and adapt along
the way. Don't get fearful. If you want to make it happen, you will find a way."
§ "When it is unclear how you can make an overwhelming change, try 'reframing'
the problem. Look for ways you can make it work."
§ "Deliver on your commitments. The expedition sponsors were very pleased
because they got some great photographs to use for their publications and valid
results from the gear tests."

1.5.12 Case Analysis

This case is an excellent example of the inclination we have as humans to describe the
activities that come naturally to us as a concise set of processes that, if we spend time
thinking through before we embark on the activity, may help secure optimal outcomes.
In this case, a project was well defined, the architecture was straightforward and well
understood, and the requirements were well established and virtually unchangeable
once the project (expedition) began. Change came in the form of decision making
based on the unknown–unknowns that were encountered during the expedition. The
actual changes that could be made were restricted to the level of remaining resources
and their own human ability and ingenuity. They adapted within their team to take
advantage of the emerging talents of the individuals. They managed their risks and their
stakeholders and delivered as promised. Most importantly, they finished safely and
within the parameters of their overall anticipated outcomes, on time, and as friends.

1.6 Key Point Summary

The focus of Chapter 1 is to describe how the discipline
of systems engineering originated and evolved into a methodology that impacts
organizational and project effectiveness. The positive effects it can have on a project,
particularly complex projects, is profound. The following are the key concepts from this
chapter. Key terms are compiled for quick reference in the Glossary.

Key Concepts
§ Systems engineering is a discipline that provides the structured processes
necessary to manage projects that require performance from many disciplines in
order to achieve their objectives.
§ Systems engineering processes can be used in most every scenario to develop
and implement a roadmap that will lead to successful outcomes and that meet
the desires of the key stakeholders.
§ The top-down systems engineering approach includes a need to understand and
correctly identify what stakeholders want, to convert that vision into a
straightforward functional architecture, and then to be able to decompose that
architecture into a physical architecture, which can be modeled and tested, in
order to create the best design to ensure that the stakeholders' expectations are
met.
§ Standards, which can be used as established methods for accomplishing tasks
within a discipline and for which quality (compliance) can be measured, is
important in promoting effectiveness, managing risks, and increasing the
probability of success in projects of all types. Implementation of sound systems
engineering practices is meant to minimize undesirable emergent behaviors and
reduce complexity.
§ Organizational structure and culture can impact the implementation of systems
engineering and the resulting successes. The implementation of systems
engineering into organizations requires commitment to the discipline, as a whole,
to be successful.
§ Although the systems engineering discipline has been established to be
applicable across all industries and includes processes written independent of
any domain, its application in different specialized domains (e.g., information
technology firms, financial industry, medical industry, etc.) might require tailoring
of the processes to address specialized vocabulary or terminology.
§ Taking the time and effort necessary to install a systems engineering discipline
into an organization has been shown, with clear and compelling evidence, to add
significant value.
§ Systems engineering views a project from the life cycle perspective—that is, the
end-to-end life of the project from conception through to closure, disposal, or
restoration to its natural or original form.
§ The discipline of systems engineering, when applied to a complex project,
requires additional discipline and rigor. A complex system's behavior, as a whole,
does not equal the sum of its parts. It will exhibit emergent behavior. This means
that the system, its elements, and its sub-elements can be drivers of, as well as
exposed to, unpredictable outcomes as a collective. A system-of-systems
approach provides the strongest defense against undesirable emergent behavior.
§ Having structures in place will increase the probability that performance and
cross-organizational issues are resolved. However, it will not entirely remove risk.
This is due to the fact that in addition to the already-existing emergent behavior
risk, people in organizations that are performing additional work outside of the
specific project will inevitably make impactful changes that will trigger unintended
consequences for the system.
 § Key considerations with any system-of-systems project is the autonomy of the
constituent parts, wherein evolution continues within the unique organization,
unrelated to the system-of-systems project, but impacting it from known or
unknown interfaces.

1.7 Apply Now

The most effective strategy in learning about systems engineering is to apply it to a
personal example. Each chapter will build on the material from the previous chapter. In
order to solidify the key material in this chapter, the reader should review the following
summary points and answer the questions that have been posed in regard to his or her
own knowledge and experience.

1. Systems engineering originally emerged from a need to achieve better project

outcomes.
Describe a project that you have completed where systems engineering
processes were not followed. What were the outcomes? How could the
outcomes have been improved with the implementation of systems engineering?
2. Interact with various engineering disciplines as they are related to a
single project or product.
Describe the disciplines that were involved in the above-stated project. What
made the involvement of other disciplines challenging?
3. Take into formal consideration the stakeholders' vision.
Describe the activities you participated in to obtain an understanding of the
stakeholders of your project and their vision. Did the outcomes match the
stakeholders' vision?
4. Form a holistic and synergistic perspective of the product.
Describe the activities that you used to obtain a holistic view of the project. What
were the challenges? Where there any synergies that could have been taken
advantage of that were not?
5. The discipline of systems engineering, when applied to a complex project,
requires additional discipline and rigor.
Describe a project that appeared to be complex. Identify any emergent behavior.
Describe what systems engineering processes you would apply to minimize the
risk if you were to complete the project today.

References
1. Liu, D. (2016). Systems Engineering: Design Principles and Models Boca Raton,
FL: CRC Press/Taylor & Francis Group.

2. Ibid.
3. SEBoK contributors. "Guide to the Systems Engineering Body of Knowledge
(SEBoK)."
SEBoK. http://sebokwiki.org/w/index.php?title=Guide_to_the_Systems_Engineering_Bo
dy_of_Knowledge_(SEBoK)&oldid=53122(accessed March 17, 2018).

4. Liu, D. (2016). Systems Engineering: Design Principles and Models. Boca Raton,
FL: CRC Press/Taylor & Francis Group.

5. Wasson, C. S. (2016). System Engineering: Analysis, Design, and Development, 2nd

Edition. Hoboken, NJ: John Wiley & Sons, Inc.

6. Ibid.

7. Kossiakoff, A., Sweet, W. N., Seymour, S. J., and Biemer, S.

M. (2011). SystemsEngineering: Principles and Practice, 2nd Edition. Hoboken,
NJ: John Wiley & Sons, Inc.

8. de Weck, O. L., Roos, D., and Magee, C. L. (2011). Engineering Systems: Meeting
Human Needs in a Complex Technological World. Cambridge, MA: The MIT Press.

9. Liu, D. (2016). Systems Engineering: Design Principles and Models. Boca Raton,
FL: CRC Press/Taylor & Francis Group.

10. Wasson, C. S. (2016). System Engineering: Analysis, Design, and Development,

2nd Edition. Hoboken, NJ: John Wiley & Sons, Inc.

11. NASA. (2007). NASA Systems Engineering Handbook. Washington, DC: NASA.
Accessed April 24, 2013, from http://www.acq.osd.mil/se/docs/NASA-SP-2007-6105-
Rev-1-Final-31Dec2007.pdf

12. Wasson, C. S. (2016). System Engineering: Analysis, Design, and Development,

2nd Edition. Hoboken, NJ: John Wiley & Sons, Inc.

13. Wingate, L. M. (2014). Project Management for Research and Development:

Guiding Innovation for Positive R&D Outcomes. Boca Raton, FL: CRC Press/Taylor &
Francis.

14. INCOSE. (n.d.) "INCOSE Principles." Accessed April 9, 2017,

from http://www.incose.org/about/principles

15. IAPM. (n.d.) International Association of Project Managers. Accessed January 8,

2018, from https://www.iapm.net/en/start/

16. APM. (n.d.) Association for Project Management. Accessed January 8, 2018,
from https://www.apm.org.uk/about-us/
17. IPMA. (n.d.) International Project Management Association. Accessed January 8,
2018, from http://www.ipma-usa.org

18. PMI. (n.d.) Project Management Institute. Accessed January 8, 2018,

from https://www.pmi.org

19. SEBoK contributors. "Guide to the Systems Engineering Body of Knowledge

(SEBoK)."
SEBoK. http://sebokwiki.org/w/index.php?title=Guide_to_the_Systems_Engineering_Bo
dy_of_Knowledge_(SEBoK)&oldid=53122(accessed March 17, 2018).

20. Walden, D. D., Roedler, G. J., Forsberg, K. J., Hamelin, R. D., and Shortell, T.
M.(eds.). (2015). Systems Engineering Handbook: A Guide for System Life Cycle
Processes and Activities, 4th Edition. INCOSE-TP-2003-002-04. Hoboken, NJ: John
Wiley & Sons, Inc.

21. SEBoK contributors. "Guide to the Systems Engineering Body of Knowledge

(SEBoK)."
SEBoK. http://sebokwiki.org/w/index.php?title=Guide_to_the_Systems_Engineering_Bo
dy_of_Knowledge_(SEBoK)&oldid=53122(accessed March 17, 2018).

22. Ibid.

23. Ibid.

24. Kossiakoff, A., Sweet, W. N., Seymour, S. J., and Biemer, S.

M. (2011). SystemsEngineering: Principles and Practice, 2nd Edition.Hoboken,
NJ: John Wiley & Sons, Inc.

25. Walden, D. D., Roedler, G. J., Forsberg, K. J., Hamelin, R. D., and Shortell, T.
M.(eds.). (2015). Systems Engineering Handbook: A Guide for System Life Cycle
Processes and Activities, 4th Edition. INCOSE-TP-2003-002-04. Hoboken, NJ: John
Wiley & Sons, Inc.

26. Ibid.

27. Kossiakoff, A., Sweet, W. N., Seymour, S. J., and Biemer, S.

M. (2011). SystemsEngineering: Principles and Practice, 2nd Edition. Hoboken,
NJ: John Wiley & Sons, Inc.

28. Harwell, Richard (ed.). (1997, August). "Systems Engineering: A Way of Thinking, A
Way of Doing Business, Enabling Organized Transition from Need to Product. "
Brochure prepared as a joint project of the American Institute of Aeronautics and
Astronautics (AIAA) Systems Engineering Technical Committee and the International
Council on Systems Engineering (INCOSE) Systems Engineering Management
Methods Working Group.
29. Walden, D. D., Roedler, G. J., Forsberg, K. J., Hamelin, R. D., and Shortell, T.
M.(eds.). (2015). Systems Engineering Handbook: A Guide for System Life Cycle
Processes and Activities, 4th Edition. INCOSE-TP-2003-002-04. Hoboken, NJ: John
Wiley & Sons, Inc.

30. Ibid.

31. Crawley, E., Cameron, B., and Selva, D. (2015). System Architecture: Strategy and
Product Development for Complex Systems. London, UK: Pearson Publishing
Company.

32. Liu, D. (2016). Systems Engineering: Design Principles and Models. Boca Raton,
FL: CRC Press/Taylor & Francis Group.

33. Smith, A. (n.d.) "Scot of the Arctic; Sue Conquers the North Pole." Daily Record.
Accessed January 29, 2014.

34. "Surprise! Cool Sue Bumps into Fellow Explorer in Arctic Wastes." (n.d.) Oxford
Mail. May 12, 1998.

35. Stockdale, S. (n.d.) "What Really Counts." Accessed January 8, 2018,

from https://www.suestockdale.com/what-really-counts-leader-striving-achieve-tough-
goals

36. Fordham, D. (2000). Greenland 1999. Alpine Journal, 105, 230—234. Accessed
March 2, 2017,
from https://www.alpinejournal.org.uk/Contents/Contents_2000_files/AJ%202000%2023
0-234%20Greenland.pdf

37. Ibid.

38. The Scotsman. (n.d.) "No Business Like Snow Business for Motivation." Accessed
January 8, 2018, from https://www.scotsman.com/lifestyle/no-business-like-snow-
business-for-motivation-1-938670

39. Fordham, D. (2000). Greenland 1999. Alpine Journal, 105, 230–234. Accessed
March 2, 2017,
from https://www.alpinejournal.org.uk/Contents/Contents_2000_files/AJ%202000%2023
0-234%20Greenland.pdf