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