Loading...
Quick Links

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

Share This Post
7 Comments
  1. Thank you for an excellent article. A very clear and thorough explanation with good use of screen images. It has explained some strange Microsoft scheduling behavior that has eluded me for some time. Thank you! One question still remains for me after testing this out. I have found that when a task is updated out-of-sequence the task splits. However further % complete updates to out-of-sequence tasks, shows progress after the resume date. The only way I’ve been able to change this behavior is to reduce the % complete to zero, remove the actual start date and update these fields with new values. The progress bar and split then displays correctly

    Reply
  2. Thank you for your series on Levelling Daryl. It’s been really interesting and useful. You’ve explained everything clearly and I’ve ended up clipping the whole series into my notebook for future reference.

    There is one gap in my knowledge now, that I think you may have touched on earlier on in the series but that I’d like to confirm what is the ‘best’ way to use the application or have your thoughts on it:

    I understand that when there are partial assignments tasks causing an over-allocated resource, a user can be frustrated because the levelling engine will not utilise seeming spare capacity, instead moving the entire levelled task. You explained that this is because the scheduling engine actually assigns partial allocations across the entire working day and the levelling engine cannot change resource assignment percentages, and thus the over-allocation cannot be addressed.

    Without manually adjusting the resource assignments or the planned work over-time on individual tasks, how can a user utilise the spare capacity to shorten the schedule duration and still resolve over-allocations? Is levelling the best way to go? For example if I have Task 1 and Task 2, both 5 day fixed duration tasks with ‘Tom’ assigned; 50% to Task 1, 60% to Task 2; how can I get the scheduling and levelling engines to utilise Tom fully?

    Hope that makes sense and I’ve not missed the simple answer? The answer may be that it has to be done manually. Any help or advice would be much appreciated.

    Reply
  3. Daryl Deffler

    Simon,
    The problem you’re running into is related to the resource’s Max Units and the individual task assignment unit totals. Assuming your resource has a Max Units of 100% and a calendar of 40 available working hours per week….
    On task 1, when you assign the resource at 50%, that means the resource will be scheduled 4 hours per day. When you assign Task 2 at 60%, that means the resource will be assigned 4.8 hours per day. HOWEVER….assuming Task 1 is scheduled first and takes 3 weeks to complete. When the scheduling engine tries to slot Task 2 in the timeline, it looks for availability of 4.8 hours per day. Since task 1 is taking up 4 hours per day, the scheduling engine doesn’t find the needed 4.8 hours per day until after Task 1 finishes. Thus Task 2 won’t schedule until after Task 1 is completed.
    And leveling won’t fix this because leveling only delays tasks or splits tasks. It won’t move them forward.
    There are two approaches to fix this.
    1) Reduce one or both task assignment units. For example, set both tasks to 50% or less. This will allow both tasks to run in parallel. Note, if there’s a project meeting type task where the resource is assigned 3% per week over the same time period, you need to take that into account as well. So maybe both tasks need to be assigned at 48% (to leave 3% for meetings).
    2) Set both tasks to full allocation (100%) and let them run back to back.

    Not knowing anything about the tasks and their need or desired need to run them parallel, I would first ask why they need to run parallel? Is there a valid reason or just a desire? I’m asking because this may be an unnecessary level of complexity you are building into the schedule for no real benefit. For example, if I have two tasks A and B that each take 40 hours, the total work for the resource doing both is 80 hours, or two weeks. So what’s the difference if the resource works on both in parallel or task A, then B. Both tasks will still be completed at the end of the two weeks. The only difference is that you’ve made you’re life as a PM more complicated by trying to force them to run parallel.

    Hope that helps

    Reply
  4. Daryl Deffler

    Bill,
    I don’t know that I have an immediate answer since my organization does all task updates via timesheets and doesn’t use % Complete.
    However, I can tell you that when the % Complete is updated, MS Project assumes that all additional work was completed exactly as the Work field (in task usage) had it planned. Meaning, if your task has 40 hours of Work scheduled M-F as 8 8 8 8 8, and you say the % complete is 50%, project will assign actual work as 8 8 4 and the remaining work should now look something like 8 8 4 with the 4 pushing out into the next day.
    The % complete will also allocate actual work into the future. If, using the prior example, the current date was only Monday, the actual work is still allocated as shown, even though the actual hours are being applied to future dates.

    I hope that helps to some degree

    Reply
  5. Thanks for your reply Daryl, that’s really helpful

    Reply
  6. Hello Daryl,

    In your answer to the comment of Simon Tidd, I miss an extra argument to use the second method (100% allocation, back to back running of task 1 & 2). Running both tasks parallel is often causing the work to take more time, because switching from task to task takes extra time, also known as the effect of “bad multitasking”.

    Hope this creates awareness

    Reply
  7. Daryl Deffler

    Freek
    Yes, I’m aware of the multi-tasking penalties and wasted time constantly switching back and forth between tasks. In my answer, I was primarily focused on the schedule mechanics.
    But you bring up a good point that I agree with and another reason NOT have multiple tasks in parallel if you don’t have to.

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please complete this equation so we know you’re not a robot. *

Thanks for submitting your comment!
You must be logged in to comment.