Multiproject Scheduling And Resource Allocation

Weist's heuristic (SPAR-1, Scheduling Program for Allocation of Resources) allocates resources to activities in order of their early start times. In the first period, we would list all available tasks and order them by their slack, from least to most. (Calculation of slack is based on the assumption that activities will be supported at normal resource levels.) Activities are selected for support and scheduling one by one, in order. As activities at the top of the list are supported, the relevant resource stocks are debited. Tasks are scheduled sequentially until the list of available jobs is completed, .or until the stock of one or more resources is depleted. If we deplete resources before completing the task list, remaining tasks are delayed until the next period. Postponed activities lose slack and rise toward the top of the priority list.

The information requirements for this heuristic are straightforward. Each period, we need a period-by-period updating of the list of currently active tasks continued from the previous period, including the resource usage level for each active task, the current scheduled (or expected) completion date, and the current activity slack. We need to know the currently available stocks of each type of resource, less the amounts of each in use. We also need a list of all available tasks together with their slacks and normal resource requirements. As activities are completed, their resources are "credited" to the resource pool for future use.

Thus, resources are devoted to activities until the supply of available resources or activities is exhausted. If we use up the resources before all critical activities are scheduled, we can adopt one of two subheuristics. First, we may be able to borrow resources from currently active, but noncritical, tasks. Second, we may "deschedule" a currently active, noncritical task. The former presumably slows the progress of the work, and the latter stops it. In both cases, some resources will be released for use on critical tasks. Obviously, if a critical task is slowed, descheduled, or not supported, the duration of the associated project will be extended.

The decision about which of these courses of action to take, borrowing or de-scheduling, can be made by adopting the same logic used in Chapter 7 when we discussed the budget negotiations between subordinate and superior. The decision to borrow or deschedule depends on our estimate of the impact either action would have on the task under consideration, given its current state of completion. Figure 9-14 shows two different versions of the project or task life cycle discussed in Chapter 7. If the task is a Type 1, borrowing would minimize the damage to the task unless it is quite near completion and we are willing to accept the outcome in its current state, in which case we can deschedule. If the task is Type 2, borrowing is

apt to have a catastrophic effect on the task and we should either deschedule it (and start it again later) or reject it as a source of resources.

If the size of the resource pool is more than sufficient for the list of active and available tasks, the extra resources may be used to crash critical activities in order to put some slack in the critical path as insurance against project delays caused by last-minute crises. In fact, it is often possible to borrow resources from tasks with plenty of slack in order to crash critical items that are frequent causes of project delay.

As a result of this scheduling process, each task from the previous period, along with any tasks newly available for support, will be:

1. Continued as is, or newly funded at a normal level

2. Continued or funded at a higher level of resources as a result of criticality

3. Continued or funded at a lower-than-normal level as a result of borrowing

4. Delayed because of a resource shortage.

If there is more than one scarce resource, a separate activity can be created for each type of scarce resource. These "created" activities must be constrained to start in the same period as the parent activity, and to have the same level of resource assig nment (normal, crash, or minimal.) Figure 9-15 shows a flow diagram for SPAR-1.

As we have noted, many commercially available software packages have the ability to schedule constrained resources and deal with resource conflicts [21, 25, 57], The Project Management Journal published by the Project Management Institute is an excellent source of reviews on project management software. These reviews typically include a discussion of the package's capabilities. Many will allow the user to solve the problem either automatically, using the program's heuristics, or by hand in which case the user can adopt any method desired. If a set of projects is linked together by dummy activities so that it can be treated like a single project, the software will report resource usage conflicts; that is, cases in which the scheduled utilization of a resource is greater than the supply of that resource.

In one sense this chapter's emphasis on resource shortages is misleading. The common case of shortage applies not to resources in general, but to one or two highly specific resources. For example, an insurance firm specializing in casualty insurance has a typical kind of scarce resource, a "Walt." Walter A. is a specialist in certain types of casualty losses in the firm's commerical lines business. He is the only such specialist in the firm, and his personal knowledge is required when designing new policies in the field. His knowledge is based on years of experience and an excellent, analytical mind. It is common for projects involving the modification or creation of policies in the commercial lines area to have problems associated with the fact that the firm has one, and only one Walt. Walt-capacity cannot be hired, trained, or subcontracted within an appropriate time frame. The firm's ability to extend its Walt-capacity is not sufficient to satisfy its Walt-demand. Left with no alternative, some projects must be delayed so that others can, proceed.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment