In this chapter I presented a taxonomy of dependencies and associated coordination mechanisms. This taxonomy is based on a simple ontology that includes resources (actors or other objects) and tasks (activities or goals to be accomplished). For simple task-resource dependencies, I present the steps in a resource assignment mechanism. Other dependencies are analyzed by considering how a common resource is used by the two tasks (in contrast to prior organizational conceptions of dependencies that view them as arising between actors) or how one task can use multiple resources. Finally, the typology includes possible dependencies between tasks and between resources, although some of these situations can be analyzed more simply in terms of other dependencies. Only composition of tasks and of resources seems to pose particular coordination problems. The resulting dependencies and coordination mechanisms are summarized in table 3.3.
The framework presented here makes a theoretical claim about the design of organizations: given a coordination problem caused by a dependency, some coordination mechanism is necessary to manage it. This claim has implications for the analysis and design of organizations.
To analyze an organizational process, it is important to identify the dependencies that arise and the coordination mechanisms that are used to 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 the ''empty world hypothesis.''Applied to organizational analysis, the implication is that any given task likely uses only a small set of resources and will thus likely be interdependent with only a few other tasks.
|
Task uses resource Determine needs
Identify resources
ads
prepared list
only one resource
Collect information on resources
by bidding
manager knows
Pick best
Do assignment
mark resource in use
Manage flow dependencies from acquiring resource to using resource
Task requires multiple resources simultaneously Pre-assign resources to simplify coordination problem
Manage dependency on the fly
avoid or detect and resolve deadlock
detect and resolve starvation
Sharing: Multiple tasks use the same resource Ensure same version of sharable resources
destroy obsolete versions
copy master prior to use
check versions prior to use
detect and fix problems after the fact
Schedule use of nonshareable but reusable resources
check for conflict before using and then mark the resource as in-use
manage flow of resource from one task to another
Allocate nonreusable resources
divide the resource among the tasks
abandon one task
get more resources
Flow: One task uses a resource created by another Usability (i.e., the right thing)
user adapts to resource as created
creator gets information from user to tailor resource
third party sets standard, followed by both producer and consumer
Prerequisite (i.e., at the right time)
producer produces first
follow plan
monitor usage
wait to be asked
standard reorder points
when out
consumer waits until produced
monitor
be notified
Accessibility (i.e., in the right place)
physical goods
truck
information
on paper
verbally
by computer
Common output: Multiple tasks create the same output Detect common output
database of known problems
Manage common outputs
effects overlap or are the same
eliminate one task (manage shared resource)
merge tasks take advantage of synergy
effects are incompatible
abandon one
don't try to achieve them at the same time
Composition of tasks choose tasks to achieve a given goal (a planning problem)
Composition of resources trace dependencies of between resources to determine if a coordination problem exists
|
|
Note: Dependencies are shown in bold. Numbered items are components of the coordination mechanism for managing the given dependency. Bulletted items are alternative mechanisms or components of the mechanism for the given dependency. |
To design a new process, it will be useful to consider alternative coordination mechanisms that could be used to manage those dependencies (see Crowston and Osborn, chapter 11 in this volume). One question I posed at the beginning of this chapter was, in what ways can a given organization be arranged differently while achieving the same goals? Understanding the coordination problems addressed by an organization suggests alternative coordination mechanisms that could be used, thus creating a space of possible forms.
The primary focus of this work has been the theoretical constructs included in this taxonomy, namely dependencies, the coordination problems created by dependencies and the coordination mechanisms actors use to manage these problems. Since a taxonomy per se is not a theory (Bacharach 1989), the primary evaluation of this work should be on the quality of these constructs: their comprehensiveness and parsimony (Whetten 1989) and their validity (Bacharach 1989). Likewise we ask if the typology is useful.
The taxonomy attempts to be comprehensive, in the sense that all dependencies fit into one of the four categories. On the other hand, I do not claim that the typology is comprehensive in the sense that I have described all possible dependencies and coordination mechanisms. The description of specific dependencies could be further refined and additional coordination mechanisms added. Further refinement of the dependencies and mechanisms is an important topic for future research.
The taxonomy probably errs on the side of parsimony since it characterizes coordination methods on the basis of a small number of factors, while obviously there are many reasons to choose a mechanism.
The constructs are valid, in the sense of being distinct from one another and actually found in practice, as indicated by the examples.
Finally, another way to assess the value of the taxonomy is to ask if it has been useful in any research projects. The answer to this question appears to be yes: earlier versions of the typology (e.g., Malone and Crowston 1994) have been used in several papers (e.g., Bailetti, Callahan, and DiPietro 1994; Bailetti, Callahan, and McCluskey 1998; Sikora 1998 #2013; Cohen and Regan 1996; Crowston 1997; Crowston and Kammerer 1998).
Much remains to be done. The focus on processes suggests that it is important to collect many examples of processes to compare the coordination problems that arise (e.g., Malone et al., chapter 1 in this volume) and identify the coordination mechanisms used. Other kinds of organizations may have somewhat different kinds of problems, although there is likely to be substantial overlap. For example, do Web design companies or open source software development teams use a different set of mechanisms to manage software changes than traditional software companies? Do Japanese companies use a different set to manage engineering, more generally?
It is important to identify limitations of this work. The overall framework is focused on managing dependencies between tasks. While this focus is generally useful, it is by no means universal. Some tasks (e.g., software requirements analysis for complex computer systems) seem to be more about developing a shared understanding of the tasks and dependencies as opposed to performing specific tasks (Crowston and Kammerer 1998). In other words, an analysis of dependencies provides a useful but partial view of organizations.
Even with these limitations the initial results show this work to be useful in several ways. A better understanding of what is necessary for coordination may provide a more principled approach for designing new computer applications, for analyzing the way organizations are currently coordinated, and for explaining perceived problems with existing approaches to coordination. By systematically exploring the space of possible coordination strategies, we may even be able to discover entirely new organizational forms, forms that are more effcient, flexible, or satisfying to their members.