none
As late as possible task behaviour when consolidating projects RRS feed

  • Question

  • Hi folks

    Encountered some unwanted behaviour with As Late As Possible (ALAP) constraints and consolidated project files.

    We have a bunch of projects using the same template. For the sake of example, assume the template is:

    1. Testing - 10d
    2. Write approval doc - 2d - ALAP - no prereqs
    3. Approval meeting - 1d - ASAP - FS1,FS2
    4. Deploy - 10d - ASAP - FS3

    This works when the project is used in isolation - 21d total duration, approval meeting follows directly on from Testing, and the "write approval document" happens on the last two days of testing.

    Problem

    For reporting, we temporarily consolidate all these projects as subprojects into a master (using VBA - there's about 75 of them as I type). Everything up to the ALAP task is fine. The ALAP task, however, will move to ALAP with respect to the last task of any of the projects. So everything after the ALAP task in almost all projects, shows later when viewed in the consolidated report than in the individual project plan.

    I've tried it linked and unlinked (in case that localised the critical path to the individual subproject - it doesn't). I can't think of any way around it at the moment, without going into every project and then the template to remove ALAP and rework the scheduling logic.

    Any suggestions gratefully appreciated!

    Thanks

    Rob

    Thursday, November 8, 2018 3:20 PM

Answers

  • Rob,

    This may be one of the very few circumstances where you'll want to check the box for  "Calculate multiple critical paths."  As long as the 75 subprojects are not otherwise linked, then checking the box will allow the sub-projects to be scheduled the same as they are when opened independently.

    Personally, I have found the ALAP constraint to be useful only when "reverse scheduling" from the Project Finish Date.  When used in forward-scheduled projects, it's essentially a zero-total-float constraint.  That's never something I want in a forward scheduled project. 

    Thursday, November 8, 2018 5:28 PM

All replies

  • Rob,

    What version of Project are you using? Is it fully updated?

    Either I don't quite understand what you are seeing or there is a definite difference in our versions. This is what I get when I create a dynamic master (i.e. linked) with your example file and another file with a later finish date.

    Am I missing something?

    John

    Thursday, November 8, 2018 4:44 PM
  • Rob,

    This may be one of the very few circumstances where you'll want to check the box for  "Calculate multiple critical paths."  As long as the 75 subprojects are not otherwise linked, then checking the box will allow the sub-projects to be scheduled the same as they are when opened independently.

    Personally, I have found the ALAP constraint to be useful only when "reverse scheduling" from the Project Finish Date.  When used in forward-scheduled projects, it's essentially a zero-total-float constraint.  That's never something I want in a forward scheduled project. 

    Thursday, November 8, 2018 5:28 PM
  • Tom,

    There must have been a change between Project 2010 and 2016 on this option. I emulated your scenario (except just the first two subprojects) and this is what it looks like with multiple critical paths unchecked.

    When I check the multiple critical paths option, it looks exactly the same.

    John

    Thursday, November 8, 2018 8:13 PM
  • John,

    I don't think there's been a significant change there.  I get exactly the same results in Project 2010 as I get in Project 2016.  I.e.

    When "Calculate multiple critical paths" is NOT Checked,then the Late Finish of each open-ended task is set equal to the Late Finish of the Master project.  The ALAP tasks then push themselves and their successors up against that Late Finish.

    When the box IS Checked, the Late Finish of each open-ended task is set equal to its own Early Finish, and that's as far as the ALAP can push.

    I have no clue why we are seeing different results.

    tom

      

    Thursday, November 8, 2018 10:40 PM
  • Tom,

    Wellllll, I think not. Here is my option setting.

    And here's my file showing the late finish of the master compared to the finish of the "open-ended" task. And yes, auto-calculate is "on".

    Obviously our setups for Project 2010 are different. I can send you my file (or vice versa).

    A conundrum for sure.

    John

    Friday, November 9, 2018 12:04 AM
  • Morning John, Tom

    Thanks for your efforts overnight (my time frame-of-reference!) - it's greatly appreciated. We're on Project Standard 2013, patched to 15.0.5075.1001 (which looks like the latest).

    Calculate multiple critical paths (CMCP for brevity) is indeed the magical fix for this problem (which is superb!), but only if I unlink all the projects after consolidation. If I don't unlink the projects, I only get the desired behaviour if I go into the subprojects individually and set them to CMCP first, and then consolidate. If I don't do that (so subprojects still linked to source, and CMCP only in the consolidated plan), I get all ALAP tasks moving to ALAP with respect to the longest critical path of any subproject.

    Unlinking is absolutely fine - the VBA was doing that already, I'd just commented it out to see if that improved matters. As such, I'll mark this as resolved, but I would still be really interested to understand what's going on with the different behaviour we're all seeing.

    Tom, in your top screenshot from your last project, if you subsequently open Project1 by itself, does task 3 Approval Meeting still start on the unwanted later date of 06 Dec? That's what I'm seeing, and nothing in the scheduling inspector explains why the task starts on that date. I can only "reset" the scheduling by deleting the predecessors and re-entering them.

    Friday, November 9, 2018 11:44 AM
  • John,

    I think Rob has zeroed in on the issue: namely MultipleCriticalPaths is a Project (not Application) property.  I've set my default to always leave the box un-checked and I'd bet your default is the opposite.  When answering Rob's question, I only modified the box for the master project, and you probably did the same.  The underlying subprojects in both our models kept their original settings (mine=False, yours=True).

    Observation:  Apparently a True on the Master can override a False on the Sub, but not the other way around.

    As Rob's follow-up has pointed out, this issue of ALAP constraints may not be so easily resolved.

    tom

    Friday, November 9, 2018 1:39 PM
  • Rob,

    Your description of MultipleCriticalPaths (MCP) in LINKED Master/Subprojects (in MSP2013) is the opposite of my own observations (in MSP2010 and MSP2016), which I've described in my earlier post to John.  That is, if a particular sub-project has MCP set to False, then I can override that setting with a True MCP on a master project, when the master project is open; you apparently cannot.  Curious.

    I'm glad an un-linked master does away with this discrepancy and otherwise works for you.

    To answer your question, I've re-built (for the third time) and saved all four projects, then closed MS Project.  (MCP=False for all four.)  If I then open only Project 1, the dates are exactly as shown (i.e. the unwanted dates), reflecting the status at last save.  Hitting F9 re-calculates the schedule and restores the correct dates.

    Good luck, tom 

    Friday, November 9, 2018 2:25 PM
  • Tom,

    Nope, not quite, but I did go to the Project registry looking for clues and that led me to the critical element. For reference I rarely work with critical paths so my default (Global) is "off" for calculating multiple critical paths. The difference I found is the option setting for "inserted projects are calculated like summary tasks". That option apparently "activates" the multiple critical path option. When I turn that option on, I get the same results as you and Rob.

    I agree, the use of constraints always seems to lead to strange/unexpected/undesired behavior so as a rule I don't use them. It's like trying to integrate manually scheduled tasks with auto-scheduled tasks. Bottom line, don't do it.

    Anyway, I'm glad Rob found resolution. This has been a interesting exercise, now if only I can remember what we found out should a similar question come up in the future :-)

    John

    Friday, November 9, 2018 3:39 PM
  • John,

    Ah ha!  Yep I think your answer - "inserted projects are calculated like summary tasks" is much more appropriate than MCP in the Master/Sub regime.

    Julie answered a similar question 8+ years ago, and her answer seems just as appropriate for Rob today. 

    tom

    Friday, November 9, 2018 6:33 PM