Bug Found When As-Late-As-Possible Constraints are Used in the Same Chain as a Manual Task RRS feed

  • General discussion

  • Occasionally we will use As-Late-As-Possible constraints. They are especially handy for determining margin breakpoints in chains leading up to a major review or delivery. For example, we would set the major review, like a PDR, with a Must-Start (or Must-Finish) constraint and then upstream set the kick-off milestone for the chain with an As-Late-As-Possible constraint.  I personally like to then add a Finish-to-Start link directly from the Kick-off milestone to the review with a lag equal to the nominal period leading to the review.  For example, the kickoff to the PDR might need to occur at T-minus 10 weeks.  If we set a FS link from the kickoff to the PDR with a lag of 10w we can then see the margin leading into the PDR and then insert discrete margin tasks to consume the slack.

    One of the things we have discovered is a task with manual mode is not treated entirely as a constrained task when in a chain with a ALAP constraint.  It is treated as a constrained task from the standpoint of it not moving.  However, the ALAP constraint will push the other tasks in the chain past the manual task.  The amount the tasks are pushed is equal to the amount of total slack downstream from the manual task.

    Consider the following example:

    In the above example we are driving the Pre-PDR tasks (which we have consolidated into a single task for illustration purposes) into the PDR event via an ALAP constraint.  The PDR is auto-scheduled and has a Must-Finish constraint.  Now lets change the PDR from having a constraint to being manually scheduled...

    Notice how the Pre-PDR tasks now have partially slipped past the PDR!  The end date had me confused until we started evaluating it against the total slack.  As shown, the chain doesn't make sense.  We have thus concluded the manual task is a pseudo-constraint and allows a partial slippage of the tasks upstream of the manual task, but only an amount equal to the total slack.  This bug has been confirmed on two separate instances of Project v2013.  We have yet to confirm it with our v2010 or v2016 users.

    We have advised our people the following:

    (1) If you must use an ALAP constraint, avoid down-stream manual tasks

    (2) If you must use a down-stream manual task, replace the ALAP constraint with a Start-No-Earlier-Than constraint placed on the date already validated as the "just in time" start point of the chain.



    Monday, July 17, 2017 12:32 PM

All replies

  • Chris, there is no bug here, just MSP working as designed. In the first case there is a mixture of ALAP, MFO and ASAP constraints. There is also the 10 weeks of lag. The combination of the MFO constraint on task 3 and the lag on the predecessor are preventing 1 and 2 from being scheduled any later than they are. If the MFO date constraint on task 3 was removed, the ALAP constraint on task 1 would push all of the successors to the limit of their float, because this is just how the very strong ALAP constraint works.


    • stick to critical path method, which means schedule forwards from the start date
    • avoid date constraints, especially ALAP
    • avoid long duration tasks, break them up into a finer, more controllable, level of detail.
    • do not use manually scheduled tasks.

    Any help?

    Tuesday, July 18, 2017 12:54 AM
  • Hi Trevor!

    The use of long tasks was for illustrative purposes only.

    Microsoft introduced manually scheduled tasks and we have always viewed them as pseudo-constrained tasks.  I contend there is a bug.  In the second screen shot provided the ALAP constraint at the start of the chain pushes the chain through the manually scheduled task; this should not be happening for the same reason tasks downstream from a manually scheduled task don't push left through a manually scheduled task.

    Manual tasks are a big deal for us and we are grateful to Microsoft for their introduction.  We use the Deliverable/Dependency capability extensively in Project Server and it was difficult getting a receiving task to have a date match identically to the giving task.  If the giver file wanted to have the task start on a Saturday then the receiving file needed it to start on a Saturday and prior to v2010 we would need to use a combination of MSO constraints and a 7-day week calendars at a task level to force the situation.  Manual task mode eliminates the need to use a 7-day week calendar and we can force the receiving file to have exactly the same dates as the giver file fairly easy via macros.

    We occasionally use ALAP to perform a limited backward pass in the network where we know a chain of activities will come to a stop --- this alleviates the need to do a backward pass on the whole network.

    Yes, we use critical path methodologies.



    Wednesday, July 19, 2017 2:53 PM