I have a summary task, and have the 'Leveling Can Split' option set to No. The four subtasks which are in sequence, also have LCS set to No. In the Leveling options I also have 'Leveling can create splits in remaining work' unchecked. The tasks are all Priority 500. I have had to insert a factory shutdown, and I have done this by creating a Priority 1000 task which uses the resources in each of the above tasks.

I believed the logic should be that the LCS set to No on the summary task would force all four tasks to run sequentially either before or after the shutdown. But the leveler, allows two tasks to be before the shutdown, and two after, with the delay being the span of the shutdown task.

Can anyone advise on whether I am doing this wrong, or if the summary task cannot be prevented from splitting in this manner? I am at a loss, the summary task has an input field to say the task cannot be split, but there it is split in the schedule. Any suggestions in how to keep these subtasks together?



1 Answer 1

  1. A "split" in MSP involves dividing a task into two or more "splitparts," whether manually or automatically.
  2. Summary tasks in MSP can't be split, whether by leveling or any other technique.
  3. Summary tasks in MSP can't be leveled (i.e. delayed by leveling), so the leveling options have no direct effect on them. Used as intended, summary tasks are primarily for reporting; they inherit their dates from the (leveled) subtasks, and their durations are back-calculated from the dates. [It is possible to drive subtask schedules by including specific logical constraints on the summary tasks, but this approach deviates from recommended practices and causes many problems. Not recommended. In any case, that doesn't use MSP's leveler.]
  4. Using the resource leveler to prioritize limited access is usually a good approach, allowing lower-priority tasks to be suspended or re-directed while the important ones take place. Still, there is no such thing as a "keep tasks together" constraint in MSP. Contrary to your belief/expectation, the behavior you describe in the second paragraph - i.e. two tasks before the shutdown and two after - is as designed.
  5. Given your demand to avoid interrupting the task string, the solution that springs to mind is to use conditional logic such as: If the last task in the group can be completed before the shutdown, then make the shutdown its logical successor. If not, then make the shutdown the logical predecessor of the first task in the group. Generally, you'll need to implement (and update) these decisions manually, though I imagine you could automate the process with a macro. Not optimal, but doable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.