Variable duration tasks RRS feed

  • Question

  • I have a schedule with a lot of testing tasks in it.  In between these tasks are periods of down time on the test stand.  I want to know if there is a way to create or link these down time tasks so that they will shorten in duration if I increase the duration of the predecessor.  I don't want the second test to slip unless all the down time has been used up.

    Test 1    10 days

    down time     5 days

    Test 2     20 days

    I would like to be able to increase duration on Test 1 without slipping Test 2 until the "down time" task is at 0 duration.  I know you can manually decrement days on the "down time" task, but I don't want to do that.


    Wednesday, October 29, 2014 6:25 PM

All replies

  • Hi,

    You could remove the down time task and set a contraint "Finish No Earlier Than" on the finish date of test 2.

    Doing this, if test 1 duration increases, test 2 will not move until the 5 days buffer has been consummed.

    Hope this helps,

    Guillaume Rouyre, MBA, MVP, P-Seller |

    Wednesday, October 29, 2014 6:33 PM
  • I would take a slightly different approach.  Set a Start No Earlier than constraint on Test2, omitting the down time task.  You can still link Test1 and Test2, but Test2 start will be delayed by the 5 days.  You may also want to put a deadline on Test1 to alert you if you are sliding past the 15 days (10 days plus 5 down time).

    Wednesday, October 29, 2014 8:14 PM
  • Thank you Julie for bringing your experience here! Your suggestion is definitely the good one!

    Hope this helps,

    Guillaume Rouyre, MBA, MVP, P-Seller |

    Wednesday, October 29, 2014 10:34 PM
  • I would take a slightly different approach. I would try to avoid the use of date constraints entirely, since I think that they are bound to cause other problems (in particular, obscuring the critical path) even if they might seem to be a solution to this one. I am not sure what happens during the "downtime" but suppose nothing happens except that duration passes (actual duration accumulates and remaining duration diminishes). By the way, I think this is better than using FS with lag.

    Assuming that once it is started Test 1 is in progress every day, so not interrupted, there two ways that Test 1 can slip. It actually starts later than scheduled and/or it takes longer, or has, by the time it is finished, more actual duration, than was scheduled. Either way, at some point during Test 1 it becomes apparent that the finish date is going to be later than scheduled. Suppose it starts as scheduled but then when you get to day 6 (the status date) you realise that is going to be an 11 day task. When you update the progress with the actual start date and the actual duration of 6 days (mark on track will do it), MSP calculates 4 days remaining. You would increment the remaining duration to 5 days. You don't want Test 2 to slip, so you shave 1 day off the downtime, which is your buffer. You might look at the progress of Test 1 each day after day 6 (move the status date) and might add one day to the remaining duration each day. Test 2 won't get re-scheduled until Test 1 turns into a 15 day task and the downtime is zero. I know you say that you don't want to decrement the downtime, but I don't know why not. The necessity for each decrement of downtime follows from the necessity to increment Test 1.

    Anyway, if you retain the FS predecessor link from Test 1 to Test 2 (if it is true that Test 2 cannot start until after the finish of Test 1), and impose a SNET date constraint on Test 2, the downtime is really just there to measure the duration between the finish of Test 1 and the start of Test 2. So don't link downtime to either of the other two and make it a hammock task.

    Thursday, October 30, 2014 1:25 AM