FNLT date has a SF precedessor with finish date later than the suc

[wendyB]

Hi

I am troubleshooting a plan that has been developed in MS Project 2000
(about 2000 lines).

Among the issues is one where tasks which have been scheduled with a Finish
No Later Than constraint, have finish dates that are earlier than their
predecessors (FS relationship) finish dates. A simplistic illustration of an
example:

1. Excavation Start Mar7, Finish Mar19, Constraint: ASAP
2. Pour concrete slab Start Mar15, Finish Mar17, Contsraint: FNLT Mar 18
Predecessor: 1(SF)

There are many such instances within the schedule which has been touched by
many people, in a shared environment where MS Project is deployed standalone.
There are no indicators to show such conflicts and I'm not sure whether this
is a limitation of 2000 or whether the issue has occured because the
scheduling alerts were disregarded when they did pop up. Can anyone shed
some light on this? In any case, I'd be interested to know whether 2002/3 or
Enteprise would overcome such an issue.

 

[Jan De Messemaeker]

Hi,

I'm not sure what your quetion is.
Is it you want to avoid this, in other words, you want the links to be
stronger than the compelling constraints?
Or is it, you want a filter to detect these situations such that you can
react properly?

Both questions have an answer.
Fior the first one, in Tools, Options, Schedule, check out "Tasks will
always honour their constraint dates"

Furthermore, verify whather in Tools, Options, general, "Advice from
planning wizard" is on to get a maximum of messages.

As for detecting these anomalies, you only can do that a loong as these
tasks haven't been put to complete because Project then will accept nearly
everything (it works on your plan not on what you input as reality)
If the tasks are still planned not "done" enter a column "Total Slack" and
Autofilter it for negative total slack. That's all.

HTH

 

[Steve House [Project MVP]]

This is the best reason I can think of to try not to use FNLT constraints
and one of the major reasons I argue so strongly against using them to
represent deadlines. A FNLT constraint tells Project never, ever, under any
circumstances, to show this task finishing later than XX date, even if it's
patently impossible for it to happen by that date in the real world (such as
a predecessor task that is required to finish in order for the task in
question to start, not finishing until after the required deadline.) The
result is a task with negative slack time when the predessesor is running
too late. The constaint says show it as happening on time even though it
can't and is essentially asking Project to lie to you, completely destroying
its ability to act as a predictive tool to test the viability of proposed
schedules. You can switch off the "tasks always obey constraint dates"
option in the tools menu but that is a global setting and means that ALL
task constraints will be ignored, not just the problem ones. Project 2000
introduced the Deadline field (found in the task information sheet advanced
tab) to handle this problem - if you put the required completion dates in
that field instead of setting a FNLT constraint you'll get the best of both
worlds - Project shows the task falling on the dates it predicts that it
WILL land on if you work the predecessors as planned, alerts you to do
something to the predecessor chain to fix it if its late, and calculates the
task's slack times exactly the same way it would if you had a FNLT
constraint instead. The thing is, using the deadline instead of the FNLT
lets Project show you what you CAN or are GOING to get rather than just
parotting back what you WANT to get whether you can have it or not.

 

[wendyB]

Thanks guys for your quick response.

Further question for Steve;

In one of the instances where this problem has occured, I removed the FNLT
constraint to asap, and set a deadline for the task. The red exclamation
alert now shows up in the Indicators column which is great. How would you
suggest that I detect all anomalies within the 2000 lines without going
through every single one manually? I have put in the Total Slack column to
track negative slack time, but the tasks where there are negative slack time
aren't always associated with the FNLT constraint problem.

Also, is there a way to "force" the Planning Wizard to be activated for a
selected task?

Thanks.

 

[JulieS]

Hi Wendy,

To more easily view the constraints in a project file, insert the column
Constraint Type into a task table. You can then quickly scan for
constraints other than ASAP.

As far as forcing the Planning Wizard for specific tasks, not to the best of
my knowledge.

Hope this helps. Let us know how you get along.

Julie

 

[Jan De Messemaeker]

Hi,

Just one small remark.
Tasks with negative slack always are a real problem (they can't be done in
time).
Negative slack can only happen when somewhere in the chain of task, a date
is forced.
Either they are linkes to a task with a constraint or with a deadline, or
they are linked to a task with an actual start (in the futuere??? shoudn't
be)
Claiming that total slack is not a good filter to detect effects of
constraints and deadlines beats me.

 

[Kevin]

I have seen this before. What I have discovered is that the activity with the
SF predecessor has another predecessor(s) that is/are driving it to finish
later than the SF predecessor. When I clear the link for the "non SF
predecessor(s)" I find that the activity honors the SF link. The FNLT
constraint has no bearing on it whatsoever.

Best regards,

Kevin

 

[Steve House [Project MVP]]

If your comment about total slack is directed at me, I never suggested that
total slack wasn't a good filter. It is but if you have slack problems
using constraints forces you to do date arithmatic to see where you stand so
far as far as the work calendar is conscerned. If you have a task with
negative slack, the displayed start and finish dates are NOT the dates that
are physically possible to achieve or the dates that will be achieved if the
project is worked exactly according to plan as it stands up to that point.
When I look at the start and finish column, I want to see the dates that the
present plan will drive the task to, completely without regard to the
project's date objectives. If the plan places the tasks on or before the
dates they are required to hit I'm happy. If it places them later, I know I
have rework the plan. But in any case I want the schedule in Project to
predict where they WILL hit IF I work the plan as it stands so I can tell if
my plan revisions will be successful or not. Negative numbers in the slack
column tells me I have a problem but I want the start and finish columns the
reflect the dates that the task will land on, not the dates I want it to
land on. Using a deadline tells me the dates I will achieve with the
current plan, using a constraint tells me the dates I want to achieve
whether this plan can do it or not. I want the model to predict
performance, not just repeat back to me what I'm trying to achieve.

 

[Jan De Messemaeker]

Sorry about the placement, I wasn't reacting to you but to Wendy's latest
post!

 

[Pratta]

Hi Kevin
If this schedule has had many previous owners I would make it my own. I
suggest you :
- print off a hard copy
- Open a new blank schedule
- set all Task Type to Fixed Duration and set as default
- paste all tasks from the old schedule into the newi
- update set all past tasks that are completed as completed
- for all non-complete tasks open a column for Contraints and make sure they
are all ASAP, apart from those that have already started
- create links for all these tasks - (make sure all links are at the task
level) - not summary level. Note: it is quite possibly summary task links
that are causing your schedule to be troublesome
- change the relationships as required in the schedule using relationshps
and lags; do not touch the Start and Finish columns so to avoid hard coded
dates such as FNLT - which is a massive NO-NO, as stated quite clearly in the
other responses.

Regards............Pratta

 

[wendyB]

Jan

I wasn't suggesting that total slack is not a good filter to detect effects of
constraints and deadlines, merely just stating what I was experiencing with
the recommended remedy after applying it on this particularly complicated
schedule. Sorry if you feel that way.

Cheers
Wendy