"Need by date" tasks

[Carlos G]

I have to set up some tasks on a "need by" basis. I have a
subcontract (SUB) that has a 52 week delivery schedule. I need the
delivery by the start of task ABC. To be safe, I want to give myself
a 4 week "buffer" which should be sufficient to cover the sub's
delays, based on prior experience.

I'm trying to figure out what the best way to set this up in Project
is.

I tried the standard "start as soon as possible". However, this moves
the tasks way too early, resulting in over a year of slack. Not at
all what I want - which makes sense, since I don't want to start as
soon as possible.

I then tried the "start as late as possible" constraint with a 30 day
lag to the successor task. This puts my task start where I want it.
However, it automatically tells me that I have 0 slack, and therefore
it is in the critical path. However, by design, I have built in 30
days reserve, so in reality I want to have Project show 30 day slack,
and remove it from the critical path.

What's the best way to setup this scenario?
Thanks!
Carlos

 

[DavidC]

Hi Carlos,

Set the start date for the project in the project information tab and in the
'Tools/ options/schedule' tab set the 'new tasks' to "start on project start
date" . Just make sure that you do not set the project start date too late
but leave yourself enough float. Remember the longer the project the more
things that can go wrong, and although you may have time to recover, overall
there may not be time left when problems happen. As a rule I will use three
to four weeks float minimum for a project looking out two to three years
hence, but driop this back to around one week when only months from
completion.

Set a milestone task for the end of the project.

Make the "need by" date the deadline for that task. Then link all your
tasks up as per normal using "As soon as possible" ending with the end of
project milstone and this will give you the float available.

Hope this helps

Regards

DavidC

 

[Carlos N]

Some clarification for what I'm trying to accomplish...

I have a "normal" schedule with lots off finish to start tasks that
start as soon as possible. I also have a handful of this "need by"
tasks that represent subcontracts. What I'm trying to do is have
Project tell me when I should let out the contracts.

I could let them all out on day 0 (as soon as possible) but then I would
have deliveries way before they are needed. That is because these task
don't really have predecessors (other than contract start). Instead all
they have are successors that determine when the deliveries need to occur.

In words the constrains I'm trying to achieve are:
- Start no earlier than contract start (obviously)
- Start as late as possible so that the tasks finishes with 30 day slack
before any successor tasks.

As I mentioned below using the "start as late as possible" with a lag
puts the tasks in the correct place. But it makes them into the
critical path, which is clearly not the case since the 30 day lag is
actually slack.

Carlos

 

[DavidC]

Hi,

First the way you have it scheduled will be critical, because what you are
essentially saying is that the last task can only start 30 days before the
end, hence it will have zero days float, because by the logic if you start
the task only 29 days before the end then you will not have enough time to
complete. Remember that project is 'dumb' and can only make the calculations
as you tell it by the way you sequence the tasks. Hence the reason I use a
deadline to show the end date, and then use a constraint "start no earlier
than" on the start date so that the last task finishes with some float that
allows for problems that will arise during the project. You then will not
see a critical path although there is always one by definition.

Another way to find the date to start is to identify how long you estimate
the project to take, then put in a milestone task called "start project no
later than" and have the end task as predecessor to this task with an SF-(the
duration of the project plus 30 days) and this will give you the latest date
to start the project and still finish with 30 days float.

Hope this helps

regards

davidC

 

[Carlos N]

I think I understand what you are saying. On more consideration I guess
my request can be worded as "can project treat lag as slack?"

CGN

 

[DavidC]

In essence, No.

When you put in a lag the logic is then saying that the task must start on
that date and hence the lag forms a part of the calculation to determine how
much float there is in the sequence of tasks. The best way is to use the lag
plus project duration to set a milestone task "must start" start date, then
use this date to manually set a constraint date on the first task as "start
no earlier than". You could if you are daring, use the "paste special/paste
link" to copy the start date from the milestone you have set above and paste
link it to the start date of the first task in the sequence. This will still
show float as the link between the end task and it's predecessor will be a
simple FS type connection.

Hope this helps

Regards

DavidC

 

[Steve House [MVP]]

That just it, a lag does NOT create slack. Lag times are always preserved.
If I have two tasks linked together with a 30 day lag in the link between
them, if the predecessor task gets delayed by 10 days, the 30 day lag will
be preserved and the successor task will also get pushed back by 10 days.
Since slack is defined as the amount of time a task could be delayed with
delaying a successor task (free slack) or the project completion (total
slack), your predecessor has zero free slack and if the successor is
critical then the predecessor is also critical.

You might want to rethink your scheduling strategy. The way you've
described it, where a task needs to be complete a certain time interval
before another task begins yet it's the latter task that controls the
former, you need some reliable clairvoiance to be able to know in advance
for certain just when that controlling task will begin and that's a talent
that's been in very short supply ever since Casandra got into so much
trouble. Just in time scheduling is very risky.

 

[Carlos N]

Steve and Trevor, thanks for your responses.

I understand your concerns and why MSP is not able to fit my needs.
After reading your post and those of others, I think the root cause of
my issue is that I'm using MSP (in this instance) ONLY for planning out
the project -- not for the actual execution.

You're absolutely right, that in general one does not want to have "just
in time" scheduling. In this case I need to figure out when to place
$40M worth of contracts, based on the need date (plus appropriate
margin, of course). Because of the large value of the contracts, and
the relatively late need date it does NOT make sense to treat these
tasks as tasks that can be done as soon as possible. It would result in
large amount of money being tied up in inventory that is not needed for
months. As you can see this is an example that "always good to do
everything as soon as it can be done" does not apply.

At the same time, because this is a planning tool (and not yet an
execution schedule), the need date may be changing based on changes to
other parts of the schedule. As such, I needed the start dates of these
tasks to change accordingly. I also know that because I'm giving myself
appropriate margin in when I'm placing these orders, they are not in the
critical path.

I've come up with a solution that fits my needs (even if kludgy). I've
created a custom field called "need date" that is computed as "[start] -
constant". I then do a special paste (link) of this field to the end
date of the "needed by" task, giving the "needed by" task a "finish no
earlier than" constrain.

This works exactly as I want it to, as now I'm told when the contract
must start. If the "needed by" date moves, the needed task moves with
it. If the length of the needed task increases, then the needed tasks's
start moves earlier. Furthermore MSP does not let the start of the
needed task move before its predecessors, and makes the needed task
critical path if it gets squeezed. I was concerned about a circular
reference in this scenario, but MSP seems to handle it.

I realize it is not the cleanest, but it seems to work. I also realize
that when we transition to an actual execution schedule, the contract
dates will probably be changed over to "start no earlier than" to remove
the funky linkages.

Carlos