»
ill'
V'i',-
V
• \
W
*:•
(UBSASIES,
J
—
vV^^
.
(S
MAX LIBRARIES DEWEY
-
Dewey
HD28
.M414
H
A TAXONOMY OF ORGANIZATIONAL
DEPENDENCIES AND
COORDINATION MECHANISMS
by
Kevin Crowston
CCS TR #174,
Sloan
WP# 3718-94
August 1994
,.:«Ui3ACHIjSF: TTS
li'-JS
ii
OF TECHNOLOGY
DEC 011994
LIBRARIES
rUTEi
A TAXONOMY OF ORGANIZATIONAL DEPENDENCIES AND
COORDINATION MECHANISMS
KEVIN CROWSTON
The University
of
Michigan
School of Business Administration
701
Tappan
Ann Arbor, MI
48109-1234
+1 (313) 763-2373
Fax: +1 (313) 763-5688
crowston@umich .edu
August
17,
1994
USA
A TAXONOMY OF ORGANIZATIONAL DEPENDENCIES AND
COORDINATION MECHANISMS*
ABSTRACT
Interdependency and coordination have been perennial topics
are related because coordination
is
in
organization studies. The two
seen as a response to problems caused by dependencies. Past studies,
however, describe depaidencies and coordination mechanisms only
in general terms,
without
characterizing in detail difference between dependencies, the problems dependencies create or
proposed coordination mechanisms address those problems. This vagueness makes
it
how the
difficult or
impossible to determine what alternative coordination mechanisms might be useful in a given
circumstance or to directly translate these alternative designs into specifications of individueil acHvities.
In this paper
activities
1
develop a taxonomy of dependency types by considering possible combinations of
using resources. The taxonomy includes task-resource dependencies and three types of task-task
dependencies: shared resources, producer<onsumer and
alternative coordination
mechanisms are described.
1
common output.
For each type of dependency,
conclude by discussing
analyze organizational processes and suggest alternative processes.
how
the
taxonomy helps
to
--^
-36
-
A taxonomy of dependencies
Although you
will
perform with different ingredients for different dishes, the same general
processes are repeated over
and over again. As you enlarge your
repertoire,
you
will find that the
seemingly endless babble of recipes begins to fall rather neatly into groups of theme
variations...
and
l
Zhild,
Bertholleand Beck (1981,
p. vii)
INTRODUCTION: DEPENDENCIES AND COORDINATION
Interdependency and coordination have been perennial topics in organization studies. The two
are related because coordination
is
seen as a response to problems caused by dependencies. (Note that
dependency and dependence mean the same
Thompson (1967) hypothesizes
adjustment
—used in response
tfiing; in tfiis
three coordination
paper,
mechanisms
to three different patterns of
I
will use the first term.) For example,
—standardization, plan and mutual
dependencies
—pooled, sequential or
reciprocal (p. 54-55).
Most
studies,
however, describe dependencies and coordination mechanisms only in general
terms, without characterizing in detail difference between dependencies, the problems dependencies
create or
how
diffjcult or
the proposed coordination
mechanisms address those problems. This vagueness makes
it
impossible to determine what alternative coordination mechanisms might be useful in a given
circumstance or to directly translate these alternative designs into specifications of individual activities or
uses of information technology to support a process
[Davenport
& Short,
1990;
Hammer,
1990; Harrison
(e.g.,
as part of a business process redesign effort
& Pratt,
1993]).
For example, consider the process of fixing bugs in a software product, a process
analyzed in a search for alternative coordination mechanisms.
this case site, the
I
will use
I
recently
examples drawn primarily from
software development division of a minicomputer manufacturer, throughout this paper.
Using Thompson's theory,
we might note that programmers all contribute code to a final
thus have a pooled dependency and that they occasionally rely
on each
others'
product, and
work, thus creating a
A taxonomy of dependencies
.
.
among specialists
it
many questions unanswered however.
What dependencies would be
left (or
support
that
if
how else might we
instead of dividing the
work
were performed by generalists? Can we design a process which would reduce or
dependent programmers need
to
For example,
created)
eliminate the sequential dependencies between programmers?
be useful
^
and mutual adjustment are all used.
This analysis leaves
organize this process?
^,
we might find, as predicted,
sequential or sometimes reciprocal dependency. Furthermore,
standardization, plans
'
-
^
this
to
If
not,
what information do sequentially
exchange and when? Would electronic mail or computer conferencing
information exchange?
Although past conceptions of dependency do not directly address these questions, newer
perspectives in
I
will
draw on
artificial intelligence offer
this
work
to
a
more
precise notion of
dependency which might. In
this
paper
develop a taxonomy of different kinds of organizational dependencies and
associated coordination mechanisms.
Organizational research
Dependencies and coordination have been studied by
many organizational
researchers.
Researchers have t^ically conceptualized dependencies as arising between actors rather than between
the tasks the actors
happen
to
be performing. The cause of a dependency
by one actor over outcomes of actions of another or due
Litwak and Hylton (1962),
for
made
this
it
upon
they are to accomplish their goals. Victor and
it
in a game-tiieoretic
could take and each actor's payoff depends on the combined
choice of actions, thus the payoffs an actor gets
is
when two or more
view of interdependency more precise by casting
framework. Each actor has a set of actions
Dependency
if
variously viewed as control
exchanges of resources.
example, define interdependency as
organizations must take each other into account
Blackburn (1987)
to
is
may depend on
the other actors' choice of actions.
defined by "extent to which a unit's outcomes are controlled directly by or are contingent
the actions of another unit" (p. 490).
——
*
- .*
A
-
-
taxonomy of dependencies
An alternative conception
is
presented by
f^
i
McCann and
^
Ferry (1979). They similarly defined
interdependency as "when actions taken by one referent system affect the actions or outcomes of another
referent system" (p.
1
13)<
but they operadonalized
tjhe
degree of dependency
in
terms of the amount of
resources exchanged, the frequency of transactions and the value of the resources to the recipient.
Dependencies usually seem to be assumed to cause problems
(1957) notes that dependencies can be competitive or focilitative.
out in
detail. Instead,
for the actors,
although Thomas
What these problems
are
rarely spelt
is
most authors suggest that as dependency increases, increasingly powerful
coordination mechanisms are used, without specifying precisely what problems these mechanisms
address. Alternately, actors might engage in actions to reduce the degree of dependency
(McCann &
Ferry, 1979).
Most researchers have considered only one source of dependency. One exception
(1974),
who distinguished between
knowledge. As a
is
Permings
four different sources of dependencies: task, role/position, social and
result, past research
has focused more on describing patterns of dependencies rather
than explicating the effects of a dependency on what actors can or should do.
For example,
^k-
-
and
reciprocal
strength.
He
Thompson
(1967) hypothesizes three patterns of
dependency
—pooled, sequential
... -lit
—^with corresponding coordination mechanisms, which he arranged in order of increasing
further suggests that organizational hierarchies will tend to cluster groups with reciprocal
interdependencies most closely, then those with sequential interdependencies, and finally those with
pooled interdependencies.
Van de Ven, Delbecq and Koenig
impersonal (plans and
and discuss
build
are
rules),
of coordinating
work
activities
(1967)
including interdependaicy, that might determine which are used. They
view of dependency, adding a
worked on jointly and simultaneous
"increases in
modes
personal (vertical supervision) and group (formal and informal meetings)
situationcil factors,
upon Thompson's
(1976) identify three
fourth,
team arrangements,
(radner than being passed back
work flow interdependency from independent
and
forth).
in
which tasks
They hypothesize
to sequential to reciprocal to
team
will
that,
be
—
,
'
5-'--
.-
-
^
A taxonomy of dependencies
-"*
-
^
,
(
»
'
'
--.^
_^
-
•
jr?
associated with... large increases in the use of group coordination
mechanisms"
(p. 325),
which they
support with data from 16 offices and the headquarters of a state agency. Mintzberg (1979) describes a
,
similar set of coordination mechanisms: mutual adjustment, direct supervision
standardization: of
While
work
earlier
processes, outputs,
work
They suggest
formality, cooperativeness
skills.
typically hypothesizes a one-to-one relationship
dependencies and coordination mechanisms,
alternative mechanisms.
norms and
and
and four kinds of
McCann and Galbraith
between patterns of
(1981) discuss the jHJSsibility of
that coordination strategies vary along three
localization
dimensions
—and that as dependency increases, the amount of
coordination necessary increases and as conflict increases, coordination strategies chosen become
increasingly formal, controlling
and
They
centralized.
therefore propose a two-by-two matrix
showing
conditions under which orgcinizations will choose to coordinate by rules, mutual adjustment, hierarchy or
a matrix structure.
Martinez and
corporations.
integration
Jarillo (1989)
survey research on coordination mechanisms used by multinational
They define a coordination mechanism
as,
"any administrative
among different units within an orgcuiization"
(p.
490)
and
list
tool for achieving
8 mechanisms identified by
past resecirchers: departmentalization, centralization or decentralization, formalization or
standardization, plcmning, output
socialization.
to
control, lateral ties, informal
to
implement a particular "organizational pattern"
companies choose a structural configuration
implement
communications and
(They do not, however, define integration.) They view the selection of coordination
mechanisms as a way
that
and behavior
to
match
their strategy
(p. 502),
although they suggest
and then choose the mechanisms
it.
There have been other attempts
to
develop a framework for a more detailed analysis, but these
have typically focused on only one kind of coordination problem. For example, Ching, Holsapple and
Whinston (1992) have the goal of developing
a
model of coordination
to
determine
possibilities for
information system support. They contrast networks with markets and hierarchies, but the only
coordination mechanisms they consider are decomposition of tasks and allocation of subtasks to
members
A taxonomy of dependencies
of the network tfirough a bidding
mechanisms extended
to
include the reputation of the bidding
company.
To summarize, most organizational conceptions of dependencies view them as arising between
actors
and describe patterns
the actors
used
to
and
of actor-to-actor dependencies. Furthermore,
and therefore the dependency as given and sought
their tasks
manage dependencies, although some have suggested assigning
dependencies or minimize undesired ones
Research in
artificial intelligence
In contrast to
(e.g.,
and other
most organizational
as in "administrative
I
management theory", Simon,
Researchers in
activities in detail
von
and
adopt
this
approach
artificial intelligence
tried to categorize
Martial, 1989). For example,
1976).
researchers, researchers in the field of artificial intelligence
activities.
This approach has the advantage that
it
allows
Once an assignment is
we can still determine implications of a dependency for a
will
mechanisms
tasks in order to create desired
us to easily examine implications of different patterns of task assignment.
of this advantages,
to identify the
fields
have analyzed dependency as arising between
determined, however,
most researchers have viewed
particular actor. Because
in this paper.
have considered dependencies between pairs of goals or
them
von Martial
(e.g.,
Wilensky, 1983; Stuart, 1985; Decker
(1989) developed a
taxonomy of
& Lesser, 1989;
relationships, both positive,
such as synergies or equality, and negative, such as conflicting use of resources or logical incompatibility.
He suggested
several dimensions for this taxonomy, including explicit vs. implicit
and resource
vs.
non-
resource-based interactions.
Alexander (1964,
p.
106-107) suggests expressing the dependency between design variables
(essentially goals of a design task) as a correlation coefficient. This
(negative)
and
facilitative (positive)
logically necessary or a
sample considered.
He
dependencies.
He
notes furtiier that
product of physical laws, while others
therefore
recommends
that
view allows
may
for
both conflicting
some dependencies may be
simply be true in
two variables be considered
all
designs in the
as interacting only
if
"the
A taxonomy of dependencies
some reason
designer can find
should do so"
....
(p. 109).
(or conceptual
model) which makes sense
to
him and
tells
him why they
A fully specified design space forms a network of linked goals; this space can then
be partition^ into weakly interacting subcomponents to be worked on indepehdentiy.
,
I
While these researchers have catalogued dependencies, few have discussed
coordination methods might be used in response to these problems.
actions that can be taken to
mechanisms
that
manage different kinds
might be appropriate
or provide a resource
if
in detail
what
Yu (1993) does suggest specific
of dependencies. For example, he suggests
one actor depends on another
to
achieve a goal, perform a task
(p. 35).
A framework for studying coordination
In this paper,
I
attempt to develop a richer conception of organizational dependencies by using
drawn from work
concepts
in AI.
To
clarify the relationship
between dependencies and coordination,
use the framework presented by Malone and Crowston (1994),
who define coordination as "managing
dependencies". They analyze group action in terms of actors performing interdependent activities
achieve goals. These activities
case of software
bug
fixing
software company. In
may also require or create resources of various
might
all
to
types. For example, in the
mentioned above, the actors are the customers and various employees of the
some cases,
a group of individuals
may be represented by a
single actor (Abell,
1987, p. 13); for example, to simplify the analysis of a particular subunit, the other subunits v^th
interacts
I
which
be represented as collective actors. Activities include reporting a problem, diagnosing
the problem, developing a fix
and delivering the
fix to
die customer.
The
gocil
of the process in this case
—such as appearing responsive
appears to be eliminating problems in the system, but alternative goals
customer requests
known
—could also be analyzed.
bugs, computer time,
bug
fixes
Finally, resources include the
to
reports, information about
Malone and Crowston's (1994) view,
organizations face coordination problems arising from dependencies. In
how
bug
and so on.
Coordination problems and mechanisms. In
constrain
it
many cases,
actors in
these dependencies
the tasks can be performed. For example, a software engineer planning to change one
A tajfonomy of dependencies
module
in a
'
computer system must check
any necessary changes
to
modules
that the
that will
changes will not
affect other
^
modules or arrange
be affected; two engineers working on the same module must
each be careful not to overwrite the other's changes. Alternately, the problem might be that
sure that a particular dependency exists,
e.g.,
we want actors
to
choose tasks
to
we want to be
perform that will
accomplish particular goals. In other cases, the dependency provides an opportvinity; for example,
same bug has been reported by two
and
fixing the
bug once and sharing
Coordination mechanisms
for
different customers, then the
if
the
company can save time by diagnosing
the solution.
may
be quite
specific,
such as different kinds of code management
systems to control changes to software, or quite general, such as hierarchies or markets to manage
assignmait of activities
for
to actors (or other resource
example, identify several
them including gofl/
Therefore, a
common dependencies and analyze coordination mecharusms
decomposition, resource allocation
different coordination
mechanisms
I
to
manage
and synchronization,. In general, there are many
that could be used to address the
taxonomy of dependencies
present the taxonomy,
assignment problems). Malone and Crowston (1994),
also serves as a
same coordination problem.
way to organize coordination mechanisms. As I
will discuss possible coordination
mechanisms along with die
different kinds of
dependency they address.
To distinguish
different kinds of dependencies,
between. For simplicity,
activities, actors
I
group die elements
and resources
of
I
consider
what the dependencies might exist
Malone and Crowston's
—into two categories:
(1)
the objects that
(1994)
framework
make up
the world, in particular,
those resources needed to perform activities (including the actors themselves); and
to
be achieved or an activity to be performed. In any situation there
may
—goals,
(2) tasks, either a
goal
be multiple instances of each of
these elements, possibly interdependent.
Tasks.
world) and
Tasks include both achieving goals and performing
activities (actions
performed
activities.
Goals (desired states of the
to achieve a particular state) are clearly different.
However,
analyzing activities and goals together makes clear the parallels between decomposing goals into
subgoals to be achieved and decomposing them into primitive activities to be performed.
A second
A
taxonomy of dependencies
advantage of
activities
"
'
this unification is that
it
eliminates
tiie
need
to
analyze
performed by individuals. Treating higher-level goals as
allows us to analyze assignment of goals to a subunit in the same
activities to individuals.
Both goals and
actor (individual or collective) to
which
all
situations to the level of primitive
activities to
way
that
be f>erformed by a subunit
we consider assigning
activities are descriptions of the task to
it is
be undertaken by the
assigned. For example, an outsider (or an analyst interested
company) might think of the purchasing department as j)erforming a "purchase
in other parts of a
materials" activity; to the
members of the purchasing department, however,
achieved by pwrforming numerous
activities,
this is a high-level goal to
be
such as qualifying suppliers, soliciting bids, awarding
contracts, etc.
More powerful
conceptualizations of actions
may help
suggest the different ways actions
interdependent. For example, a typical model of action in AI includes preconditions,
world that must hold before the
become
activity
can be fwrformed) and
true or false as a result of the activity) (Fikes
primitive
compared
to those currently
used in
engineers can diagnose problems, they must
know
the diagnosis.
Of course,
it is
& Nilsson,
clear that actions
Resources.
are not
this analysis,
know
1971). (Actually, this
the
symptoms
world that
model
is
relatively
For example, before
of the problems; afterwards, they also
made
to this
model
to
handle such events
although the model will never be complete. Given such a model,
in several different
it is
ways, with different implications.
include everything used or affected by activities together in this category. Things that
somehow used
activities of
states of the
states of the
possible that they will be unable to diagnose the problem or that their
may be dependent on each other
I
(i.e.,
artificial intelligence research.)
diagnosis will be incorrect. Additional refinements can be
without damaging
effects
(i.e.,
may be
or affected by an activity are not considered;
some actor, then they
if
they are not involved in the
are irrelevcint to the analysis of the behaviour of that actor. Resources
include both material goods and the effort of actors. For example, in the case of a car company, resources
include tools, raw materials, parts, partially completed assemblies, information such as designs or process
instructions as well as the effort of the
employees of the company. Note
particularly important kind of resource.
I
that actors are
viewed simply as a
group actors and other kinds of resources together
in this
way
10
A
taxonomy
of dependencies
despite their significant differences because
many of the
steps necessary in assigning tasks to actors
parallel those involved in assigning other kinds of resources to tasks.
More abstractly,
particular tool setup
is
particular states of the
world might be considered as resources:
example,
if
a
necessary for a manufacturing task to be performed, then that setup might be
considered a resource, possibly to be created by some other task.
differences
for
between resources. The implications of some of these
coordination mechanisms are discussed in
Of course, there are important
distinctions for the choice of
more detail below.
MANAGING TASK-RESOURCE DEPENDENCIES
In
task
Malone
& Crowston's (1994) framework, the important type of dependency is that between a
and a resource. Recall
actions, activities
preconditions.)
required,
effect,
have preconditions and
The preconditions and
consumed
knowing what
that tasks are either goals or activities
the
or created
bug
is,
having a patch that
by an
effects.
activity.
more
generally, states of the world)
having the capability of fixing bugs,
fixes the code. In turn, integrating a
1,
simple model of
For example, the preconditions for fixing a bug include
to the source code,
access to the object code of the entire system,
to the
(We can consider goals as having effects but no
effects are the resources (or
having access
be shown graphically as in Figure
and according
etc.
and
omitting for the
Insert Figure
1
the
patch requires knowing the patch, having
results in a
moment
etc.;
new
system. These dependencies might
possible difference in the types of resources.
about here
Task uses a resource
Consider
first
a task that requires
some
resource.
If
there
is
just
one appropriate resource known,
then that resource must be the one used. This simple case includes an actor deciding that
perform a task
itself
or
knowing only one other
have problems with the operating system,
actor that could perform
typically their only choice
is
it.
For example,
to report the
it
should
when customers
problem
to the
11
...
A taxohomy of dependencies
response centre and ask them to
if
they
knew
the
fix
^
s^
the bug. (Of course, customers
phone number of a developer, they might
would
try to call that
_
more options;
like
person
directly;
if
for
example,
they had
access to the source code, sophisticated customers might try to fix certain bugs themselves.)
More commonly, however,
of resource assignment,
i.e.,
there are
knowing a
many possibly appropriate
task with a precondition
that satisfies the precondition. In the remainder of this section
a resource
whai
there
is
I
resources, creating the problem
and looking
for
will consider the steps necessary to assign
a set of resources, one of which might be appropriate.
problem of assigning a task
an appropriate resource
I
mostly discuss the
be performed, but most of the steps discussed are
to a particular actor to
necessary to assign any kind of resource to a task.
In order to assign resources to a task, the following steps
(This
is
must be performed:
1)
identifying
what resources are required by
2)
identifying
what resources are available;
3)
choosing a particular
4)
assigning the resource (in the case of an actor, getting the actor to
the task;
set of resources;
—
essentially aruautline of a decision process
intelligence, design
work on
the task).
—wJbere
and choice
first
step
is
divided into intelligence about the needs of the task and about the available resources.)
In principle, these steps can be
performed
in
any order. For example, tasks can be chosen
that can
be performed with resources available (and that achieve higher level goals). For example, one manager
interviewed suggested that in software development, a manager might divide a system into modules
based on the
abilities of
the problem.
A garbage can model might suggest that all
the
programmers who
connect more-or-less by chance (Cohen, et
al.,
will
work on them,
steps
rather than
on some a priori division
of
go on simultaneously and occasionally
1972). For convenience,
however,
I
will discuss the steps in
the order listed.
12
A
taxonomy
of dependencies
Identifi/ing necessary resources. First, the
resources needed by a task must be identified. For
example, determining in which module of the system a bug appears identifies the resources needed by
that task
(i.e.,
an engineer with expertise
what kind of resources are available
to
be able
module). In some cases the assigner
may need
specialists
and
to
know
same
to characterize the task requirements along the
may range between two extremes:
dimension. For example, actors' roles
specialist
in that
generalists. In a
model, only one actor can perform any given task, so the needs of the task must be identified in
terms of these actors' specializations. In the generalist case, any actor can perform the
task. In reality,
things are rarely so precise, but organizations will be located along the spectrum between these
two
extremes.
Identifi/ing available resources.
simplest case, there
This
may be due
is
Second, a set of appropriate resources must be identified. In the
only one potential resource, for example, only one actor, that can perform the task.
to specialization of roles of
departments or individuals
particular task) rather than a distribution of ability
case there
The
may be several
available resources
resources,
(i.e.,
who
what resources might be appropriate
(e.g.,
making
to the assigner; the assigner
some of which may be appropriate; or
the assigner
for the task. Obviously, there cire
availability, motivation, etc.
many
to evaluate
possible bases for
supposed
to
do a
it
necessary to choose one.
may know a larger set of
else).
Choosing a resource. Third, one particular resource must be chosen.
some way
is
may have to spend some effort identifying
by asking someone
other resource from those available requires
who
capable of doing the task). In the general
is
resources that could be used for the task,
may be known a priori
(i.e.,
making
To choose a
particular actor or
how good a particular resource v^ill be
this decision,
such as speed, quality,
For example, assigning bug reports to the next free engineer
choose a particular resource based on availability rather than expertise. Which
criteria to
is
a
way to
use depends on
the nature of tasks being coordinated.
In
some cases,
it is
important to consider
resources are required at the
are free.
Numerous
same
when
the resources are available, especially
time. In this case, the choice
if
multiple
depends on when the required resources
techniques have been developed to schedule multiple resources. For example, Ripps
13
A taxonomy of dependencies
(1991) presents a
taxonomy
of
'
;
mechanisms
which includes numerous mechanisms
^
^
,
.^
,
for task synchronization in a real-time
for transferring information
& Davis,
'
programming system
between tasks or avoiding conflicts
over resources. Sen (1993) discusses coordination mechanisrrts that might be applied
resource scheduling, including contract-nets (Smith
_.
to distributed
1981), distributed search
and multi-agent
planning.
Assigning resources. Finally, the assignment of the resource must be communicated to the actor
As
performing the
task.
other assigners
warned
actor
must be
told to
significantly (e.g.,
well, for non-shareable resources, the resource
to
avoid conflicting assignments.
perform the
Where
task.
when the interaction
individuals), the assigner
may have
to
is
must be marked as
"in use" or
When die resource is the effort of an actor, the
the personal goals of the individual actors differ
non-routine or
when
the actors are
whole firms rather than
convince the performer to do the task by designing appropriate
incentives schemes or monitoring performance. Kraus (1993) discusses techniques for obtaining
cooperation in non-cooperative distributed problem solving systems. In addition, as
reminds
the
two
us, "origination of action"
is
Whyte
(1948)
often complicated by the relationship or status differences between
individuals.
In other cases, such effort will be unnecessary. For example,
legitimate requester to
do
task assignments in the
programmed
a task that
companies
I
if
employees are asked by a
their definition of their job, they are likely to
fits
studied had this character.)
simply do
it.
(Most
Computer actors might not be
to refuse requests. In other cases, of course, the conditions
had
to
be negotiated, as with
bidding for a contract v^ath an external company. Differences in these important motivational features
will
presumably
affect cin assigner's choice of performer.
Example resource allocation mechanisms. Different coordination mechanisms for resource
assignment can be analyzed as particular choices
resources are
owmed by
the organization;
appropriate for a given task.
based on factors
known
If
if
for these four steps. In a hierarchy, the available
the resources are specialized, there
may be only one
the resources are generalized, the choice between
to the assigner,
such as workload, or be delegated
to the
them may be made
group. In a market, the
14
A taxohomy of dependencies
""
"^
available resources are those competing in the market place. Appropriate resources are identified through
advertising or requesting bids and the choice between
interested resources. In a
network organization (Ching,
the network; typically each
assignment
in
Table
is
them made based on the bids submitted by the
member has
et
al.,
1992) the resources are those that belong to
a particular specialization
it
brings to the network. The basis for
reciprocal relations, rather than contracts or hierarchy. These alternatives are
summarized
1.
Insert Table
1
about here
Task produces a resource
Another kind of coordination mechanism
is
to
choose tasks that have a particular
effect,
thus
maintaining a goal-resource relationship between the desired resource and the tasks. To choose the tasks
is
a plcinning task, for
which many methods have been investigated
an actor must know the
effect to
be achieved and
know
(or
(e.g.,
(Allai, et
may have
to
1990). In general,
be able to generate) possible tasks (subgoals or
primitive activities) and their preconditions and effects, and be able to choose
decompositions. As well, the actor
al.,
among
multiple possible
choose tasks that create needed resources
(i.e.,
that
maintains a precondition dependency, discussed below), for example by performing a meems-end
analysis.
For example, an engineer with a large change
smaller changes
made
to
implement might decompose the work
to several different parts, e.g., to different
on each of those changes independently.
modules
Similarly, process engineers
of the system,
decompose goals
activity that
If
into activities. Alternately,
appears
to
move closer
an actor might proceed one step
to the desired goal,
performing
multiple subtasks are performed to accomplish
their results. This integration step
is
cmd then work
decompose a design
operations the assembly workers can perform to assemble the cars. There are obviously
it
some effect,
at a time,
into specific
many ways
to
choosing an
and then reassessing the
it
into
may be necessary to
situation.
integrate
frequently viewed as a kind of coordination task. However,
I
believe
15
.
-
i
>
A taxonomy of dependencies
i
~
-
-
_
"
•
that integration can be
viewed as simply another part of performing the
into multiple subtasks,
one of which may be
to integrate the results.
task, that
modules
to
be submitted
An integration group may be formed
group knows
into the final system. This
working operating system and how
is
For example an engineer
decomposes a task and requests changes from other engineers may be responsible
changes together
a task
is,
for
to integrate
how to recompile and
*
-«
s^
•.
decomposed
who
grouping the
changes
link the different
to various
modules
into a
to test the resulting system.
MANAGING DEPENDENCIES AMONG MULTIPLE TASKS AND RESOURCES
In general, of course, there are multiple tasks
in this
and resources
paper suggests that the only way two tasks can be dependent
resource. Figure 2
(the boxes); the
there are three
shows the
=et of possible
to be considered.
is
via
some kind
dependencies between two tasks (the
The view proposed
of
circles)
arrows indicate flows of a resource that are either produced or used. In
ways two
tasks might
dependencies: overlapping
Similarly, a single task
effects,
have something
in
common and
common
and resources
this
framework
therefore three major kinds of
overlapping preconditions and overlapping effects and preconditions.
might use several resources, consume one resource
cind create another or create
multiple resources. Each of these cases will be considered in turn below.
Insert Figure 2
about here
Shared resource
Two
tasks are interdependent
require additional
additioncd
work is
shareablity
and
work
to share that resource. Clearly the nature of the resource will
necessary.
I
reusability, as
Shareablity describes
material, tools or effort
both have the same resource as a precondition, which might
if
determine what
consider in particular two dimensions along which resources differ:
shown
in
Table
how many
2.
tasks can use the resource simultaneously.
—are non-shareable. Note that an actor may be assigned
to
Most resources
— raw
multiple activities, but
16
A taxonomy of dependencies
works on only one
at
any
since multiple tasks can use the
Reusability describes
Some
and other
instant. Information
same resource
how many
if it is
states of the
world are important exceptions,
not changed by the tasks.
tasks can use the resource over time (von Martial, 1989, p. 62).
resources, such as tools or information, can be used
and reused;
others, such as
only be used once. Of course, tools do eventually wear out; the key distinction
will
be able to use the resource
materials. (Note the
if it
waits, as with tools, or
no resources appear
the
common resource is shareable,
time. For example,
there
materials can
whether another task
the resource will be gone, as with most
raw
both shareable and consumable.)
to
Insert Table 2
If
if it
is
raw
about here
then there
is
no
conflict for
two
actors to use
it
at the
same
two engineers can use the same piece of iriformation without any problem (although
may be conflicts
for the physical
media on which the information
is
stored, a non-shareable but
typically reusable resource).
If
the resource
is
not shareable, then the two tasks can not be performed simultaneously with the
available resources. Additional resources
the resource
time.
Note
is
must be acquired or one of the
tasks selected to be performed.
If
reusable then the conflict can also be resolved by perfornung one of the tasks at a different
in particular that this applies to
an actor performing multiple
tasks: the actor
needs to pick an
order in which to do the tasks (for example, by prioritizing them and doing the most important or urgent
ones
first).
Managing
this
dependency frequently requires additional work. Since
exclusion" problem in computer science,
applicable. First, the conflict
many physical
information,
must be made
resources, the act of using
or in a conference
room
many
will prevent
it
of the solutions
visible, typically
developed
it is
for that
similar to the "mutual
problem may be
by marking the resource as being
in use. For
may be sufficient (e.g., sitting in front of a computer
anyone
more elaborate schemes may be
else
from using
it).
For
less tangible resources,
terminal
such as
necessary. For example, a code check-out system prevents
17
A taxonomy of dependencies
two engineers from modifying the same source code module
at the
some kind of locking mecharusm to prevent concurrent updates
is
same
time;
to a piece of information. If the resource
not marked as being used, the performer of the task can so mark
and then use
it
being used, the performer must either monitor the status of the resource until
to
be notified
when
the
first
task
is
facilities
to the schedule.
are frequently allocated with a sign-up
might have
to
at the
same
simultaneity dependency. For example,
is
becomes
certainly a
far are
used
free or arrange
avoid conflicting use of a
to
time.
ail
Malone and Crowston
attendees of a meeting
common coordination
problem.
,
i.e.,
several tasks
(1994) call this relation a
must attend
at the
same time and
We might model tius situation as
several "attend meeting" activities joined with a simultaneity constraint, but
a "hold meeting" activity
marked as
For example, conference rooms and
one task might require the concurrent execution of anotfier task
be performed
meeting scheduling
If it is
list.
The coordination mechanisms we have discussed so
resource. Conversely,
it
it.
completed. Alternately, the use of the resource might be scheduled
ahead of time and both task performed according
other
most databases provide
it
seems
model
easier to
which requires multiple resources simultaneously. (Coordination methods
assigning multiple resources are considered below.) Similarly, two people lifting a piano must
ends simultaneously, but
this activity is
probably best modelled as a
lifting action
Alternately,
it
may be necessary
as
for
their
which requires
multiple people. This approach eliminates the category of simultaneity constraints but for
might require the conceptual creation of an unnatural aggregate
lift
it
some cases
task.
ensure that two tasks both use the same version of a resource.
to
For example, two designers working on the detail design of components of a product should be using the
same version of
all
the overall design. (Note that
and so are not subject
resources, then the
to this problem.)
problem
is
to
If
consumable resources can not be used by different tasks
we consider different versions
choose resources
to
be used by the tasks
of a resource to be different
to
ensure that there
is
a shared-
resource dependency between Ihem. This problem seems very hard. Solutions include destroying
obsolete resources, to ensure there
is
at
all
only one resource, checking the status of the resource or making a
18
A taxonomy of dependencies
new copy of the
problems
resource prior to each use, or tolerating a certain level of disagreement and repairing
after the fact.
Producer-consumer
If
a resource
is
the effect of one task
dependency between the two
and a precondition of another then there
tasks, requiring that the tasks
is
a precedence
be performed in the correct order and the
flow of the resource between the two be managed. This relationship frequently holds between steps
process. For example, in software changes, fixing the
bug has
the effect of creating a patch
which
is
in a
a
precondition for integrating the complete system.
(1994) point out that precedence dependencies imply additional
Crowston and Malone
constraints
creates
in fact
is
—ensuring that what the task
what the second needs —or an inventory constraint—ensuring that the resources needed
on how
tasks are performed, such as a usability constraint
first
by the second task are available when needed. Usability constraints can be managed by
standcirdization,
by negotiation between the user and creator or by giving the creator additional information about the
needs of the user. For example,
work
in
an engineering context, design and manufacturing aigineers might
together to develop products that are easy to manufacture or designers might be trained in the
requirements of manufacturing processes ("design for manufacturability"). Quality control tasks
seen as a
way of ensuring
that
kinds of approval processes
an output of one task
may also be serving this
adding buffers between the two processes
to the rate of use, as
to
is
in fact the correct
input for the next.
function. Inventory constraints can be
smooth the flow of material or tying the
widi the "producer/consumer" problem
in
Ccin
be
Many other
managed by
rate of
production
computer science or just-in-time
manufacturing.
Alternately, a resource required
another,
what
is
by one
task
may be inadvertently or necessarily destroyed by
called "clobbering" in the planning literature (Sussman, 1974, p. 116). In construction, for
example, installing one piece of equipment
may block access need
to install another. Fixing the clobber
19
;
A taxonomy of dependencies
'
..
can be done by reordering the steps
avoid
to
this
,
problem or possibly adding an additional task
to
recreate the resource or state of the world.
Common object
The effects of two
may be the same resource. This dependency can have either positive or
tasks
negative effects, which requires additional effort to exploit or avoid.
create die
same
resource, then
it
its
production.
To exploit
times. Rather than fixing
engineers check
resource or taking
these possible synergies requires additional
if
and
refixing the
a reported problem
same problem may be reported
same problem,
in a
is
database of
tiie
resource (the
to a software
compemy
known problems.
If it is,
then the already
which would create a duplicate
tasks specify different aspects of a
common
resource, then
may
it
be necessary
to
additional task of negotiating a mutually acceptable output. For example, the interface between
common object created by
developing the two modules. Finally,
then
it
may be
more detail below:
at the
same
the design of the modules,
if
may be negotiated by
add an
two
the engineers
the effects conflict, for example, both doing a task
and not doing
impossible to perform both tasks. Possible resolutions of this dependency are
interestingly similar to the case
in
known
bug fix).
two
modules, a
multiple
customer service centre and marketing
solution to the problem can simply be reused, thus eliminating a task
it,
i.e.,
such as checking for duplication before one or both of the tasks have been performed and
distributing the output. For example, the
If
both tasks do the same thing,
may be desirable to merge the two tasks, reusing the
advantage of econorrues of scale in
activities,
If
either
where two tasks both require the same non-shareable resource, discussed
abandoning one task or scheduling them so they do not have
to
be achieved
time.
Dependencies between one task and multiple resources
The
three cases
where
a task
is
—
dependent on multiple resources
producing two resource or using one resource and producing another
either using
—seem to be
less
two
resource,
problematic than
20
-
A taxonomy of cfependencies
the cases discussed above.
Of the
three,
only the
i^
first
seems
to
pose
~
difficulties. In this case, there is a
to synchronize the availability of multiple resources. For example, multiple people attending a
need
meeting
can be modelled as a "hold meeting" task that requires several peoples' efforts simultaneously, as
discussed above; most production activities require an actor, raw materials and tools simultaneously.
This dependency can be
managed by f>ermanently assigning all
resources, or
one, to the task. For example, a production activity might always be performed
which
always operated by a particular
is
single resource, as discussed above.
activities. In this case, the
actor. In this case, this
on a
all
resources but
particular machine,
dependency reduces
to a task
More generally, some of the resources may be used by
dependency
is
typically
managed by scheduling
using a
multiple
die use of the resources, as
discussed above. As well, computer scientists have develof)ed algorithms for assigning resources to avoid
deadlock
(a
condition where one task
waiting for the
first)
is
waiting for a resource held by the another, which in turn
and starvation (where a task waits forever
for the resources
it
needs
to
is
become
available).
Multiple modes of use
A resource may appear as both a precondition and effect of some task; for example, modification
or consumption of a resource can be modelled this way. The resulting dependencies are the combination
of the dependencies from the individual operations.
software module
effect-effect
(a
shareable/reusable resource) must
dependencies.
dependency causes no
might.
If
Two engineers who both want
From
we can see that the
both can read the module
freely),
precondition-precondition
but the effect-effect dependency
they are both making the identical change, then one of the tasks can be eliminated; otherwise,
they will have to negotiate to ensure the resulting module
fixed). Alternately, the
module could be viewed
so
one makes changes and then the
is
acceptable to both
(i.e.,
that both
bugs are
as a non-shareable/ reusable resource. In this case, the
precondition-precondition dependency must be managed,
module
modify a single
manage both precondition-precondition and
the previous discussion
conflict (they
to
e.g.,
by scheduling the engineers' use of the
other.
21
A tax5nomy of dependencies
'.^
-.
„
DEPENDENCIES BETWEEN TASKS OR BETWEEN RESOURCES
In developing this
taxonomy,
model would include dependencies
alternative
particular, both tasks
tasks can be
decomposed
into subtasks,
between tasks and subtasks,
that
However, there does not app>ear
the
in the set of coordination
number of dependencies
It is
together in
that arise
task,
is,
to
a
and an
be
to
much
mechanisms
hierarchies: higher-level
object into components.
planning might be viewed as a
way
choose a
way
set of activities that
difference
between
applicable.
It is
this
manage
to
interdependencies are
managing the
the relationship
accomplish a desired
task.
view and the view proposed
in this
probably conceptually simpler to minimize
considered.
also possible for different resources to be interdependent, for example,
some kind
An
between tasks or between resources. In
and resources can be thought of as forming decomposition
Given such a model of a
paper
considered only dependencies between tasks and resources.
I
by being connected
of assembly, such as the parts of a car or of a computer system. These
clecirly
interfaces
important: an essential part of change management, for example,
between parts
to
ensure that changes
to
one part do not
is
interfere with the
function of another.
It is
probably simplest
to think of these interdependencies as
forming components into a larger
resource and then analyzing the dependencies as created by that resource. In other words,
if
two
tasks
use different resources that are interdependent in this way, then the two tasks can be analyzed as both
depending on a larger
common resource.
Conversely, two tasks
resource because they are each dependent on components of a
cooking tasks
(e.g.,
more complex
may both appear to consume an orange, because one requires
pulp. Schelling (1978) describes
a system
may appear to be using a common
numerous
instances
where an
the racial composition of a neighbourhood)
subcomponent of the system
(e.g.,
one person deciding
to
and
activity
affects
move
in or
resource. For example,
its
rind
and the other
two
its
depends on the macro properties
it
indirectly
of
by changing a
out of the neighbourhood).
22
A taxonomy of dependencies
Nevertheless,
exist.
it is
clear that to
these dependencies, actors
must
For example, for engineering change management, engineers must spend
which other engineers need
to
manage
to
be informed of a proposed change to a
first
identify that they
some effort
part. Alternately,
an actor may have
choose or create another resource that maintains the given dependency. For example,
large system, engineers
may need
to
choose component parts that maintain desired
to identify
in
designing a
relations.
DISCUSSION
The framev^ork presented here makes a
a coordination
it.
theoretical claim
about the design of organizations: given
problem caused by a dependency, some coordination mechanism
This claim has implication for the cinalysis and design of organizations.
process,
used
to
it is
is
necessary to manage
To analyze an
organizational
important to identify the dependencies that arise and the coordination mechanisms that are
manage
those dependencies. Fortunately, as
Simon
(1981) points out, in practice
"most things are
only weakly connected with most other things; for a tolerable description of reality only a tiny fraction of
all
possible interactions needs to be taken into account" (p. 221),
what he calls
(he
"empty world
hypothesis".
To design
a
new
process,
it
will
be useful
could be used to nwiage those dependencies.
what ways can
to
consider alternative coordination mechanisms that
One question I posed
at the
beginning of
a given organization be arranged differently while achieving the
same
this
paper was, in
goals?
Understanding the coordination problems addressed by an organization suggests alternative
coordination mechanisms that could be used, thus creating a space of possible forms.
look for
more systematic approaches
concrete example,
1
will discuss the
and consider other ways the
One approach is
methods
to
to searching this
way problem
task could
is
to
useful to
reports are assigned to software engineeis to be fixed
have been organized.
to identify the basic steps of the task to
develop a patch
may be
design space. Several strategies are apparent. As a
be performed and add coordination
manage problematic dependencies. For example, we might decide
change process
It
to fix a set of
symptoms, which involves
that
at a
primary goal of the
minimum diagnosing
23
A taxonomy of dependencies
the bug, writing
who
initially
unable
to
new code and
knows about
perform
integrating
tfiat
code with the
this task, the user of the
this task
because of a lack of
system
skills,
rest of the system.
However, the person
who has encountered a
correct tools, etc. Therefore,
problem,
ti|iere is
is
usually
a problematic
dependency between the task and those resources, requiring a resource assignment coordination
mechanism
to find the appropriate resources. For the customer, a
the only other actor the customer
knows about is
simple mechanism can be chosen, since
the company's supf>ort group. This analysis can be then
repeated for the other activities and actors involved.
As
.;
^
.
•
well, alternative assignments of abilities can be considered. For example, custonr>ers could be
given the means to do some of the work themselves; for example, some companies provide customers
access to their database of
known
bugs, allowing the customers to see
if
their
problem has already been
reported and perhaps find a solution. Facilitative coordination mechanisms can also be added. For
example, since one possibility
is
checking to see
already known. In the
initially
if
a solution
is
by the service centre
that this task
staff,
is
actually a duplicate of
company
I
some other
task,
studied, this check
but in principle, anyone could do
it
it
might be worth
was performed
(including, as discussed above, the
customer).
A second approach would be to start with existing organization and modify
substituting different coordination
mechanisms
for those currently used.
redundant steps or mismatches between tasks and
actors' skills. For
it
incrementally by
As well, one could look for
example,
many of the actors
in the
mini-computer manufacturer perform some part of a task assignment mecharusm to assign the task
engineer with the appropriate
skills. In
are generalists rather than specialists
other companies (and other parts of the
and task assignment
This system has the advcuitage of spreading the workload
is
to
an
same company) engineers
based on workload rather than expertise.
more evenly and reducing the need
for
engineers to coordinate changes for one bug, but does not promote or take advantage of any expertise
engineers might have.
A more radical change might be to
problem
use
some kind
reports. In this case, a description of each
of market-like task assignment system for
problem report would be sent
to all available
or
24
*
-
^
.
«
A taxonomy of dependencies
interested engineers. Engineers
who couid
how much it would
to fix the bug,
be assigned the
task. This
fix
the
bug would submit a
what they would
cost or even
would be given
them. Second, there must be a
Finally, the assigner
need some way
and
cost)
to
also
shows what
common
how
communicate with the task
Additional substitutions might be
it.
and
long
it
would
long
The lowest bidder would
generalist systems: at
is
necessary to perform this kind
it
performers and be able to
would take
For their part, the performers need to
to fix the
problem
(or
how much it
possible by the use of information technology. For
example, while market-like mechanisms have theoretical performance advantages, the disadvcmtage
and evaluated,
etc.
any
assigner.
made
that there are expensive to run: each report
take
language in which the tasks can be described.
to evaluate the bids returned.
be able to evaluate each task and estimate
would
specialist
know which actors are potential
of task assignment. First, assigners need to
v^ath
do
how
the task.
The analysis of the coordination mechanisms
communicate
bid, saying
charg:: to
system would have the benefits of both
point, the best person available
i
must be read by multiple engineers, bids must be
is
collected
However, many of these steps could be automated, thus reducing the cost of the
scheme, perhaps enough
to
make
it
attractive.
For example, engineers could use rules to
filter
out
desirable or undesirable tasks (Malone, et al.,«1989); bj^s could be automaticaUj: collected and,tasks
^
assigned.
Many coordination mecharusms create the need
up
list
for a resource or a centralized
information
is
list
to access or
of reported problems
and bug
fixes.
Traditionally such
kept on paper and can therefore be kept up-to-date only be in one place, either centralized,
which makes choosing among multiple resources
easier or decentralized,
particular resource easier. Either approach requires additional
technology
update information, such as a sign-
may make it possible to do
work
which makes accessing a
to share the resources. Information
both.
25
A taxonomy of dependencies
CONCLUSION
In this paper,
This taxonomy
(activities
is
I
present a taxonomy of dependencies and associated coordination mechanisms.
based on a simple ontology which includes resources (actors or other objects) and tasks
or goals to be accomplished). For simple task-resource dependencies,
analyzing the steps in resource assignment mechanisms.
considering
The
how a common resource is
resulting dependencies
present a framework for
More complex dependencies
used by the two tasks or
how one
are analyzed by
task can use multiple resources.
and coordination mechanisms are summarized
Insert Table 3
I
in
Table 3.
about here
Evaluation of contribution
Since a
taxonomy per se
is
not a theory (Bacharach, 1989, p. 497),
my primary focus has been on
the theoretical constructs, namely dependencies, the problems created by dependencies
coordination mechanisms actors use to
manage
those problems. Although Doty
1994) suggest that a typology Ccm be a theory, their analysis
relate characteristics of those organizations to
performance and
is
is
of typologies of
some dependent variable, such
of this
constructs are distinct from each other.
characterizes coordination
work should be on
whole organizations
that
the quality of these constructs: their validity
The taxonomy probably
methods on the
reasons to choose what to do.
basis of a small
errs
number
on the
dependencies should
fit
As
into
well, the
seems
clear that these
parsimony since
it
of factors, while obviously there are
On the other hand, as (Bacharach,
a critical basis for cumulative research".
It
side of
1989,p. 500) says,
most abstract and broad perspectives on organizations, while not necessarily
all
& Click,
as organizational
(Bacharach, 1989, p. 497), comprehensiveness and parsimony (Whetten, 1989).
sense that
and Click (Doty
not directly applicable to the taxonomy presented here.
The primary evaluation
many
and the
taxonomy attempts
to
"some
rich in detail,
of the
have provided
be comprehensive,
in the
one or another of the three categories. Clearly, additional
26
A taxonomy of dependencies
dependencies and coordination mechanisms need
the
taxonomy seems
to
to
be added and the categories further refined. Finally,
be useful, as discussed above.
Future research
Much
remains to be done. The focus on processes suggests that
examples of processes
the coordination
compare the coordination problems
to
likely to
is
mechanisms
However,
that arise (Malone, et
al.,
to collect
1993)
many
and
identify
it is ^'<=o
to
of
be substantial overlap. For example, do Japanese companies use a
manage engineering changes?
irrportant to identify the limitations of this work.
focused on tasks. Organizations that do not perform tasks
tasks (for
important
mechanisms used. Other kinds of orgeinizations may have somewhat different kinds
problems, although there
different set of
it is
example software requirements analysis
for
may not find
diese
The overall framework
mechanisms
complex computer systems) seems
useful.
to
is
Some
be more
about developing a shared understanding of the tasks and dependencies as opposed to actually
performing them (Kammerer
Even with these
better understanding of
designing
1993).
limitations, the initial results of this
what
is
necessary for coordination
new computer applications,
for explaining perceived
If
& Crowston,
for analyzing the
work should be
may
useful in several ways.
A
provide a more principled approach for
way organizations are currently coordinated and
problems with existing approaches
better formalized, the kind of analysis sketched
to coordination.
above could be incorporated into an expert
support system. Such a system, given a task to be performed and the set of actors available, would
suggest alternative ways to organize the actors or work out the implications of particular organizational
designs. Based
coordination
on the
recipes for different coordination mechanisms, the system
work each agent would do and even what kinds
of support systems
systematically exploring the space of possible coordination strategies,
entirely
new organizational
forms, forms that are
more
would suggest what
would be
we may even be
useful.
By
able to discover
efficient, flexible or satisfying to their
members.
27
.<^
»4-
<-4
A
taxonomy of dependencies
REFERENCES
Abell, P. 1987.
The Syntax of Social
Life
;
The Theory and Method of Comparative Narratives Nev^
.
York: Clarendon Press.
Alexander, C. 1964. Notes on the Synthesis of Form Cambridge,
.
Allen,
J.,
Hendler,
Bacharach,
Ching,
J.,
& Tate, A. (Eds.).
S. B. 1989.
Review.
Child,
J.
1990.
MA: Harvard
University Press.
Readings in Planning San Mateo, CA: Morgan Kaufmann.
.
Organizational theories:
Some criteria
for evaluation.
Academy
of
Management
14(4): 496-515.
Bertholle, L.
C, Holsapple,
& Beck, S.
C.
1981.
Mastering the Art of French Cooking
W. & Whinston,
A. B. 1992. Modeling
.
New York: Alfred A.
Network Organizations:
Knopf.
A Basis for
Exploring Computer Support Coordination Possibilities Unpublished mfinuscript. Decision
.
&
Information Systems, College of Business, Arizona State Univeristy.
Cohen, M.
D.,
March,
J.
& Olsen,
G.
J.
Administrative Science Ouarterly.
Davenport, T. H.
& Short,
E. 1990.
J.
Decker, K.
S.
& Lesser, V. R.
control. In
M. Benda
1989.
(Ed.),
17: 1-25.
The new
business process redesign. Sloan
A garbage can model of organizational choice.
P. 1972.
industrial engineering: Information technology
Management Review. 31(4):
Some
initial
CDPS network
Proceedings of the Ninth Workshop on Distributed Artificial
:
& Click, W. H.
11-27.
thoughts on a generic architecture of
Intelligence 73-94. Rosario Resort, Eastsound,
Doty, D. H.
and
1994. Typologies as a
understanding and modeling.
WA.
unique form of theory building: Toward improved
Academy of Management Review.
19(2):
230-251.
29
A taxonomy of dependencies
Fikes, R. E.
& Nilsson, N.
problem solving.
Hammer, M.
J.
-» '*
1971. STRIPS:
A new approach to the application of theorem proving to
Artificial Intelligence.
2:
198-208.
1990. Reengineering work: Don't automate, obliterate.
Harvard Business Reviewduly-
August): 104-112.
Harrison, D. B.
& Pratt, M.
D. 1993.
A methodology for reengineering business.
Planning Review.
21(2):
6-11.
Kammerer,
& Crowston, K. 1993.
E.
Coordination and Collective
Mind
in Software Requirements
Development Unpublished manuscript. University of Michigan, School of Business.
.
Kraus,
S.
Agents contracting tasks
1993.
in non-collaborative
environments. In Proceedinf
Eleventh National Conference on Artificial Intelligence 243-248. Washington, EXZ:
:
Press/MIT
Litwak, E.
AAAI
Press.
& Hylton, L. F.
1962. Interorganizational analysis:
Administrative Sciences Quarterly.
Malone, T. W.
of tl.s
& Crowston, K.
1994.
A hypothesis on coordinating agencies.
395-420.
6(4):
Toward an
interdisciplinary theory of coordination.
Computing
Surveys. 26(1): 87-119.
Malone, T. W., Grant, K.
R., Lai, K.-Y.,
Rao, R.
& Rosenblitt, D.
1989.
The Information Lens: An
system for information sharing and coordination. In M. H. Olson
Work Group
Martinez,
McCann,
J.
.
& Jarillo,
J. I.
research.
Collaboration Hillsdale, NJ: Lawrence Eribaum
J.
C. 1989.
The evolution
of research
(Eds.),
intelligent
Technological Support for
& Associates.
on coordination mechanisms
in multinational
loumal of International Business Studies 489-514.
E.
Academy
:
& Ferry, D.
of
L. 1979.
An approach
Management Review. 4(1):
for assessing
and managing
inter-unit interdependence.
113-119.
30
.
A taxonomy of dependencies
McCann, J.
(Eds.),
E.
& Galbraith,
The Handbook
J.
R. 1981. Interdepartmental relations. In P. C.
of Organizational Design (Vol.
2):
60-84.
Mintzberg, H. 1979. The Structiiring of Organizations Englewood
.
Pennings,
J.
1974. Differentiation. Interdependence
Nystrom
& W. H. Starbuck
New York: Oxford
University Press.
Cliffs, NJ: Prentice-Hall.
and Performance in Formal Organizations Paper
.
presented at American Sociological Association Annual Conference, Montreal, Camegie-Mellon
University.
Ripps, D. L. 1991. Task coordination: Specific methods, general principles.
Schelling, T. C. 1978.
Sen,
S.
Micromotives and Macrobehavior
.
EDN (March 1): 97-110.
New York: Norton.
1993. Predicting Tradeoffs in Contract-Based Distributed Scheduling,
Dissertation, University of Michigan,
Department of Computer Science and Engineering.
Simon, H. A. 1976. Administrative Behavior (3rd
Simon, H. A. 1981. Sciences of the
Smith, P.. G-
ed.).
Artificial (2nd ed.).
New York: Free Press.
Cambridge: MIT
Press.
& Davis, R?-1981. Frameworks for cooperation in distributed problem solvi^^.
Transactions on Systems.
Stuart, C. 1985.
An
Man and
J.
IEEE
Cybernetics. 11(1): 61-70.
implementation of a multi-agent plan synchronizer. In Proceedings of the Ninth
International loint Conference
Sussman, G.
Unpublished Doctoral
1974.
on Artificial
The Virtuous Nature
Intelligence (IICAI-85) 1031-1033.
of Bugs. In
:
J.
Allen,
J.
Hendler
& A. Tate (Eds.), Reading s in
Planning 111-117. San Mateo, CA: Morgan Kaufmann.
:
Thomas,
J.
1957. Effects of facilitative role interdependence
on group functioning.
Human Re lations.
19:
347-366.
31
A taxonomy of dependencies
Thompson,
J.
D. 1967.
.
Organizations
—
,
--
Theory
in Action; Social Science Bases of Administrative
.
New
York: McGraw-Hill.
Van de Ven, A.
H., Delbecq, A. L.
organizations.
Victor, B.
1976. Determinants of coordination
American Sociological Review.
& Blackburn, R. S.
Management Review.
von
& Koenig, R., Jr.
1987. Interdejjendence:
12(3):
41(ApriI): 322-338.
An alternative conceptualization. Academy of
486-498.
M. Benda
Martial, F. 1989. Multiagent plan relationships. In
Workshop on Distributed
(Ed.),
Proceedings of the Ninth
Artificial Intelligence 59-72. Rosario Resort, Eastsound,
:
Whetten, O. A. 1989. What constitutes a theoretical contribution?
14(4):
modes within
Academy
of
WA.
Management Review.
49(M95.
Whyte, W.
F. 1948.
Human
Relations in the Restaurant Industry
Wilensky, R. 1983. Planning and Understanding:
Reading,
Yu,"E. 1993.
MA:
New York:
McGraw-Hill.
A Computational Approach
to
Human
Reasoning
.
Addison-Wesley.
Modeling organizations
Requirements Engineering
Method
.
for information systems requirements engineering. In Pfoc. of
'93: 34-41.
of Comparative Narratives.
.
Abell, P. (1987). The Syntax of Social Life
:
The Theory and
New York: Clarendon Press.
32
A taxonomy of dependencies
TABLES AND RGURES
FIGURE
1
Tasks use or produce resources.
^
D
^^^SOy^Cl^^
Kii5UUKL.t
I
PRODUCES A
RESOURCE
33
—*
A
taxonomy of dependencies
TABLE
1
1
A
taxonomy
of dependencies
nGURE2
Dependencies between multiple tasks and resources
O TASKS
\n/
SHARED
RESOURCE
A
TASK
CONSUMES
MULTIPLt
RESOURCES
PRODUCER/
CONSUMER
O
TASK CONSUMES
ONE RESOURCE
AND PRODUCES
ANOTHER
RESOURCES
COMMON
OBJECT
A
TASKS
RESOURCES
TASK
PRODUCES
MULTIPLE
RESOURCES
35
A taxonomy of dependencies
TABLE 2
Examples of resources
Reusable
Consumable
classified
by shareability and
reusability.
Shareable
Non-shareable
Information: designs,
Tools: test systems, meeting
problem
repwrts, fixes
rooms
Raw materials: components,
assemblies
36
Mir
I
IBRAHU
S
A taxonomy of dependencies
3
TDflO
aOflM3QT2
5
TABLE 3
Summary of dependencies and
Dq)endency
coordination mechanis.ms.
To manage
Sample coordination mechanism
dependency
a
Task-resource
task uses a resource
resource assignment (identifying
necessary and available resources,
choosing resources, marking resources
in
use)
Common
effects
same
look for duplicate tasks
merge
tasks or pick
one
to
do
overlapping
negotiate a mutually agreeable result
conflicting
pick one task to do
Common
preconditions
same
shareable resource
no
reusable resource
make
conflict
conflict visible
schedule use of the resource
non-reusable resource
acquire
more resources or pick one
task to
do
Effect of one
is
precondition of other
manage flow of resource
or add another task to
order tasks and
same
conflicting
reorder tasks
repair the precondition
To maintain
a
dependency
Task-resource
task creates a resource
Common
effects
pick tasks that accomplish desired goals
decompose
a task into subtasks (possibly
including integration)
Common preconditions
ensure same version of resource
Effect of one
means-ends analysis
is
precondition of other
37
2176
n3/^
Date Due
0ji^^
SEP
3
1937
Lib-26-67