IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART A: SYSTEMS AND HUMANS, VOL. 27, NO.
2, MARCH 1997 137
The New Taxonomy of Systems: Toward an
Adaptive Systems Engineering Framework
Aaron J. Shenhar, Senior Member, IEEE, and Zeev Bonen, Life Member, IEEE
Abstract— Systems engineering is developing rapidly, while
new standards are created and new tools are being developed.
However, the theoretical understanding and the conceptual foun-
dation of systems engineering are still in their early stages. For
example, although real-world systems exhibit considerable differ-
ences, there is very little distinction in the literature between the
system type and the description of its actual system engineering
pursuit. We suggest here a new approach to systems engineering.
It is based on the premise that the actual process of systems
engineering must be adaptive to the real system type. Using this
concept, we present a two-dimensional (2-D) taxonomy in which
systems are classified according to four levels of technological
uncertainty, and three levels of system scope. We then describe
the differences found in systems engineering styles in various
areas, such as system requirements, functional allocation, systems
design, project organization, and management style. We also
claim that adapting the wrong system and management style may
cause major difficulties during the process of system creation.
Two examples will be analyzed to illustrate this point: the famous
Space Shuttle case and one of the system development projects
we studied.
I. INTRODUCTION
T HE CREATION of complex man-made systems probably
has its historical roots in early civilization. Today, with
the development of management theory, such creations are
often linked to modern concepts of systems engineering. As
a problem-driven field, the practice of systems engineering
is rapidly growing, while more standards are being written
and additional tools are being developed. However, as a
theoretical discipline, systems engineering is quite new and
probably not well understood. Most research literature on
the systems engineering process is still young and suffers
from a scanty theoretical basis. Originated in the defense
and space industries, attempts are being made to introduce
the ideas of systems engineering into the commercial and
consumer-oriented industries. However, these attempts have
had only limited success, since managers and engineers in such
industries do not see the relevance of defense-based systems
engineering to their fields. The reason, again, is perhaps the
tenuous conceptual foundation of systems engineering.
One of the difficulties in developing a better understanding
of systems engineering is that little distinction has been made
in the literature between the system type and its strategic
type, or its systems engineering and managerial problems. For
Manuscript received April 26, 1995; revised March 20, 1996.
A. J. Shenhar is with Stevens Institute of Technology, Hoboken, NJ 07030
USA (e-mail: ashenhar@stevens-tech.edu).
Z. Bonen is with Bar-Ilan University, Besa Center for Strategic Studies,
Israel.
Publisher Item Identifier S 1083-4427(97)00134-3.
1083–4427/97$10.00  1997 IEEE
example, many influential project management and systems
engineering texts and handbooks focus on the universal set
of project management activities such as organizing, planning,
controlling, and monitoring [8], [16], and systems engineering
tasks such as requirements analysis, functional allocation, trade
studies, and system synthesis [4], [7], [14], [23]. Several
exceptions should be mentioned, however [2], [3], [6], [28],
[31]. In practice, as most project managers assert [22], there
are great differences among systems and among the processes
of their creation. Consider, for example, the case of building
a new cross-city highway, as compared to the development
of a new space vehicle, or the case of making a new model
of a small appliance such as a coffee maker, as compared
to the effort of building the English Channel tunnel. Natu-
rally, these efforts are called projects, and they may employ
some system engineering procedures; however, it is clear that
their differences outweigh their resemblance. Although some
distinctions among systems have been mentioned previously,
from a conceptual perspective, the following question still
remains open: do all systems look alike, and, for that matter,
are all systems engineering processes really the same?
This paper is based on our ongoing field study of recent
years, that has so far collected data on more than 250 projects
in the United States and Israel. Data was collected in the
defense and the commercial sector, and in a variety of in-
dustries such as aerospace, electronics, computer, mechanical,
chemical, and construction. The purpose of this study was
to identify the differences among systems, to investigate
contingencies in the processes of system creation, and to
develop a conceptual foundation for the distinction among
systems and projects. Our basic proposition is that both project
management style and systems engineering practice differ with
each specific kind of system and that management attitudes
must be adapted to the proper system type. Our methodology
was based on a combination of qualitative and quantitative
methods encompassing the process of building theory from
case study research and traditional statistical analysis based
on data accumulated through structured questionnaires.
We suggest a conceptual 2-D taxonomy for the classification
of systems. In our framework, systems are classified according
to their technological uncertainty at the moment of project
initiation and system scope which is their location on a hier-
archical ladder of systems and subsystems. After presenting
the basic model, we will describe some highlights from our
study as they relate to systems engineering. In particular,
we will outline the differences that were found in systems
engineering practices between different system types. We will
138 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART A: SYSTEMS AND HUMANS, VOL. 27, NO. 2, MARCH 1997
Fig. 1. A 2-D taxonomy of engineering projects and systems.
then use several famous projects to illustrate the virtue of
our framework. We will also discuss two cases of system
misclassification. They are the famous Space Shuttle program
and one of the system development projects in our study.
II. THE 2-D TAXONOMY
Innovation literature has often used a traditional distinction
between radical and incremental innovation [1], [3], [9], [10],
[12], [32]. Radical innovation is frequently based on new
technology, and it often results in products new to the firm
and new ventures unrelated to existing businesses. Incremental
innovation, in contrast, introduces relatively minor changes
in existing products, and generally takes the form of product
modifications, upgrades, derivatives, and line extensions. As
our studies revealed, this low–high dichotomy is insufficient
to capture the full-spectrum of engineering tasks [26]. The
first dimension is based on levels of technological uncertainty
as perceived by the organization at the time of the project’s
initiation [13]. It includes four different levels, designated as:
A—low-tech, B—medium-tech, C—high-tech, and D—super-
high-tech.
The second dimension is based on the complexity of the
system as expressed by the different hierarchies inside a
product. Since products are composed of components and
systems of subsystems, hierarchies in systems may include
many levels [5], [25], [29]. However, our findings exhibit a
predominant split between three clusters of engineering project
styles. The dimension is called system scope and it includes
the following three designated levels: assembly, system, and
array (see Fig. 1).
III. SYSTEM CLASSIFICATION, SYSTEM
CHARACTERISTICS, AND SYSTEMS ENGINEERING STYLES
How could systems be classified according to the 2-D
model, and what are the distinct system characteristics, sys-
tems engineering, and management styles used for different
kinds of systems and projects? As found, different concerns
characterize the two dimensions. In this section, we define
the different types of systems and describe the associated
managerial and systems engineering characteristics. These
characteristics are summarized in Tables I and II.
A. The Technological Uncertainty Dimension
1) Type A—Low-Tech Projects: Type A projects are those
projects that rely on existing and well-established technologies
to which all industry players have equal access. Although
such projects may be very large in scale, no new technology
is employed by the firm at any stage. Typical projects in
this category are construction, road building, and other utility
works that are common in the construction industry.
The main characteristic of this kind of project is that no
development is required and usually no system testing is
conducted. The system requirements are usually set by the
customer prior to signing the contract and before the formal
initiation of the project execution phase. System functional
requirements are usually simple and straightforward, and are
often static. The design cycle of such systems is usually
characterized by a single cycle and no design iterations are
performed, while the final design of the system is usually
frozen prior to the project initiation. The management and sys-
tems engineering style of low-tech projects can be described
as a firm and formal style, in which one should stick to the
initial design, and no changes are allowed or required.
2) Type B—Medium-Tech Projects: Type B projects rest
mainly on existing technologies; however, such systems
incorporate a new technology or a new feature of limited
scale. Typical projects of this kind include engineering efforts
of incremental innovation, as well as improvements and
modifications of existing products and systems. They may
involve new models in well-established product lines, such as
automobiles or consumer electronics; they can also include
defense projects that involve upgrades of existing systems.
Such projects are found in almost all industries including
mechanical, electronics, aerospace, and chemical.
Medium-tech projects require some development work and
some testing. Their requirements are mainly set in advance;
however, some changes may be introduced during the prod-
uct development phase. This process often involves a joint
effort of the contractor and customer. It may also require
the involvement of potential customers in the process. The
system’s required functions, although still simple, are more
dynamic than in low-tech systems, and often include more
than one mode of operation. The design cycle of such systems
would frequently consist of more than one iteration, and the
final system design is usually fixed early, normally during the
first quarter of the project. The style of these projects can be
described as moderately firm; however, it is more flexible than
in type A projects. More communication—both formal and
informal—is also required, since more tradeoffs and changes
are made.
3) Type C—High-Tech Projects: Type C projects are de-
fined as projects in which most of the technologies employed
are new, but existent—having been developed prior to the
project’s initiation. Many projects in the high-tech industry
that involve a new family of products or a new technology
generation produce products of this kind. Similarly, most new
defense development efforts would normally be characterized
as high-tech system projects, incorporating new technologies
that have been recently developed [11]. Typical industries are
electronics, computers, and aerospace.
SHENHAR AND BONEN: TOWARD AN ADAPTIVE SYSTEMS ENGINEERING FRAMEWORK
SYSTEM CHARACTERISTICS BY
Integrating several new technologies for the first time ob-
viously leads to a high level of uncertainty and risk. Type C
projects therefore require extensive development and testing
efforts, and building of several prototypes along the way.
System requirements are derived interactively with a strong
involvement of customers or potential users, and many changes
are introduced. Functional allocation is complex, and functions
are dynamic and multimodal. The design cycle of these
systems is also iterative, usually entails two or more cycles,
and the system design freeze takes place at a later stage than
in type B systems. It often occurs as late as the second quarter
or the midpoint of the project. The systems engineering and
management style of high-tech systems can be described as
moderately flexible, since many changes are expected and
are a natural part of this type of system development. It
139
TABLE I
LEVEL OF TECHNOLOGICAL UNCERTAINTY
involves intensive interaction and the use of multiple formal
and informal communication channels.
4) Type D—Super-High-Tech Projects: Type D projects are
based primarily on new, not entirely existent, technologies.
Some of these technologies are emerging, others are even
unknown at the time of the project’s initiation. The project’s
execution period is, therefore, devoted in part to the devel-
opment of new technologies, testing, and selection among
alternatives. This type of development project obviously en-
tails extreme levels of uncertainty and risk; it is relatively rare,
and is usually carried out by only a few and probably large
organizations or government agencies. Typical products are
the development of a new nonproven concept, or a completely
new family of systems, and they are usually confined to the
few leading electronics and aerospace industries. The most
140 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART A: SYSTEMS AND HUMANS, VOL. 27, NO. 2, MARCH 1997

TABLE II
SYSTEM CHARACTERISTICS BY SCOPE LEVEL

known example of such a project was the Apollo moon-landing
mission [21]; however, other smaller scale projects can also
be found in this category.
Type D projects require extensive development—both of
the new technologies and the actual system. Their develop-
ment frequently requires building an intermediate, small-scale
prototype, on which new technologies are tested and approved
before they are installed on the prototype. System requirements
are hard to determine; they undergo enormous changes and
involve extensive interaction with the customer. Obviously,
the system functions are of similar nature—dynamic, complex,
and often ambiguous. A super-high-tech system is never
completed before at least two, but very often even four,
design cycles are performed, and the final system design freeze
is never made before the second or even the third quarter
of the project. To summarize, the management and system
engineering style of these projects can be described as highly
flexible to accommodate the long periods of uncertainty and
frequent changes. Managers and engineers must live with
continuous change for a long time; they must extensively
increase interaction, be concerned with many risk mitigation
activities, and adapt a “look for trouble” mentality.
B. The System Scope Dimension
1) Scope 1—An Assembly: An assembly is a collection of
components and modules, combined into a single unit. A
typical assembly may perform a well-defined function within
a larger system, hence constituting one of its subsystems;
SHENHAR AND BONEN: TOWARD AN ADAPTIVE SYSTEMS ENGINEERING FRAMEWORK
it can also be an independent, self-contained product that
performs a single function of a limited scale. A radar receiver,
a missile’s guidance and control unit, or a computer’s hard-
disk are common examples of assemblies (subsystems) within
larger systems; compact disc players, coffee makers, washing
machines, and other household appliances can be considered
independent assemblies of the second kind. Such products
are either functioning as autonomous, or they require only
a limited amount of human interaction.
The creation of assemblies is usually performed within one
organization, and often under the responsibility of a single
functional group. It involves mostly technical people with
limited staff support or no staff at all. Systems engineering
in assemblies is mostly concerned with design related issues
such as design for manufacturability, reliability, etc., and much
less with total system organization. The core of the systems
engineering activity is the process of concurrent engineering
and the involvement of crossfunctional teams. Resources plan-
ning is relatively simple, with no more than 100 activities in
the network or PERT, and it is often performed manually.
Control is simple as well; it often involves reporting only
to top management or main contractor, with the majority of
documents being technical rather than managerial. In essence,
therefore, managing the creation of an assembly is usually
made in an informal way, using a team, or family-type style.
2) Scope 2—A System: A system is a complex collection
of interactive units and subsystems within a single product,
jointly performing a wide range of independent functions to
meet a specific operational mission or need. A system consists
of many subsystems (and assemblies), each performing its
own function and serving the system’s major mission. Radar,
computers, missiles, and, for that matter, entire aircraft are
typical examples of systems performing independent tasks.
Systems are capable of performing a complex mission, and
their use involves considerable man-machine interaction.
Organizing a system project usually involves a main con-
tractor who establishes a project management team and who
is, in turn, responsible to managing and coordinating many
internal and external subcontractors. The management team
includes technical personnel, administrative staff, and sys-
tems engineering people. The systems engineering at this
level encompasses the activities at the lower level, but it
primarily involves most of the traditional aspects, such as
system requirements, functional allocation, system synthesis,
and tradeoffs. One of the major difficulties in the system level
is the problem of system integration, and that of achieving
an overall optimized and effective system. The systems engi-
neering process at this level also requires a detailed systems
engineering management plan. Planning resources in a system
project is a complex activity. It requires advanced and com-
puterized tools, since the system development network may
include hundreds or even thousands activities. Control—both
managerial and technical—must be tight and formal, and
extensive technical and administrative documents are used,
usually according to a formal standard. For example, one of
the major concerns is configuration control and configuration
management to keep track of all the changes and detailed
baseline of design. In summary, management style of system
141
creation must be greatly formal and bureaucratic; however,
some informal relationships always develop at this level be-
tween the management team and some subcontractors and
customers.
3) Scope 3—An Array: An array is a large collection of
systems functioning together to achieve a common purpose.
Different terminology for an array may be a “supersystem,”
a “system of systems,” or the Greek word “systema,” all
being an expression of the array’s nature as a conjunction
or conglomeration of systems. Arrays are usually dispersed
over wide geographical areas and normally include systems
of many kinds. A nation’s air defense system, consisting of
early warning radar, command and control centers, combat
aircraft and ground to air missiles, is a good example of such
a super system. Similarly, the public transportation network
of a large city, or the city’s highway system, may also be
considered typical arrays. Arrays achieve wide-range missions,
based on the simultaneous functioning of many systems, and
their operation involves the association and interaction of
many people.
To manage the effort of building or even improving an
array, a program management office is usually established
as an umbrella organization which coordinates the efforts of
various system project organizations. This office is usually
staffed with legal, administrative, and finance experts who
provide the proper control in each discipline. This office
is usually less occupied however, with technical matters;
those are left to the separate projects. It is also much less
concerned with system integration. Sometimes the leading
organization is hiring another system house organization to be
the super-system integrator. Many system engineering efforts
are directed toward ensuring coordination among various
system projects. Another major concern of array projects
involve environmental and government regulations, which are
becoming critical due to the dispersed nature of the final
product. Planning such projects is done through a master
central plan, which is followed by detailed planning at the
systems level. The total number of activities may reach tens
of thousands, and project planning tools are often inadequate
for planning purposes of array projects. In fact, array projects
normally develop their own tools for planning, coordinating,
and control. Most central control in these projects involves
managerial and financial issues, and they require extensive
amounts of documentation. Finally, the management style of
such a program is primarily formal, bureaucratic, and tight,
since the central office is usually remote from the separate
projects, and most of their connections are formal and in
written form.
IV. INTEGRATING THE
TWO-DIMENSIONS—INTERACTION EFFECTS
As discussed above, when moving from lower to higher
technology systems while keeping the system unchanged, the
concerns of managers and engineers are shifting toward addi-
tional technical issues: more design cycles, more testing, and
longer periods of ambiguity in requirements and specifications.
Similarly, increased scope with constant uncertainty results
142 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART A: SYSTEMS AND HUMANS, VOL. 27, NO. 2, MARCH 1997
in additional concerns for formal administrative issues: more
planning, tighter control, more subcontracting, and more bu-
reaucracy. When, in addition, one moves simultaneously along
both dimensions, from low- and medium-tech assemblies
toward high-tech and super-high-tech systems and arrays, new
challenges must be addressed, and, as found, there is a strong
interaction effect between the two dimensions.
First, it is at this end of the model that systems engineering
is practiced at its best. The development of large multidis-
ciplinary systems, which consist of many subsystems and
components, involve the incorporation of most modern sys-
tems engineering tools and processes to optimally harmonize
an ensemble of subsystems and components. Such tools are
almost not present in low-tech or medium-tech system projects.
System engineers in high-end projects are a natural part of
the management team, and they are responsible for creating
the system’s architecture and configuration and incorporating
a multitude of technologies that must cohere in the final
design. They are also accountable for the system’s reliability,
maintainability, supportability, human factors, and economic
feasibility of the entire engineering effort.
In lower-tech systems, assembling, integrating, and testing
all subsystems into one unit is usually not an issue, since
all pieces readily fit together. Integration difficulties become
prominent, however, in the higher uncertainty type system
projects. In these projects, the successful production of the
separate subunits is one thing, while integrating them into one
working piece is another. Problems of interfaces, energy dis-
sipation, electromagnetic interference, and even lack of space,
require long and tedious processes of assembly, numerous
tests, and necessary trade-offs in many of these projects.
Finally, there are problems of configuration and risk man-
agement. Special software must be used in high-uncertainty
high-scope projects to keep track of all the decisions and
changes, and to identify the potential interactions that would
occur with each change. Such projects develop a cumulative
database for their design baseline, which, in some cases, must
be updated on a day-to-day basis. As for risks, although all
projects involve a certain level of risk, higher-scope higher-
tech projects are more sensitive to the need for sytematic
risk analysis and risk mitigation. In such projects, a risk
management procedure is usually integrated into the program.
It often involves issues of design control, personnel qualifica-
tions, procurement management, quality control, and budget
and schedule control.
V. A RETROSPECTIVE CLASSIFICATION OF FAMOUS PROJECTS
Several famous projects can be easily coded according to
this paper’s classification. For example, IBM’s project of
building the personal computer in the early 1980’s would
be characterized in this framework as a high-tech system
development project, since it was based on new but existent
technologies. Similarly, development projects of defense sys-
tems such as the Patriot missile are usually based on recent
technologies that were developed prior to the main project
effort. Such projects are normally contracted following a well-
structured procedure of defense acquisition to contractors that
demonstrate a viable capability and sufficient maturity of
technologies. Other examples of high-tech projects are the
development efforts of the first generation of videocassette
recorders introduced by JVC and Sony in the mid-1970’s
[24]. However, according to our framework, it is an assem-
bly. Lockheed’s SR-71 Blackbird reconnaissance aircraft was
initiated in the late 1950’s with no clear technology available,
and almost no known configuration [15]. Retrospectively, we
may classify it as a super-high-tech system. New York City’s
transit authority capital program of modernizing the city’s
transit infrastructure would be classified as a low-tech array
[20]; the English Channel tunnel is a medium-tech array, since
it involves some new challenges and risks of digging such a
long undersea tunnel [18]. Finally, the U.S. strategic defense
initiative, or as it was often called “Star Wars” [17], is the only
example we could site of a super-high-tech array development
program.
VI. CONSEQUENCES OF MISCLASSIFICATION
Systems engineering and program management must be
conducted according to the proper style and be adapted to
the system type. Such style should be chosen according to the
classification presented above. In that sense, one may see the
above discussion as a description of project and system “ideal
types.” When the proper style is employed, we claim, that the
chances for project success are much higher. However, when a
wrong style is utilized, or the when the system is misclassified,
this may result in substantial difficulties and delays in the
process of the system creation. For example, working on a
project perceived as type C, when it is really a type D,
may lead to problems which are beyond the competence
within the framework of the organization. It may require
higher technical skills, additional resources, longer periods of
development and testing, and much later design freeze. On
the other hand, when a project is actually a type C, and it is
wrongly perceived as type D, many overruns and difficulties
may be attributed to technology, while they are simply the
result of bad administration and weak leadership. To illustrate
some of these difficulties, the framework of this work will
be used to analyze the style and management of two system
development projects.
A. The Space Shuttle Program
On Jan. 28, 1986, the space shuttle Challenger took off
on its last mission, tragically exploding just 73 seconds into
launch. The tragedy shocked the American nation and se-
riously damaged NASA’s image, which had been built on
a history of 25 years of continuous success. The shock
of the tragedy was followed by months of investigation,
and it has been widely analyzed in many articles and other
writings. Using the model presented in this paper, we suggest
a new way of looking into the Shuttle program. It is based
on the proposition that from its inception, this ambitious
system was designed and managed while employing the wrong
management and systems engineering style. We also claim that
a proper classification at project initiation would have led to a
different systems engineering style and culture, and might have
helped eliminate many of the circumstances which eventually
led to the Challenger tragedy.
SHENHAR AND BONEN: TOWARD AN ADAPTIVE SYSTEMS ENGINEERING FRAMEWORK
The space shuttle was designed to enable man to function
in an extraterrestrial environment by using the same vehicle
on repeated flights. The program was first proposed in 1969
following the successful Apollo moon landing as an element
of an interplanetary transportation system that would enable
the United States to land a crew on Mars in the 1980’s. At
that time, however, the enthusiasm and space competition that
characterized the Apollo era had gone, and the shuttle’s initial
high-cost proposals encountered low priorities.
NASA officials discovered that their main hope of winning
congressional support for the shuttle in the atmosphere of
indifference and skepticism of that time was to emphasize
its cost effectiveness, namely, its reusability and its low
development price-tag. The notion became that this new
innovation could be built almost entirely within the state-of-
the-art, largely from off-the-shelf parts which either existed or
could be readily fabricated. The space agency’s projection of
the shuttle was simply that of a “space-adapted airplane,” and
this was expressed by saying: “We have the technology, we
have the skills, we know how to build it” [19]. Eventually,
a moderate, low-cost reusable space shuttle program was
approved and its final configuration was selected in 1972. The
shuttle’s first orbital flight was scheduled for 1978 while the
shuttle fleet was to become operational in 1979.
The program involved three major components: the orbiter,
which is powered by three main liquid hydrogen–oxygen
rocket engines, the external tank which carries the liquid fuels
for the orbiter’s main engines and is not reusable, and two
solid rocket boosters which supply the main thrust at liftoff.
It is clear now that NASA’s initial attitude toward the
space shuttle project was one which in our notation would
be classified as a type C. The belief, however, according to
which this invention could be built almost entirely within the
state-of-the-art, based on existing technologies, turned out to
be unrealistic. The problem of building such a huge vehicle
that can function effectively in two different mediums, both in
space and in the atmosphere, was too difficult to accomplish,
using the “success-oriented” attitude [30]. Eventually, the
program suffered overruns amounting to almost three years in
schedule delays and 60% in unexpected costs, all accumulated
even before the first flight.
The following list demonstrates some of the main risks that
existed at the beginning of the project:
1) It was the first vehicle which was designed to fire hy-
drogen–oxygen engines at ground level in the proximity
of an external fuel tank and to be reused again at least
50 times.
2) Although NASA had already been using solid-fuel ve-
hicles for launching small unmanned spacecraft, solid
boosters for manned flights was a technology new to
the agency.
3) Never before had such a large winged “space aircraft”
reentered the atmosphere.
4) Never before had a 75-ton glider descended through the
entire regime of hypersonic and supersonic speeds to
make a pinpoint landing 5000 miles from the point of
reentry.
143
5) NASA had no prior experience in reusable thermal
protection materials.
6) Never before had a manned space vehicle undergone its
first orbital flight with a live crew.
7) Finally, the shuttle was to become the first American
space vehicle without a crew escape system.
Developing the space shuttle turned out to be one of the
most difficult and exasperating engineering challenges of the
space age, if not the most difficult of all. Engineering and
design problems encountered during the development phase
were enormous, as illustrated by the following two examples.
First, there were problems involving the main engines.
These engines were expected to be fully developed by 1977,
but between Mar. 1977 and Nov. 1979 there were 14 engine
test failures caused by faulty seals, uneven bearing loads,
cracked turbine blades, and many other defects. Eight of
the failures resulted in fires which damaged the engines
or the test-stand. NASA’s early commitment to the initial
design, based as it was on a success-oriented strategy, made
it imperative to keep going, even when “Murphy’s law”
took over and anything that could have failed actually did.
What was missing in this part of the program was a prior,
much longer experimental phase of separate testing of the
new technology of high-pressure hydrogen–oxygen engine
components, before bringing the fully assembled engine to
the test-stand [19].
The second example relates to the thermal protection diffi-
culties. The main thermal protection of the orbiter was made of
special tiles using a new material which had never been tested
on any previous space vehicle. Its main problem appeared to be
the stability of the tiles installed. Each one of the 30 000 tiles
was different, and it had to be manually installed by skilled
craftsmen. After the first vehicle was flown from California to
Florida, thousands of tiles were missing and many others failed
the pull tests conducted to examine their stability. The thermal
protection turned out to be a nonstable add-on to the orbiter
structure, causing the agency many disruptions and continual
delays. In retrospect, this shield should have been built into
the vehicle’s structure, rather than glued in as an add-on. Had
the agency run earlier flight tests, perhaps on a smaller scale
reentry vehicle, it might have chosen a different solution to
the thermal protection problem than the one that was initially
selected [19].
These and many additional problems encountered during
the shuttle’s development phase did not change NASA’s initial
“go ahead” attitude, and in 1982 under the pressure of demands
for an intensive flight rate, the shuttle’s fleet was declared
“operational,” a state for which, in many respects, the system
was not prepared [30].
In retrospect, although at the time of the Shuttle’s approval
NASA was under severe pressure to cut costs, it seems that
the program should have been managed using a different
philosophy. In the context of this paper, a type D system
management scheme was probably more appropriate than the
one actually used. If such a philosophy had been used, then the
final configuration selection, the freezing point of the design,
and the operational declaration would have been scheduled for
a much later point, leaving open the possibilities of using other,
144 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART A: SYSTEMS AND HUMANS, VOL. 27, NO. 2, MARCH 1997
more thoroughly tested, and perhaps improved technologies. In
addition, a type D philosophy would have vested the program
managers and engineers with a different systems engineering
attitude toward risks, possible development problems, and
probability of failure, and would have created the need for
a much higher level of communication among the various
parties involved.
Returning to the Challenger tragedy, we may note here
that the presidential commission that investigated the accident
confirmed that it occurred because of a leak of a vaporized
material out of the right solid rocket booster. This leak caused a
flame that resulted in an enormous explosion. The commission
concluded that the failure was the result of faulty design of
an aft field joint, which was unacceptably sensitive to factors
such as temperature, physical dimensions, the properties of
the materials, the effects of reusability, etc. The commission
also concluded that the decision to launch the Challenger
was wrong. Those who made that decision were unaware of
the recent history of problems concerning the o-rings on the
joint and were unaware of written recommendations of the
contractor against the launch at temperatures below 53 F.
Among its recommendations, the commission suggested
performing a new design of the faulty solid rocket motor
joint and seal and forming an independent solid rocket motor
design oversight committee. The commission also recom-
mended reviewing the shuttle program management structure,
redefining the program manager’s responsibilities, reviewing
all critical items, performing hazard analyses, establishing
an office of safety, reliability and quality assurance, and
improving communication among various NASA’s units and
subcontractors.
Looking back on the shuttle’s program after the accident,
one cannot help but ask whether if NASA had adopted a
different attitude toward the program, this tragic accident
would not have occurred? Of course, we may never know.
What we may say, however, is that if the agency had initially
employed a managerial form that is closer to a type D style,
it would have scheduled many of its decisions related to
technology and configuration to a later data, and, as mentioned,
it would have adopted a different and a much more intense
communication pattern inside the program. It would certainly
not have conducted this program by using the success-oriented
approach, and would have been more keenly aware of the
possibility of trouble.
One must note however that when the space shuttle program
was approved and its budget set, NASA was under extreme
pressure from the administration to prove the system’s cost-
effectiveness and to considerably cut development expenses.
Under such circumstances, NASA abandoned its initial plan
to build a small-scale test vehicle to make certain it had
all the technology in hand before embarking on a full-scale
vehicle. But these circumstances probably also nurtured in the
agency the success-oriented type C attitude that prevailed in
the program since its inception.
B. A New Military System Development Project
The second case is a research and development project
we investigated during the course of our studies [27]. The
goal was to develop a new aiming and control system to
be installed on an existing military platform. Previous ex-
perience of the main contractor with earlier generations of
this kind of system was not sufficiently indicative of the
level of complexity and difficulty associated with this project.
Consequently, the project management team chose a traditional
management style. It turned out, however, to be a completely
new experience to the firm, particularly in terms of integrating
new technologies for the first time. As it turned out, the project
went into a serious crisis and was saved only after significant
reconstruction and a change of managerial style and attitude,
and only after substantial overruns occurred. We maintain that
a careful early analysis of the project characteristics could have
led management into a different style right from inception and
would have helped to save considerable resources.
Using our framework in retrospect, our analysis shows that
the project should have been classified as a high-tech type
C system level project. The initial management attitude that
was employed on this program could be seen, however, as
that of a medium-tech type B assembly project. Most of
these projects are usually improvement or modification efforts
entailing only minor advancements in-terms of technology,
and they involve building separate units without much regard
to their interaction. The project proved to be much more
complicated and it required, in fact, a more careful design
and an increased level of flexibility in management style as
required by type C system projects. The difference can clearly
be seen when looking at the initially scheduled time for design
freeze which was set at a very early stage of the program, and
was in sharp contrast to the actual, much later, time when the
design was finally frozen.
The second problem emerged during the system integration
phase. The integration stage was not sufficiently predicted,
and even not planned for in detail until after it had started
and initially failed. The initial assumption was that this phase
would be short and simple. The first subsystems and units
systems were indeed supplied on time, after they had been
subjected to partial, nondynamic testing. However, when as-
sembled together onto the final platform, they did not meet
many performance requirements. The consequences required
renewed system engineering, additional feasibility studies, and
redevelopment of two of the subsystems. The result was
extensive budget overrun and schedule delay.
In conclusion, the main problem lay in misclassification of
the project’s initial uncertainty and misevaluation of its scope.
In the developer’s initial estimation, the system was nothing
more than an add-on improvement to a system of a previ-
ous generation. Similarly, the complex link between various
system components, and between the system and platform,
was almost completely ignored. The failure to predict the
technical and integration difficulties resulted in a managerial
and technical crisis to which only extensive top management
support helped the project to become a success after all.
VII. CONCLUSION
Systems engineering is a wide-range activity, and it should
not be handled in the same form for all kinds of systems.
Above all, system engineering requires a proper attitude,
SHENHAR AND BONEN: TOWARD AN ADAPTIVE SYSTEMS ENGINEERING FRAMEWORK
concept, and philosophy. To design and manage systems
effectively, one must choose the appropriate concept and adopt
the right attitude. Only then can one choose the specific tools
and practices for executing the project. In this paper, we have
suggested classifying systems into four classes according to
their level of technological uncertainty and into three classes
of system scope. Each class requires a different concept and
a distinctive philosophy for effective systems engineering and
management.
The framework given here is not conclusive; it could
be further refined and investigated. For example, one may
consider additional uncertainties for the analysis of system
management—market uncertainties, for example. In this case
the uncertainty dimension may represent a different kind of
uncertainty and would require different skills. There is also
a need for more work in order to develop better and more
advanced tools for system engineering in specific classes of
systems. Researchers in the field of engineering and manage-
ment science, as well as practitioners and consultants, may
find the framework of this work useful for seeking additional
insights into the managerial differences among systems, and
for finding better and more effective ways to manage the
creation of different kinds of systems.
REFERENCES
[1] W. J. Abernathy and J. M. Utterback, “Patterns of industrial innovation,”
Technol. Rev., pp. 40–47, June/July 1978.
[2] N. Ahituv and S. Neumann, “A flexible approach to information system
development,” MIS Quart., pp. 69–78, June 1984.
[3] S. B. Blake, Managing for Responsive Research and Development. San
Francisco, CA: Freeman, 1978.
[4] B. S. Blanchard and W. J. Fabricky, System Engineering and Analysis,
2nd ed. Englewood Cliffs, NJ: Prentice-Hall, 1990.
[5] K. Boulding, “General systems theory: The skeleton of science,” Man-
age. Sci., vol. 2, pp. 197–208, Apr. 1956.
[6] J. I. Cash, Jr., W. F. McFarlan, and J. L. McKenney, Corporate
Information Systems Management. Homewood, IL: Irwin, 1988.
[7] W. P. Chase, Management of Systems Engineering. Malabar, FL:
Krieger, 1985.
[8] D. I. Cleland and W. R. King, Systems Analysis and Project Manage-
ment. New York: McGraw-Hill, 1983.
[9] R. D. Dewar and J. E. Dutton, “The adoption of radical and incre-
mental innovations: An empirical analysis,” Manage. Sci., vol. 32, pp.
1422–1433, 1986.
[10] J. E. Ettlie, W. P. Bridges, and R. D. O’Keffe, “Organizational strat-
egy and structural differences for radical vs. incremental innovation,”
Manage. Sci., vol. 30, pp. 682–695, 1984.
[11] R. J. Fox, The Defense Management Challenge: Weapons Acquisition.
Boston, MA: Harvard Business School Press, 1988.
[12] C. Freeman, The Economics of Industrial Innovation, 2nd ed. Cam-
bridge, MA: MIT Press, 1982.
[13] J. R. Galbraith, Organization Design. Reading, MA: Addison-Wesley,
1977.
[14] J. W. Hunger, Engineering the System Solution. Englewood Cliffs, NJ:
Prentice-Hall, 1995.
[15] C. L. Johnson and M. Smith, Kelly: More Than My Share of It All.
Washington, DC: Smithsonian, 1985.
[16] H. Kerzner, Project Management: A Systems Approach to Planning,
Scheduling, and Controlling, 5th ed. New York: Van Nostrand Rein-
hold, 1994.
[17] R. M. Lawrence, Strategic Defense Initiative. Boulder, CO: Westview,
1987.
[18] J. K. Lemley, “The channel tunnel: Creating a modern wonder of the
world,” PmNetwork, July 14–22, 1992.
[19] R. S. Lewis, The Voyage of Columbia. The First True Spaceship. New
York: Columbia Univ. Press, 1984.
145
[20] S. J. Manne, and L. Collins, “Reconstructuring an aging infrastructure,”
Project Manage. J., Apr. 9–24, 1990.
[21] C. R. Pellegrino and J. Stoff, Chariots for Apollo. New York:
Athenaeum, 1985.
[22] J. K. Pinto and J. G. Covin, “Critical factors in project implementation:
A comparison of construction and R&D projects,” Technovation, vol.
9, pp. 49–62, 1989.
[23] E. Rechtin, Systems Architecting. Englewood Cliffs, NJ: Prentice-Hall,
1991.
[24] R. S. Rosenbloom and M. A. Cusumano, “Technological pioneering and
competitive advantage: The birth of the VCR industry,” Calif. Manage.
Rev., vol. 24, no. 4, pp. 51–73, 1987.
[25] A. J. Shenhar, “On system properties and systemhood,” Int. J. General
Syst., vol. 18, no. 2, pp. 167–174, 1991.
[26] “From low to high-tech project management,” R&D Manage.,
vol. 23, no. 3, pp. 199–214, 1993.
[27] A. J. Shenhar and S. Alkaher, “Meeting the high technology system inte-
gration challenge: The BAT project case history,” working paper, Center
for the Development of Technological Leadership, Univ. Minnesota,
Minneapolis, 1994.
[28] L. W. Steele, Innovation in Big Business. New York: Elsevier, 1975.
[29] J. P. Van Gigch, Applied General Systems Theory, 2nd ed. New York:
Harper and Row, 1978.
[30] F. Webster, “The space shuttle Challenger incident: Showcase project,”
Project Manage. J., vol. 18, pp. 41–68, June 1987.
[31] S. C. Wheelwright and K. B. Clark, Revolutionizing Product Develop-
ment. New York: Free Press, 1992
[32] G. Zaltman, R. L. Duncan, and J. Holbek, Innovations and Organiza-
tions. New York: Wiley, 1973.
Aaron J. Shenhar (S’74–M’76–SM’86) received
five academic degrees in electrical engineering, sta-
tistics, and engineering economic systems from the
Technion–Israel Institute of Technology, Haifa, and
Stanford University, Stanford, CA.
He is now Institute Professor of Management
at Stevens Institute of Technology, Hoboken, NJ.
He has 20 years of business and management ex-
perience in a high-technology environment. In the
business world, he has managed the development
of several high-technology projects involving radar
and computer technology. As executive at Rafael, the Armament Development
Authority of Israel, he was Corporate Vice President and President, Electronic
Systems Division. Since beginning a second career in academia, he has been
involved in teaching and research in the areas of technology and innovation
management, project and product development, systems engineering, and
the management of professionals in high-technology organizations. He has
published three books and more than 40 refereed articles. He is a recognized
consultant and well known speaker in technology-based organizations such as
3M, Honeywell, Loral, the Trane Company, and Israel Aircraft Industry.
Zeev Bonen (A’51–M’56–LM’92) was born in
Jerusalem, Israel, in 1926. He received the Electrical
Engineer degree from the Technion–Israel Institute
of Technology, Haifa, in 1951, and the Ph.D. degree
in nonlinear control from Cambridge University,
Cambridge, U.K., in 1961.
From 1952 to 1979 and 1981 to 1989, he
was with Rafael, the Armament Development
Authority, Israeli Ministry of Defense. He served
as President of Rafael from 1970 to 1978 and 1982
to 1987. He has published many papers on weapons
development and on the evolution of battlefield systems. Since his retirement
in 1989 he has engaged in various consulting activities. Since 1994, he has
been Senior Research Fellow, Bar Ilan University Besa Center for Strategic
Studies, Israel.
In 1970, Dr. Bonen received the Israel Defense Prize for the development
of the Shafrir air-to-air missile.