Resource-Leveling Strategies

You can use one of the following three approaches to level project resources:

• Utilizing available slack
• Shifting the project finish date
• Smoothing

This section describes each of these strategies in more detail.

Utilizing Available Slack

Slack was defined in Chapter 5 as the amount of delay expressed in units of time that could be tolerated in the starting time or completion time of a task without causing a delay in the completion of the project. Recall that slack is the difference between the ES–LF window of a task and its duration. For example, if the ES–LF window is four days and the duration of the task is three days, its slack is 4 – 3, or one day.

Slack can be used to alleviate the over-allocation of resources. With this approach, one or more of the project tasks are postponed to a date that is later than their ES date but no later than their LF date. In other words, the tasks are rescheduled but remain within their ES–LF window.

When you are seeking to level resources, having free slack can come in handy. Free slack, as mentioned in Chapter 5, is the amount of delay that can be tolerated in a task without affecting the ES date of any of its successor tasks. When you need to resolve the “stack-up” of tasks on the schedule, first determine whether any of the tasks has free slack. If any of them do, and if rescheduling the task to that later start date will solve the resource over-allocation problem, you are done. If moving the start date of the task does not resolve the over-allocation, you have to use total slack, and at least one other task will have its ES date delayed.

Shifting the Project Finish Date

Not all projects are driven by the completion date. For some, resource availability is their most severe constraint. On these projects, the critical path may have to be extended to achieve an acceptable resource-leveled schedule. This case could very well mean that the parallel scheduling on the task network diagram that moved the original finish date to an earlier date needs to be reversed. The start-to-start (SS) and finish-to-finish (FF) dependencies might need to be set back to the linear finish-to-start (FS) type.

In some cases, a project is of a low enough priority within the organization that it is used mostly for fill-in work. In that case, the completion date is not significant and doesn't have the urgency that it does in a time-to-market project. For most projects, however, moving the finish date to beyond a desired date is the least attractive alternative.

If you find yourself caught between over-allocated resources on a schedule that cannot be acceptably leveled and a firm, fixed completion date, you may have to consider reducing the scope of the project. For example, you might consider delaying some of the features to the next release.

Smoothing

Occasionally, limited overtime is required to accomplish the work within the scheduled start and finish dates of the task. Overtime can help alleviate some resource over-allocation because it allows more work to be done within the same scheduled start and finish dates. I call this smoothing. You can use smoothing to eliminate resource over-allocations, which appear as spikes in the resource loading graphs. In effect, what you do is move some of the work from normal workdays to days that otherwise are not available for work. To the person doing the work, it is overtime.

Alternative Methods of Scheduling Tasks

Rather than treating the task list as fixed and leveling resources within that constraint, you could resolve the leveling problem by considering further decomposition of one or more tasks. One of the six characteristics of a complete WBS mentioned in Chapter 5 is “work assignments are independent.” That independence means that once work has begun on a task, work can continue without interruption until the task is complete. Usually, you do not schedule the work to be continuous for a number of reasons, such as resource availability, but you could if necessary.

Further Decomposition of Tasks

Resource availability, or rather the lack of it, can require some creative task scheduling on the part of the project manager. For example, suppose that a task requires one person for three days within a five-day window. There are two days of slack in the schedule for that task. In other words, the ES–LF window of the task is five days, and the task duration is three days. The project manager would prefer to have the task scheduled for its ES date, but the unavailability of the resource for three consecutive days beginning on the ES date will require scheduling the task work to a longer period of time. One solution would be to have the resource work for three nonconsecutive days as early as possible in the five-day window. Continuing with the example, suppose that the resource is available for the first two days in the five-day window and for the last day in the five-day window. To simplify the scheduling of the resource, the project manager could decompose the five-day task into two tasks — one two-day task and one one-day task. The two-day task would then have an FS dependency on the one-day task. The scheduled start and finish dates of the two tasks would be set so that they fit the availability of the resource. Other solutions to this scheduling problem are possible but I do not discuss them here. The one I have presented is the best approach to situations similar to the example.

Stretching Tasks

Another alternative that preserves the continuity of the task work is to stretch the work over a longer period of time by having the resource work on the task at a percent per day lower than was originally planned.

The previous example can be modified to illustrate this by stretching the task. Suppose the resource is available 80 percent of each day in the five-day window, and you need four days of work. The resource is therefore available for (0.80) × five days, or four days of work, over the five-day window. You need only four days of work from the resource, so how do you schedule the work in the five-day window to accomplish the four days of work you need? The solution is to stretch the task from four days to five and schedule the resource to work on the task for those five days. Because the resource can work only 80 percent of the time on the task, the resource will accomplish four days of work over a five-day period.

In this simple example, the percentage was constant over the five days, but it might also follow some profile. For example, suppose you need the resource for three days, and the resource is available full-time for the first and second days but only half-time for the remaining three days of the five-day window. You could first split the task into two tasks — a two-day task and a one-day task. The two-day task would fully use the resource and get two days of work completed. The second task would be stretched to two days, and the resource would be assigned half-time for two days to complete the remaining day of work on the task. In other words, you got the three days of work in four days — the first two days at full-time, and the next two days at half-time. Resource availability can be the determining factor for how you can stretch a task within its ES–LF window and still get the required amount of work from the resource.

Assigning Substitute Resources

Your original estimate of task duration was based on the assumption that a typically skilled resource will be available to work on the task. That may not be possible, however, because of the unavailability of the resource. This unavailability will be especially likely in the case of scarce resources such as some of the newer technologies. In this case, the project manager needs to use another strategy. One approach would be to use less-skilled resources and add to the total number of hours requested. Here, the thinking is that a less-skilled resource would require a longer period of time to complete the task work.

Cost Impact of Resource Leveling

It should be obvious to you that resource leveling almost always stretches the schedule. For example, a stretch may occur when slack is available in the right places in the schedule. Scheduling the work of a resource over a longer period of time not only removes scheduling conflicts, but it also removes any over-allocations of that resource. To do all that, the project completion date is extended, which can have the following results:

• If the resources are billable based on the labor expended, project costs do not increase.
• If there are resources that are charged on a calendar basis, project costs will increase. Such expenses would be attributable to equipment and space on a rental agreement. In some cases, there may be increased human resources costs as well.
• If there are incentives for early completion and penalties for late completion of a project, a cost impact will be felt as well.