Author: Daryl Deffler

Daryl Deffler is currently employed by a large insurance company where he provides project management, project scheduling tool, process, and standards consulting for an enterprise project management office comprised of about 200 project managers. He has over 25 years in the IT project management field with experience managing small projects to large programs. During this time he has also developed and taught classes in both project management and scheduling tools such as Microsoft Project 2013, Primavera and ABT Workbench. He has been employed in the IT industry since 1979 in additional roles, including software development, technical support and management across mainframe, midrange and PC platforms.

Resource Leveling: Understanding Split Task Options

Simply defined, the word “split” means “to break apart.” There are many types of splits in the world, ranging from banana splits to stock splits. And not to be left behind, Microsoft Project allows tasks to be split. But what does “split” mean within the context of resource leveling and what actually happens when Project splits a task? In this article, I explain the task-splitting options and illustrate what they do, when they occur and how they interact. There are two task-splitting options in Project: Split in-progress tasks; and Leveling can create splits in remaining work. Conceptually, these two options do the same thing — they break apart a task. But how they split a task is subtly different. And when a specific combination is selected, the results can be confusing. Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand. Read Daryl’s articles in this resource leveling series here: “Scheduling vs. Leveling” “Problem Indicators” “Leveling Mechanics” “Leveling Hierarchy, Part 1” “Leveling Hierarchy, Part 2” “Resolution Options” “Understanding Split Task Options” “Leveling Fields” “Limitations” “Preparing to Level” “Resource Leveling: It’s Time to Level Your Schedule” “Resource Leveling: The Leveling Cycle” “Resource Leveling: Recommendations” Also, download a resource leveling “cheat sheet” in PDF format! Split Tasks: Within Scheduling As a brief refresher, scheduling occurs when the Calculate Project icon is clicked. Or, if you’re like many project managers who turn on the “Calculate project after each edit” option, scheduling occurs automatically after every change. At a high level, the scheduling engine is timeline-oriented, focused on creating the absolutely shortest schedule duration. Scheduling, however, doesn’t care about resource overallocations and, consequently, will often result in a schedule containing overallocated resources. “Split in-progress tasks” “Split in-progress tasks” is the scheduling split option. It can be found in the File | Options | Schedule page in the “Scheduling option for this project” section illustrated below. This option tells the scheduling engine if it can split a started task (checked) or not (unchecked) — the basic point being a started task, but more specifically, a task started out of dependency logic sequence. The following examples illustrate how the “Split in-progress tasks” option works. The scenario started with a simple, six-task waterfall schedule. And as often occurs in real life, tasks were started out of sequence. In the screen below, that would be Tasks 3 and 4. With the “Split in-progress tasks” option unchecked, Project isn’t allowed to split these tasks. As a result, the remaining work for Tasks 3 and 4 is scheduled immediately on the next workday, even though this violates the dependency relationships. Simply by checking the “Split in-progress tasks” option (no leveling), the image below shows how the scheduling engine immediately adjusted the tasks and specifically how it split Tasks 3 and 4. On both tasks, the actual work stayed on the day it was applied, but every drop of remaining work was moved into the future and scheduled to restart/complete based on the task chain dependency relationships. As a result, Tasks 1 and 2 are scheduled first, followed by the remaining work for Tasks 3 and 4 (our split tasks), followed finally by the last two tasks in the chain. Resume Before leaving the “Split in-progress tasks” discussion, there’s one additional aspect — the “Resume” date — you should understand. The Resume date is set by the scheduling engine. It contains the date on which ALL remaining work is scheduled to restart. Looking at the first example with the “Split in-progress tasks” option unchecked, the Resume date for both Tasks 3 and 4 contain 6/7/16, which is the next workday. In the second example where the option is checked, the Resume date is 6/20/2016 for Task 3 and 6/24/2016 for Task 4, which aligns the Resume date with completion of the predecessor task. In concept, it’s simple, but it’s a key component in understanding the difference between the “Split in-progress tasks” and “Leveling can create splits in remaining work” options, as you will see. Split Tasks: Within Resource Leveling As a reminder, leveling occurs when one of the leveling icons such as Level All is clicked. It can also occur automatically after every change is made if the Leveling option “Leveling calculations” is set to Automatic. Leveling is resource-oriented, focused on making the most effective use of available resources. But there are scenarios that leveling won’t fix. We have seen several of these in prior articles, and I illustrate one more later in this article. “Leveling can create splits in remaining work” “Leveling can create splits in remaining work” is the leveling split option. It can be found in the Resource Leveling options window illustrated below. When unchecked, the leveling engine isn’t allowed to split remaining work. When checked, the leveling engine can split remaining work. But before moving forward, there’s an important concept to understand with this option. When you check this option, it only splits remaining work after the Resume date. Remaining work scheduled on the Resume date (by the scheduling engine) will always stay on the Resume date. Keep this in mind as you look at the following three examples, which illustrate how this option works. To simplify explanation, a Task Usage view is used so that remaining work allocations can be seen. For each example I’ve created a simple schedule with three tasks. Task 1 is a predecessor of both Tasks 2 and 3. Resource A has been assigned to all three tasks. No tasks are started. This means no tasks have an assigned Resume date, which removes the “Split in-progress tasks” option from the equation. And, finally, I’ve manually configured Task 2 with a custom load pattern (highlighted) as a simple way to create remaining work allocation gaps (days with 0 hours). The first sample below is the starting point with tasks entered, but not leveled. The sample below shows the tasks after leveling with the “Leveling can create splits in remaining work” option unchecked. Because the leveling engine can’t split remaining work, Task 3 is delayed and starts after all remaining work on Task 2 is finished. Finally, the example below shows the results of leveling when the option is checked. Notice the remaining work for Task 3 has been split to fill the Task 2 remaining work allocation gaps. Also, note that Task 3 work is only booked on days where Task 2 has 0 hours of remaining work planned. As a result, Task 3 starts and finishes earlier, Resource A is better used (fewer gaps) and Task 3 now contains three splits. As illustrated, this option can create multiple splits and because of this, there is no leveling-related “Resume date” type field. However, Project does leave clues to indicate that the leveling engine has split remaining work. The first and obvious clue is shown above: Task 3 contains gaps in the remaining work allocation. Additionally, when a leveling split occurs, Project also sets the resource assignment level Work Contour field value to “Contoured,” meaning that the remaining workload pattern has been customized. Crossing the Streams “Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.” — Spengler While the results of using both options together won’t be nearly as bad as what Ghostbusters’ Spengler predicted should “the streams be crossed,” it is important to understand what Project will do when different combinations of these two options are used. One works out nicely while the other produces unanticipated results. This last section covers what happens with the final two combinations of these split options. Both Options are Checked In this scenario, both task-splitting options are checked and the schedule contains tasks started out of sequence. The outcome of this scenario, shown below, is probably the easiest to understand and often the most desirable. When the project is scheduled, the scheduling engine splits all remaining work from actual work on Tasks 3 and 4, schedules the remaining work based on dependency logic and sets the Resume date on each task accordingly. When the project is leveled, the leveling engine doesn’t have much to do. In this scenario, Task 1 remaining work created an overallocation due to Task 3 and Task 4 actual work. As a result, the leveling engine shifted the start of Task 1 and, subsequently, the entire remaining work chain, to occur one day later. The result is an easily understood outcome that allows tasks to start early but still sequences all remaining work following the task dependency logic. Only the Leveling Option is Checked The final option combination shows the results when “Split in-progress tasks” is unchecked and “Leveling can create splits in remaining work” is checked. In the first example below, the waterfall project schedule is created, but no actual work has been applied. In the second example, actual hours have been applied to Tasks 3 and 4, starting them out of sequence. As a result, all work for Tasks 3 and 4 shifts forward. Because the “Split in-progress tasks” option is unchecked, Project schedules the remaining work for both tasks to start on 6/7/16, the next workday. Note that this date is reflected in the Resume date for each task. The scheduling engine then schedules all of Task 4 successor tasks based on Task 4’s adjusted Finish date. The result is a project schedule that doesn’t reflect a realistic total duration and all tasks except Task 6 show resource overallocations. But not to worry, leveling will fix all this, right? Not so fast! The example below shows what happens and illustrates one more scenario where leveling will leave overallocated resources. As a result of leveling: Task 3, including ALL remaining work remains where it was placed by the scheduling engine. Why? The leveling hierarchy (discussed in a later article in this series) assumes remaining work for started tasks takes precedence. Task 1 is delayed to start after all remaining work for Task 3 is done. Task 2 is delayed because of the Task 1 delay. The remaining work for Task 4 is split by the leveling engine. Remember, the remaining work split ALWAYS occurs after the Resume date. One day of remaining work on Task 4 stays on the Resume date, and the leveling engine splits the rest of the remaining work, shifting it to start after Task 2 completion. Tasks 5 and 6 are then delayed to start after the Task 4 finish date. But there’s a problem. Tasks 3 and 4 still show overallocated resources. This problem is rooted in how “Split in-progress tasks” sets the Resume date and how the “Leveling can create splits in remaining work” option treats the Resume date. Because the “Split in-progress tasks” option wasn’t checked, the scheduling engine couldn’t split Tasks 3 and 4 and schedule the remaining work based on dependency logic. Therefore, the Resume date for both tasks is the next workday (highlighted above). The “Leveling can create splits in remaining work” option is checked and this allows the leveling engine to split the remaining work, but only after the Resume date. Meaning, the leveling engine will NOT move remaining work scheduled on the Resume date. But the leveling engine will delay remaining work starting with Resume date + 1, and this is what occurs with the Task 4 split. Both Tasks 3 and 4 have the resource allocated on the same Resume date, causing a resource overallocation. Looking at the leveling results from the last example, you can see this overallocation issue when you examine the resource usage view shown below. All remaining work (rose highlights) for Task 3 starts immediately; and while Task 4 was split, the Task 4 remaining work scheduled on the Resume date doesn’t move. As a result, the resource is allocated 13.6 hours on Tuesday, 6/7/16. A Summary on Task Splitting My hope is that you will now be able to recognize task-splitting related outcomes, understand why they occurred and — most importantly — know how to correct them. The main aspects of each task splitting option (when selected) are summarized below. “Split in-progress tasks” When: During scheduling, if a task was started out of sequence. What: Splits all remaining work from actual work. How: Schedules all remaining work to occur following dependency chain logic. Sets: Resume date, to the date on which all the task remaining work will continue. “Leveling can create splits in remaining work” When: During resource leveling. What: Creates splits only within the remaining work. How: Splits remaining work after the Resume date. Remaining work scheduled on the Resume date isn’t moved. Splits can occur in two scenarios: Remaining work after the Resume date is scheduled to occur based on the task dependency chain logic. Remaining work may be split (multiple times) to fill allocation gaps created by predecessor tasks. Image Source

Resource Leveling: Resolution Options

In prior articles, we’ve talked about two of the three resource leveling components. The first component, leveling mechanics, defines what will be leveled and when leveling will occur. The second component, leveling hierarchy is a decision tree for defining the tie-breaker aspects of leveling. In other words, it determines which task stays put and which task is delayed. In this article, we’ll examine resolution options, the third component of resource leveling. Resolution Options Once the leveling engine identifies which task will be delayed, the question becomes how to resolve the overallocation. By default, the leveling engine will simply move that task after the completion of the higher precedence task. The resolution options, shown in the screen below, are part of the resource leveling window, which is accessed by clicking the Leveling Options icon in the Resource ribbon. These options provide additional possibilities. Let’s look at each individually. Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand. Read Daryl’s articles in this resource leveling series here: “Scheduling vs. Leveling” “Problem Indicators” “Leveling Mechanics” “Leveling Hierarchy, Part 1” “Leveling Hierarchy, Part 2” “Resolution Options” “Understanding Split Task Options” “Leveling Fields” “Limitations” “Preparing to Level” “Resource Leveling: It’s Time to Level Your Schedule” “Resource Leveling: The Leveling Cycle” “Resource Leveling: Recommendations” Also, download a resource leveling “cheat sheet” in PDF format! “Level only within available slack” This option is related to the “Slack” tiebreaker I discussed in the leveling hierarchy articles, except it places a constraint on the resolution. When checked, this option tells the leveling engine that tasks can only be delayed within available slack. If insufficient slack is available, this option will leave resource overallocations. This sample shows a series of tasks before leveling. The Task ID chain driving the finish milestone is comprised of Task IDs 60, 61 and 66. The current completion date is 7/20. Task IDs 62 through 65 are all direct successors of Task ID 61 and can start on the same day. They are all direct predecessors of the finish milestone, have varying amounts of slack, and are the only tasks with resource overallocations. This next screen shows the leveling results when the “Level only within available slack” is checked. Task IDs 64 and 65 were delayed as far as possible without impacting the 7/20 date. As a result of this constraint, both Task IDs 64 and 65 still contain an overallocation but the finish date remains unchanged. The final example below shows the leveling results when the “Level only within available slack” remains unchecked. In this scenario, Task IDs 64 and 65 could be delayed to the point that the overallocations were resolved. But this resulted in the final date moving to 7/27. Some project managers like this option checked because the resulting overallocations indicate key points within the schedule where additional work will be required, which could mean overtime or the addition of a temporary, short term resource, if feasible. Other project managers like this option unchecked because this result alerts them when the target date moves and allows them to determine how to bring the date back in. “Leveling can adjust individual assignments on tasks” When checked, this option allows the leveling engine to stagger start dates for each resource assigned to a task. In other words, Joe can start his task work on Monday, Sue can start her work the following Friday, and so on. When this option is unchecked, all assigned resources must be available before the task can be started. This option does nothing if only one resource is assigned. While the staggered start dates have a good chance of extending the task duration, this option will allow the leveling engine to make much more effective use of the resources, as will be demonstrated by the following examples. The first example below shows the schedule before leveling. Daryl and Sue are assigned to Task ID 37. Daryl has one day of work while Sue has five days of work. Task ID 38 is very similar. Daryl has one day of work, Sue has three days of work, and on this task Joe also has five days of work. The sample below shows the leveling results with this option unchecked. There are two key items of note. First, ALL of Task ID 38 work is delayed until after ALL the work on Task ID 37 is completed. Second, Daryl now has a four-day gap in planned work because Daryl’s work on Task ID 38 can’t start until all work on Task ID 37 is finished. Also note that Joe doesn’t start work until day six. The final sample below shows the leveling results with this option checked. Task ID 37 wasn’t adjusted, but Task ID 38 can now start on the same day. This occurs because Joe has no predecessor work and can start his work on Task ID 38 immediately. Daryl can start his work on Task ID 38 on day two, immediately after his one day of work completes on Task ID 37. And finally, Sue’s work on Task ID 38 is delayed to start on day 6, immediately after her 5 days of work completes on Task ID 37. As a result, the gaps left when leveling with this option unchecked disappear, and all the resources are used much more effectively. Also observe that the duration of Task ID 38 changed from 5.36 days to 8 days due to the staggered start/finish times. This option works best when there is no requirement that all assigned resources work on the task at the same time. For example, each resource could be working on a different chapter of the training manual. “Leveling can create splits in remaining work” Leveling results with this option are tightly tied to the scheduling “Split in-progress tasks” option located in the File | Options | Schedule window. Due to the complexity of this relationship, these two options will be examined in the next article in this series. “Level resources with the proposed booking type” The “Booking Type” field allows the project manager to define a project team resource in one of two states.  “Proposed” means the resource is tentative. It can be thought of as a placeholder resource. The resource can be used for cost and schedule forecasting within the project schedule, but the resource’s enterprise availability isn’t affected and tasks assigned to a “Proposed” resource will never appear on their timesheets. “Committed” means the resource is working on the project. Enterprise availability is impacted and tasks assigned to committed resources appear on timesheets. This option is basically an additional parameter for the Level All function. It doesn’t define how to resolve an overallocation. It defines the type of resource to include in leveling. By default, Microsoft Project will only level committed resources. When this option is checked, resources with a Booking Type value of Proposed will also be included in leveling. Consider the following examples. In the example below Resources A and B are assigned to a project. Resource A has been formally assigned to the project and as such, that is reflected in the Booking Type value of Committed. Resource B, however, is tentative and is being used as a placeholder until either confirmed or another resource is assigned. As such, resource B is identified as Proposed. The following example shows the schedule before leveling. Note that Task IDs 3 through 5 are assigned to Resource B. With this option unchecked, the results are shown below. Only resource A is leveled. With this option checked, the after-leveling results show that resource B is also leveled. “Level manually scheduled tasks” This option allows the leveling engine to delay one manual task when it creates an overallocation with another manual task. The leveling engine uses the leveling hierarchy tiebreakers to determine which manual task is delayed. This is illustrated in the following samples. The first sample below is before leveling. Task IDs 36 and 39 are conflicting manual tasks with the same resource assigned. With the option unchecked, Task IDs 36 and 39 are not moved and the resource remains overallocated. With the option checked, Task ID 36 is delayed to start after Task ID 39. As a result, there are no more overallocations. Scheduling Options that Influence Resource Leveling Two scheduling options have a direct impact on the resource leveling results. Both options can be found in the Schedule options window, File | Options | Schedule: “Tasks will always honor their constraint dates”: This option and its relationship to the Task Constraints hierarchy level was discussed in earlier articles on the leveling hierarchy, which you can read in “The Leveling Hierarchy,” part 1 and part 2. “Split in-progress tasks”: This option will be examined in conjunction with the resource leveling option, “Leveling can create splits in remaining work,” which I’ll be discussing next. A Mish-mash of Alternatives The resolution options are a mish-mash of alternatives. Several provide the leveling engine possibilities to make better use of allocated resources, while others constrain leveling or simply identify which types of resources to level. Unlike the leveling hierarchy, which exits the decision tree logic as soon as it determines which task to delay, the resolution options are either available for use (checked) or not available (unchecked). So it is possible for the leveling engine to apply multiple options to the same task. As I noted earlier, my next article will focus on task splitting options available in both the scheduling and leveling options. But in the meantime, challenge yourself. Before instinctively clicking the Level All icon, take a minute to manually review an overallocation and try to determine, based on the leveling hierarchy, which task the leveling engine will delay and why. Then after leveling, examine the results to determine which — if any — resolution options were applied. Have questions for author Daryl Deffler on resolution options? Post them in the comments below.

Resource Leveling: The Leveling Hierarchy, Part 2

Last time I introduced the concept of the “leveling hierarchy” and examined the first three hierarchy levels: Priority 1000, Manual and Started Tasks. In this article, we review the remainder of the leveling hierarchy. As a reminder, all of the examples I present look for overallocation on a “Day by Day” level with the scheduling option “Split in-progress tasks” unchecked and all “Resolving overallocation” options also unchecked. Many leveling examples purposely contain limited or no dependency relationships to expose leveling results in a scenario where tasks can be moved freely by the leveling engine. Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand. Read Daryl’s articles in this resource leveling series here:“Scheduling vs. Leveling”“Problem Indicators”“Leveling Mechanics”“Leveling Hierarchy, Part 1”“Leveling Hierarchy, Part 2”“Resolution Options”“Understanding Split Task Options”“Leveling Fields”“Limitations”“Preparing to Level”“Resource Leveling: It’s Time to Level Your Schedule”“Resource Leveling: The Leveling Cycle”“Resource Leveling: Recommendations” Also, download a resource leveling “cheat sheet” in PDF format! Leveling Order The following hierarchy levels are part of the ordered list associated with the selected leveling order value. They are presented in the sequence, Leveling Order = Standard. Predecessors The predecessor tie-breaker looks at task dependency relationships. Predecessor tasks are given higher leveling priority than their successor tasks. The next example shows how the leveling engine treats tasks with predecessor relationships. The screen below is pre-leveling. Task IDs 10-13 are linked in a basic waterfall chain, Task ID 14 is a Priority 1000 task and Task ID 15 is a Manual task. The following sample shows the results of leveling. Task ID 14 stayed put because it’s a Priority 1000 task. Task ID 15 didn’t move either because it’s a Manual task. Task ID 10 is leveled first, because it is the predecessor task to the entire dependency chain. Because it created an overallocation with the Priority 1000 task, Task ID 10 is delayed to start after the Priority 1000 task. Task ID 11 is leveled next; but because it can’t start immediately after Task ID 10 without creating an overallocation with Task ID 15, it’s delayed to start after Task ID 15. Then Task IDs 12 and 13 follow in sequence. Slack Slack is the amount of time a task can be delayed without affecting its successor task. When Project uses Slack values to determine which task to delay, the task with the smaller Slack value (before leveling) wins, and the task with the larger Slack value is delayed. Translated, the task with less wiggle room is leveled first. This is somewhat counterintuitive, but it will make more sense to you if you go through the examples below: The Task ID chain driving the finish milestone is comprised of Task IDs 2, 3, 7 and 8. Task IDs 4-7 are all direct successors of Task ID 3 and can start on the same day. The combination of Task ID 7 and 8 is an eight-day duration. Task IDs 4-6 are also direct predecessors of the finish milestone. These three tasks range from one to three days of duration and have a range of eight days in which to complete their work before causing an impact on the completion milestone. Thus, they have slack. Task ID 6 has five slack days. Task ID 5 has six slack days Task ID 4 has seven slack days. Because Task IDs 7-8 are a different resource altogether, only Task IDs 4-6 are overallocated. When Project levels Task IDs 4-6, 6 wins and stays put because it has the smallest window for delay (five slack days). Task IDs 4 and 5 are delayed until after Task ID 6. Then Task ID 4 and 5 are compared and Task ID 5 wins because it had the next smallest delay window (six slack days). As a result, Task ID 4 is delayed until after Task ID 5. This can be seen in the screen below, which shows the results after leveling. Note: Prior hierarchy levels didn’t resolve the resource overallocation on Task IDs 4-6. There are no Priority 1000 tasks, no Manual tasks, no tasks Started, and all three tasks had the same predecessor or successor. As a result, resolving this overallocation came down to Slack values. Dates This tie-breaker looks at task Start dates. When two tasks create an overallocation, the task with the earlier start date before leveling wins, and the later start date task is delayed. In the first sample below, Task IDs 3 and 5 are assigned to the same resource and there is an overallocation as indicated by the burning man problem indicator. Task ID 5 has an earlier start date. After leveling, Task ID 3 has been delayed to begin after Task ID 5 because Task ID 3 had the later start date before the leveling. Note: If the tasks are in the same dependency chain, meaning Task IDs 2 and 4 have a common predecessor, the Dependency tie-breaker takes precedence. While the concept of this level is simple, it may be rarely used if all schedule tasks have predecessors and successors. Constraints This tie-breaker applies to tasks with a user-entered constraint type other than “As Soon as Possible.” The leveling engine will always try to honor those constraints; however, there are scenarios where Project will disregard the constraint date and delay the task. There’s also a way to force Project to honor the constraint. In the first example below, Task ID 5 has a Must Start On constraint with the date of June 6, 2016. The second example shows the leveling results. Task ID 1 can finish before the constrained task, so it stays put. Task ID 2 is delayed to begin after the constrained task, and Task IDs 3 and 4 are also delayed as shown. The third example is another pre-leveling example. In this scenario, Task IDs 1-4 are linked in a basic waterfall relationship and Task ID 5 has the same constraint as prior examples. The schedule after leveling is shown below, and the results are similar to the previous example. But why didn’t Task ID 2 take precedence over the constrained task? After all, it has a predecessor, which gives it a higher tie-breaker level. As I mentioned, Project tries to honor the constraint because this can be thought of as a pseudo-manually scheduled task. While not manually scheduled, it has a manually entered override constraint. In the screen below, Task ID 1 stays put. Since the manual constraint can be honored, Project leaves Task ID 5 alone and delays the remainder of the dependency chain until after Task ID 5. The next example, below, shows a different twist. The only change is that duration of Task ID 1 was changed from two days to three days. Now, when leveling occurs, Task ID 1 stays put, but because its duration overlaps with the constrained task, the constrained task is also delayed a day. The result is a constraint violation identified by the circled problem indicator. In my final example below, the scheduling option “Tasks will always honor their constraint dates” has been checked. This option can be found in the File | Options | Schedule window. Even though this option is a scheduling option, it has an impact on leveling because it forces Project to honor the constraint date in both scheduling and leveling. The final leveling results are shown below. Since Task ID 1 overlapped the constrained task, it was delayed until after the constrained task completes. The constrained task takes precedence. The rest of the tasks then follow the dependency chain. Priority This tie-breaker examines the individual task level Priority field values to determine leveling order. The field values can range from one to 1,000 with one being the lowest priority. Priority 1000, which I covered in the last article, has special meaning and won’t be discussed here. The default value is 500. In the screen below, I’ve highlighted the non-default Priority values. Note that Task ID 3 contains a “must start on” constraint of June 8. The screen below shows the results after leveling. Task ID 4 has the highest priority at 600 and takes precedence. Task ID 3 contains the constraint, so it leveled second. Then, the remaining tasks are leveled in descending order based on their priority value. If Priority values are being used, it’s beneficial to change the leveling order value to “Priority, Standard.” Without changing this parameter, the Priority value won’t be taken into consideration until almost the bottom of the hierarchy (Leveling Order = Standard) or not even included (Leveling Order = ID Only). Final Predefined Hierarchy Levels The following two tie-breaker levels are predetermined by Project. They’re the last two levels within the overall hierarchy. Duration When tie breakers with no higher precedence can determine which task stays put and which task is delayed, the leveling engine will examine task duration. Longer tasks are considered more important and will therefore be leveled first. In the sample below, Task ID 4 has five days of duration, Task ID 3 has four days and the remaining tasks last three days. After leveling, the tasks are ordered in descending rank by duration. But why did Task ID 1 take precedence over Task ID 2? That’s the final tie breaker. Task ID The final tie breaker in the hierarchy is the Task ID value. Tasks with a lower Task ID value will level before tasks with a higher Task ID. In other words, top down. In the first screen below, both tasks are the same in every respect, which means no other hierarchy level breaks the tie. After leveling, Task ID 2 is delayed because its Task ID value is greater than Task ID 1. Leveling Order Comparison The following compilation illustrates how the leveling results can be radically different when you use each of the three leveling option values. (I’m showing the chart again so that you don’t have to go hunting for it at the start of the article.) Each sample started with the same schedule and other options. However, there’s one difference on these examples from those presented earlier. I’ve checked the scheduling option, “Tasks will always honor their constraint dates.” Leveling Order Standard Results Task ID 9: Priority 1000; Task ID 5: “Must Start On” constraint; Task IDs 10-12: Predecessor relationships; Task IDs 8 and 7: In descending priority value sequence; Task IDs 4 and 3: In descending duration sequence; Task IDs 1 and 2: In ascending Task ID value sequence; and Task ID 6: The “Finish No Later than” constraint can’t be honored, so the task is delayed until the end of the schedule and shows a constraint violation problem indicator. Leveling Order Priority, Standard Results Task ID 9: Priority 1000; Task ID 8 and 7: In descending Priority value sequence; Task ID 6: The “Finish No Later than” constraint was close, but couldn’t be honored; so the task is delayed and the task shows a constraint violation problem indicator; Task IDs 10-12: Predecessor relationships; Task IDs 4 and 3: In descending duration sequence; Task IDs 1 and 2: In ascending Task ID value sequence; and Task ID 5: “Must Start On” constraint can’t be honored; the task is delayed until the end of the schedule, and the task shows a constraint violation problem indicator. Leveling Order ID Only Results Task ID 9: Priority 1000; Task ID 5: “Must Start On” constraint could be honored; Task IDs 1-3: in ascending Task ID value order. Note that ID 3, was started and split around Task ID 6; Task ID 6: The “Finish No Later than” constraint is close, but can’t be honored; the task is leveled next and shows a constraint violation problem indicator; Task ID 7-8: in ascending Task ID value order; and Task IDs 10-12: in ascending Task ID value order. It’s a Tie-breaking Decision Tree An overallocation is a scenario where a project team resource, for example, Joe, is scheduled to work on multiple tasks, A and B, concurrently. As a result, Joe’s planned work in that period exceeds his availability. In this scenario, the first thing resource leveling must do is answer one simple question: Which task is delayed, A or B? The leveling hierarchy defines a decision tree for answering that question. It offers a series of six to 10 tie-breakers that compare attributes of both tasks, checking user defined aspects such as priority or constraints, task progress (started), and other characteristics such as slack, duration and Task ID. Eventually, the hierarchy will find a tie-breaker; the task with higher precedence will stay put, and the other task will be delayed. Once a determination is made to delay task A or B, Project needs to know which leveling techniques can be used to make the most effective use of available resources. These are the resolution options, which we’ll discuss in the next article. Have questions about these aspects of resource leveling? Pose them to author Daryl Deffler in the comments below.

Resource Leveling: The Leveling Hierarchy, Part 1

Last time we examined resource leveling mechanics for Microsoft Project. This time, we look at the leveling hierarchy. And because it’s a BIG topic that can easily overwhelm, I’m breaking it into two “bite-sized” articles. Overallocation Types As a refresher, an overallocation is a situation where a project resource is scheduled to work more than he or she is available. For example, Joe is scheduled to work 58 hours in a week even though he is only available 40 hours per week. There are two types of overallocations. The first type is a combination of the task configuration and resource assignment which results in an overallocation within a single task. The project manager must fix these scenarios by making task configuration and resource assignment changes. Leveling will not fix these. The second type of overallocation is the result of multiple tasks scheduled in parallel. Because leveling will generally fix these, I focus on this type of overallocation in this article. Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand. Read Daryl’s articles in this resource leveling series here: “Scheduling vs. Leveling” “Problem Indicators” “Leveling Mechanics” “Leveling Hierarchy, Part 1” “Leveling Hierarchy, Part 2” “Resolution Options” “Understanding Split Task Options” “Leveling Fields” “Limitations” “Preparing to Level” “Resource Leveling: It’s Time to Level Your Schedule” “Resource Leveling: The Leveling Cycle” “Resource Leveling: Recommendations” Also, download a resource leveling “cheat sheet” in PDF format! Leveling Hierarchy When resolving an overallocation, Project follows a decision tree — a tie-breaking hierarchy to determine which task wins (stays put) and which task loses (is delayed). The first and last parts of this hierarchy are predetermined by Microsoft and built into the scheduling engine. But the project manager can tailor the core of this hierarchy by changing the “Leveling order” parameter. The Leveling order parameter is part of the Resource Leveling window. You access it by clicking the Leveling Options icon in the Resource ribbon. There are three options: “Standard,” “Priority, Standard” and “ID.” Each parameter or option represents a predefined hierarchy list inserted into the middle of the overall hierarchy. Here’s a little chart that lays out the leveling hierarchy, including the predefined leveling order options. The first three levels — Priority 1000, Manual Tasks and Started Tasks — are predetermined by Microsoft. After that the ordered list associated with the selected leveling order value is inserted. And the last two levels — Task Duration and Task ID — are also predetermined. Leveling Sample Options The following sections illustrate each tie-breaker within the leveling hierarchy. I present them in the Leveling order = Standard sequence. Unless I indicate otherwise, for all of my examples, overallocations are examined on a “Day by Day” level, the scheduling option “Split in-progress tasks” is unchecked and all the “Resolving overallocations” options are also unchecked. Many leveling examples purposely contain limited or no dependency relationships so that leveling results can be seen in a scenario where tasks can be moved freely by the leveling engine. Initial Predefined Hierarchy Levels The following hierarchy levels are predetermined by Project. They are the first three levels within the overall hierarchy. Priority 1000 and Manual Tasks Priority 1000 is the highest-level tie-breaker. Nothing else is higher. Priority 1000 is a value of 1000 inserted into the Priority column at the task level. This task will never be touched by leveling. Nor — short of manually changing the task configuration — is there a way to make leveling delay a Priority 1000 task. Other priority values and their impact on leveling will be discussed later in this article. The second highest tie-breaker is Manual Tasks. These are tasks with a Task Mode value set to Manual. Manual tells Project to bypass this task during leveling. However, as I will explain in a later article, the “Resolving overallocations” option “Level manually scheduled tasks” can allow leveling to move a manual task, but probably not in the way you’d think. The following two examples illustrate leveling with Priority 1000 and Manual Tasks. The first screen shows the schedule before leveling. Task IDs 2-5 are general tasks. Task ID 6 is a Priority 1000 task, and Task IDs 7 and 8 are Manual tasks. The screen below shows the results after leveling. Task IDs 6-8 stayed put and Task IDs 2-5 were delayed to fit around the Priority 1000 and Manual tasks. Additionally, notice the “burning man” problem indicator on Task IDs 6 and 7 which indicates resource DD remains overallocated. This overallocation remained because one task is Priority 1000 and the other task is Manual. Both task configurations tell the leveling engine to skip the task. As a result, an overallocation remains. Started Tasks Started Tasks are any task with actual work applied. Project contains internal logic that assumes a started task takes precedence over an “un-started” task. While the leveling engine treats all started tasks in the same manner, leveling results are best illustrated when a task is started out of sequence. The following two examples illustrate how the leveling engine treats Started Tasks. The first screen shows the schedule before leveling. Task IDs 2-5 are general tasks linked in a waterfall dependency sequence. Task ID 5 has been started out of sequence, having actual work applied before any of its predecessor tasks. Task ID 6 is a Priority 1000 task, and Task IDs 7 and 8 are Manual tasks. The screen below shows the results after leveling. The remaining work for Task ID 5, the started task, is now scheduled first, even though this breaks dependency logic and creates a resource overallocation with Task IDs 6 and 7. Again, Project assumes that started tasks take precedence over un-started ones. In simple terms, if you started it ahead of other tasks, it must be because it’s more important. Task IDs 6-8 stayed put because they are Priority 1000 and Manual tasks. Task IDs 2-4 were delayed to start after the started task and to fit around the Priority 1000 and Manual tasks. But notice that Task ID 5 now contains a burning man problem indicator also. Even though the remaining work for Task ID 5 creates an overallocation, the leveling engine doesn’t delay it. The “Split in progress tasks” option will correct this scenario. This will be discussed in more detail in a future article. Next time, we’ll continue our examination of the leveling order hierarchy.

Resource Leveling: Leveling Mechanics

Resource leveling is comprised of three components, and you need knowledge of all three to understand leveling in Microsoft Project. Leveling mechanics define the “what” and “when” aspects of leveling. Leveling hierarchy defines the tiebreaker aspects of leveling — which task wins (stays put) and which one loses (has to move). Resolution options define “how” overallocations can be resolved. Stated another way, it defines the techniques Project can use to resolve an overallocation and any restrictions that constrain the resolution. Over the next few articles, I explain and illustrate the options in each component. Let’s start to peel back the layers of resource leveling with an examination of leveling mechanics. Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand. Read Daryl’s articles in this resource leveling series here: “Scheduling vs. Leveling” “Problem Indicators” “Leveling Mechanics” “Leveling Hierarchy, Part 1” “Leveling Hierarchy, Part 2” “Resolution Options” “Understanding Split Task Options” “Leveling Fields” “Limitations” “Preparing to Level” “Resource Leveling: It’s Time to Level Your Schedule” “Resource Leveling: The Leveling Cycle” “Resource Leveling: Recommendations” Also, download a resource leveling “cheat sheet” in PDF format! Leveling Mechanics In simple terms, leveling mechanics define when leveling will occur, what constitutes an overallocation and the date range to be leveled. These parameters are part of the Resource Leveling window (shown below), which you access by clicking the Leveling Options icon in the Resource ribbon. Let’s examine the functions you’ll find in this window. Leveling Calculations This option determines when leveling occurs. If “Automatic” is selected, leveling automatically occurs for every task and every resource after every change. This is generally not recommended. With the “Manual” option selected, leveling only occurs when the project manager manually clicks one of the leveling icons (Level Selection, Level Resource, or Level All). The “Manual” option provides more control, allowing you to determine which resources to level, which tasks to level and when. It also lets you view and assess scheduling results separately from leveling results, which can be useful when you’re attempting to determine the cause of a schedule issue. Look for Overallocations on a [Timeframe] Basis When looking for an overallocation, Project knows that any resource exceeding the Max Units is overallocated. But the program also wants to know the size of the timeframe to be examined for an overallocation. This option defines that timeframe size. When “Hour by Hour” is selected, Project will examine each hour looking for overallocations. In a simple scenario say that Harry works a 40-hour, five-day week and is available 100 percent of the time (Max Units). Translated, Harry can work one hour within each one-hour timeframe. Any one-hour timeframe with more than an hour of allocation would be considered as an overallocation. Still considering Harry’s situation, if you select the “Day by Day” option, Project will look for any daily allocation exceeding eight hours. And when the “Week by Week” option is selected, Project looks for any weekly allocation exceeding 40 hours. The same pattern holds for the other options. When smaller timeframes are analyzed for overallocations, generally, more overallocations will be found. Conversely, when larger timeframes are analyzed, fewer overallocations will be found. The larger timeframe allows more “fudge factoring.” Monday could be overallocated by an hour and Wednesday under-allocated by an hour. But the net result across the entire week is that the resource is allocated at 40 hours or less. This is illustrated by the following two examples. The first example below illustrates leveling “Day by Day.” Notice that Harry’s work allocation is a nice, flat eight hours per day. This is pretty much what project managers expect to see after leveling. The second example, below, is a bit more interesting. It illustrates the same tasks leveled with “Week by Week.” Here, Harry is allocated 16 hours on Monday and Tuesday, eight hours on Wednesday and zero hours on the remaining week days. But why is there no red text to indicate an overallocation problem on Monday or Tuesday, even though Harry is clearly allocated more than eight hours each day? The answer is simple. Project is looking for overallocations at a weekly level. When examined in that timeframe, Harry doesn’t exceed 40 hours per week so he’s not considered overallocated. Generally speaking, set this parameter to match the timeframe most commonly used in project schedule analysis. If the project schedule will be scrutinized at a daily level, set this parameter to “Day by Day”. If analyzing the schedule at a weekly level, set this parameter to “Week by Week”. Clear Leveling Values before Leveling When checked, this option tells Project to reset, or clear the results of the prior leveling process before leveling the schedule again. This initiates the same function as clicking the Clear Leveling icon. If you leave this unchecked, the results of the prior leveling process won’t be cleared first. Project uses fields such as Preleveled Start, Preleveled Finish and Leveling Delay to store pre-leveling values and post-leveling results. These fields allow Project to reset the schedule back to a pre-leveling state when the Clear leveling function is initiated. Because leveling may change task start and finish dates, the original start and finish dates are stored in the preleveled start and finish dates. After leveling Project determines the number of days that leveling delayed the task and stores that value in the Leveling Delay field as “edays,” or elapsed days. This example shows a leveled schedule. Note the Preleveled and Leveling Delay column values. After the Clear Leveling icon is clicked, Project resets the schedule back to the pre-leveled state as shown below. Tasks are moved back to their original Start and Finish dates, which were stored in the Preleveled fields. The Leveling Delay values are now zero. Note: Microsoft recommends checking this option to avoid the potential of compounded leveling results. Leveling Range The leveling range options determine the date range to be leveled. The “Level entire project” option tells Project to level tasks regardless of the date range — basically, all tasks. The “Level From: To:” option tells Project to level tasks only within the defined date range. Tasks outside the defined range will be ignored. The following examples illustrate leveling within a specific date range. The first screen shows the project schedule before leveling. All five tasks start on 4/28. In the second screen the project schedule was leveled only within the 4/28 through 5/5 date range. Task 1 stayed put. Task 2 was delayed to start after Task 1 is finished. Tasks 3 through 5 were delayed, but because leveling was constrained within the 4/28 through 5/5 date range, as soon as these tasks were delayed beyond the 5/5 leveling constraint, leveling moved them no further and dropped them onto 5/8, the next working day. Next time, we’ll examine the leveling hierarchy, the component that serves as the tie-breaking judge.

Resource Leveling: Problem Indicators

Who doesn’t like a good mystery movie? They’re chockful of timelines, inter-related events and lots of clues that, when understood, help the viewer arrive at a solution. These same attributes can also describe an uncooperative project schedule. But while a good mystery is entertaining and goes great with popcorn, a project schedule that won’t schedule or level correctly can be downright frustrating. Luckily, Microsoft Project provides clues to help identify and correct leveling issues, if you know what to look for. Project provides the project manager with clues in the form of visual indicators. The indicators are used to convey information and identify problems. Both types do what they sound like. Informational indicators provide information. Problem indicators tell the project manager that there is, or might be, a problem here. In this article I discuss the different types of indicators and what they’re telling us and in some scenarios show how a sample problem could be corrected. Informational Indicators Informational indicators are icons displayed in the Indicator column of a task or resource view. They are informational only and as such don’t necessarily mandate any actions by the project manager. However, there are two types with subtle differences. The first type is purely informational. For example: The second type tells the project manager, “There’s something atypical about this task.” For example: While atypical indicators can be purely informational, they also tell the project manager to “be aware” because they can also be clues pointing to the root cause of a scheduling or leveling problem. For instance, remaining work stuck in the past may be the result of an inflexible constraint, or a gap in resource usage may be the result of a task calendar specifying that work can only occur on Tuesdays. Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand. Read Daryl’s articles in this resource leveling series here: “Scheduling vs. Leveling” “Problem Indicators” “Leveling Mechanics” “Leveling Hierarchy, Part 1” “Leveling Hierarchy, Part 2” “Resolution Options” “Understanding Split Task Options” “Leveling Fields” “Limitations” “Preparing to Level” “Resource Leveling: It’s Time to Level Your Schedule” “Resource Leveling: The Leveling Cycle” “Resource Leveling: Recommendations” Also, download a resource leveling “cheat sheet” in PDF format! Problem Indicators Project uses several types of visual indicators to notify the project manager, “There’s something wrong here and you should probably fix it.” These are problem indicators, which can be displayed in two ways: 1) as icons in the Indicator column; or 2) as a red bit of text, a number or a graphic. Problem indicators come in two flavors as well: those signifying leveling issues and those representing overallocation. Leveling Issue These indicators are icons displayed in the Indicator column. They highlight non-resource-related problems that couldn’t be resolved by the leveling engine. For example, a constraint violation is designated with this icon: In the sample below, task 7 contains a “Finish No Later” than constraint of June 29, but the task is finishing in August. There’s also the non-intersecting work calendars indicator: This scenario is illustrated by task 70 below. While the task uses a Monday through Friday workday calendar, the assigned resource can only work on Saturdays: Overallocation These indicators highlight resource-related schedule problems. While these indicators include icons displayed in the Indicator column, they also include red text, numbers and graphics that can appear just about anywhere. Resource overallocations identified within the Indicator column are illustrated below.   The red “burning man” indicators appears in a task view; the yellow diamond appears in the resource view. This sample illustrates the overallocation of a resource in the task view (indicating that at least one resource assigned to the task is overallocated): This shows an overallocation in the resource view (including that the resource has at least one task assignment on which he or she has been overallocated): Note: The resource name also appears in red to indicate an overallocation. As I noted, Project also indicates overallocations by displaying red text. In the sample below, it’s obvious Joe is overallocated because the Name and Work columns are red. Additionally, looking at the timescale data, it’s clear that Joe is overallocated Monday through Thursday because the summary row totals by period are red. But digging a bit deeper, you can also see that Joe is overallocated on “Test Task” because those task-specific numbers are also displayed in red. But why are only the summary and Test Task numbers displayed in red? I’ll discuss that in a moment. Finally, overallocations can also be seen in graphics. Here’s Joe’s overallocation in a resource graph. Joe’s name appears in red and his overallocations appear as the red bars in the stacked graph: Here it is in Team Planner, where his name is shown in red and the days on which Joe is overallocated are bracketed in red: Overallocation Types As I mentioned earlier, there are two types of overallocations: by time and by task. As a project manager, you need to be able to distinguish them and understand how to correct each. Let’s re-examine the earlier example. You can identify time overallocations by looking for red numbers within the summary row of a Resource Usage view. The sample above illustrates this. The summary allocation for Joe is 56.67h on Monday, 64.67h on Tuesday and so on. Time overallocations occur when the sum of multiple tasks in the same period exceeds the resource’s maximum availability. The sample shows that individually, Tasks 10 through 15 are fine. But when summing these tasks along with Test Task, the total exceeds resource availability and the resource ends up overallocated. There’s a good chance that resource leveling will fix these issues. However, it’s always possible for a talented project manager to induce these types of problems by using techniques like hard constraints or manual tasks that resource leveling can’t fix. You can identify task-specific overallocations by looking for red numbers appearing on a specific task within a Resource Usage view. This is illustrated on Test Task in the sample above. Task-specific overallocations are caused by the combination of task configuration and resource assignment. Looking at the Test Task sample, Joe is available to work eight hours per day. But in this sample, Test Task was created as a three-day fixed-duration task with 50 hours of work. As a result, Joe ends up allocated 16.67 hours per day which obviously exceeds his daily eight-hour capacity. The second example is a bit more perplexing. There’s only one task assigned and the total work is one hour. So why is Project flagging this as an overallocation? In this sample, the resource max units is 85 percent, meaning the maximum the resource can be assigned to any unit of time is 85 percent. For example, 85 percent of an eight-hour day would be 6.8 hours. And 85 percent of a 60-minute hour would be 51 minutes. In this case, the resource was assigned at 100 percent (60 minutes) to a one-hour fixed-duration meeting task. Because the 60-minute resource assignment within this one-hour period exceeds the 51 minutes the resource is available in that period, that specific period (not the task) is flagged as an overallocation. Since resource leveling won’t fix either of these examples, you as the project manager would be required to adjust either the task or assigned resource to correct the overallocation. Project’s Clues Project provides lots of clues in the form of visual indicators to tell the project manager that something’s wrong or may be a concern. These indicators may point to specific issues or they may point to something that could be the indirect cause of an issue. Understanding how to interpret these clues can help you resolve schedule and leveling issues and ultimately build better project schedules. However, I offer this caution: Problem indicators don’t identify all scheduling and leveling issues. But we’ll leave that discussion for another article. Additional information about the Indicator icons can be found at this Microsoft support link. Next time, we begin to examine leveling components, starting with leveling mechanics.

Resource Leveling: Scheduling vs. Leveling

“Don’t click the level button — it messes up your schedule.” How many times have you said this or heard it? If I had a nickel for each time I’ve heard this over the course of 25-plus years, well, let’s just say I’d be a wee bit closer to a comfortable retirement. There’s a truth in that statement. Microsoft Project will mess up your schedule — if you don’t understand what leveling does or how it works. Sometimes we forget that Project is only a software tool, albeit a complicated one. It has no perception of time and therefore doesn’t understand concepts like today, the past or the future. It only has algorithms. And it doesn’t understand what we “want” it to do; it only does what we “tell” it to do. As a result, the ownership is on us, the human, to learn how Project works and what the available options do so that we can “tell” Project the right things to get the results we “want.” Resource leveling — or just “leveling” as it’s more commonly known — is probably the most complicated, feared and misunderstood functionality within Project. It takes a long time to learn and the learning process is often a series of anxiety-filled experiments that end up creating more frustration than understanding. And because project managers actually have projects to run (who knew?), they typically don’t have time to experiment. The result; “Don’t click that button…” It’s time to change that. This is the first in a series of articles focused on resource leveling. The series objective is simple; to uncloak the mystery that is resource leveling and help you, the project manager, transition from fighting the tool to controlling the tool. To accomplish the objective this series includes articles covering the following general topics: Laying a foundation, including scheduling vs. leveling and problem indicators and what they’re telling you; A deep dive into how leveling works, including leveling mechanics (what to level and when); Leveling hierarchy, covering which task stays and which task moves; Resolution options — ways to resolve overallocations and limitations; Leveling a schedule such as preparing to level, the leveling functions and the leveling cycle; and Leveling guidelines. Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand. Read Daryl’s articles in this resource leveling series here: “Scheduling vs. Leveling” “Problem Indicators” “Leveling Mechanics” “Leveling Hierarchy, Part 1” “Leveling Hierarchy, Part 2” “Resolution Options” “Understanding Split Task Options” “Leveling Fields” “Limitations” “Preparing to Level” “Resource Leveling: It’s Time to Level Your Schedule” “Resource Leveling: The Leveling Cycle” “Resource Leveling: Recommendations” Also, download a resource leveling “cheat sheet” in PDF format! Scheduling vs. Leveling: An Overview Scheduling and leveling are two distinct foundational concepts within Project. They’re as essential as formula calculations are to Excel. In essence, they’re the primary reason for Project; to automate the process of sequencing project tasks while making the most effective use of available resources. Scheduling is timeline-oriented, focused on creating the absolute shortest schedule duration. It occurs when the Calculate Project icon is clicked. Or, if you’re like many project managers who turn on the “Calculate project after each edit” option, scheduling occurs automatically after every change. Leveling is resource-oriented, focused on making the most effective use of available resources. It occurs when one of the leveling icons such as Level All is clicked. If the Leveling option “Leveling calculations” is set to Automatic, it can also occur automatically, after every change is made. What does “timeline-oriented” and “resource-oriented” mean? The following sequence provides a simple illustration of how scheduling and leveling work. For this sequence automatic scheduling and leveling have been turned off. The project manager creates Tasks 1 through Task 3 with no relationships as illustrated below. Resource A is overallocated on the first three days. In the second screen, below, the project manager defines Task 1 as the predecessor to Tasks 2 and 3. Notice that even though the relationships have been established, nothing has changed. The project manager clicks the Calculate Project button and the results are shown below. Tasks 2 and 3 are shifted later in the timeline because they’re Task 1 successors. But notice Tasks 2 and 3 start on the same day, even though this overallocates the resource. The reason is simple: Scheduling is focused on sequencing the tasks to create the absolute shortest possible duration. Starting Tasks 2 and 3 on the same day doesn’t violate any dependency relationship, but it does result in the shortest possible duration, regardless of resource impacts. In the final sample, below, the project manager clicked Level All. At this time, leveling, which is resource-oriented, delayed Task 3 to start after Task 2. This was done not because of any dependency relationship between Tasks 2 and 3, but because the first availability for the resource was the following Friday. The following table provides a summarized comparison of both scheduling and leveling.   Note: Task-level adjustments such as changing work, resource assignment units or duration adjust the individual task immediately, regardless of the automatic schedule or level option selections. Guidelines As tempting as it might be to set both scheduling and leveling to occur automatically, I don’t recommend this. My suggestion: Configure scheduling to occur automatically and leveling to occur manually. This is recommended for several reasons. Performing both processes automatically blurs the process boundaries, and as a result it becomes difficult to determine if an issue appeared during scheduling or leveling. Performing these processes separately helps resolve issues at a high level. If the issue appears after scheduling (before leveling), it’s task related (task configuration, task dependencies, etc.). When the issue appears after leveling, it’s resource related. Additionally, Microsoft recommends executing these processes separately to enable better tool performance and to produce better results. Next time: Learn about resource leveling indicators.

How Microsoft Project Calculates Task Duration

Ever wondered why a task starting on 1/2/17 and ending on 1/30/17 displays a duration value of three days while a task starting on 1/2/17 and ending on 1/6/17 displays a duration value of five days? Or why an allocation of three hours on one day is a duration value of 0.75 days, while an allocation of eight minutes on another day may show as 0.33-day’s duration? This article explores how Microsoft Project calculates duration and allocates work. I also try to demystify why these seeming inconsistencies are actually accurate. Microsoft Project isn’t Human The first thing to do is to forget about thinking like a human. As humans, our instinct when allocating a resource four hours of work on a day is to allocate the work from 8:00 a.m. to 12:00 p.m., noon to 4:00 p.m. or some other contiguous block of time. Unfortunately, Project doesn’t “think” that way. Microsoft’s project management application distributes work allocation based on mathematical algorithms. As a result, it does things that make sense from an algorithm perspective, but not from a human perspective. And that’s what we humans need to understand. Project defines Duration as the “Total span of working time for a task.” Based on that definition, one would think that calculating a task duration would be rather simple: the number of business days between the task Start date and the task Finish date (inclusive). But let’s consider the following examples. Tasks 1 through 5 and Task 8 are all eight-hour tasks with one assigned resource allocated at 50 percent. Looking at the Duration column values, the task Durations for those tasks range from two days to 10 days. Tasks 6 and 7 are three and four Work hours with 0.75 day and one-day durations, respectively. There are a lot of inconsistencies. So just how does Project really calculate Duration? Project uses two duration calculation formulas, one for Fixed Duration tasks and another for Fixed Units and Fixed Work tasks. Let’s explore each. Fixed Duration Tasks Fixed Duration tasks are the easiest, directly aligning with most people’s initial concept for how duration should be calculated. It’s simply the number of business days between the task Start date and the task Finish date (inclusive). Looking at Tasks 1 and 2 above, both are Fixed Duration with a project manager-entered duration value of 10 days. Task 1 is a Flat work contour (default value) which simply means Work value is equally distributed across the entire Duration. In this example, the timescale data confirms this, showing there are 0.8 hours of work planned for each of the 10 days. Task2 is slightly different. While it is also Fixed Duration with eight hours of work, the Work Contour field contains a value of “Contoured,” meaning the project manager manually entered planned work values directly into the timescale data cells. In this case, the PM decided that the eight hours of work would be done by working four hours on day four and the final four hours on day eight. Note that all other days show zero planned hours and the final two days show no value whatsoever. In both these Fixed Duration examples, the Duration is 10 days simply because the PM entered that value. Both tasks start on 1/2/17 and finish on 1/13/17. How the work is distributed across those 10 days is irrelevant. Fixed Units or Fixed Work Fixed Units or Fixed Work duration calculations are more complex and less intuitive. Starting simply, duration only includes any day on which work is planned. Restated from another perspective, duration does NOT include any day on which planned work is zero. Task 8 below illustrates this concept. Despite the task Start date of 1/2/17 and a Finish date of 1/11/17, the task Duration is three days (not eight) because work only occurs on the three highlighted days. So far, easy, right? Just wait. It gets more complicated. Daily Work Distribution The first step in understanding work distribution is to understand how Project divides the work across the days. Assignment Units, Work Contour and Work fields all play a part in this determination. Again, starting simply, Task 5 below has eight hours of planned work, the resource is allocated with an Assignment Units value of 50 percent, and the Work Contour value is “Flat,” meaning the work is spread equally. Project determines the maximum hours per day to be four (50% x 8 hours per day) and then proceeds to spread the eight hours of work at four hours per day. In this case, the result is a two-day duration. Task 4 follows the same work distribution process, albeit slightly more circuitously. In this example, the Work Contour value is “Front Loaded.” As with Task 5, the Assignment Units value of 50 percent determines that work distribution cannot exceed four hours per day, but the Work Contour (Front Loaded) algorithm determines the number of days and how the work will be allocated on each day. The result is a four-day load pattern highlighted below. But wait! That doesn’t really explain why each task’s partial daily allocation (compared to an eight-hour day) is considered a full day. The key to understanding this aspect rests within how Project physically distributes the time. Time Segment Allocation The second step to understanding work distribution is being aware of how Project divides the work day. Each day is 24 hours. Each hour is comprised of 60 one-minute segments. This is a basic but important concept in understanding Project. Let’s go through it in more detail. The following screenshot shows a daily timescale segmented into hours 12 a.m. through 11 a.m. and then 12 p.m. through 11 p.m. The sample below shows an hour within a day segmented into 10 six-minute segments starting at 0, 6, 12, 18, etc. minutes past the hour. Without grouping, each hour would show 60 one-minute segments. After the day’s work allocation is calculated, Project distributes the day’s total planned work across the time segments within each day. When the workday is displayed as one-hour segments, the timescale data below reveals what Project is really doing. If you recall, our Task 5 example showed that Project calculated four hours per day. Looking at Task 5 below, rather than allocating four hours from eight to 12, as a person might do, Project spreads the four hours across all of the day’s time segments. The result, as highlighted below, is that each hour segment contains 0.5 hours of work. Each of the eight one-hour time segments contains planned work. And because each of the daily time segments contains work, Project sees this as a full day of Duration. As a result, the four hours of work counts as a full day of Duration. Looking back to our Task 4 example, the Work Contour (Front Loaded) algorithm calculated a four-day task duration with daily work allocations as shown below. The following screenshots show how each day’s planned work distributed across each of the eight one-hour segments. On Monday, the four hours of work spread out as shown below. On Tuesday, the 2.67 hours of work was distributed as follows: And on Wednesday, the 1.2 hours of work was allocated as shown below. Looking at the first three days of Task 4, it’s now understandable why Project considers these small allocations to be full days. Remember, it’s the fact that each of the day’s time segments contain an allocation, regardless of how large or small. But how is Project calculating the last or partial days? Partial Day Allocations Partial day allocations occur on the first or final day of work allocation when the remaining work is less than the calculated maximum. Continuing our Task 4 example, the sample below shows how the remaining 0.13 hour (0.13 x 60 min = 8 minutes) of work is distributed across the final day. To understand how the final day duration of 0.33 is derived, we need to look at the day’s work distribution from a smaller timescale perspective. Here, I’ve changed the Options to show both Date/Time and the timescale data by hour, grouped into 20-minute segments in order to display how Project distributes the final day of work. If you look at the sample below, you’ll see that Project allocated about 1.2 minutes of work (0.02h x 60 minutes) in each 20-minute segment until all of the day’s total planned work was distributed. This starts at 8:00 a.m. and concludes after eight allocated segments at 10:40 a.m., which also happens to be the task’s Finish time. To arrive at the final day’s allocation of 0.33, divide the eight 20-minute segments containing planned work by the total number of 20-minute segments available in the full work day (3 per hr. x 8 hr. = 24) and you get 0.33 (8 / 24). In this case, the percentage of the full day is determined by the number of allocated segments compared to the total number of segments within the day. What to Remember about Task Duration To summarize, Project calculates task Duration in two ways: The Duration for Fixed Duration tasks is simply the fixed duration value, regardless of when planned work is or is not distributed within that duration. The Duration for Fixed Units or Fixed Work tasks requires a deeper understanding of the algorithms. Duration includes any business day with planned work. Business days with zero planned work are NOT included in Duration. However, to really understand what Project considers a full day of Duration and how it calculates partial days of Duration takes an understanding of how Project distributes planned work. Planned work is distributed using the following logic: Daily work allocation is calculated based on the Work, Assignment Units and Work Contour value. This determines the maximum hour allocation per day, the number of days across which work is allocated and the hour allocation for each day. For all days where the day’s work allocation matches the maximum work allocation per day, the day’s work allocation is simply spread equally across the total work segments within the day. For the first or last day’s allocations when the allocated work is less than the maximum allocation per day, Project spreads the day’s allocation across the work segments until all the day’s allocation is distributed. With that logic in mind, Project determines the Fixed Units or Fixed Work full/partial days based on these simple rules: If all work segments across the day contain work, regardless of how much or how little, it is considered a full day. If the last day’s work allocation doesn’t fill all work segments, it’s a partial day. The percentage of the full day is calculated based on how many of the work segments contain work compared to the total number of available work segments in the full day. Perhaps now you’ll better understand how eight hours of work can result in a one-day, three-day or five-day duration; and with partial durations, why three hours is considered a 0.75-day duration or how eight minutes can be seen as 0.33-day duration. Image Source