Yes, but why would you need to do it more than once or twice? Finding the
last possible start date that lets you hit a certain finish date is an
interesting academic exercise but it is an incredibly risky way to schedule
and manage the project. Doing so means that if anything goes wrong,
anything at all, anywhere along the line, you have blown it and will finish
late. Wisdom dictates that you start well BEFORE the latest possible start
date so that there is a cushion to absorb those inevitable delays that are
absolutely guaranteed to occur. It's fine to schedule backwards to find the
absolutely latest date you could possibly begin, but you should then switch
to scheduling forward from start and select a convenient and realistic start
date somewhat in advance of the latest date you've just determined as the
date where you'll actually begin work. When you do, your finish milestone
will pull forward to show you where you'll finish given that start date IF
everything goes perfectly. With a deadline date entered, you'll also have a
marker somewhat later on the timeline to show a reminder of the required
date and you can see at a glance how much "cushion" you have between where
it looks like you'll finish and where you absolutely, positively HAVE to
finish. If delays move the finish milestone too close to the deadline for
comfort, or G*d forbid, PAST the deadline, you know you need to exercise
some management controls - call in overtime, for example - to shorten up
some of the predecessor tasks and pull the finish milestone back from the
brink. That's a major reason I don't like using the "must finish on"
constraint - if you do, the plan will always show the milestone on the
required date EVEN IF you're running terribly late. The timeline always
says you're right on schedule even when you're not.
Jan and I have an on-going friendly disagreement between colleagues about
this but I'm absolutely NOT a fan of using a "must finish on" constraint on
the finish milestone instead of the deadline entry. He's absolutely correct
in that if you run the slack time reports and look for negative slack you
can make the same determination - but for me, that's jumping through
relatively obscure hoops - I like to see a dynamic Gantt chart with fluid
dates that predict where tasks are actually going to fall if I deploy my
assets in a certain way and a big red DANGER diamond indicator showing up
next to the task names if a task is missing a required target date. But for
me it's crucial that the date that's being displayed is the real date we'll
obtain if our resources work the way we've scheduled them, for better or for
worse. Using the constraint means the milestone will always be shown on the
desired date, whether or not your working schedule will actually have it end
up there. IMHO, that finish milestone needs to be able to move forward and
backward in response to changes in the plan leading up to it - showing me
where it WILL fall IF things go as presently outlined. If it doesn't fit, I
can't just move it to the desired date with a constraint, I have to do
something more concrete and reschedule the resource's work to adjust the
plan to make it fit the requirements. Once we start work, I also want it to
move around as I post progress, keeping me posted on where we're going and
telling me the date we will be finished if things continue going as they
have been up until now, whether we're gaining or losing with respect to the
original predicted finish date. If it doesn't meet my needs, I need to
change the events leading up to it until it does and I can't just use a
constraint to force it to the desired date because that's fudging the
program, pretending I've got money in the bank when in fact I'm seriously
overdrawn.
Such differences of "expert opinion" is why they hold horse races <grin> and
why PM is as much an art as it is a science.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
)