none
Split Task Detection RRS feed

  • Question

  • Is there any way in VBA (other than SplitParts.Count > 1) to detect a split task?

    Background: Some of my PMs portray Down Time with a stand-alone split task. They set Work to 0 for all periods in the split task. It shows on a Gantt as split, but the count = 1 because there appears to be no split in the values. So, I'm having trouble detecting the DT. As a kludge, I've asked them to put a dummy value such as .01 in the first and last period of the split task. That forces the Count to be greater than 1. But, I'm wondering if there's another way to pick up the split, e.g., a Split Indicator property?


    RobVV

    Saturday, April 2, 2016 10:08 PM

Answers

  • Thanks, everyone, for your help.  It appears that the only way to detect a split task is with SplitParts.Count > 1. So, the best solution for my program blends ideas from each of you. For Down Time tasks, we will instruct the PMs to do the following:

    1. Use Auto Scheduled Tasks. 
    2. Avoid Auto Resource Leveling, especially on a whole project. If Resource Leveling is used, recognize the impact of automatically generated splits—they’ll be treated as DT.
    3. Set up the DT task as follows:
      1. Create Down Time task (Auto Scheduled)
      2. Assign resource associated with the Down Time
      3. Set Start Date to start of DT
      4. Set Duration to 2d
      5. Split the task so that part 1 is the DT start and part 2 is DT finish

    The approach is clear, simple, and requires minimal PM effort.  It uses standard MSP functionality, and so, it is available to all the PMs. External explanations of split tasks and their use for DT are available. The DT is readily visible to PMs and PMOs.  Finally, the PMO has ways to monitor compliance. 


    RobVV

    • Marked as answer by RobVV Thursday, April 7, 2016 1:56 PM
    Thursday, April 7, 2016 1:56 PM

All replies

  • RobVV,

    Can you elaborate a bit on exactly how your PMs set up the splits. I just tried a sample of what I understood you to mean and in my simple example, the split count is 3 as would be expected (see screenshot). Am I missing something?

    John

    Sunday, April 3, 2016 2:18 AM
  • Thanks, John. Here is the process that yields a split count of 1:

    1. Create Down Time task (Manually Scheduled)
    2. Assign dummy resource
    3. Set Start Date
    4. Set Finish Date = Start Date + 1d
    5. Split the task so that part 1 is the DT start and part 2 is DT finish
    6. Go to Resource View
    7. Override the first part's Work with 0 and same for second part
    8. In the Gantt, the task appears to be split, but SplitParts.Count = 1

    I don't know how to add screen shots here. So, I've posted the Resource View & Gantt on my website: http://www.projectflightdeck.com/SplitParts.php?nosessionkill=1


    RobVV

    Sunday, April 3, 2016 2:15 PM
  • Rob,

    First of all, I avoid manually scheduled tasks completely. In my opinion they are useful only for very preliminary plans that are still in development. Once a plan coalesces, all tasks should be auto-scheduled to let Project do what it is designed for - calculating a schedule based on planning requirements.

    Second, with the process you describe, if indeed the intention is a task with a break in the middle, then why is work zero for both parts?

    Third, given that the work is zero for the whole "task", it isn't really a split task at all, it is simply a delayed task. That's why the split count is 1.

    If the intent is to introduce a delay or down time, if you will, into a task, either set up a task calendar or resource calendar to show an exception for the days "off". Doing it the way you describe is not the way to do it. Sounds like some re-training is due for your PMs.

    John

    Sunday, April 3, 2016 3:19 PM
  • As John said, don't user manually scheduled tasks. At all.

    Once your task is auto scheduled, setting actual work to zero for a time period in the usage view will split the task and increase the count, so let your PMs continue doing that. No need to use your .01 work around once you let Project do its work rather than turn Project off by using manual tasks.


    Rod Gill
    Author of the one and only Project VBA Book
    www.project-systems.co.nz

    Monday, April 4, 2016 2:40 AM
    Moderator
  • Thanks, guys. We're close to a solution. Rod, the following steps still don't produce a count > 1. Please tell me where they go wrong.

    1. Create Down Time task (Auto Scheduled)
    2. Assign dummy resource
    3. Set Start Date
    4. Set Duration to 2d (this exposes enough of the task to split)
    5. Split the task so that part 1 is DT start and part 2 is DT finish
    6. Go to Resource Usage view
    7. Set Actual Work to 0 for part 1 and same for part 2

    RobVV

    Monday, April 4, 2016 3:24 PM
  • Rob,

    Rod is probably counting zz's right now but the answer to your question is this. If you follow the steps you outline you should see that once the actual work portion of the start is set to zero, all the remaining work is shifted to the finish part. If you then set that to zero, the remaining work will keep extending the task indefinitely, moving day by day. But the bottom line is that there is only one part to the task and hence the split count is 1.

    Had you entered zero for each part in step 7 using the Work field instead of the Actual Work field, you would see that the task turns into a milestone. Again, not a split task so the count is 1.

    What's the problem with using a best practice method of setting up down time with calendar exceptions? Trying to fit the square peg into the round hole is just not going to get it done.

    John

    Monday, April 4, 2016 5:36 PM
  • Thanks, John. I forgot that Rod lived "down under". You've described exactly the behavior I observed, except that in one case, I did get the multiple split Rod suggested. I haven't been able to reproduce it, however. So, I thought that I had messed up the steps but that he knows how to do it. We'll have to wait until the sun hits NZ to find out what he was thinking!

    As for calendars: that is an alternative we tried, but we found it wasn't feasible on the program. There were two problems with it: first, we have 20+ PMs with large schedules and multiple, diverse Down Times. The number of calendars exceeded the capacity of the PMO to manage. Having the PMs manage them led to the second problem. Few of the PMs were familiar with managing calendars. All were familiar with managing tasks, and many understood splits. The training you suggested would have been a good approach, but few of the PMs were in-house. Vendor training was not part of program costs. So, we went with the split task approach.


    RobVV

    Monday, April 4, 2016 6:26 PM
  • Rob,

    Yes, I was a bit puzzled by Rod's response also, so I'm anxious to hear the details of his approach.

    As far as your PMs are concerned, it sounds like there are too many "fingers in the pie" and a single individual (you?) is needed to pull everything together. Nothing worse than a whole lot of users with limited knowledge of the application all trying to run with the ball.

    However, aside from what trick Rod may have up his sleeve, let me offer a simple alternative that is easy to implement. For any task that needs down time, instead of trying to implement it with splits, why not break the single task into two or more pieces. The down time can be a link with a lag between each of the task pieces. Easy to understand and easy to manage.

    Just a thought.

    John

    Monday, April 4, 2016 6:56 PM
  • Hi Rob (and John),

    Pending Rod's return I'll venture a contribution.

    As I understand, your 20+ PMs indicate non-working time in their schedules by over-writing the scheduled work with 0 values in one of the usage views.  You want to detect these non-working periods in the schedules you review.

    1. Where "downtime" is entered in the middle of the task (i.e. with positive work before and after), you can find the entries by looking for task.SplitParts >1.  This is your root case that seems to work for you.
    2. Where "downtime" is entered at the beginning of the task (i.e. your linked example), task.SplitParts =1.  As John has pointed out, this is in fact not a split but an assignment delay.  You can identify this case by looking for task.assignments(i).Delay >0.  (i=1 for only one resource assignment, but in general you need to loop through all the task's assignments.)
    3. Where "downtime" is entered at the end of the task (and the task is fixed-duration or manually scheduled), I haven't found an obvious approach other than the general solution below.
    4. As a general solution, I would loop through the time scaled work data for each assignment (from task.start to task.finish) looking for unexpected null values.  (Assuming you don't want to capture normal weekends and holidays that are included in the project default calendar, then you'll need to include code to ignore these entries.)  Rod's book has a good section on time scaled data analysis, and you can now link to it on MSDN.  It's easier than it looks.

    There are a million reasons why I wouldn't choose to use this methodology in the industries where I work, and John has named the most important ones; nevertheless I guess it works for you.  I'll note that these manually-entered splits representing resource unavailability (i.e. downtime) are essentially indistinguishable from other splits that the program legitimately imposes through logic-driven or resource-leveled scheduling, and Project may over-write them.  I would expect your methodology to remain stable only as long as these powerful scheduling techniques (i.e. Project's reason for being) are avoided. 

    Good luck, tom

    Tuesday, April 5, 2016 1:57 PM
  • Ok, I'm awake now even though some people might dispute that.

    Re-reading your question, I see 2 scenarios, one where the site is stood down for various reasons and secondly where work stops on a task because something else more urgent diverts the resource away from the task.

    For reason 1 I would first update progress accurately then add a milestone called Site resumes work and link it to all incomplete tasks. With the milestone date set to resume date, all remaining tasks automatically split. Add task notes as appropriate to explain what happened.

    2 - If a task starts late simply set the actual start date. For days where nothing happens on a task set the actual work for the day to zero which will split the task.

    I wouldn't have dummy tasks with dummy resources. Keep the schedule realistic.


    Rod Gill
    Author of the one and only Project VBA Book
    www.project-systems.co.nz

    Tuesday, April 5, 2016 11:38 PM
    Moderator
  • Thanks, everyone, for your help.  It appears that the only way to detect a split task is with SplitParts.Count > 1. So, the best solution for my program blends ideas from each of you. For Down Time tasks, we will instruct the PMs to do the following:

    1. Use Auto Scheduled Tasks. 
    2. Avoid Auto Resource Leveling, especially on a whole project. If Resource Leveling is used, recognize the impact of automatically generated splits—they’ll be treated as DT.
    3. Set up the DT task as follows:
      1. Create Down Time task (Auto Scheduled)
      2. Assign resource associated with the Down Time
      3. Set Start Date to start of DT
      4. Set Duration to 2d
      5. Split the task so that part 1 is the DT start and part 2 is DT finish

    The approach is clear, simple, and requires minimal PM effort.  It uses standard MSP functionality, and so, it is available to all the PMs. External explanations of split tasks and their use for DT are available. The DT is readily visible to PMs and PMOs.  Finally, the PMO has ways to monitor compliance. 


    RobVV

    • Marked as answer by RobVV Thursday, April 7, 2016 1:56 PM
    Thursday, April 7, 2016 1:56 PM
  • Rob,

    You're welcome and thanks for the feedback.

    John

    Thursday, April 7, 2016 3:06 PM