HOW DO
COMMITTEESINVENT?

design organization criteria

by MELVIN E. CONWAY
That kind of intellectual activity which createsa useful whole from its diverse parts may becalled the design of a system. Whether theparticular activity is the creation of specifications for a major weapon system, the formation of a recommendation to meet a social challenge, or the programming of a computer, the general activity is largely thesame.
Typically, the objective of a design organization is thecreation and assembly of a document containing a coherently structured body of information. We may name thisinformation the system design. It is typically produced fora sponsor who usually desires to carry out some activity
guided by the system design. For example, a public official
may wish to propose legislation to avert a recurrence of a
recent disaster, so he appoints a team to explain the catastrophe. Or a manufacturer needs a new product and designates a product planning activity to specify what should be
introduced.
The design organization may or may not be involved in
the construction of the system it designs. Frequently, inpublic affairs, there are policies which discourage a group's
acting upon its own recommendations, whereas, in private
industry, quite the opposite situation often prevails.
It seems reasonable to suppose that the knowledge that
one will have to carry out one's own recommendations orthat this task will fall to others, probably affects somedesign choices which the individual designer is cailed upon
to make. Most design activity requires continually making
choices. Many of these choices may be more than design
decisions; they may also be personal decisions the designer
makes about his own future. As we shall see later, theincentives which exist in a conventional management environment can motivate choices which subvert the intent of
the sponsor.!

ing a design team means that certain design decisions havealready been made, explicitly or otherwise. Given any
design team organization, there is a class of design alternatives which cannot be effectively pursued by such anorganization because the necessary communication paths
do not exist. Therefore, there is no such thing as a designgroup which is both organized and unbiased.
Once the organization of the design team is chosen, it ispossible to delegate activities to the subgroups of theorganization. Every time a delegation is made and somebody's scope of inquiry is narrowed, the class of design
alternatives which can be effectively pursued is also narrowed.
Once scopes of activity are defined, a coordination problem is created. Coordination among task groups, although
it appears to lower the productivity of the individual in thesmall group, provides the only possibility that the separatetask groups will be able to consolidate their efforts into a
unified system design.
Thus the life cycle of a system design effort proceeds
through the following general stages:
1. Drawing of boundaries according to the groundrules.
2. Choice of a preliminary system concept.
3. Organization of the design activity and delegation oftasks according to that concept.
4. Coordination among delegated tasks.
5. Consolidation of subdesigns into a single design.
It is possible that a given design activity will not proceed straight through this list. It might conceivably reorganize upon discovery of a new, and obviously superior,
design concept; but such an appearance of uncertainty is
unflattering, and the very act of voluntarily abandoning acreation is painful and expensive. Of course, from thestages of design
The initial stages .of a design effort are concerned morewith structuring of the design activity than with the systemitsel£.2 The full-blown design activity cannot proceed until
certain preliminary milestones are passed. These include:
1. Understanding of the boun9aries, both on the design
activity and on the system to be designed, placed by
the sponsor and by the worltl's realities.
2. Achievement of a preliminary notion of the system'sorganization so that design task groups can be meaningfully assigned.
We shall see in detail later that the very act of organiz1 A related, but much more comprehensive discussion of the behavior ofsystem-designing organizations is found in John Kenneth Galbraith's,
The New Industrial State (Boston, Houghton Mifflin, 1967). See especially
Chapter VI, "The Technostructur<! ."2 For o discussion of the problems which may arise when the design
activity takes the form of o project in a functional environment, see C. J.
Middleton, "How to Set Up o Project Organization," Harvard Business
Review, March-April, 1967, p. 73.

28

Dr. Conway is manager, peripheral systems research, at
Sperry Rand's Univac Div.,
where he is working on recognition of continuous speech. He
has previously been a research
associate at Case Western Reserve Univ., and a software
consultant . . He has an MS in
physics from CaiTech and a
PhD in math from Case.

:C»ATAMATION

vantage point of the historian, the process is continually
repeating. This point of view has produced the observationthat there's never enough time to do something right, butthere's always enough time to do it over.

the designed system
Any system of consequence is structured from smaller
subsystems which are interconnected. A description of asystem, if it is to describe what goes on inside that system,must describe the system's connections to the outside
world, and it must delineate each of the subsystems andhow they are interconnected. Dropping down one level, we
can say the same for each of the subsystems, viewing it as asystem. This reduction in scope can continue until we aredown to a system which is simple enough to be understood
without further subdivision.
Examples. A transcontinental public transportation system consists of buses, trains, airplanes, various types ofright-of-way, parking lots, taxicabs, terminals, and so on.
This is a very heterogeneous system; that is, the subsystems are quite diverse. Dropping down one level, an airplane, for example, may possess subsystems for structure,
propulsion, power distribution, communication, and payload packaging. The propulsion subsystem has fuel, ignition, and starting subsystems, to name a few.
It may be less obvious that a theory is a system in thesame sense. It relates to the outside world of observed
events where it must explain, or at least not contradict,them. It consists of subtheories which must relate to eachother in the same way. For example, the investigation of an
airplane crash attempts to produce a theory explaining acomplex event. It can consist of subtheories describing thepath of the aircraft, its radio communications, the mannerof its damage, and its relationship to nearby objects at thetime of the event. Each of these, in turn, is a story in itself
which can be further broken down into finer detail down to
the level of individual units of evidence.
Linear graphs. Fig. 1 illustrates this view of a system asa linear graph-a Tinker-Toy structure with branches (thelines) and nodes (the circles). Each node is a subsystem
which communicates with other subsystems along thebranches. In turn, each subsystem may contain a structure
which may be similarly portrayed. The term interface,which is becoming popular among systems people, refers to
the inter-subsystem communication path or branch represented by a line in Fig. 1. Alternatively, the interface is theplug or flange by which the path coming out of one nodecouples to the path coming out of another node.

dictable relationship between the graph structure of adesign organization and the graph structure of the system
it designs? The answer is: Yes, the relationship is so simple
that in some cases it is an identity. Consider the following"proof":
Let us choose arbitrarily some system and the organization which designed it, and let us then choose
equally arbitrarily some level of complication of thedesigned system for which we can draw a graph.
(Our motivation for this arbitrariness is that if we
succeed in demonstrating anything interesting, it willhold true for any design organization and level ofcomplication.) Fig. 2 ( p. 30) shows, for illustration
purposes only, a structure to which the following statements may be related.
For any node x in the system we can identify adesign group of the design organization which designed x; call this X. Therefore, by generalization ofthis process, for every node of the system we have arule for finding a corresponding node of the design
Figure 1
The system, shown at the top,communicates with the outside
world through the three interfaces 1, 2, and 3. The middle
figure shows the major subsystems, two of which are shown indetail at the bottom.

1

Interfaces~4

relating the two
The linear-graph notation is useful because it provides
an abstraction which has the same form for the two entities
we are considering: the design organization and the system
it designs. This can be illustrated in Fig. 1 by replacing thefollowing words:
1. Replace "system" by "committee."
2. Replace "subsystem" by "subcommittee."
3. Replace "interface" by "coordinator."
Just as with systems, we find that design groups can beviewed at several levels of complication. The Federal Government, for example, is an excellent example of a designorganization with enough complexity to satisfy any systemengineer. This is a particularly interesting example forshowing the similarity of the two concepts being studied
here because the Federal Government is both a designorganization (designing laws, treaties, and policies) and adesigned system (the Constitution being the principal preliminary design document) .
A basic relationship. We are now in a position to address
the fundamental question of this article: Is there any pre-April 1968

.Subsystem a

Subsystem b

Fig. 1organization. Notice that this rule is not necessarily
one-to-one; that is, the two subsystems might havebeen designed by a single design group.
Interestingly, we can make a similar statement
about branches. Take any two nodes x and y of thesystem. Either they are joined by a branch or they arenot. (That is, either they communicate with eachother in some way meaningful to the operation of thesystem or they do not.) If there is a branch, then thetwo (not necessarily distinct) design groups X and Y
which designed the two nodes must have negotiatedand agreed upon an interface specification to permit
communication between the two corresponding nodesof the design organization. If, on the other hand, there
is no branch between x and y, then the subsystems do
not communicate with each other, there was nothing
for the two corresponding design groups to negotiate,

29

COMMITTEES ...
and therefore there is no branch between X and Y. *What have we just shown? Roughly speaking, we havedemonstrated that there is a very close relationship between the structure of a system and the structure of theorganization which designed it. In the not unusual casewhere each subsystem had its own separate design group,
we find that the structures (i.e., the linear graphs) of the
DESIGN ORGANIZATION~3First, choose asystem (to left)
and its designer(to right).

1

Then choose some levelof complication within
the system (below).

point. In the middle fifties, when the prototypes of theselanguages appeared, their compilers were even more cumbersome objects than the giant (for then) computers whichwere required for their execution. Today, these translators
are only historical curiosities, bearing no resemblance indesign to today's compilers. (We should take particular noteof the fact that the quantum jumps in compiler design
progress were associated with the appearance of new groupsof people on territory previously trampled chiefly by computer manufacturers-first it was the tight little university
research team, followed by the independent softwarehouse.)
If, then, it is reasonable to assume that for any system
requirement there is a family of system designs which willmeet that requirement, we must also inquire whether the
choice of design organization influences the process of
selection of a system design from that family. If we believe
our homomorphism, then we must agree that it does. To
the extent that an organization is not completely flexible inits communication structure, that organization will stampout an image of itself in every design it produces. The
larger an organization is, the less flexibility it has and themore pronounced is the phenomenon.
Examples. A contract research organization had eightpeople who were to produce a COBOL and an ALGOL compiler. After some initial estimates of difficulty and time, fivepeople were assigned to the COBOL job and three to the
ALGOL job. The resulting COBOL compiler ran in five phases,
the ALGOL compiler ran in three.
Tvvo militarv services were directed bv their Commanderin-Chief to de'velop a common weapon ~ystem to meet their
DESIGN OR@ANIZATION

Coordinator

Common logistics

Common logistics agency

Subsystem a- Figure 2
Here is an illustration of the strong relationship between the structure (graph) of a system (left} and thestructure of the organization which designed it (right).

Fig. 2

design group and the system are identical. In the casewhere some group designed more than one subsystem wefind that the structure of the design organization is acollapsed version of the structure of the system, with thesubsystems having the same design group collapsing into
one node representing that group.
This kind of a structure-preserving relationship between
two sets of things is called a homomorphism. Speaking as amathematician might, we would say that there is a homomorphism from the linear graph of a system to the linear
graph of its design organization.

Weapons special
to Service A~*This claim may be viewed several ways. It may be trivial, hinging on
the definition of meaningful negotiation. Or, it may be the result of theobservation that one design group almost never will compromise its own

design to meet the needs of another group unless absolutely imperative.

30

3.a.

Service A

Service B

A Weapon System

Application

user'sprogranuners

programUser
Mfr.

SystemSystemsoftwareprograrrnners

SystemEngineers

hardware3b.

systems image their design groups
It is an article of faith among experienced system designers that given any system design, someone someday
will find a better one to do the same job. In other words, it
is misleading and incorrect to speak of the design for a
specific job, unless this is understood in the context ofspace, time, knowledge, and technology. The humility
which this belief should impose on system designers is the
only appropriate posture for those who read history or
consult their memorie~.
The design progress of computer translators of programming languages such as FORTRAN and COBOL is a case in

Weapons special
to Service B

Figure 3

A Computer System

Two examples of identity of structure

between a system and its design organization.

Figs. 3a and 3b

respective needs. After great effort they produced a copy of
their organization chart. (See Fig. 3a.)Consider the operating computer system in use solving aproblem. At a high level of examination, it consists of threeparts: the hardware, the system software, and the application program. (See Fig. 3b.) Corresponding to these subsystems are their respective designers: the computer manufacturer's engineers, his system programmers, and theuser's application programmers. (Those rare instanceswhere the system hardware and software tend to cooperaterather than merely tolerate each other are associated with
CIRTRMRTICN

manufacturers whose programmers and engineers bear· asimilar relationship. )system management
The structures of large systems tend to disintegrate during development, qualitatively more so than with small
systems. This observation is strikingly evident when applied to the large military information systems of the last
dozen years; these are some of the most complex objects
devised by the mind of man. An activity called "systemmanagement" has sprung up partially in response to thistendency of systems to disintegrate. Let us examine theutility to system management of the concepts we havedeveloped here.
Why do large systems disintegrate? The process seems tooccur in three steps, the first two of which are controllable
and the third of which is a direct result of our homomorphism.
First, the realization by the initial designers that thesystem will be large, together with certain pressures intheir organization, make irresistible the temptation to assign too many people to a design effort.
Second, application of the conventional wisdom of management to a large ddign organization causes its communication structure to disintegrate.
Third, the homomorphism insures that the structure of
the system will reflect the disintegration which has occurred in the. design organization.
Let us first examine the tendency to overpopulate adesign effort. It is a natural temptation of the initial designer-the one whose preliminary design concepts influence the organization of the design effort-to delegatetasks when the apparent complexity of the system approaches his limits of comprehension. This is the turning
point in the course of the design. Either he struggles toreduce the system to comprehensibility and wins, or else heloses control of it. The outcome is almost predictable if
there is schedule pressure and a budget to be managed.
A manager knows that he will be vulnerable to thecharge of mismanagement if he misses his schedule without
having applied all his resources .. This knowledge creates astrong pressure on the initial designer who might prefer towrestle with the design rather than fragment it by delegation, but he is made to feel that the cost of risk is too highto take the chance. Therefore, he is forced to delegate inorder to bring more resources to bear.
The following case illustrates another but related way inwhich the environment of the manager can be in conflictwith the integrity of the system being designed.
A manager must subcontract a crucial and difficult design task. He has a choice of two contractors, a small neworganization which proposes an intuitively appealing approach for much less money than is budgeted, and an
established but conventional outfit which is asking a more
"realistic" fee. He knows that if the bright young organization fails to produce adequate results, he will be accused ofmismanagement, whereas if the established outfit fails, itwill be evidence that the problem is indeed a difficult
one.
What is the difficulty here? A large part of it relates to
the kind of reasoning about measurement of resources
which arises from conventional accounting theory. According to this theory, the unit of resource is the dollar, and all
resources must be measured using units of measurement
which are convertible to the dollar. If the resource ishuman effort, the unit of measurement is the number ofhours worked by each man times his hourly cost, summed
up for the whole working force.
One fallacy behind this calculation is the property oflinearity which says that two men working for a year or one
hundred men working for a week (at the same hourly cost

April 1968

per man) are resources of equal value. Assuming that two
men and one hundred men cannot work in the same organizational structure (this is intuitively evident and will be
discussed below) our homomorphism says that they will
not design similar systems; therefore the value of theirefforts may not even be comparable. From experience weknow that the two men, if they are well chosen and survive
the experience, will give us a better system. Assumptions
which may be adequate for peeling potatoes and erecting
brick walls fail for designing systems.
Parkinson's Law 3 plays an important role in the overassignment of design effort. As long as the manager's prestige
and power are tied to the size of his budget, he will be
motivated to expand his organization. This is an inappropriate motive in the management of a system design activity. Once the organization exists, of course, it will be used.
Probably the greatest single common factor behind many
poorly designed systems now in existence has been theavailability of a design organization in need of work.
The second step in the disintegration of a system design-the fragmentation of the design organization's communication structure-begins as soon as delegation has
started. Elementary probability theory tells us that the
number of possible communication paths in an organization is approximately half the square of the number ofpeople in the organization. Even in a moderately smallorganization it becomes necessary to restrict communication in order that people can get some "work" done. Research which leads to techniques permitting more efficient
communication among designers will play an extremely
important role in the technology of system management.
Common management practice places certain numericalconstraints on the complexity of the linear graph which
represents the administrative structure of a military-styleorganization. Specifically, each individual must have at
most one superior and at most approximately seven subordinates. To the extent that organizational protocol restricts communication along· lines of command, the communication structure of an organization will resemble its
administrative structure. This is one reason why militarystyle organizations design systems which look like theirorganization charts.
conclusion
The basic thesis of this article is that organizations
which design systems (in the broad sense used here) areconstrained to produce designs which are copies of thecommunication structures of these organizations. We haveseen that this fact has important implications for the management of system design. Primarily, we have found acriterion for the structuring of design organizations: a design effort should be organized according to the need forcommunication.
This criterion creates problems because the need tocommunicate at any time depends on the system concept
in effect at that time. Because the design which occurs firstis almost never the best possible, the prevailing system
concept may need to change. Therefore, flexibility of organization is important to effective design.
Ways must be found to reward design managers forkeeping their organizations lean and flexible. There is needfor a philosophy of system design management whiCh is notbased on the assumption that adding manpower simply
adds to productivity. The development of such a philosophy promises to unearth basic questions about value ofresources and techniques of communication which willneed to be answered before our system-building technology. can proceed with confidence.
•
8 C. Northcote Parkinson, Parkinson's Law and Other Studies in Administration (Boston, Houghton Mifflin, 1957).

31