What, exactly, in MS Project terms, is a split?
From a practical perspective, it’s when the work on a task has one or more breaks in the middle.
From a technical perspective, a potentially problematic split h happens when there is already some amount of actual progress reported on the task and the remaining work gets rescheduled. How can you tell if your task is split? If there are date values in the Stop/Resume fields for the task that don’t make seem to sense, then you probably have a split happening. There are scenarios where you won’t have dates there but the task will still have the same behavior, I’ll explain that below.
Splits can happen on purpose or by accident, and while it can be a handy tool if you set out to make it happen, it can be a *nasty* problem if it happens inadvertently. We’re mostly going to focus on the accidental version here, but I will quickly outline the intentional methods first.
Intentional Split Causes:
The first and most obvious way is by using the “Split” button in the ribbon on a task that has already started. If the task has not started, the work is split, but there are no Stop/Start dates until progress is reported.
Move Task Forward: (move incomplete parts to status date)
When you use this function on a task that has already started, it creates a split.
If there’s a calendar Exception smack dab in the middle of a task while a resource is supposed to be working on it, it will (rightfully) create a split.
Oh Split! Unintended Causes:
Progress has been reported on the task and then:
Lag is added
A Predecessor that dictates a later start is added
An existing predecessor moves out
Assignment Delay is added (this doesn’t create Start/Stop dates, but it doesn’t need progress on it to move the work out) (I don’t have strong feelings about this at all…)
Contouring 0’s into the middle of a task. This is ok. You can do this.
But why is it bad!?
A lot of this resolves around Duration. (Yeah, I’m still mad at you, Project!) Duration shows the actual days that a task gets worked on, so the split throws that number off a whole lot. It’s just confusing.
Another problem with this is resource loading. You can contour over the split (thankfully) but it’s messy and ugly and instead, I suggest to just not set yourself up for these scenarios. You get these fields of 0’s in the middle of your loading and they will push out if you up the duration or lower the unit percentage.
This is the least of my concerns, but it also makes the Gantt chart UGLY:
Most importantly though, if you’re not looking at a usage view and your schedule has a ton of splits in them, it can be really frustrating to try to pull in your dates or even to just understand the critical path.
Because really, why would you:
Add LAG when a task already started?
Change the predecessor when a task is already started? (maybe the work was started but something else came up that had to be done before the work could finish? This might be ok, but don’t do it by accident, mmm’kay?)
Start a task when the predecessor isn’t complete?
Add assignment delay when an assignment is started? (when there’s more than one resource this would be understandable, I suppose)
So, how do we FIX them?
Provided they are not wanted (nobody asked you here, SPLIT!) then you’ll want to determine the cause and just work backwards. If it’s a bad predecessor, remove it. If it’s dumb lag, remove it. The most important thing is to make sure that the schedule makes sense and is doing its job of telling you what’s happening when and helping you keep track of your nifty projects.
Ok, so are we starting to understand Splits a bit? I’m not a fan, they make me so mad I could split!