MXT. LIBRARIES - DEWEY
Dewey
HD28
.M414
Electronic communication and
new
A
organizational forms:
coordination theory approach
by
Kevin Crowston
CCS TR #175,
Sloan
WP # 3719-94
August 1994
:.;ao&achusctts iimstitute
of technology
DEC 01
1994
LIBRARIES
Electronic
communication and new organizational forms:
A coordination theory approach
Keuin Crcrwstorr^
School of Business Administration
University of Michigan
August
^
Author's present address:
17,
1994
School of Business Administration
University of Michigan
701
Tappan
Ann Arbor, MI
48109-1234
Electronic mail (internet):
crowston@umich.edu
Telephone:
+1 (313) 763-2373
+1 (313) 763-5688
Fax:
USA
Electronic
communication and new organizational forms:
A coordination theory approach
Abstract
Describing and categorizing organizational forms remains a central problem in
organization theory. Unfortunately defining organizatic»\al form poses numerous difficulties.
Rather than attempting to categorize entire organizations, researchers have instead suggested
focusing on
how
particuleu- tasks are
performed,
i.e.,
adopting the process as the unit of analysis.
An important practical problem then is to identify processes that would be suitable for
performing a desired
task, especially processes that are
enabled by the use of
new electronic
media and other forms of information technology.
Coordination theory provides an approach
to the
study of processes. In
form a process takes depends on the coordirution mecharusms chosen
among tasks and
to
tiiis
view, the
manage dependences
resources involved in the process. These mechanisms are primarily information-
processing and so the use of
new media will
particularly affect their cost, perhaps changing
which are preferred.
In this paf)er,
I
use coordination theory to analyze the software change process of a large
mini-computer manufacturer and suggest alternative ways the dependoices involved could be
managed and thus
alternative forms the process could take.
for task assignment, resource sharing
Mechanisms analyzed include those
and managing dependences between modules
of code.
The
organization studied assigned problem reports to engineers based on the module which
appeared to be in
alternative
error; engineers specialized in particular
mechanisms including assignment
modules. The framework suggests
to generalists
based on workload or based on
market-like bids. Modules of code were not shared, but rather
"owned" by one engineer, thus
reducing the need for coordination; a more elaborate code management system would be
Draft of 8/17/94
3
required
if
multiple engineers needed to
work on the same modules.
dependences between modules informally, based on
their personal
Finally, engineers
managed
knowledge of which
otiier
engineers used their code; alternatives include formally defining the interfaces between modules
and tracking
their users.
Software bug fixing provides a microcosm of coordination problems and solutions.
Similar coordination problems arise in most processes
and are managed by a similar range of
mechanisms. For example, diagnosing bug reports and assigning them to engineers
interesting parallels to diagnosing patients
and assigning them
While the case presented does not formally
test
may have
to specialists.
coordination theory,
it
does
illustrate the
potential of the coordination theory for exploring the space of organizational forms. Future
includes developing
more rigorous techniques
for
such analyses, applying the techniques
work
to a
broader range of processes, identifying additional coordination problents and mechanisms and
developing tools for collecting and comparing processes and perhaps automatically suggesting
potential alternatives.
Draft of 8/17/94
1
Introduction
IDescribing
and categorizing organizational forms remains a
organization theory
(e.g.,
McKeivey, 1982; Rich, 1992; Sanchez,
centred
problem
in
1993). Unfortunately, defining
organizatioruil
form poses numerous
characteristics,
such as production technology (Perrow, 1967; Woodward, 1980), as being too
simplistic.
difficulties.
Rich (1992)
criticizes typologies
based on single
He suggests instead viewing organizational form as a multi-dimensional construct and
grouping together organizations that share similar sets of characteristics. As McKeivey and
Aldrich (1983) point out, however, most large organizations are actually mixtures of different
forms.
Mohr (1982)
describes organizational structure as, "multidimensional
have constant meai jig and therefore
.
In short,
an
to serve as a
entire organization
is
good
theoretical construct" (p. 16).
too aggregate a level of analysis for meaningful
comparison. Instead, researchers have suggested focusing on
i.e.,
how particular tasks are performed,
adopting the process as the unit of analysis (Mohr, 1982; Abbott, 1992,
rather than listing
might compare
ways
in
—too inclusive to
p. 428-9).
For example,
which General Motors and Ford are alike or different, researchers
their processes for designing
automobiles or even more specific subprocesses. The
problem thus becomes, not what form does an organization have, but what process does
use to
it
accomplish particular tasks?^
Given a task being
f)erforTned
identify other processes that
scramble
more
to
adapt
would
by an organization, an important
also be suitable for performing that task.
to increasingly frequent
pressing. For example, a
environmental changes,
manager may
this
these goals into concrete organizational changes
(e.g.,
still
problem
is to
As compeuiies
question has become even
realize that the survived of his or her
depends on reducing time-to-market and improving quality, but
^
practical
find
it
company
difficult to translate
as part of a business process redesign effort
Such an analysis presumes, of course, that organizations perform tasks. This presumption can
be questioned, but it seems clear that many organizations have at least a stated purpose that
would be preserved
Draft of 8/17/94
in a reorganization.
& Short, 1990; Hammer, 1990; Harrison & Pratt, 1993]). Other managers may be
[Davenport
concerned with making effective use of the
information technology
organizational forms
media
(IT), electronic
become
billions of dollars invested in different
in particular,
all
what kinds of
v^ronder
possible as the historic constraints
information processing are relaxed. Underlying
issue:
and
on communications and
of these questions
is
ttw central theoretical
how can we represent organizatioTvil processes in a way that allows us
contrast
them or
to
kinds of
to
compare and
design new ones (Malone, et al., 1993)?
CcHisider the software problem (bug) reporting process: customers having problems with
a piece of software report the problems to
some kind
of solution.
One company 1
its
develof>ers,
who (they hope) will eventually provide
studied, the developer of a nnini-computer operating
system, has an elaborate process to receive problem reports,
identify (for novel problems)
filter
which modules of the system are apparently
reports to the software engineers responsible for those modules.
might develop a workaround
patch
it,
(i.e.,
to
avoid the problem; the
a change to part of the system) to
integrate
it
the problem.
into the total
out reports of
fix
it.
final
The patch
system and, eventually, send
(A more detailed description
it
knovm
at fault
problems,
and route the
Along the way, an engineer
software engineer might develop a
is
then sent to other groups
to the
who test
who originally had
customers
of this process appears below.)
Why is the process structured this way, with finely divided responsibility for different
parts of the process?
companies,
What different forms
are there for this process?
we will observe a wide variety of approaches
to this
sometimes called change ownership (Swanson and Beath,
arrives,
it is
module and
simply cissigned to the next
free engineer.
task assignments are therefore based
examine many processes,
individuals or firms
Draft of 8/17/94
we examine many
same software bug
process. For example, other companies (and even other parts of the
is
If
1990):
company
I
studied) use
when a problem
Any engineer can,
fixing
report
in principle, fix
on workload rather than
any
specialization.
we will see an even \vider range of possible forms.
what
If
we
For example,
may be generalists, performing a wide variety of tasks, or specialists.
6
performing only a few. Tasks
may be assigned
to actors within a single orgaiuzation, as
fixing; others take place in the market, as witti auditing, consulting
variety of services;
with bug
and an increasingly wide
and increasingly cor]x>rations are forming networks
for allocating
work
(e.g.,
Powell, 1990).
When we begin to systematically compare these processes, however,
the organizations are performing essentially the
required. For example,
bug, write code for a
broadly,
all
same
software companies that respond to
the fix
fix, test
and
integrate
it
with
same basic
bug reports need
tfie rest
performs them and
here there are
how
steps are
of the system. Looking
more
steps are
tihe
how these large abstract tasks are decomposed,
tfiey are assigned, that
common patterns:
If
to diagnosis the
many engineering change processes have similar steps. While the general
same, organizations differ in imjx)rtant details of
who
task, typically the
patterns emerge.
is,
similar problems arise
in
how these tasks are coordinated. Even
and are managed by
similar coordination
mechanisms.
2
A coordination theoiy approach to organizational form
To study coordination, 1 use
the
model presented by Malone and Crowston
(1994),
who
define coordination as "managing def)endences between activities" (p. 90) and coordination
theory as the
still
developing body of "theories about
kinds of systems"
(p. 87).
performing interdependent
how coordination can occur in diverse
Malone and Crowston analyze group action
activities to
resources of various types. For
achieve ^oa/s. These activities
example, in the case of software bug
customers and various employees of the software company^;
in terms of actors
may also require or create
fixing, the actors are the
activities include those
mentioned
above. The goal of the process in this case appears to be eliminating problems in the system, but
3
In
some cases,
13); for
which
a group of individuals
example,
it
interacts
Draft of 8/17/94
may be represented by a
single actor (Abell, 1987, p.
to simplify the cinalysis of a particular subunit, the odier
might all be represented as
collective actors.
subunits with
—such as appearing responsive
alternative goals
Finally, resources include the
problem
time, software patches, source code
In
tfiis
that constrain
of
tfie
customer requests
reports, information
—could also be analyzed^.
about knowrn problems, computer
and so on.
view^, actors in organizations face coordination problems arising
how
problem
to
tasks can be performed. These dependerKes
(e.g.,
compwients of a system may
of changes that can be
made
to a single
interact
may be iiiherent in die structure
with each other, constraining the kinds
component) or they may
result
from decomposition of the
goal into activities or the assigrunent of activities to actors and resources
working on the same component
face constraints
from dependences
(e.g.,
two engineers
on the kind of changes they can make without
interfering with each other).
To overcome
ttiese
coordination problems, actors must perform additional
form of coordination mechanisms. For example, a software engineer planning
in a
computer system must check
any necessary changes
module must each be
be quite
specific,
to
that the changes will not affect other
modules
that will be affected;
such as a code management system
or other resources. Note that
mechanisms
modules or arrange
for
two engineers working on the same
to control
to
in the
change one module
careful not to overwrite the other's changes. Coordination
general, such as hierarchical or market
changes
mechanisms may
to software,
or quite
manage assignment of activities
to actors
many coordination mechanisms are primarily information
ordering or picking tasks, negotiating with other actors or informing
processing activities
(e.g.,
them about planned
activities)
^
to
work
and thus
potential candidates for support
from electronic media.
In taking this approach, we adopt Dennet's (1987) intentional stance: since there is no
completely reliable way to determine someone's goals (or if indeed tiiey have goals at all),
we, as observer"^, can only impute goals to the actors. For instance, in analyzing markets, we
might as observers regard the goal to be achieved as one of optimally allocating resources to
maximize consumer utilities (e.g., Debreu, 1959). Even though no single individual in the
market necessarily has this goal, observers might evaluate market coordination in terms of
how well
it is
Draft of 8/17/94
achieved.
In general, there
may be several coordination mechanisms that could be used
a given dependence; different organizations
to address
may use different mecharusms to address
similar
problems, thus resulting in a different organizational form. Given a particular organization
performing some task then, one
way to generate alternative processes is to idaitify the particular
depoidences and coordination problems faced by the orgai\ization and consider what alternative
coordination mechanisms could be used to
manage them. For example, Lawler (1989) argues
the functions of an organization's hierarchy,
many of which are ways of coordinating the actions
of the lower levels, could be accomplished in other ways, such as
systems or
that
new patterns of information distribution.
work design, information
(Of course, there are also
many non-
coordinating functions of the hierarchy, such as motivating or coaching workers that must be
considered before makir ^ such chtinges.)
2.1
•
Implications of coordination theory for the study of electronic media
and organizational form
Coordination theory provides a useful theoretical framework for analyzing the
implications of
new communications
mechanisms (and thus
in
media
(cuid
An organization's choice of coordination
our view, the organizational form)
determined) by their relative
electronic
technologies.
costs,
which
in turn
is
affected (although not
depends on the technology available. The use of
other kinds of IT) will change the relative cost of coordination mechanisms,
making new processes
feasible or desirable. Coordination theory thus provides a conceptual link
between organizational form and the use of communication technology.
For task assignment, communications technology makes
it
easier to gather information
about available resources and to decide which to use for a particular
task.
At a macro
level,
Malone, Yates and Benjamin (1987) suggest that decreased coordination costs favour more
extensive use of markets, which usually have lower costs but require
instead of vertical integration, which
Draft of 8/17/94
make
the opposite trade-off.
more coordination
activities,
Avoiding duplicate tasks
is
difficult if there are
working on the same task. For example,
by many users;
tt\e
company would
in a software
numerous workers who could be
company, the same bug is may be reported
prefer to not diagnose
and solve this problem repeatedly.
Past solutions to this problem include ceitralizing the workers to
easier, specializing
workers so diat identical tasks are all assigned
accepting the duplication.
iitformation about tasks
make exchange of information
to the
same worker or simply
New alternatives include an information system containing
and known
solutions or communications technologies that can cheaply
broadcast questions to a large community, such as a computer conferoicing system (Finholt and
Sproull, 1990).
Just-in-time delivery of components, a
between suppliers and
users,
up-to-date information about
on hand
is
in large part a
new way to manage prerequisite dependences
communications innovation: new ways
what components should be delivered replace keeping
to transmit
inventories
in the plant.
For sharing information resources, commurucations and database technology
themselves provide the necessary coordination. For example, coordination
is
may
necessary
if
multiple tasks need access to information stored on paper (a shared resource dependence).
therefore be desirable to have a single individual handle
For example, a conference room schedule
is
possibility of conflicting reservations being
every time a reservation
is
all
may
the data to simplify the coordination.
usually kept in a central location because of the
made and
the prohibitive cost of updating copies
made. Data such as customer accounts or
handled similarly, resulting
It
in specialization of actors
credit information are often
based on their access to information.
A database and communications system enable multiple workers to access and make
changes
to the data.
change the basis
By empowering workers and reducing the need
for assigning tasks;
tasks can be assigned
on
criteria
workers are equally capable of performing a
can
task,
then
such as workload or the customer involved rather than on
availability of data or specialization.
Draft of 8/17/94
if all
for specialization, IT
Such a change was made
to the Citibank letter of credit
10
process
when a group of specialists, each performing a
by generalists
2.2
A
single step of the process,
who handle the entire process for particular customers (Matteis,
were replaced
1979).
typology of coordination mechanisms
As a guide
to
such analyses, Crowston (1991) presents a preliminary typology of
dependences and associated mechanisms. The main dimension of the typology is the type of
objects involved in the dependence, either tasks (goals
and
activities
from Malone and
Crowston's (1994) framework) or resources used or created by tasks (irKluding the effort of the
There are therefore three major kinds of dependences between two
actors).
two
tasks,
of resource or resources are shared by the
output of the
task).
dependence or
to
Mecharusms
two
also differ
tasks
in Table
1.
by considering
and how they are used
by purpose,
either to
(as
Vat kind
an input or
as
an
manage constraints created by a
maintain a desired depeulence.
The typology of dependences and examples
task-task
between
between two resources or between a task and a resource. These categories can be
further refined: for example, task-task dependences are distinguished
shovm
objects: diose
Some of the cells
of associated coordination
of this typology are
dependences have been analyzed
in
more developed than
mechanisms
is
others; for example,
some detail, while resource-resource dependences
have not.
Insert Table
3
1
about here
Data and methods
As a concrete example of a coordination theory
process
and consider
example
is
analysis,
alternative forms the process could take.
I
The
will
examine a software change
particular orgcinization in this
the minicomputer division of a large diversified electronics corporation; in 1989,
the study started, the entire corporation
Draft of 8/17/94
had
sales of
when
approximately $10 billion and roughly
11
100,000 employees^.
The computer division produces
several lines of minicomputers
and
workstations and develops system software for these computers.
3.1
Research setting
This process
was examined as
part of a study of
*e engineering change process in three
First, the process
organizations. Engineering change processes are interesting for several reasons.
is
manufacturing to
very coordination-intensive and requires individuals in engineering and
work together to be effective. Second, even though each change is unique, change
management is
of routine
relatively routine. Pentland (1992) notes advantages to shidying this sort
work: each
one.
change forms a clearly bounded unit of work and intensive records are kept of each
change management
which are
is
done
in
Finally,
some form by nearly all manufacturing companies, many
interested in improving the performance of this process.
The
particular
group studied was responsible
for the
development of the kernel of a
high-level language.
proprietary operating system, a total of about one million lines of code in a
Development of the operating system had
that time, the system
To
system
is
had
just
set the context for
been
started about 5 years before
we began our study; at
irutially released.
my analysis,
I
will first briefly describe the product.
the basic software of the computer;
its
major function
is
to insulate
The operating
programmers from
users to share the computer
the details of the hardware. Additional mechanisms permit multiple
services such as access
without interference. Increasingly, operating systems provide specialized
to a
network or database and transaction management. Operating systems are
specific to the details of the
hardware; the system studied works only with
typically quite
this
manufacturer's
hardware.
5
The
field
work and
Draft of 8/17/94
analysis
was done with the
assistance of Stephen Brobst.
^^
Software
differences
is interestingly different
is tfiat
software
the development process
is
is
from other products. One of the most fundamental
not a physical product, which has several implications.
completed, reproduction of the finished product
straightforward, consisting mostly of duplicating tapes ai\d documentation.
is
very malleable: almost any change that can be imagined can be
is
not to imply that changes to software are costless, however.) As a
changes
is
once
relatively
As well,
ttie
product
made without the physical
constraints of other products, such as the need to change tooling or produce
(This
is
First,
new components.
result, the rate of
higher in software than in hardware (A, p. 110)^.
Second, problems are
much more likely to be systematic. A problem with a
hardware may or may not occur
may also be a random
failure.
in
another item: the problem
piece of
may be due to a design flaw, but it
A problem with a piece of software, on the other hand, it is likely to
occur in every copy of the software. This
is
especially true for system software,
which
less
customized than mainframe or mini<omputer application software and thus
and
for
is
usually
less variable,
micro or minicomputer software, where the variance in the underlying hardware
In a sense there
is
only one product, not multiple instances. As a
processes are important to
do well, because they affect every
The operating system developed by
this
several major subsystems, such as the process
software change
user.
organization
manager or
result,
file
is
decomposed
hierarchically into
system; each subsystem
divided into a number of modules. Each module implements a small set of services.
depends on another
process manager
if
the
first
makes use of services provided by
may use routines
management code depends on
that are part of the
(part
oO
the
file
file
is less.
further
is
A module
the second. For example, the
system; therefore, (parts
oO
the process
system code. The set of routines and data
provided by a module form the interface to that module.
^
References to page numbers of
statements by subjects.
Draft of 8/17/94
my field notes are given as the source for quotations or
13
Different interfaces are provided for use
to customers are described in published
interfaces, called service interfaces, are
software. Service interfaces used
sp>ecifications; tt\ose
manuals
for the
library.
system and rarely
Interfaces provided
ever change. Other
if
provided for general use by other parts of the system
by other development groups are documented
used only within a single unit
specification or perhaps not at
documentation
by different classes of users.
all.
may be dociunented
Manuals and external
in
an
in external
internal
specifications are maintained in a paper
Programmers who request copies of a document are registered as a user
of the described interface, in principle so tfwy can be informed of any changes to the
document
At the time of our study, there were 800-900 documents, with about 1000 users
A total of
15,000 copies of
3.2
Data
documents had been
total.
distributed.
collection
The analysis presented here
is
based on 16 interviews with 12 different individuals,
including 6 softwtu-e engineers, two managers and three
members of support groups and one
marketing engineer. The interviews were carried out during 6
headquarters; most were or>e to two hours long.
member of the
software development group
As
who
well,
I
trips to the
worked on
company's engineering
the analysis with a former
much additional
provided
information.
As discussed above, coordination mechanisms primarily involve information-processing
activities.
(e.g.,
For
my study
I
March and Simon,
therefore adopted the information processing (IP)
1958; Galbraith, 1977;
Tushman and
view of organizations
Nadler, 1978) because of
its
focus on
how organizations process information.
During the interviews,
I
attempted to uncover, in March and Simon's (1958) terms, the
programs used by the individuals
in the group.
March and Simon suggest
these programs: (1) interviewing individuals, (2) examining
operating procedures or
and Simon
(3)
(1958) point out,
Draft of 8/17/94
observing individuals.
I
relied
"most programs are stored
documents
three
ways
to
uncover
that describe standcu-d
most heavily on interviews. As Mcirch
in the
minds of the employees who carry
14
them out, or
in ti\e
minds
and most accurate way
simplest
I
many purposes, the
of their superiors, subordinates or associates. For
to discover
started the data collection
studied. This identification
what a person does
to ask
is
him"
by identifying differa\t kinds of actors
was done with
the aid of a
(p. 142).
in the
group being
few key informants, and refined as the
study progressed. As well, formal documentation of the process was used as a starting point
where
was available. For example, a number of individuals design and code parts of the
it
operating system,
each
is
all
working
in
rougJJy the same
using the same kinds of information;
an example of a "software engirwer actor." Response centre or marketing engineers use
and process
different information
Subjects
were
identified
was no evidence, however,
it
by
differently
and were therefore analyzed
the key informants, based
that their reports
identify the types of information received
were
from whom they receive
systems); (4)
it;
(3)
how they process
messages as a
result.
how
atypical.
I
on
separately.
their job responsibilities;
they receive
(1)
.ere
then interviewed each subject to
by each kind of actor and the way each type
handled. Data were collected by asking subjects:
talk
way and
is
what kinds of ir\formation they receive;
it (e.g.,
from telephone
and
the different kinds of information;
calls,
(5) to
(2)
memos or computer
whom they send
When f)ossible, these questions were grounded by asking interviewees to
about items they had received that day.
I
also collected examples of
documents created and exchanged as part of the process or
that described standard procedures or individual jobs.
Not surprisingly, the process as performed
frequently differs from the formally documented process. For example, at a different site in the
study, engineers receive a listing of
all
approved changes, but the
official list
seems merely
to
confirm that the changes have been approved. In order to react to a change an engineer must be
warned
of
it
well in advance of
its
appearance on the
primarily through an informal process.
Draft of 8/17/94
It is
official list.
this informal process
This warning seems to happen
I
sought to document.
15
3.3 Validation of data
The initial product of these studies was a model of the change process (presented
detail
in
more
below) that describes the actors involved, which steps each performs and the information
they exchange.
contact at this
It
should be noted that data were collected about only one group because
company worked
in that group.
my
My impression from interviews with individuals
who had worked in other groups in the past or who interacted with them is ttiat processes are
similar in odier software
development uiuts, but I have rw
direct information
Relying on interviews for data can introduce some biases.
what they
the
really think.
company, so
(the
"company
company
Some interviews were conducted
intervie A^ees
line"),
may have been te^npted
what they think I want
look best. Second, individuals sometimes
people do not always say
in the presence of another
to say
to hear or
First,
about them.
employee of
what they think they should say
what will make themselves or the
may really not know
the
answer or may be
mistaken.
Some of these
biases can be controlled
informants. For example,
can check
if
that other
if
by cross-checking reported data with other
one interviewee reports sending information
to a particular
group,
I
group reports receiving such information.
Furthermore, the modelling process serves as another check on the consistency of the
data.
I
used an
iterative
approach, sometimes called the negative case study method [Kidder,
1981 #114], switching between data collection and
collection serves as the basis for
the data, for example, places
an
where
initial
it
model development. The
model. Constructing
this
was not clear how an actor
initial
round of data
model revealed omissions
reacts to
in
some message or from
whom a particular piece of information comes. These omissions or ambiguities serve as
the basis
for further data collection.
Draft of 8/17/94
16
3.4
The change process
Reasons for changes. Lientz and
Swanson (1980) distinguish
three reasons for
making
changes to a program: corrective, perfective and adaptive. Corrective changes are those
fix
made
to
problems. For this company, problems are defined as disagreements between the behaviour of
a program and
its
documentation. The interface ctnd behaviour of a module are supposed to
match Q\e document describing it, so changing
tfie
interfece requires a revision of the
corresponding docviment. Fixing problems usually requires changing the software, but
sometimes the
fix is
made
to the
documentation instead. Perfective changes are those made
improve a correct program without altering its behaviour,
typically
by improving performance.
Adaptive changes are those that add new functionality, altering the software
requirements. The
last
two
categories of changes are mostly
than as part of the change process, so
Goals of the change process.
process (A4, p.
•
I
will not discuss
made
them
to
to
to
meet changing
enhance the system rather
further in this paper.
The organization had the following
stated goals for the change
7):
ensure that
all critical
program parameters are documented: customer commitments,
cross-functional dependencies.
•
ensure that a proposed change
•
ensure that document status
is:
reviewed by all impacted software development
units/functions; formally approved or rejected.
and
•
date);
is
made available
ensure changes are made quickly and
More generally,
I
and
ensures that changes are
and
number
efficien tly
believe the change process actually has
quality of the software
are fully tested
to all users: stable (revision
changes being considered; approved/rejected/withdraum.
to
two primary goals:
module and
its
the
module involved,
documentation are kept
cost of changes, the change process requires that changes be
authorized enhancement.
maintain the
minimize the cost of changes. To maintain quality, the process
made by someone who understands
that the
to
As one manager put
it,
in
tha«^
changes
agreement. To reduce the
made only to
fix
a problem or
the "formal change control process
is
add an
there to
prevent changes" (A, p. 108).
Draft of 8/17/94
17
Many problems are found during the development process by the testing group. Some
are found
testing
by customers using the product. The software maintenance processes
start
when the
group or a customer notices some problem with a product and complains. The
group can enter a problem report directly
Customer complaints are altered
centre staff
if
in the
testing
change request system described below.
into the system
by a
field
engineer or by the customer support
the customer telephones for help.
When a customer calls, \he call is directed to one of approximately 300 specialists in one
of 10-15 groups, depending
on \he reported product The staff member handling A\e call may use
information such as the manuals distributed with the product, marketing information, ciurent
price
lists,
ordering information and other documents describing the product. Specialists also
have access
to a
database of all
calls
logged in the past few years and a database of change
requests.
may be due to several causes, such as user misunderstanding of the product
Problems
(an estimated 4 out of 6 calls per day, according to one interviewee), hardware problems (1/2 to
call
per day) or real problems with the software
(1 to 1
1/2
calls
per day). The reported problem
may duplicate a known report already in tiie change request database.
patch, the call handler can order
existing
problem
tracking system.
ref)ort,
is
for the customer.
the call handler can enter a
Our interviewee had
a specialist group
database
it
(i.e.,
If
1
In
tt\is
case,
if
the reported problem does not
there
a
is
match any
new change request in the change request
entered a change request 2 times in 9 mondis of working in
on the order of 2 out of an estimated 1000 calls). The change request
the major commuiucation channel between the customer service centre
and the
development engineers.
Marketing engineer. Once a change request
marketing engineer
studied.
for review.
entered from any source,
it is
retrieved
There are eight such engineers for the operating system
The marketing engineers
Draft of 8/17/94
is
get a
list
of
by a
we
problems entered every morning. About half the
18
time the problem report
is
complete enough to work with; in other cases, the a\gineer requests
additional information from the submitter
Once the report is complete,
and waits
for
really a user misunderstanding, a duplicate of a
\he problem appears to be genuine,
decide that the problem
process.
is
it
may also determine tinat the problem is
known problem or due to a documentation error.
The marketing engineer may also
an enhancement, which are haiKlled by a separate
sets the priority for fixing the
The marketing engineer next determines
to the
be sen*^
gets processed further.
really a request for
The marketing engineo* then
change request
to
the marketing engineer attempts to replicate &»e problem to
gain a better understanding of its causes. The engineer
If
it
the location of the
development unit responsible
for that
problem.
problem and assigns the
module.
can not locate the problem, the report goes to a group called the
If
the marketing engineer
SWAT team. This team has
access to the system source code which they use to further diagnose the problem.
they locate the bug within
group; they
may go as
some module and
far as to
At the
least,
assign the report to the appropriate engineering
suggest a possible
fix to
the engineer, although they
do not make
changes themselves.
Software engineer. Periodically a coordinator in each software development group assigns
new change
requests in the database to the engineer responsible for the affected modules.
software engineer then investigates the problem.
module, then the engineer passes the request
The engineers
first
If
the
problem turns out
discuss the problem informally;
the problem
is
internal to a single
if it is
another
module.
change request tracking database.
module, the engineer can just
used by other modules, requiring that changes be made
Draft of 8/17/94
in
agreed that the problem should be
resubmit the code to the integration group. In other cases, the change
interface
be entirely
to the engineer responsible for the other
transferred, the engineer then changes the assignment in the
If
to
The
fix
the
module and
may require changes
to those
modules as
to
an
well. In
19
these cases, the engineer
must discuss die change with the owners of the affected modules as well
as other interested engineers
and arrange
Change approval process. Changes
for
to
them to change their modules as
some service interfaces
use) require changes to dociuneits that are controlled
interface
and the
change, this mig^t be a thick document which
jjeople
what
The engineer
will be changed.
invites diese people to the design reviews.
otherwise, they
change
for the change. For a
ma^or
widely circulated; for a minor change, only a few
may be involved. Typically the change includes a marked up copy of the document
indicating
and
is
(those intended for general
by a change control group. To change the
document, the engineer writes a proposal
related
necessary.
is
come to
the design review
investigates
If
who will be affected by the change
they are not affected, they simply say so;
and comment on the proposed change. When the
agreed on, the engineer seeks approval from management and from the change review
board. The board
is
composed of representatives
of different software
development
units,
software manufacturing, integration and a testing and performance unit, 15-20 people in
This group meets once a
week
for
two hours, during which they discuss change
other issues. For this operating system, the board considered 4-5 changes per
documented
week
among
to
interfaces.
Once
is
requests,
total.
the change
is
approved, the engineer changes the code as necessary. The end result
code for a new module with the problem
fixed.
When the change
is
complete, the engineer and
another engineer review the code to check that no other errors were introduced. As well, the
engineer
code for
first
tests the affected
all
modules
the
to create the
engineer informally
Integration
new code
identify
modules by recompiling
and
to the testing
(i.e.,
merging the
affect multiple
modules, the
change with die aid of the other engineers.
When the engineer is satisfied with the change, he or she submits
and integration group.
which change request
and relinking the system
complete system). For changes that
tests the entire
testing.
it
is
In order to
submit a change, the engineer .nust
being addressed; without a request, the integration group will
not accept the change. The submittal form must also be approved by the engineer's manager.
Draft of 8/17/94
20
When multiple modules must be changed, the changes for each module are submitted separately,
but with a notation that
it is
part of a bundle.
The
complete. The integration group then recompiles
The kernel
is
initial
all
engineer indicates
die changed code
and
when the bundle is
relinks the system.
then tested; any bugs fouTKl are reported to the engineer, potentially starting
another pass through the process.
If tt\e
problem was serious and required a quick response, a
fix
can be released in the
form of a patch. To make a patch, the compiled code for ihe just the affected modules
is
copied on
a ta(>e which can be separately installed on the affected customer's system by a field engineer or
the customer.
If
the problem did not need an immediate solution
(e.g.,
diere
is
a
workaround
that
avoids the problem), then the customer would wait for a routine release of the system that
includes the change. Customers are periodically sent the most recent release of the system.
The
activities
performed
for a typical
Table 2^. Although no particular bug
were described
as typical
by
is
change are sunnmarized
in die first
two columns of
necessarily treated in exactly this way, these activities
my interviewees.
Insert Table 2 about here
4
Dependences and coordination mechanisms in software bug fixing
In the course of
making a change
to the system,
managed. The coordination theory approach
identifying diese dependences
least)
two ways
First,
part of
^
to identify
numerous dependences must be
to analyzing
and redesigning
and considering alternative ways
to
this process
suggests
manage them. There are (at
dependences and coordination mechtinisms (Osbom, 1993).
we c£m examine activities
in the current process, identify tfiose that are
seem
to
some coordination mechanism and determine what dependence they manage. Some
be
of the
Because the orignal study focused on the actions of the software engineers, the response
was treated as a collective actor. As a result, activities internal to it, such as the task
assignment discussed above, are omitted from the summary of the process.
centre
Draft of 8/17/94
21
activities in the
discussed
column
bug fixing process
the def)endences such activities apparentiy
eeirlier;
of Table
2.
For example, one of the
tasks
is
known problem listed
in the
manage
are listed in the third
things the customer service centre
first
marketing aigineers aiKl software engineers do
duplicates a
Ae coordination mechanisms
apf)ear to be instances of
when
receiving a problem report
staff,
is
check
if it
change database. In the typology, looking for duplicate
coordination mechanisms for managing a dep)eKlence between two tasks
listed as a
which have duplicate outcomes. The organization can avoid doing the same work twice by
noticing the duplication and reusing the result of one of the tasks (as
Task assignment
task
and
a p>erformer
is
a coordination
mechanism
by finding a f>erformer
performed repeatedly
in this process:
them
allocation
task.
the
dependence between
a
Such coordination mechanisms are
to the
marketing engineers, marketing engineers
software oigineers and software engineCTS assign tasks to each other.
to the
Prioritizing tasks,
do the
managing
the case in this example).
customers assign tasks to the customer service centre, the
customer service centie assigns novel tasks
assign
to
for
is
performed by the marketing and software engineer,
a sign of a resource
is
mechanism.
A second
approach
what dependences
is
to
list
the tasks
and resources involved
are possible between them.
It
in the process
may be that some of the
and consider
steps in a process are
coordination mechanisms for managing those dep>endences. As mentioned above, tasks necessary
to res{X)nd to
problem reports include noticing there
is
reproducing aind diagnosing the problem, designing a
a problem, finding a
fix,
writing
new code and recompiling
system with the new code. Resources include the problem reports, the
sf>edalized actors
and the code
Dependences between
one
task.
code,
For example,
tinat is
the two.
many
tasks can be identified
used as input by some other
Draft of 8/17/94
efforts of a
the
number of
itself.
tasks create
Malone and Crowston
workaround,
by looking
some output, such
a
for resources
bug
rep>ort,
task, thus creating a prerequisite
(1994) note that such dependences often
used by more than
a diagnosis or
new
dependence between
impose
usability
and
22
Some
invaitory constraints.
new module works
example, testing that a
creating code
If
of the steps in the process appear to
two problems
in the
code. In this process, this def>endence
correctly addresses the usability constraint
same module, then both bug
is
least greatly
in these
modules
often called "code ownership," since each
p>erforms
all
modify
tasks that
fixing tasks
managed by assigning modules
is
programmers and then assigning problems
owner who
constraints; for
between
and relinking and using the system.
there are
arrangement
manage such
that
to that
module
need the same
of code to individual
programmer. This
of the
system has a single
module. Such an arrangement eliminates or
at
reduces the need for coordination to share that resource.
Finally, there
e
dependences betweeri modules owned bv different engineers
constrain whiat changes can be
made and must
therefore be
that
managed. Interactions between
different parts of the system are not always obvious, since they are not limited to direct physical
connections. As a result, the impacts of changes are not always immediately apparent.
In principle
to
each module
is
should be easy to detect dependences automatically, because the interface
it
defined in what
is
calling modules.
Simply looking
at
mixiuie includes
many
all
u hich may
routines,
called a "header file",
these
of
files
which
is
explicitly referred to in
overstates the dependences, however, since a
which are defined
in the
header
file,
but only a few of
actually be used by the particular calling module. Furthermore, since
time consuming to
list
exactly
which other mixiules
that simply defines everything that
is
likely to
underlying dependences by (apparent!)
)
all
a
module
uses,
sometimes
programmers often use
be necessary. Overuse of
making
it is
this file
masks the
a
file
real
ever)'thing depvend on everything else.
Interactions can be determined directly from the source code of the system, for example,
by looking
list
for places
which mtxiules
where one nxxiuie
call
which other modules. These
limitations. First, the cross-reference
Draft of 8/17/94
calls another.
Cross-reference listings can be
listings exist
made
that
and are used, but they have two
does not indicate where mcxJules use data structures from
23
a
another module (as opposed to calling routines). Second, the cross reference only covers the
kernel;
it
does not show which routines are called by code developed by other groups.
As a
result of these problems, there
seem
to
be no
reliable
mechaiucal means to determine
the interactions between different modules. Instead, social mechanisms are used. In theory, a
programmer should
interface
register
with the documoit library
and ask the maintainer if they want
to
if
they want to use a documented
use an uivlocumented interface.
An engineer
could then use these sources to determine who would be affected by changes to a module and
should be invited to review any changes. In practice, programmers sometimes borrow a
document or copy
pieces of
someone
some cases,
irtform the developer. In
usual social norms that control
4.1
how
else's
code jmd therefore do not realize that they should
these other
programmers are
interfaces are
used
in other
groups where the
may not apply.
Developing new forms
—such as could be easily generated from Table 2 above—
Given a flowchart of a process
common approach to
where
steps or places
redesign
tasks
is to
look for problems such as redundant or non-value added
spend long periods waiting to be worked on and then modify the
process to address these problems (Harrington, 1991, pp. 134-163;
Hammer and Champy,
1993,
pp. 122-126). For example, the current change process assumes that customers are incapable of
doing anything
to fix their problems.
for example, to
check themselves for duplicate
developed
at the conclusion of
and search
for
documents
information. Customers
The process could be modified
our study to allow
that describe their
who
tasks. In fact, a
just this.
to
allow customers do more,
database of documents was
Customers can
dial-in to the database
problem and the appropriate workarouna or patch
find solutions can order the patch or apply the
they can leave an electronic request for a return
call
workaround;
if
not,
from the response centre, starting the change
process described above.
Draft of 8/17/94
24
Our analysis suggests another approach to
redesign, namely, replacing
some
coordination mechanisms with alternative mechanisms. In the remainder of this section,
discuss three examples involving alternative techniques for
managing
I
will
task-task, resource-
resource and task-resource dependences described above.
Alternative mechanisms for managing prerequisite dependences. In the
manage prerequisite dependences between
several activities appear to
output of the one task
reports are detailed
is
enough
approvals
tests,
tasks
by ensuring that the
usable by another. For example, marketing engineers check that problem
to
be used by
tite
engineers fixing the bugs;
bug
fixes are tested at
problem and do not introduce new problems. In
several points to check that they actually fix the
addition to these
problem fixing process,
managers must approve changes before they can be implemented. Such
may serve as an additional check on
the quality of the change, either directly,
if
the
meinager notices problems or indirectly, because engineers are more careful with changes they
show
their
managers. There are other possible interpretations of
might use the information
to allocate resources
spend
to
all. If
their time or
simply
demonstrate
this
approval process: managers
among different projects,
their
power without
track
how engineers
necessarily adding
any value at
approvals are a quality check, however, there are other mechanisms that might be
appropriate. For example,
if
approvals are time consuming and most changes are approved,
may be more effective to continue the change process
it
without waiting for the change to be
approved. Most changes will be implemented more quickly; the few that are rejected vnW require
additional rework, but the overall cost might be lower. Alternatively, managerial reviews could
be eliminated altogether in favour of more intensive testing and tracking of
Alternative mechanisms for managing resource-resource dependences.
when
test results.
Changes are problematic
they are visible outside a single module since they then require coordinated changes to the
modules which depend on
it.
These dep)endences are especially difficult
are developed in different divisions, since there
divisions. For example,
Draft of 8/17/94
one interviewee
is little
told a story
to
mange
if
the
modules
informal communication between
about the time the word processing system
25
became the source of mysterious system crashes.
It
turned out that
its
developers had used a very
low level system call which had been changed between rdeases, c£ using
no way
for the
developers of the word processor to
for the developer of
*e system call
to
know
the problem. There
was
know not to use the system call and no way
they were using
it,
since the
word
processor
is
developed in another, geographically remote software development urut
The typology suggests tfiat such dependences must
sometimes
first
be noticed and then managed.
however. For example, engineers can only perform
Noticing dependences
is
unit tests (that
of a single module); they can not really test the whole operating system
since they
access to
tests
do not necessarily know how
all
recompile
is,
difficult,
the code.
all files,
To save
time,
tfw other
modules are supposed
to
behave or even have
an engineer or even the integration group might not
but since there are no sure-fire methods
mi^t be affected by a change some affected
files
to
determine which other modules
migjit be omitted,
an almost certain source of
problems.
One solution is
programmers
use.
Such
provide documented service interfaces for the data and
to
interfaces
change only
rarely,
calls
reducing the chance of problems. At the
time of our study, the change control group was planrung to control the use of more interfaces
were planning a new
solution
is
set of interfaces to internal data that
to better ti-ack
database that
lists
principle these
what
interfaces people are using.
which engineers have requested copies
lists
can be used
often they are used or
to track
who
how accurate tiiey are.
documents or code fragments;
captured by die database.
customers were using.
tiiese
As mentioned
of
A second
earlier, there is a
documents describing
uses a particular interface, but
it
is
interfaces; in
not clear
how
For example, engineers frequently borrow copies of
borrowings could result in dependences that are not
One engineer was working on a
known dependences, but he was concerned
that witiiout a
database
tiiat
mechanism
included
all
currently
for people to report their
use of other modules the database would not stay up-to-date.
Draft of 8/17/94
26
Alternative mechanisms for task assignment. In the analysis
we noted numerous places
where actors perform part of a task assignment process. For exctmple, customers give problem
rejwrts to the service centre,
which
in turn assigns
them
software engineers. In addition, software engineers
to product oigineers,
may assign
reports or subtasks to each other.
Currently these assignmoits are done on the basis of specialization, that
problem
ref)ort
must determine the module
in
who assign them to
which the problem
likely
is,
an actor with a
appears and assign the
task to the engineer responsible for that module. This system has the advantage \hat a particular
engineer
code.
is
(TTiis
responsible for a small set of modules and can therefore develop expertise in that
feature
the system.)
As
result of
particularly important
well, since
discussed above
location of a
is
is
when
modules are assigned
is
also developing
to engineers, the
problem can be
new versions of
code sharing problem
minimized. However, there are aiso disadvantages.
First,
diagnosing the
because symptoms can appear to be in one module as a
difficult,
problems somewhere
else. In
the best case, an error message will clearly identify the
problem; otherwise, the problem will be assigned
transferred.
the engineer
to the
most
likely area
and perhaps
later
A second problem is load balancing: one engineer might have many problems to
work on while others have none.
Towards
the
The reorganization
the
end of our study, the group
split the
development engineers
system
is
made available
we were studying underwent a reorganization.
engineers into support and development groups, possibly to allow
to concentrate
on adding new
to the customers,
functionality.
As each version of the
development stops and the version goes
into support.
only important problems and refer others to the
Engineers working on these versions
fix
development engineers be addressed
in future versions.
Most bugs are reported against the
current versions though, since those are the ones that customers have.
In this form, support engineers are not specialized
support group has fewer engineers
who do
not
split their
by module, apparently because the
time between support and
development, thus reducing the need for specialization as well as
Draft of 8/17/94
tiie
resources to support
it.
The
27
support engineers are instead organized around change ownership rather than module
ownership, that
is,
an engineer is assigned a
modules are affected. As a
result, task
particular
problem report aivl changes whatever
assignment can be done by workload rather than
specialization.
With change ownership, multiple engineers may be working on the same module. To
manage these new task dependoKes, the company started
system maintains a copy of all source
check
it
files.
The activities and
is
analysis of this
checked back
in
form are shown
in
assignment mechanism. In
this form,
Table
3 about here
lowest bidder
4.2
fix
is
the bug,
mechanism
for task
A more extreme substitution is to use a market-like task
each problem report
evciluates the report; engineers interested in fixing the
take to
3.
the substitution of a specialist
assignment with a generalist mechanism.
When the change
and the system records the changes made.
Insert Table
The previous example showed
The
When engineers want to make a change to a file, they
out of the library, preventing other programmers from modifying it
has been completed, the module
would
to use a source control system.
is
sent to
bug submits
all
available engineers. Each
how
a bid, saying
long
it
how much it would cost or even what they would charge to do it. The
chosen and the task assigned
to
him or her.
EiHiluating alternative organizational forms
Given
this aruilysis,
it is
important to be able to evaluate the advantages and
disadvantages of each kind of organization. In
this section,
I
will suggest informally
—
evaluation might proceed for the three forms of task assignment consider above
generalist
and market-like
how such an
specialist,
—following Malone and Smith's (1988) analysis of four different
organizational structures. In their model, tasks arrive at an organization and
must be assigned
an actor that can execute them. They compcu-e organizational forms on three
criteria:
Draft of 8/17/94
to
the
28
production cost
(i.e.,
the average delay to process a task), the coordination cost (the
messages necessary to assign a
task) aiKl vulnerability of the
Many other fectors could be added
three additioruil factors: learning
form
to failures of
to complicate such a model.
by engineers who work
rej)eatedly
on
I
an
number of
actor.
will briefly consider
the
same modules mi^t
reduce production costs; diagnosing a problem to choose an appropriate specialist and
decomposing and distributing complex problems across
costs. Calculating these costs requires
e.g.,
specialists
might increase coordination
some detailed assumptions about parameters of
what proportion of tasks are complex or how long
it
takes to diagnose a
the system,
problem versus
sending a message. However, even without these assumptions, some qualitative comparisons can
be made.
The
first
form, assignment based on
sf>ecialists,
has a low coordination cost. Assigning a
task requires only three messages, from the customer to the service centre, from the service caitre
to the
marketing engineer and from the marketing engineer to the software engineer. Each of
these actors
must evaluate the
task
and
Because software engineers are
relatively quickly
once they get the
decomposed and assigned
identify the appropriate specialist to
specialists,
task.
presumably they
However, problems
to multiple engineers. If the load
become available, however.
Also, other engineers
those engineers could be busy working on
Finally, the
form
is
substitute in a pinch).
engineers will have
(i.e.,
some
wait until the engineer
to
is
wait for the code to
may be under-employed, although presumably
new versions of the system.
vulnerable to the failure or overloading of a single actor since the
engineer responsible for each module has no backup
Draft of 8/17/94
to
time to finish the task. The engineer does not have
problems
modules must be
distributed unevenly
modules have more problems than others) then a problem may have
free, increasing ttie
will be able to fix
that span
is
work on it next.
(in practice, of course,
other engineers could
Assignment based on module reinforces specializations by module since
little
opportunity or need to learn about other parts of the system.
29
The cost of the task assignment in the generalist model
number of messages.
Furtfiermore, the fiiud assigrunent
need for the marketing engineer
to identify the
is
is
also low, requiring the
same
done by workload, eliminating
the
module involved. Problems are handled by
the
next available actor, minimizing waiting time and reducing vulnerability of the organization to
the failure of a single engineer. However, because the engineers are generalists, the time they take
to fix a
module is
likely to
be higher than
in the specialist model.
The organization
advantage of any difference between actors in performance and no actor has
(or incoitive) to learn in detail
someone
for the
else is already
code
to
to
make
in the
if
the changes.
messages to assign each task (one for each bid request and
for
much opporturuty
module, then the engineer will have to wait
The market-like model has a much higher coordination
messages includes,
no
about a particular module to improve performance. Firudly,
working on a problem
be available
takes
bid).
cost, since
it
requires
many
The cost of processing these
example, the cost of having each engineer read each problem report.
However, problems can be immediately assigned, aldnough the engineer may have
code to be available to make the changes.
Finally, in this
to
wait for the
model, the task will be assigned to the
actor with the lowest bid, thus taking advantage of differences in knowledge.
If
the actors learn,
then can specialize, preferentially bidding for one type of task and constantly improving their
performance on
it.
For example, an engineer
who has
recently
worked on one module may be
able to bid lower for other changes in that module.
The
relative costs of these three
have identified additional
nrvarket-like
form
is
is
summarized
fix
in Table 4.
Of course,
researchers
factors that affect the feasibility of these forms. For example, the
susceptible to agency problem:
number of bugs they
flat salary,
forms
if
engineers are rewarded based on the
they might bid unrealistically low to win assignments;
they might not bid at
implications of such factors
all.
As with
tfie
if
they are paid a
product of any redesign method, the
must be considered before a
particular
form can be recommended.
Insert Table 4 about here
Draft of 8/17/94
30
4.3 Effects of electronic media
on the choice of coordination methods
As discussed above,
the use of
new communication media and
differa\tially aitect the costs of coordination
technology
for
is
mechanisms. Clearly, the exact form of the
important than the functionality
less
it
provides. In the case discussed in this paper,
example, the main communicaticms channel between groups
requests rattter than a
(Electroruc mail
other kinds of IT
more ccmventional system
like electronic
is
actually a database of change
mail or computer conferencing.
was available, but not heavily used witfiin the group.) However,
system provides much of
tf\e
same
functionality
and was sometimes even used
For example, on one occasion the response centre created a
the database
in the
same way.
new change request to enter a
question about the status of an older report; the responsible engineer then replied to the question
in another field of the database
Ratiier than focusing
technologies
is
and closed
on the
the request.
specific
technology then, one approach to analyzing such
consider which of a system's attributes are important. Nass and
to
pp. 52-53) discuss
numerous dimensions of communications technology; key
Mason
(1990,
attributes for the
case above include permanence across time, one-to-one vs. one-to-many communication and
programmability and integration with computer technology.
Permanence across time means
a later date.
that
messages entered into the system can be retrieved at
Computer conferencing and databases have
electronic mail
do
not. This function allows the
this property; telephones
product of fixing a problem
to
and ordinary
be stored and
reused, a key part of one of the coordination mechanisms discussed above.
A second key characteristic is
the
Telephones are usually one-to-one; paper
number of possible
recipients for a single message.
memos can be one-to-many, for a cost; and electronic
media can be one-to-many with almost no extra
cost.
This functionality enables
more
coordination intensive forms. For example, in the market-like form, the response centre needs to
send the same message
Draft of 8/17/94
(a
bid request) to
all
software engineers. The organization could use a
31
computer bulletin board on which task announcements are posted
to
support
this
communication. Such a system would reduce the coordination cost by replacing multiple bid
request messages widi a single broadcast.
Finally, electronic
computer technology,
system could
filter
number that need
communications media
pot»\tially automating certain kinds of coordination. For example, such a
problem reports
to
may be programmable or integrated with
for engineers
based on an interest
profiles,
be evaluated. Bid processing and awarding could also be easily automated,
further reducing the cost of a market-like mechanism, perhaps enougji to
5
reducing the
make it desirable.
Conclusion
Engineering change provides a microcosm of coordination problems and mechanisms to
management of numerous
solve them. Successful implementation of a change requires
dependences among tasks and resources.
A variety of mechanisms are used
may simply be
dependences. For example, the possibility of duplicate tasks
to
manage
these
ignored or engineers
may check for a know^ solution before attempting to solve the problem. Dependences between
tasks
and the resources needed
to
perform them are managed by a variety of task assignment
mechanisms, such as managerial decision making based on expertise or workload; those between
modules of the system, by a variety of code management systems and
The choice
of coordination
of possible organizational forms,
mechanisms
to
disciplines.
manage these dependences
some already known (such
results in a variety
as change ownership)
and some
novel (such a bidding to assign problem reports) The relative desirability of mechanisms
to
be affected by the use of electronic media. For example,
make it easier
to find existing solutions to a
tiie
problem, either
use of a computer system
in a
is
likely
may
database or from geographically
distributed coworkers, thus reducing duplicate effort, or reduce the coordination costs of a
market-like task assignment sufficiently to
Draft of 8/17/94
make
it
desirable.
32
As
well, the software
change process may have interesting parallels
in other industries.
Despite differences in the products, the other engineering change processes studied (Crowston,
1991)
had
sinularities in goals, activities, coordination
one reviewer noted
parallels
betweoi diagnosing software bugs
diagnosing patients to assign them to
mi^t reveal
problems and mechanisms. Further
ttiis
them
to engineers
and
An analysis similar to the one presented here
specialists.
interesting alternatives in
to assign
afield,
domain as well. Such an effort may be particularly
timely, given the leading role IT-enabled changes play in current proposals to
revamp
the
American health care system.
Coordination theory, like
organizations, but
it
all
theories,
a simplification of the complexity of real
is
seems to usefully explain a variety of alternative processes and highlight the
contribution of new communications media
and other information
example presented here obviously does not serve
to
to those
to test the tiieory, but rather to
with other
interests.
Furthermore, the suggestions of the analysis needs
is
cheaf)er,
(as
is
true of
does not mean
any kind of analysis).
it is
what should happen
communication systems, although
1987). For
it
to
any single organization
Specifically,
automatically better or that
should be implemented. In other words, coordination theory does not
predictions about
demonstrate the
how tasks are performed, however, the technique
because a particular mechanism
will or
single
focus on
Given
be tempered by consideration of omitted factors
just
The
its
potential of the approach.
may not appeal
technologies.
that
does suggest what wall hapf)en
make
it
strong
implemoits a
new
in aggregate (Malone, et
al.,
example, as mentioned above, market-like task assignment mechanisms have certain
cost benefits, but are also susceptible to agency problems that
succeed. Rattier than saying
must be addressed
what must happen, the analysis suggests
if
possibilities
A\ey are to
which an
informed manager can consider and modify as appropriate for the particulars of the organization.
Therefore, the appropriate test for the theory
Coordination theory
useful to consider
Draft of 8/17/94
is
a success
if
is its utility
for organization designers.
those attempting to understand or redesign a process find
how various dependences
are
managed and
it
the implications of alternative
33
mechanisms. As an example,
processes (Malone, et
consult the
al.,
handbook
we are currently using these techniques to compile a handbook of
1993).
Managers or consultants
to identify likely alternatives
and
interested 'n redesigning a process could
to investigate the
advantages or
disadvantages of each. Coordination theory makes the haiKlbook feasible by more precisely
revealing
how processes are similar and where they differ.
A redesign agenda suggests several additional research prc^ts. First, development of
the
handbook £md general use of a coordination-theory analysis
for recording processes
and identifying depeiKlences
requires
more rigorous methods
in organizations. There are already
many
techniques for data collection which are relevtint, but none focus explicitiy on identifying
dependences. Other researchers
that relies
on
affiliated witti the
handbook
basic techniques of ethnographic interviewing
activity lists to identify
project
have proposed an approach
and observation
to collect data
dependences and coordination mechanisms (Pentland, et al.,
and
1994).
Prototypes of such methods are currently being used for our research and in the classroom.
Experiences to date attempting to teach students to use
this
while to pick up the concepts, but that using them leads
Second, more work
is
needed
techniques indicate that
it
takes a
to greater insight into the process.
to elaborate the typology of
dependences, particularly
those between objects, and associated mechanisms. Identifying additional mechanisms
inevitable result of the
work being done
ways to organize
mechanisms
these
will
to record a variety of processes, cind
be develof)ed.
Finally,
I
is
an
exp)ect that better
computer simulations of
processes will provide an aid to understanding the performance of processes using alternative
coordination mechanisms and might even automate the exploration of alternative forms.
Although
still
under developir«.nt, coordination theory seems
underpinning for the study
efforts will
cuid design of
new organizational
be a coordination-theory based
processes.
The
much needed
result of these
set of tools for organizational analysts
that perhaps help realize the potential of electronic
Draft of 8/17/94
to provide a
and designers,
media and new organizational forms.
34
m
Acknowledgments
This research
Institute of
was supported by
tiie
Center for Coordination Science at the Massachusetts
Technology arul a fellowship from the Ameritech Foundation.
discussions with Michael Ccrfien, Jin-tae Lee,
It
has benefited from
Thomas Malone, Charlie Osbom, Brian Pentland
and other members of the CCS Process Handbook Project
Draft of 8/17
^5
References
Abbott, A. (1992),
"From causes
to events:
Notes on narrative positivism,"
Sociological
Methods and
Research, 204, 428-455.
Abell, P. (1987), The Syntax of Social Life
:
The Theory and Method cf Comparative
Narratixfes,
New
York: Clarendon Press.
'Towards a Coordination Cookbook: Recipes
Crov^rston, K. (1991),
Unpublished doctoral
Davenport, T. H. and
J.
dissertation,
E. Short (1990),
MIT Sloan School of Management.
"The new industrial engineering: Information technology
and business process redesign,"
Debreu, G. (1959), Theory cf value:
Sloan
Management Review, 314, 11-27.
An axiomatic analysis of economic equilibrium. New York: Wiley.
MA: MIT Press.
Dennett, D. C. (1987), The Intentional Stance, Cambridge,
Finholt, T.
and
Galbraith,
J.
L. S. Sproull (1990), "Electronic
R. (1977), Organization Design,
Hammer, M.
for Multi- Agent Action,"
groups
Reading,
at
work," Organization
Science, 11, 41-64.
MA: Addison-Wesley.
"Reengineering work: Don't automate, obliterate," Harvard Business
(1990),
Rmetyjuly- August, 104-112.
Hammer, M. and
J.
Revolution,
Harrington, H.
J.
Champy (1993),
Reengineering the Corporatwn:
A Manifesto for Business
New York: Harper Business.
(1991), Business Process Improvement: The Braikthrough Strategy for Total Quality,
Productivity,
Harrison, D. B. and
and Competetiveness,
M. D.
Pratt (1993),
New York: McGraw-Hill.
"A methodology
for reengineering business," Planning
Review, 212, 6-11.
Draft of 8/17/94
37
Lawler, E.
E., Ill (1989),
Lientz, B. P.
and
E. B.
"Substitutes for hierarchy," Organizational Dynamics, 1633, 39-45.
Swanson
(1980), Scfhvare Maintenance
Management: A.Study of the
Maintenance of Computer Applications Software in 487 Data Processing Organizations,
Reading,
MA: Addison-Wesley.
Malone, T. W. and K. Crowston (1994), 'Toward an interdisciplinary theory of coordination,"
Computing Surveys, 261.
Malone, T. W., K. Crowston,
Toward
a
J.
Lee and
B.
Pentland (1993), "Tools for invwiting organizations:
handbook of organizational
processes," In Proceedings of Second Workshop on
Enabling Technologies: Infrastructure for Collaborative Enterprises (pp. 72-82), Morgantown,
WV: IEEE Computer Society Press.
Malone, T. W. and
S.
A. Smith (1988), "Modeling the performance of organizational structures,"
Operations Research, 363, 421-436.
Malone, T. W., J. Yates and R.
I.
Benjamin
(1987), "Electronic
markets and electronic hierarchies,"
Communications of the ACM, 30, 484-497.
March,
J.
G. and H. A. Simon (1958), Organizations,
Matteis, R.
J.
(1979),
"The new back
office focuses
New York: John Wiley and Sons.
on customer
service," Harvard Business Review,
57, 146-159.
McKelvey,
B. (1982), Organizational Systematics:
Taxonomy, Evolution,
Classification.,
Berkeley:
University of California.
McKelvey,
B.
and H. Aldrich
(1983), "Populations, natural selection
and applied organization
science," Administrative Science Quarterly, 28, 101-128.
Draft of 8/17/94
38
Mohr,
L. B. (1982), Explaining Organizational Behavior:
Research,
Nass, C. and L.
J.
The Limits and PossUrilities cf Theory and
San Frandsco: Jossey-Bass.
Mason
(1990),
On tfte study of technology and task: A variable-based approach. In
Fulk and C. Stdnfield
(Eds.), Organizations
and Communication Technology (pp. 46-67),
Newbury Park, CA: Sage.
Osbom, C.
(1993), Field Data Collection Tor The Process
Handbook (Unpublished working paper),
MIT Center for Coordination ScioKe.
Pentland, B. T. (1992), "Orgaruzing
moves
in software
support hotlines," Administrative Science
Quarterly, 37, 527-548.
Pentland, B.
T.,
C. S.
Osbom, G. M. Wyner and
F. L.
Luconi (1994), Useful Descriptions cf
Organizational Processes: Collecting Data for the Process Handbook (Unpublished
manuscript),
Perrow, C. (1967),
MIT Center
"A framework
for
Coordination Science.
for the
comparative analysis of organizations," American
Sociological Review, 32, 194-208.
Powell,
W. W.
(1990), "Neither
market nor hierarchy: Network forms of organization," Research
in
Organizational Behavior, 12, 295-336.
Rich, P. (1992),
"The organizational taxonomy: Definition and design," Academy
of Management
Review, 174, 75S-781.
Sanchez,
J.
C. (1993), "The long and thorny
way
to
an organizational taxonomy," Organization
Studies, 141, 73-92.
Swanson,
E. B.
and C. M. Beath
(1990), "Departmentalization in software
development and
maintenance," Communications of the ACM, 336, 658-667.
Draft of 8/17/94
39
Tushman, M. and D. Nadler (1978), "Information processing as an
integrating concept in
organization design," Academy cf Management Review, 3, 613-624.
Woodward, J.
(1980), Industrial organizations: Theory
and practice (2nd
ed.),
Oxford: Oxford
University.
^^
Draft of 8/17/94
Figures
Table
1.
A
typology of dependences and associated coordination mechanisms from (Crowston, 1991).
Dependence
Coordination mechanisms
Coordination mechanisms to
to
manage dependence
maintain dependence
Task-task
Tasks share
common output
decompose a
task into
subtasks, iiKluding
integration
same
characteristics
look for duplicate tasks
merge tasks or pick one
do
to
negotiate a mutually
overlapping
agreeable result
pick one task to
conflicting
Tasks share
common
do
input
shareable resource
no
reusable resource
make conflict visible
conflict
schedule use of the
resource
non-reusable resource
Output of one
task
is
pick one task to
do
•
input of
means-ends analysis
other (prerequisite)
same
characteristics
order tasks
ensure usability of output
manage flow of resources
reorder tasks to avoid
conflicting
conflict
add another
ttisk to
repair
conflict
Task-object
Object
is
identify necessary
resource used by task
resources
identify available
resources
choose a particular
set of
resources
assign the resources
Object-object
One object depends on
Draft of 8/17/94
another
dependence
manage the dependence
identify the
pick objects with the
desired relationship
41
Table
2.
Typical steps in the software problem fixing process.
Actor
Activity
Customer
find a
rep>ort
nee
problem while using system
problem to response centre
managed between.
problem fixing task and
capable actor
Response Centre
look for bug in database of
to customer and stt^
known bugs; if found,
return fix
problem
fixing task
and
duplicate tasks
attempt to resolve problem
refer hardware problems to field engineers
problem
fixing task
and
capable actor
problem is novel, determine affected product and
forward bug report to marketing engineer
look for bug in database of known bugs; if found, retxim
to customer
problem
if
Marketing
Engineer
request additional information
if
fixing task
and
capable actor
fix
necessary
problem fixing task and
duplicate tasl^
usability of
problem report by
next activity
attempt to reproduce the problem or find workaround
set priority for
problem
problem fixing task and
actor's time
if
the report
treat
Programming
Manager or
it
actually a request for
aifferently
is
an enhancement then
,
determine affected module
if unable to diagnose, forward to SWAT Team
if bug is in another product, forward to appropriate product
task and reso
tasks
manager
forward bug report
module
capable actor
to
manager of group responsible
:es rt
quired by
problem fixing task and
for
determine engineer resf>onsible for module and forward
bug rejxjrt to that engineer
problem fixing task and
pick tfie report with the highest priority, or the oldest, or
the one you want to work on next
problem fixing task
actor's time
diagnose the problem
task and resources required
tasks
capable actor
Designate
Software
Engineer
if the problem is in another module, forward
engineer for that module
design a fix for the bug
it
to the
if change is needed in other releases and make the
change as needed
send the proposed fix to affected engineers for their
comments; if the comments are negative, then revise the
Managers
approve the change
write the code for the
problem
fixing task
two modules
management of
necessary, ask
tfie
usability task
and capable actor
usability of fix
to other
modules
task
by next activity
and subtasks needed
accomplish
Integration
and
capable actor
fix
determine what changes are needed
if
and
the process
the change requires changes to a controlled document,
then send me proposed change to the various managers
and the change review board for their approval
if
Software
engineer
fixing task
engineers responsible for the other
modules to make any necessary changes
test the proposed fix
send the changed modules to the integration manager
send the patch to the someone to send to the customer
check that the change has been approved
recompile the module and link
test the entire system
it
with the
rest of the
problem
to
it
fixing task
and
capable actor
by next activity
and capable actor
usability of fix
task
usability of fix
activity
by integration
system
usability of entire system
by
next activity
release the
Draft of 8/17/94
new
by
capable actor
check
bug and repeat
problem
and
software
42
MIT LIBRARIES
3
Table
3. Activities in
Agent
TDfio
0Da^3Dfl^ r
the generalist form of task assignment.
Activity
Dependence managed
between...
Customer
Use system,
report
bug
find a
bug
to response centre
problem fixing task
and capable actor
database of known bugs;
Response
lookup bug
in
Centre
retiim
customer and stop
fix to
if
found,
determine affected product and forward bug report to
marketing engineer
Marketing
Engineer
lookup bug
in
database of known bugs;
if
found,
return fix to customer aiKl stop
—part of diagnosing
attempt to reproduce the bug
determine affected module;
to
if
problem fixing task
and duplicate tasks
problem fixing task
and capable actor
problem fixing task
and duplicate tasks
it
can't diagnose, forward
SWAT Team; if other product, forward to
problem fixing task
and capable actor
appropriate product manager; put bug report in the
queue of bugs
Software
Engineer
start
work on
to
Work on the next bug
in the
queue
problem fixing task
and actor's time
diagnose the bug
if it's
actually an
enhancement request, then
treat
it
differently
design a
fix for
the
bug
if the change requires changes to a controlled
document, then send the proposed change to the
various managers and the change review board for
their
Managers
management of
usability task and
capable actor
approval
approve the change
usability of fix
subsequent
Software
engineer
check out the necessfiry modules; if someone else
working on them, then wait or negotiate to work
is
concurraitly
write the code for the
test the
proposed
problem fixing task
and other tasks using
the same module
fix
usability of fix
fix
subsequent
send the changed modules
check in the module
Integration
to the integration
usability of fix
subsequent
recompile the module and link
system
system
it
by
activities
manager;
check that the change has been approved
test the entire
by
activities
with the rest of the
by
activities
integration
endre
system by next
usability of
activity
release the
Draft of 8/17/94
new
software
43
Table
4. Relative costs
of different task assignment mechanisms.
Cost
Specialists
Production costs
Waiting
for engineer
Waiting
for
module
Fixing problem
Takes advantage of learning
Coordination costs
Diagnoses
Messages to assign
Decomposition and assignment
of subtasks
Vulnerability to failure
Necessary
Generalists
Market-like
Date Due
AUG.
3
NOV- f
'9*^
-
3
1996
JUL 2 9
1998
"^ J-0
19! )9
Lib-26-67