Project managers are becoming increasingly aware of the importance of resource-constrained scheduling (RCS). Not only must our schedules be time-feasible, by honoring logical task dependencies, they must be resource-feasible, by honoring resource constraints. Just as logical task dependencies can block a task’s execution, forcing the task to wait for predecessor tasks to finish, a task’s execution can be blocked while waiting for resources to work on the task. Either of these blockages tend to extend overall project duration.
Here is a scheduling exercise that I have used for several years in my classes. It involves a portfolio of three projects, all of which utilize a shared resource pool. The projects A, D and X each utilize resources p, q and r. Individually, any of the three projects is free of resource over allocation. However, taken as a whole, we see there is resource contention between the projects. We would like to know the timeframe in which all of the projects can be completed. Since the sum of the durations of the tasks that resources q and r work on individually is 16 days, the overall portfolio duration cannot be 15 days without those two resources being over allocated. The initial unleveled schedule is shown in Figure 1.
FIGURE 1. Unleveled schedule
Leveling the schedule by hand
Before showing how MS Project levels the exercise, we will level the schedule manually, by hand. Whenever there is resource contention, where two or more tasks require the same resource concurrently, one or more of those tasks must be delayed until the resource becomes available. The objective is to minimize the effect of these delays on the overall schedule duration. We will use a simple leveling rule: always give the resource to the most critical task (the one with the least slack). This is known as the minimum slack rule. While this rule doesn’t guarantee an optimal leveling solution in terms of overall project duration, it has been shown to be effective in minimizing the effect of leveling delay.
There are other leveling rules we could apply. We could choose to assign the resource to the task with the shortest processing time (minimum duration rule). Or, we could simply assign the resource to the task that comes first in the task list (ID rule). In addition to these three leveling rules, there are many other rules we could use. But, to keep this manual exercise simple, we will use the minimum slack rule exclusively, unless we need to break a tie. To further simplify the exercise, we will not consider splitting tasks (preemptive switching between tasks) or altering initial resource assignment levels (allowing a resource to work two or more tasks simultaneously).
The leveling process is straight forward. We step through the schedule time period by time period. In each period, we continue any tasks that are already in progress (no preemption). We note which tasks are eligible to be scheduled. A task is eligible if all of its logical predecessors are complete. We order the eligible tasks by the amount of slack the tasks have, from least slack to most slack available. We can use the minimum duration or ID rules to break ties. We step through the ordered list of eligible tasks. If a resource is available, we assign the resource to the task and schedule (start) the task. If there is no available resource for an eligible task, the task must be delayed for at least one time period until a resource becomes available. We do this by inserting Leveling Delay (lag) in front of the task. We continue the process for each time period until all tasks have been scheduled (started). Note that the schedule must be recomputed in each step, since the critical path and slack may change as tasks are delayed.
Figure 2 shows the 16-day hand-leveled schedule. The overall schedule was extended by only one day over the initial 15-day schedule. In Figure 2, a combination view is displayed, with a Resource Usage view on top (subtasks hidden), and a Leveling Gantt chart beneath, with a Delay table modified to include Total and Free Slack. The project calendar was modified to make all days working days so as to not clutter the Gantt chart.
FIGURE 2. Hand-leveled schedule
The manual hand-leveling of the exercise is traced in Table 1. If you have never leveled a schedule by hand using MS Project, it is well worth the time it takes to work through the exercise, following the actions enumerated in the table. Starting with the unleveled schedule (Figure 1), work through the schedule day by day, manually incrementing the Leveling Delay field in order to insert leveling lag in front of a task whose execution you want to delay. Note that in the Leveling Gantt chart view (with a Delay table), the contents of the Leveling Delay field (and the graphic underscore preceding tasks in the chart) is the prime indicator of which tasks have been affected by leveling. If you would like more details about the mechanics of resource leveling, consult a project management textbook, such as Erik Larson and Clifford Gray’s Project Management : The Managerial Process (McGraw-Hill, 2017).
TABLE 1. Manual leveling trace
Leveling the schedule with MS Project
Let’s compare the hand-leveled schedule to one that Microsoft Project Professional 2016 produces. Figure 3 shows the Leveling Options dialog used to set up the leveling. We chose to level Manually (one time, at our discretion). We cleared any prior leveling and leveled the entire project. We chose the Standard leveling order. This controls the order in which tasks are leveled, much as the ordered eligible set controlled the leveling order in the example above. It is fair to conjecture that MS Project is using a much more complicated leveling scheme and set of rules than we used in the hand-leveling example above. And, we chose not to preempt tasks or adjust initial assignment levels. Figure 4 shows that MS Project’s leveling yields a 17-day resource-feasible schedule.
FIGURE 3. MS Project 2016 Leveling Options Dialog
FIGURE 4. MS Project 2016 Standard Leveling
Let’s inspect the two results to identify the differences in leveling. The 17-day schedule has only one critical path, a-b. Note that Leveling Delay (lag) is part of the critical path calculation. Both levelings started by assigning resources to tasks y, d and a, and delaying task b. And, at day 5, both levelings delay tasks b and c. However, at day 6, both levelings delay tasks y and c (waiting for resource r), but MS Project does not assign resource q to task b, even though resource q is available. The remainder of the leveling trace is contained in Table 2.
Table 2. MS Project leveling trace.
A conundrum
Now, we have a conundrum. Why did MS Project not find the 16-day leveling? Just as a seer in a tea room attempts to conjure rational meaning for the random arrangement of tea leaves in the bottom of a cup, we are left to conjure an explanation as to why MS Project leveled the schedule differently compared to the hand-leveled solution. While we can observe what MS Project did to level the schedule, we can only conjecture as to why MS Project chose not to assign resource q to task b at day 6.
There is nothing wrong with the MS Project leveling. Both schedules are resource-feasible. While the hand-leveled solution ensured that tasks were scheduled whenever a resource was available, this was not the case in MS Project solution. The reason for this difference is most likely the algorithm and set of heuristics that MS Project uses.
Microsoft Project is capable of handling much more complicated resource leveling problems than the basic example presented here, especially when you remove the preemption and assignment adjustment constraints that we imposed for simplicity. It is fair to assume that MS Project’s leveling process is more sophisticated than the simple process we presented above and that it uses a richer, potentially more powerful set of heuristics than the three basic ones we used. It is that process and set of heuristics that compelled it to find a 17-day resource-feasible schedule.
This is perfectly acceptable, since any heuristic-based leveling scheme is not guaranteed to find an optimal solution in terms of schedule duration. However, without intimate knowledge of how MS Project levels schedules (which is probably proprietary information), we are left to conjecture as to why MS Project makes the decisions that is does during the leveling process.
A related conundrum
There is a related conundrum. Figure 5 shows an integrated, leveled project file in which the three projects were loaded as subprojects with a shared resource pool. The entire integrated file was leveled using the Standard leveling order. MS Project yielded the 16-day leveling, the same as the one obtained from the manual hand-leveled solution in Figure 2. Why did MS Project find the 16-day schedule in the integrated file, but not in the single file instance? It is not inconceivable that MS Project might level an integrated file of subprojects differently than a single file with the same tasks and task relationships. But, it certainly leaves us guessing as to why that would be the case.
FIGURE 5. Standard leveling of integrated file with subprojects and shared resource pool
What do you think?
In this article, we leveled a schedule by hand, using a process with three simple leveling rules (heuristics). This yielded a 16-day resource-feasible schedule. We then leveled the schedule using MS Project and found a 17-day resource-feasible schedule. But, we are left trying to figure out why MS Project did not find the shorter 16-day schedule. Our confusion was compounded when we discovered that by entering the initial schedule as a set of subprojects using a shared resource pool, MS Project could indeed find the 16-day schedule!
If someone does know the answers to the conundrums posed here, please share a comment on this article.
Resource constrained scheduling (RCS) is a difficult topic, even without conundrums. But, we have just scratched the surface. In a subsequent article, we will explore a troublesome byproduct of RCS: phantom float. And, we will explore the notion of a resource critical path.
___________________________________
© Nicklas, Inc. and robinnicklas.com, 2018. All rights reserved. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited.
Robin Nicklas 