Allocating Scarce Resources to Several Projects

When the problem of allocating scarce resources is extended to the case when several projects are being carried out concurrently, the size and complexity of the problem increase but the nature of the underlying problem remains the same. The projects might be independent or members of one large superproject. In any case, there is a decided advantage if several projects are joined as a set.

Consider a single project for a moment. It is composed of a set of first-level tasks connected in a technological relationship of predecessors and successors. Each first-level task is composed of a set of second-level tasks, also arranged in technologically deter­mined ways. The second-level tasks are divided into third-level tasks, and so on, much like the fleas in Jonathon Swift’s famous verse:

So, naturalists observe, a flea

Hath smaller fleas that on him prey;

And these have smaller still to bite ’em;

And so proceed ad infinitum.

If we take several projects, we can link them together with pseudoactivities, here defined as activities that have duration but do not require any resources. The set of pro­jects linked in such a way becomes a sort of superproject and can be “managed” like any other. We can use the pseudoactivities to establish precedences between the projects they connect, and thus we can separate the projects in time. This is simplest to illustrate as an AOA network (see Figure 6-15), but a Gantt chart could be used by displaying the projects with leads and lags. Each node in Figure 6-15 represents a project, and the arrows connecting them are pseudoactivities. The temporal relationships of the projects are altered by varying the duration of the pseudoactivities.

The individual projects are interrelated by specifying predecessor/successor relation­ships in MSP. Thus they appear (to MSP) to be parts of one project. If the original pro­ject calendars are put on the same time base (exactly as we did with individual activities when scarce resources were allocated among several activities in a single project), we can use the single-project resource-allocation methods for several projects at a time. (MSP’s ability to handle projects with a very large number of activities on multiple levels is not limited by the software but by the size of the computer’s memory.) MSP can also easily link many large projects, treated as separate and independent, but they share the same set of resources. The pseudoactivities may represent technological relationships among the projects—which will often be the case when individual projects are parts of an overall program. Pseudoactivities may separate projects according to planned delivery dates, or the separations may be completely arbitrary.

Putting a set of projects into a format that deals with them as a single project allows us to use MSP’s resource loading and leveling charts and tables. Remembering that the calendars of all projects should be adjusted to the same time base, we can examine the status of resource allocation—or overallocation—for all activities in all projects over any time period. By using the leveling routines, we can also examine the consequences of adopting different resource allocation priority rules. Further, we can examine the impli­cations of adding more resources by comparing the costs of additional resources with the costs that might accrue from late deliveries or delays if the resources are not added. The assignment and handling of various priority rules are, of course, the same as in the single project case. The number of cases to be investigated will be larger in the multiproject case, but few genuine Walts are involved. Extending or contracting the pseudoactivities is the mechanism by which we change the start or finish dates of projects in order to avoid overallocation of Walts.

1. Criteria of Priority Rules

Whatever the priority rule, the PM faces the problem of choosing between the alterna­tive outcomes that result from different priority rules, as well as different arrangements and durations of the pseudoactivities. There are many measurable criteria available to help us choose a priority rule. The most useful for projects are schedule slippage, resource utilization, and in-process inventory.

Schedule slippage simply measures the amount by which a project, or a set of pro­jects, is delayed by application of a leveling rule (or by extending a pseudoactivity so that a project finishes later because it starts later). As we noted above, the PM (and senior management) must trade off penalty costs or the possible displeasure of clients against the cost of adding resources, if that is possible, or by reducing the overallocation of Walts. Just as serious is the ripple effect that often occurs when a delay in one project causes a delay in others. Indeed, expediting one project typically causes disturbances in the sched­ules of others.

The shortest-task-first rule for assigning resources minimizes the level of in-process inventory or how much unfinished work is in the system. Clients have little desire to pay for things they have not yet received—though partial prepayment is sometimes arranged by contract—and the organization carrying out projects may have large quantities of human and material resources invested in projects that have little value until they are complete.

The minimum slack rule is probably the best overall priority rule according to research on the subject. It gives the best combination of minimum project slippage, mini­mum resource idle-time, and minimum in-process inventory (Fendley, 1968). While first-come-first-served may be the client’s idea of “fair,” it is a poor priority rule when measured against almost any of the others. If the minimum slack rule produces ties among two or more projects (or activities), the shortest task rule seems to be the best tie-breaker.

2. The Basic Approach

It is now appropriate to stop for a moment and consider a matter. The basic approach taken here to solve project loading and leveling problems is borrowed from a manufactur­ing model that has widespread application and works equally well for projects. Our prob­lem is that there exists a set of activities belonging to one or more projects all eager for processing by a limited set of facilities or other resources. Not all activities require the same subset of facilities or resources, and some activities are more in need of immediate attention than others. To make matters worse, some activities need more work than oth­ers, and some insist (for technological reasons, of course, rather than natural cussedness) on being dealt with before some others.

As if this were not enough, the activities do not have access to the facility or resources at precise, predetermined times so the PM or facility manager does not know—with any great precision—when to expect specific activities to be ready for processing. Finally, even when an activity does arrive, and when the facility is ready to begin, there may still be considerable uncertainty about exactly how much time it requires to do the process­ing. Remember that we are discussing the unfinished outputs of some projects. They have completed a previous activity and are now waiting for resources to engage in the next activity for which they are scheduled. All of these activities involve the use of a scarce resource (or two) that we must allocate to the waiting activities.

In this setting, a scarce facility (resource) is like a bottleneck. A line or queue of activities waiting to be processed forms in front of the processor. Assume that jobs arriv­ing to join the queue arrive randomly at an average or expected rate of X jobs per unit of time. Also assume that the time required for the processor to service the activities is random and has an average or expected rate of p jobs per unit of time. The behavior of queues has been studied for many years and under our assumptions, not unreasonable for the constrained resource, multiproject problem, the average number of jobs in the wait­ing line is given by J = (X/p)/(1 – X/p). Note what happens when the arrival rate of tasks approaches the system’s capacity, for example X approaches. p. J, the number of jobs in the queue, heads toward infinity. This supports our earlier contention that production or servicing systems must have excess capacity unless they are tightly controlled assembly­line type operations—and even these need a small amount of excess capacity to handle the normal, small variations in arrival or service rates.

3. Resource Allocation and the Project Life Cycle

Whatever the scheduling rule, the scheduling method assigns scarce resources to activi­ties on the basis of the degree to which the activity meets some priority conditions. Once the most urgent cases (as measured by the priority rule) have been given resources, the next most urgent cases receive their resources. The process continues until there are no more activities qualified under the rule.

If all critical activities demanding scarce resources are supplied, but the remaining stock of scarce resources is depleted before all noncritical activities are resource loaded, the less urgent activities go unsupplied. When this happens, the less urgent activities become more urgent as period after period passes until they rise far enough up the priority rank list and receive their resources. But what happens if the stock of scarce resources is depleted before all the critical activities receive resources? For example, when using the minimum slack rule, what happens if we run out of our scarce resource before we run out of critical (zero slack) activities?

When this condition occurs, it is often possible to borrow some resources from another (ongoing) activity that is lower on the priority list, that is, has some slack in the case of the minimum slack rule. Perhaps we could even deschedule such an activity and take all the scarce resource being used, restoring the scarce resource later when the descheduled activity has risen higher on the priority list. The decision about whether to borrow some resources from a high-slack ongoing task or whether to stop the task and use all its resources is made by looking at the implication of either action on the project. Borrowing the scarce resource may only slow down progress on an activity or it may stop the activity altogether. If borrowing does the latter, it would make sense to borrow all other resources at the same time.

We can also use our knowledge of the project’s life cycle to help make the decision. Figure 6-16 shows both types of project life cycle that were discussed in Chapter 1, Section 1.4. The Type 1 life cycle shows decreasing returns to additional resources toward the end of the project. If we borrow from or deschedule activities late in the life of a Type 1 project, we lose proportionately little from the project. If we borrow from or deschedule activities late in the life of a Type 2 project, we may destroy it completely. On the other hand, if the borrowing or descheduling is done near the middle of the life of the project, our conclusion might be exactly the opposite. We need to understand the general shape of the project’s life cycle curve in order to assess the implications of slowing or stopping it.

Allocating scarce resources among multiple projects is more complicated than the single project case, but is not different in its basic logic. The several projects are linked with pseudoactivities and treated as if they were the individual activities of a single project. Schedule slippage, resource utilization, and in-process inventory are measures of the goodness of any priority rule.

Much of the allocation problem results because project facilities/resources have insufficient excess capacity to handle the uncertainties associated with projects. The shape of the project’s life cycle helps determine whether or not resources can be bor­rowed from ongoing activities to supply stalled activities with critical resource needs.

Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.