Quick Links

Task Splits in the Future – A Scheduling Mystery

Some time ago, one of our clients experienced an unusual situation with an enterprise project in Project Online. The client is using the Timesheet feature in Project Online to capture task progress entered on a daily basis by team members. The project contained task splits in the future, and the client could not determine why.

After studying the project in depth, I was able to determine the source of the task splits in the future. Allow me to share the results of my research with you.

Figure 1 shows a sample project that I set up to mimic the behavior the client was seeing. This figure shows the project after one week of updates were applied by the project manager. Notice the following about this project:

  • The project contains two tasks with a Duration of 20 days each. (The client was using task Durations that were much longer than 20 days).
  • These two tasks are linked with a Finish-to-Start dependency.
  • The Build task is scheduled to start on Monday, August 7.
  • The Design task has progress applied for the week of July 9. The progress was submitted by Mickey Cobb on her Timesheet in Project Web App, and this update was approved by her project manager.
  • The red dashed line is the Status date for the project, which is set to Friday of the week of July 9.
  • The green line is the Current date for the project, which is today.
  • Everything to the right of the Current date line is in the future.
  • There is nothing unusual about this project…yet.

Figure 1: Gantt Chart view before updates

Figure 2 shows the project after the project manager approved task updates from the team members for the week of July 16. Notice the following about this project:

  • The Design task has progress applied for the week of July 16. The progress was submitted by Mickey Cobb on her Timesheet in Project Web App, and this update was approved by her project manager.
  • The Build task has early progress applied to the task on Friday of the week of July 16. The team member assigned to this task reported 1 hour of Actual Work on Friday of that week. The team member submitted this progress on his Timesheet in Project Web App, and this update was approved by his project manager.
  • The early progress on the Build task created a task split that spans from last week (to the left of the Current date line) to two weeks into the future (to the right of the Current date line).
  • Microsoft Project created the task split to honor the Finish-to-Start dependency between the Design and Build tasks. Because of this, the Actual Work on the Build task is shown on Friday of the week of July 16, but the Remaining Work on this task is still scheduled to start on Monday, August 7.
  • The Duration of the Build task is now 20.88 days. This change in Duration is caused by the task split.
  • The task split in the future is normal and not a bug. Microsoft Project is working as designed.

Figure 2: Task split in the future on the Build task

If your organization uses the Timesheet feature in either Project Online or Project Server, you should be aware of the behavior documented in this blog post. There is a good possibility that you will see task splits in the future whenever you use tasks with long Durations and team members enter early progress on a task using the Timesheet in Project Web App.

Related Content

Webinars (watch for free now!):
Task Planning using Microsoft Project
What’s the value of Schedule Risk Analysis?

Levels of Project Scheduling Proficiency
Are You Using the Team Planner View Feature in Microsoft Project?
Resource Leveling: Scheduling vs. Leveling

Written by Dale Howard

Dale Howard is the Director of Education for Sensei Project Solutions.  He is in his 15th year of serving as a Microsoft Project MVP (Most Valuable Professional) and is currently one of only 39 Microsoft Project MVPs in the entire world. Dale is the co-author of 21 books on Microsoft Project, Project Server, and Project Online. He works out of his home in Ellisville, Missouri (a west suburb of St. Louis).

Share This Post
  1. Good morning Dale. This is a good article illustrating how Project will react based on one potential setting combination of the Scheduling option “Split in progress tasks” and the Leveling option “Leveling can create splits in remaining work”. As a Project Server 2013 user, I see the same outcomes.
    Might I suggest that if you’re readers are not seeing these same results, more information on how these two options interact can be found in an MPUG article I wrote earlier this summer; Resource Leveling: Understanding Split Task Options which can be found here.

  2. As a rule, I avoid split tasks for several reasons, this being a good example of one of them. While MSP has the functionality to model many process scenarios I find it impractical to actually manage the scenario. I certainly would never plan a project with split work as that is not how people normally operate in the real world. If you see this it is likely because of multitasking which is bad behavior. Also, the definition of what is work needs to be clear. Thinking about a deliverable is not working on the deliverable for purposes of time reporting.

    If the need arises to stop work on a deliverable then simply end date the task and create a new task, assign the remaining work/duration, with a FS+x relationship to represent the lag.

  3. A better solution would be to break the task Build (and Design) into subtasks. The problem with tracking 20d tasks is that they are too “big” to be tracked reliably. By breaking them into subtasks with FS dependencies, you can both avoid this split problem and you get a better prediction of the finish dates (invariably breaking down long duration tasks into subtasks causes the duration to increase because people usually underestimate how long something will take).

  4. This is known as out-of-sequence updating. Normally the build task could only start after the design task is completed due to the (FS).
    But actuals will override the dependency logic, even date constraints. So the actual start date, and actual duration reported reflects what happened on the build task.
    The reason for the split is because the remaining duration is still controlled by the initial (FS). This is known as “Retained Logic”


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>

− 1 = 5

Thanks for submitting your comment!