In the figure above, a schedule was resource leveled using Project (left Gantt chart). It was resource smoothed using Excel (right Gantt chart). Both results are resource-feasible, but the schedule on the right has a smoother resource allocation. To contrast the resource optimization techniques of leveling and smoothing, I will share how both schedules were computed.

The two techniques have different objectives. Resource leveling minimizes project duration while honoring logical and resource constraints. Smoothing minimizes the deviations from a mean resource loading while honoring the same constraints.

In both cases, the project can never be shorter than the unleveled, time-feasible schedule computed using the critical path method. Depending upon the availability of slack in the schedule, if the project schedule cannot be extended, it may not be possible to find an acceptable leveling or smoothing solution.

Both methods involve delaying tasks. In resource leveling, tasks are delayed until resources are available. Whenever there is a choice, a heuristic leveling order decides which task gets the resource and which task is delayed. In smoothing, tasks are delayed, as needed, in order to balance the resource loading.

Leveling the Schedule in Project

The original unleveled schedule is shown in the next figure. There are four paths through the network and the critical path C-D-E is 13 days long. There is one resource type with a capacity of 10 units.

To resolve the resource over allocations at the beginning of the schedule, Project’s resource leveling tool was used, as shown in the dialog box below. To start, the “ID Only” leveling order was selected. For simplicity, task preemption (splitting), assignment unit adjustment, and leveling only within available slack were not considered. Since the task Priority field was not modified, the “Priority, Standard” leveling order was not considered.

The result of the leveling is shown in the initial figure above (left Gantt chart). The result is one of four active 13-day leveling solutions for this schedule. An active schedule is a leveling in which no task can be scheduled earlier without delaying some other task or violating a logical or resource constraint. In this schedule there is sufficient slack available within which to delay tasks to accommodate the resource constraint. Task H is delayed by six days from its original start time, and task I follows it according to network logic.

This particular leveling can be obtained manually using a serial scheduling scheme and the ID heuristic leveling rule. That is, tasks are ordered by ID and each task in order is slotted into the schedule, using the earliest start time that honors logical dependencies, but does not create resource conflicts with any previously scheduled tasks. This assumes that the initial task ID ordering was topological according to logical dependencies.

Smoothing the Schedule in Excel

Project does not have a resource smoothing option. To demonstrate the smoothing process, the problem was set up in Excel, as shown in the following figure. The objective is to minimize the mean absolute deviation (MAD) between the average daily resource load and the scheduled daily resource load, while honoring logic constraints. The smaller the MAD, the less deviation there is between resource demand and the average daily loading.

The Solver add-in was used to find an optimal smoothing within a 13-day project duration. The dialog box below shows how the problem was defined. The objective function is to minimize the MAD of the daily resource loading by changing the task start times relative to the constraints imposed by logical task dependencies and overall project duration. For simplicity, resource constraints were not enforced in this model.

The task start times displayed in the Excel model above show the Solver solution. The start times were transcribed to Project and the resulting schedule is shown in the initial figure above (right Gantt chart). Whereas MAD is 3.56 units/day in the unleveled schedule, it is 1.04 units/day in Project’s ID only leveling. In the optimal smoothing, MAD is 0.53 units/day. There is a variation of the optimal smoothing solution in which task G starts a day later. MAD remains the same.

Resource constraints were not considered as part of the model. In this schedule, the daily allocations did not exceed the maximum resource availability, which means that the smoothed schedule is resource-feasible. A more advanced model would consider resource constraints. Regardless, to be viable, any solution needs to be resource-feasible.

The smoothed result is not one of the four active 13-day resource feasible schedules. This is not relevant since the objective was smoothing, not leveling. Tasks are shifted within available slack in such a way as to produce a smoothed resource loading. Some tasks were delayed further than what was necessary to accommodate logic and resource constraints.

A word of caution is in order. Resource smoothing, along with leveling, are complex problems that can become intractable. Solving the smoothing problem in Excel was done for educational purposes. It should not be taken as a recommendation that Excel should be used on schedules more complicated than the schedule we are examining.

Using Other Leveling Orders and Options

The leveled schedule shown in the next figure (left Gantt chart) was produced manually using a parallel scheduling scheme and only the minimum slack priority rule. That is, time period by time period, tasks that are eligible to be scheduled are ordered by increasing slack. More critical tasks are scheduled before less critical ones. Eligible tasks are those whose logical predecessors have completed. In each time period, eligible tasks are scheduled if resources are available; otherwise, they are delayed. The result is another of the four active 13-day leveling solutions. In addition, it is an active non-delay schedule in that no resource is left idle if it can be assigned to an eligible task. Task A is delayed by two days and task I by 6 days to accommodate the resource constraint. MAD is 1.36 units/day.

If you level the schedule in Project 2016 or 2019 with the “Standard” leveling order selected in the Leveling Options dialog, the result is a 14-day resource-feasible schedule, but one that is not active. This begs the question: Why did Project not find a 13-day solution? The standard leveling in Project 2010 or 2013 is the 13-day active non-delay schedule found manually, as described and shown above.

However, in Project 2016 or 2019, if you select the standard leveling order and force a 13-day solution by selecting the level only within available slack option, the result is a 13-day resource-feasible schedule, but one that is not active (see the right Gantt chart in the preceding figure). Task B is delayed unnecessarily by five days and task G is delayed by 6 days, as compared to the manually leveled active non-delay schedule in which there were no delays other than those required for leveling.

Note that the resource loading in the latter schedule is equivalent to the loading in the optimally smoothed schedule. MAD is 0.53 units/day. By coincidence, the latter schedule is a third variation of the optimal smoothing.

Discussion

The two resource optimization techniques have different objectives. While both produce a resource-feasible schedule, the smoothed schedule should have a more balanced resource demand over the span of the project. However, in the examples above, we saw that one particular leveling was coincidently an optimally smooth schedule.

Valid resource-feasible schedules are distributed over a range of project lengths. When leveling a schedule in Project using a given set of options, with only one schedule produced, it is difficult to tell if it is optimal. Likewise, the resource loading in resource-feasible schedules ranges from optimally smooth to uneven. Even if you compute the MAD for a resource-feasible schedule, you do not know where in the latter range your schedule falls.

Further, for any project duration within the distribution of resource-feasible schedule lengths, there can be many resource-feasible schedules with that duration. In this example, of the eighteen active resource-feasible schedules, there are four 13-day, two 14-day, four 15-day, five 17-day, and three 19-day schedules. Of the eighteen, eleven are non-delay. There can be any number of resource-feasible schedules that are not active.

Even with a Leveling Gantt chart view and the Leveling Delay field in a Delay table, it is difficult to explain why Project levels a schedule in a certain way. In the examples above, we manually leveled the schedule in two ways producing optimal active schedules, one using a serial scheduling scheme and the ID priority rule, and the other using a parallel scheduling scheme with the minimum slack priority rule. While Project found the first using the ID only leveling order, more recent versions of Project did not find the second using the standard leveling order. Instead, Project produced a longer schedule that was not active. Without explicit knowledge of the scheduling schemes and heuristic leveling orders that Project uses, the rationale behind a particular leveling in Project may remain a mystery.