negative lead time

[Michael Gwin]

Heres my scenario:

I have 2 tasks: Migrate SQL database and Communicate SQL Migration.
Id like to put the task for communicating this migration to happen 10
working days prior to the migration.

I want the date for communicating the migration to move if the migration
date changes.

I basically want to type 2-10d in the successor field of the communication
task but Project wont let me. the communication is not a required task but I
want to see this in a list so my PM knows by which dates he needs to send out
the communication. since the plan is still being built, the actual migration
date may change (a few times) and I dont want to go check the communication
task to move it up to 10 days prior....

Any thoughts?

 

[JulieS]

Hi Michael,

Assuming the Migrate task is task ID 2 and Communicate is task ID 3.
In the predecessor field for ID 3, enter 2FS-10d to set a ten-day lead
on the finish-to-start relationship.

I hope this helps. Let us know how you get along.

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional information
about Microsoft Project

 

[Michael Gwin]

Ha. that worked. Thanks. I didnt have the FS in it and it barked at me.
Thanks for the quick reply!

 

[Jim Aksel]

although I understand exactly what you intend to do, I need to ask you a
question.... just exactly how are you going to know that 10 days after you
announce the migration that it WILL occurr? If you follow the logic
presented, all I have to do is announce the occurence of the migration and it
is GUARANTEED to happen 10 days later as there is no other logic driving it.
That said, that means all I have to do is "declare so shall it be...." and it
happens. No chance.

I recommend that you find some other milestone to tie this to. Think about
it, there has to be some test plan or result, something. Normally, there is
some type of Start to Start logic that can be employed.

Remember, using negative lag implies you can predict the future with
certainty.

Here is an alternative. Let's use drying concrete for an example. The
"rules" state that concrete is completely cured 28 days after pour. OK, so
that means 21 days after pour I can announce: "The floor will be ready to
walk on in 7days". We are tempted to use the "Ready for Walking Annoucement"
milestone as "Concrete Dry FS-7ed". However what we really have that we
can objectively measured is "Concrete Poured FS + 21ed" as a predecessor to
the announcement.

Only under the rarest of circumstances should we be using negative lag. At
least that's my two cents worth. Prepare for the wrath of my peers who will
villify me for not allowing the future to be predicted.
--
If this post was helpful, please consider rating it.

Jim

Check out my new blog for more information:
http://www.msprojectblog.com

 

[DavidC]

Jim,

For what it is worth I agree in principle with your comments. The main time
I see value in negative lag is to define a deadline for a submission where
that needs to be made a period of time before an activity commences. The
negative lag allows a deadline to be identified and this is then dynamic as
the activity start chnages with progress.

There are other examples of negative lag being valid but I believe they are
the exception and not the rule.


Regards

DavidC

 

[Jim Aksel]

Yes, we routinely have to notify customers 10 business days prior to a
meeting by sending them an agenda. Again, we use a deadline and not negative
lag.

Leads me to another point... it would be nice to have a more flexible
constraint date and deadline date system in Project. All I can do now is
place a deadline as a real date. What I'd like to be able to do is establish
a deadline as "30edays prior to the start of Task 19" For now, we do it with
a calculated date field and then hand jam the deadline date.
--
If this post was helpful, please consider rating it.

Jim

Check out my new blog for more information:
http://www.msprojectblog.com

 

[JulieS]

You're welcome Michael. Glad to have helped and thanks for the
feedback.

Julie

 

[DavidC]

What I do is to create the deadline date by using the negative lag, then use
that date as a link date to the deadline for the last activity in the
sequence. In my situation I have dates for lodging notifications 10 days
before commenceing a construction activity, however the start of that
activity is not fixed and could start earlier or later than planned. Hence
if progress shows that the start will now be earlier, then the deadline date
will automatically shift to an earlier date and then provide me with a new
set of critical time frames. The other side of that is the activity slipps
and we have longer before we need to notify. Some of the activities I have
can vary up to 15 to 20 days if things do go horribly wrong.

As usual I think it comes down to using the tools to suit the circumstance
but needs to still retain the basic tenet of scheduling.

Regards

DavidC

 

[salgud]

although I understand exactly what you intend to do, I need to ask you a
question.... just exactly how are you going to know that 10 days after you
announce the migration that it WILL occurr? If you follow the logic
presented, all I have to do is announce the occurence of the migration and it
is GUARANTEED to happen 10 days later as there is no other logic driving it.
That said, that means all I have to do is "declare so shall it be...." and it
happens. No chance.

I recommend that you find some other milestone to tie this to. Think about
it, there has to be some test plan or result, something. Normally, there is
some type of Start to Start logic that can be employed.

Remember, using negative lag implies you can predict the future with
certainty.

Here is an alternative. Let's use drying concrete for an example. The
"rules" state that concrete is completely cured 28 days after pour. OK, so
that means 21 days after pour I can announce: "The floor will be ready to
walk on in 7days". We are tempted to use the "Ready for Walking Annoucement"
milestone as "Concrete Dry FS-7ed". However what we really have that we
can objectively measured is "Concrete Poured FS + 21ed" as a predecessor to
the announcement.

Only under the rarest of circumstances should we be using negative lag. At
least that's my two cents worth. Prepare for the wrath of my peers who will
villify me for not allowing the future to be predicted.

Wrathful peer here! I guess we have to give up scheduling. How would any of
us "know" that a task will take 5 days, or 2 days, or 3 weeks? You're
saying we can't estimate because we can't know with certainty. You're
right, we know nothing of the future with certainty. What we do is hope we
know, pretend we know. Whatever you want to call it. How is estimating that
a certain event can start so many days before another one we've estimated
to complete at a certain time different than the original estimate of a
time to complete? Let's face it, a schedule of future events is all made
up. I think I'm going to continue to do so, since I know of no other way of
scheduling. When you come up with a better way, I'll be all ears!

 

[Steve House]

Wrathful peer here! I guess we have to give up scheduling. How would any
of
us "know" that a task will take 5 days, or 2 days, or 3 weeks? You're
saying we can't estimate because we can't know with certainty. You're
right, we know nothing of the future with certainty. What we do is hope we
know, pretend we know. Whatever you want to call it. How is estimating
that
a certain event can start so many days before another one we've estimated
to complete at a certain time different than the original estimate of a
time to complete? Let's face it, a schedule of future events is all made
up. I think I'm going to continue to do so, since I know of no other way
of
scheduling. When you come up with a better way, I'll be all ears!

If I can interpret Jim, a milestone announcing "Floor Ready For Walking In 7
Days" as a FS+21d successor to "Pouring Complete" is a valid approach to
estimating. But setting it up as a SS-7d (or SF-7d) successor to "Walk On
Floor" implies you can know the date that someone will actually walk on the
floor with absolute certainty. You might WANT someone to walk on the floor
on Day 28 but that doesn't mean someone WILL walk on the floor on Day 28.
The first method says someone CAN walk on the floor on Day 28 but doesn't
attempt to predict with certainty that the event will actually take place.

IMHO, schedules are not determined, they are urking within the process and
the social environment of the firm, waiting to be discovered. Managers want
to take charge and make things happen - that's why they've chosen to become
managers. But it's a pipe-dream, an illusion. The greatest myth of
management is that it's actually possible to control the future. All we can
actually do is understand the system so we can set up conditions where there
is a higher probabilty of a desired outcome. But nothing is ever certain
until it becomes history.

 

[Dave]

If I can interpret Jim, a milestone announcing "Floor Ready For Walking In 7
Days" as a FS+21d successor to "Pouring Complete" is a valid approach to
estimating. But setting it up as a SS-7d (or SF-7d) successor to "Walk On
Floor" implies you can know the date that someone will actually walk on the
floor with absolute certainty. You might WANT someone to walk on the floor
on Day 28 but that doesn't mean someone WILL walk on the floor on Day 28.
The first method says someone CAN walk on the floor on Day 28 but doesn't
attempt to predict with certainty that the event will actually take place.

I don't see anymore certainty in SS-7d than in FS+21. Both are estimates,
and entirely uncertain just as any other estimate of future events. And in
reality, they are not both the same if the duration of the concrete drying,
which we don't know with a certainty, changes. What if it takes the
concrete 30 days to cure? And how would we know? This is all semantics, and
to me, a waste of time when I'm trying to schedule a real project.

Anyone who looks at a projected schedule such as these, and declares that
something WILL HAPPEN based on it, is a fool, regardless of what kinds of
links are used.

IMHO, schedules are not determined, they are urking within the process and
the social environment of the firm, waiting to be discovered.

So we're all little Leonardos carving out our personal Michaelangelos? I
don't place myself that high, but that's just me. But please, don't preface
it with false humility!

Managers want to take charge and make things happen - that's why they've chosen to become
managers. But it's a pipe-dream, an illusion. The greatest myth of
management is that it's actually possible to control the future. All we can
actually do is understand the system so we can set up conditions where there
is a higher probabilty of a desired outcome. But nothing is ever certain
until it becomes history.

Then you're reading different history books than I am. Mine give more
versions of history than I ever could have imagined before the events
themselves took place!

 

[Michael Gwin]

Im glad I could start such a controversial thread! My email address
changed from when I started this thread so I didnt notice the replies till
now when I happened to search on my name.

To add, at the time I was creating the plan that we would execute. Since
documentation and communciation are things that people seem to "forget" the
most, I wanted to ensure they popped up on the schedule. I started with a
framework of tasks and wanted to make sure that once we met with each
stakeholder, and the plan grew, that wherever that end deployment date ended
up, the communication followed it automatically. This particular
communication was to be an indication of the planned event. We in IT know
nothing can ever be guaranteed 100% but we can guess and inform.

I appreciate the help and this is working for me.

Sincerely,