Part II: How Can We Represent Processes? Toward A Theory Of Process Representation
3.3 Managing Task-Resource Dependencies
The implications of the possible dependencies between a task and one or multiple resources can be represented graphically as in figure 3.1. In the two-component framework discussed in the previous section, a task can depend on a resource either as a precondition or as an effect. For example, the preconditions for fixing a bug include knowing what the bug is, having access to the source code, and having the capability of fixing bugs. The effect of patching a bug is having a patch that fixes the code. Of these two dependencies involving one task and one resource, only the first, a task using a resource, seems to create a coordination problem, in that it requires additional work to manage.
Figure 3.1: Tasks use or produce resources
3.3.1 Task Uses One Resource
Consider a task that requires or consumes some resource. The coordination problem implied by this dependency is acquiring the necessary resource. If there is just one
appropriate resource available, then that resource must be the one to be used. This simple case includes an actor deciding that it should perform a task itself or knowing only one other actor that could perform it. For example, when customers have problems with a piece of software, typically their only choice is to report the problem to the manufacturer's help desk and ask them to fix the bug. More commonly, however, there are many possibly appropriate resources, requiring a more elaborate coordination mechanism. The mechanism can be decomposed into the following steps:
Identifying what resources are required by the task.
1.
Identifying what resources are available.
2.
Gathering information about the resources.
3.
Choosing a particular resource.
4.
Assigning the resource (e.g., getting an actor to work on the task).
5.
The steps in this mechanism are derived from the steps in a decision process—intelligence, design, and choice—where the first step is divided into intelligence about the needs of the task and about the available resources and a final step is added to execute the decision.
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, in software development, a manager might divide a system into modules based on
the abilities of the programmers who will work on them, rather than on some a priori division of the problem. A garbage can model might suggest that all steps go on simultaneously and occasionally connect more or less by chance (Cohen, March, and Olsen 1972). For
convenience, however, I will discuss the steps in the order listed.
Identifying Necessary Resources First the resources needed by a task must be identified.
For example, determining the module of the system in which a bug appears identifies the resources needed by that task (i.e., an engineer with expertise in that module). In some cases the assigner may need to know what kind of resources are available to be able to characterize the task requirements along the same dimension. For example, if actors are specialists and only one actor can perform any given task, then the needs of the task must be identified in terms of these actors'specializations. If actors are generalists, then any actor can perform the task, so the assignment can be based on other factors.
Identifying Available Resources Second, a set of appropriate resources must be identified.
In the simplest case there is only one potential resource, for example, only one actor, who can perform the task. In the general case there may be several resources that could be used for the task, making it necessary to choose one. The available resources may be known a priori to the assigner; the assigner may know a larger set of resources, some of which may be appropriate; or the assigner may have to spend some effort identifying what resources might be appropriate (e.g., by investigating the background of each possible actor or by asking someone else for a recommendation).
Gathering Information about the Resources Third, information about the resources must be gathered to evaluate how good a fit a particular resource will be for the task. Obviously there are many possible bases for such a decision, such as speed, quality, availability, and motivation. The necessary information might be gathered by asking potential resources to identify themselves, for example, by submitting bids, in which case this step and the previous one are essentially merged.
Choosing a Resource Fourth, the most appropriate resource must be chosen based on the information collected and whatever criteria are important for the task.
Assigning Resources Finally, the assignment of the resource must be communicated to the actor performing the task. As well, for nonshareable resources, the resource must be marked as ''in use''or other assigners warned to avoid conflicting assignments, as discussed below. When the resource is the effort of an actor, the actor must be asked or convinced to perform the task. Where the personal goals of the individual actors differ significantly (e.g., when the interaction is nonroutine or when the actors are whole firms rather than individuals), the assigner may have to 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 other cases, effort to influence the performer will be unnecessary. For example, if employees are asked by a legitimate requester to do a task that fits their definition of their job, they are likely to agree to do it.
Once the resources have been acquired, additional work may be necessary to manage the flow dependency between acquiring and using the resources, as will be discussed below. For example, it may be necessary move the resources to the task that will use them and to ensure that they are available at the appropriate time.
Example Resource Allocation Mechanisms Different coordination mechanisms for resource assignment can be analyzed as particular choices for these five steps. For example, to assign a task to an employee, a manager must:
Determine what skills are necessary to perform the task.
1.
Identify which employees are available (which might be done from memory).
2.
3.
1.
2.
Collect information about which employees have the necessary skills (again, possibly from memory).
3.
Decide which employee is the most appropriate, based on skills, workload, and so on.
4.
Ask the employee to work on the task.
5.
Buying a product has equivalent steps:
Determining needs.
1.
Identifying possibly appropriate products.
2.
Collecting brochures, reviews, and other sources of information about the products.
3.
Picking the most appropriate products.
4.
Arranging payment for and delivery of the product.
5.
More generally, these steps can be used to distinguish broad classes of organizational form.
Take, for example, the market-hierarchy dichotomy. In a hierarchy the available resources are those owned by the organization. If the resources are specialized, there may be only one appropriate for a given task. If the resources are generalized, the choice between them may be made based on factors known to the assigner, such as workload, or be delegated to the group. In a market the available resources are those competing in the market place.
Appropriate resources are identified through advertising or requesting bids and the choice between them made based on the bids submitted by the interested resources. In a network organization (Ching, Holsapple, and Whinston 1992; Nohria and Eccles 1992) the resources are those that belong to the network; typically each member has a particular specialization it brings to the network. The basis for assignment is reciprocal relations, rather than contracts or hierarchy. These alternatives are summarized table 3.1.
Table 3.1: Decompositions of different mechanisms for resource allocation
Step Market Hierarchy Network
Identify needs Based on
specializations in market
Based on
specializations in firm
Based on specializations in network Identify
resources
Broadcast a RFB and wait for replies;
check advertising
Use known set of resources in firm
Use known set of resources belonging to network Choose
resource
Evaluate bids Specialization;
workload
Specialization Assign resource Contract Employment relation Network
membership
3.3.2 Task Uses Multiple Resources
I will next consider cases where a single task uses multiple resources. There are three cases where a task is dependent on multiple resources—using multiple resources, producing multiple resources, or using one resource and producing another, as shown in figure 3.2. Of the three, only the first, a task using multiple resources, seems to pose unique coordination problems, namely constraints on the performance of the task and thus the need for a coordination mechanism. In this case there is a need to synchronize the availability of
multiple resources.
One way to manage this dependency is to simplify it by permanently assigning all resources, or all resources but one, to the task. For example, a particular production task might always be performed on a particular machine, which is always operated by a particular operator.
Such pre-assignments reduce this dependency to a task using a single resource, as discussed above.
More generally, the dependency can be managed by scheduling the use of all of the needed resources. However, the need to use multiple resources creates additional potential
problems, such as deadlock (where one task waits for a resource held by the another, which in turn is waiting for a resource held by the first) and starvation (where a task waits forever for all the resources it needs to become available). For instance, a meeting convener may not be able to find a time at which everyone is available, resulting in the meeting being
repeatedly postponed. For computer systems a variety of algorithms have been developed for assigning resources to avoid these problems. For example, deadlocks can be avoided by requiring that all needed resources be assigned at once (preventing a task holding a
resource while waiting for another) or by always assigning resources in a specified order (preventing a loop). Alternately, deadlocks can be periodically searched for and one task canceled if a deadlock is detected. Some of these approaches have analogues in human systems (e.g., if nothing has happened with your resource request for a while, call again to check on the status).
Figure 3.2: Dependencies between multiple tasks and resources.