Finsh No Later Than Constraints

[JaneH]

I have to finish a project on a certain date but I schedule the project from
a start date as I want all tasks to start As Soon As Possible. I use a Finsh
No Later Than constraint on a milestone task at the end of the project to
forewarn me (when I update my project plan with actual information) if the
project is likely to finish late. I can then add resources to tasks to bring
the project back on track. Up until now this has worked very well for me.
On my current project however, I need to finish the project by 29th May 2009
and so have have set my FNLT constraint for that date, and one of my tasks
has delayed the project so that it is scheduled to finish on 27th May 2009.
I am still getting the planning wizard box up telling me that there is a
scheduling conflict. This is the only constraint I have set. Any ideas what
I may have done and where that may be causing this

 

[Dom - the MS Project Guy]

Jane,

Take a look at the Schedule Table - View:Tables:Schedule and then look at
the last 2 columns Free Slack and Total Slack - the planning wizard message
you are getting is triggered by there being "Negative Total Slack" in your
case this is the amount of time by which you are overshooting your FNLT
date. Working up from the final milestone trace back the dependencies and
see if you can "tweak" your schedule to eliminate the negative total slack.

Remember that for the critical tasks in your schedule you cannot improve on
0 days Total Slack - they will have either a negative value or 0 value.

I hope this helps.

--
Dominic Moss

Projectability - Helping People achieve more with Microsoft Project

www.projectability.co.uk

 

[JaneH]

Dom, you are a star. Thanks for that, I had negative slack as I am using as
resource that works longer hours than those defined in the standard calendar.

 

[Jim Aksel]

Jane - glad to see Dom could help you.

One more thing to consider instead of using a "FNLT" ... we use Deadlines
and key a deadline date (From the advanced tab) into the final milestone
leaving it "ASAP" as task type. You will see a green dog house on the Gannt
for the deadline. If the deadline is exceeded the indicators column shows a
red diamond as you see now. The deadline date will also drive the negative
total slack and you can keep everyone "ASAP" in accordance with good
scheduling practices.

With a deadline date you have a visual indicator on the Gannt which is what
we like.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

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

 

[JaneH]

Hi Jim,

I have used the deadlines before and I know that I should but being the
unobservant little madam that I am the big box appearing in the middle of the
screen spurs me on to do something to solve the date going beyond my required
date whereas the red diamond can be ignored!!!

 

[Projectability]

FWIW - I prefer the FNLT for the reason Jane offers. As long as there is a
continuous sequence through the schedule and a FNLT on the last Milestone
and things are within tolerance all is sweetness and light. As soon as a
delay causes the FNLT to be in jeopardy the planning wizard displays the
warning dialogue box that cannot be ignored. With deadlines the red warning
diamond may not always be visible due to differing tables being used or
columns being scrolled rightwards so the indicator column is not visible.

--
Dominic Moss

Projectability - Helping People achieve more with Microsoft Project

www.projectability.co.uk

 

[Steve House [MVP]]

The problem is that when you use a FNLT instead of the deadline, the Gantt
will always be promising you're finishing on time. Let's say your required
finish date is the 29th of May and you're predecessors are running two weeks
late. Looking just at the milestone, with the FNLT constraint it will still
show sitting on the 29th, promising you're finishing on time even though
it's physically impossible for the real world to happen that way. With the
deadline, you'll see both the required date and the date you're actually
likely to hit unless you do something to fix it. As I like to put it to my
classes, constraints model physical realities while deadlines model
objectives.

 

[Steve House [MVP]]

Actually it can be ignored - in fact, there's a "Don't Show Me This Again"
checkbox in the lower left corner of that error message that suppresses it
permanently. I don't want my schedules to show me the requirements - I
already KNOW what they are. I want Project to predict whether or not I'm
going to be successful in meeting those requirements if I commit to a
certain workflow. To do that, it has to be able to freely show me what's
going to happen, for better or worse, when we go forward with the present
plan. To my thinking, constraints should be used to model physical
realities effecting the schedule that are NOT part of the collection of
variables such as links, durations, resources, etc that Project's
calculations take into account - parts on back order until 01 Nov mean that
a task using those parts needs to have a Start No Earlier Than constraint of
01 Nov on it in order to prevent Project from scheduling it to start before
the required parts arrive. That's a legitimate use, but forcing the
schedule to show objectives such as deadlines as if they are a certainty is
not. Tasks and milestones should appear in the timeline where they're going
to fall in the real world if one attempts to work the current plan.