Late Dates incorrect after indenting under Summary Task

S

Sean

Many of you know there is a "bug" in MS Project that affects the late dates
and backward pass.

If you indent a group of tasks under the summary task the late dates for
that group are changed by the summary task. A weird problem that only
surfaces when calculating total slack and the backward pass.

I've heard of some people using MSO/MFO anchors at the end of thier network
to solve this. Does anybody else have a solution. My company (a rather
large one) has submitted this to Microsoft and they acknowledge that it is a
bug, but aren't planning on fixing it anytime soon.

Please advise.

Sean
 
J

JackD

It is not entirely clear what you are talking about or what sort of advice
you are looking for.

Total slack is calculated whenever the schedule is recalculated (for those
who have calculation set to automatic - like me) a recalc occurs every time
a change is made to a schedule duration or link so to say it only occurs
when this happens is to assert that it occurs constantly.

There are some issues with linking to summary tasks, but I don't know that
I'd characterize them as a bug. Perhaps if you can give a more concrete idea
of what you are trying to say and some steps to reproduce it someone here
can help.

What is your problem specifically?
 
S

Steve House [MVP]

I'm not aware of any "bug" like you're describing. The total slack time of
a task is the amount of time it could be delayed without delaying the
project finish, in a nutshell. Imagine Summary Task A with subtasks A1
(3d), A2 (4d), & A3 (5d). The subtasks are not linked so they occur in
parallel, all starting the same day. Summary task A links to Summary X FS
and Summary X in turn links FS to the Finish milestone. What are the late
dates of A1, A2, & A3? Summary A's finish is determined by A3 so the late
date of A3 and Summary A are the same. Only if Summary A is delayed past
that point will Summary X be delayed, hence that is also the latest date it
can finish without delaying the project's finish. The late finishes of A1
and A2 are also that same date as A3 (which is also the late finish of
Summary A), since they could slip by 2 or 1 day respectively before they
delay the finish of Summary A. I think that is what you're describing in
your posting but where's the bug in that? That is exactly the way late
starts and late finishes are supposed to be calculated and that's the way
project does calculate them. And this is even with linking between the
summary tasks, which is often considered a bad idea. The alternative
linking would have A1, A2, and A3 all as predecessors to X1 and no links
directly in or out of the summary tasks themselves but the results are
exactly the same.

If I'm missing something here, please give us some concrete example that
demonstrates what you consider to be this bug - what Project gives you and
what you think it should be giving you instead (and why you feel Project is
wrong and your way is right). I'm really curious.
 
S

Sean

Let me explain better.

Create a project with the following info. The summary task is not Linked.
Don't indent it under the summary until you've added all the tasks. All
relationships are FS. Use a 5 day duration for all tasks. Insert the late
start field into your table.

Now, indent all the tasks under the sumary task. Watch the late dates
change. They shouldn't becuase there is no link or relationship to the
summary line. Microsoft has acknowledged the problem but has made no promise
to fix it. I've heard of some work around's but not found one that is 100%

Thanks
Sean

ID NAME PRED
1 summary
2 Start Milestone #1
3 Activity #1 2
4 Activity #2 3
5 Activity #3 4
6 Finish Milestone #1 5,10
7 Start Milestone #2
8 Activity #4 7
9 Activity #5 8
10 Activity #6 9
11 Start Milestone # 3
12 Activity #7 11
13 Activity #8 12
14 Activity #9 13
15 Finish Milestone #2 14
 
J

JackD

Um.... It works fine for me. There is no change. I can't reproduce your
problem.
Which version of project are you using?
Are all tasks set to be start as soon as possible?
 
S

Steve House [MVP]

Using Project 2003 Pro with all service packs up to date. I just asked
about task 11's predecessor, but then I tried it both ways - no predecessor
for task 11 or Activity 3 FS to Task 11. Either way I get no change in the
late start dates for any of the tasks whether they're indented under the
summary or not. I followed your directions to the letter, re-check your
message quoted below to make sure there's no typo that lead me someplace
other than where you intended.

There are no other tasks in the project. When you say indent under the
summary, you are NOT indenting task 1 labeled "summary" but are indenting
tasks 2 though 15, right?

--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
 
S

Sean

Okay, Sorry for the confusion. Forgot the critical part of constraints.
Make a quick network with the project start date of 2/28/05.

Name Dur Pred Constraint Type Constraint date
Summary 1 day? ASAP NA
Start Milestone One 0 days SNET 3/10/2005
Task One 5 days 2 ASAP NA
Task Two 5 days 3 ASAP NA
Task Three 5 days 4 ASAP NA
Task Four 5 days 5 ASAP NA
Finish Milestone 0 days 6 FNLT 5/19/2005

Insert the late start field. After you've entered in the network highlight
and indent everything under the summary task. The late start will change.
 
J

JackD

Hm.
Another reason to avoid constraints.
Of course the workaround is to put the task with the finish constraint
outside the summary task. Is that what Microsoft advised you to do?
 
S

Steve House [MVP]

You problem is in the (IMHO incorrect) use of the FNLT constraint on the
Finish milestone to indicate your deadline. First of all, using a
constraint to indicate your deadline says that Project will never schedule
that task to end later than the date you've entered, even if that date is
impossible to meet. When you work the schedule you *will* be late. Usiong
a deadline entry instead, OTOH, marks the plan where that task needs to hit
but it does NOT disable Project's ability to show you where it currently
will actually end up. If the schedule as planned results in your missing
the required finish date, the deadline shows you that fact directly AND
shows you how bad you've blown it. The constraint will show you finishing
on your deadline whether you're actually going to do that or not and to see
you've got a problem you have to add columns to monitor the slack time.

As an aside, I can see many examples where a SNET constraint might be a
valid model of reality - a supplier might not be able to deliver required
parts for the subject task before a certain date, for example - but I've
wracked my mind over and over and I have yet to come up with a real world
example where a FNLT constraint, as opposed to a Finish Deadline, would be
the appropriate setting. The FNLT constraint says, in effect - "If this
task hasn't already happened by xx/xx/xx date, it absolutely, positively,
WILL happen on that date regardless of anything you do" (note "will" and not
"should" - constraints imply established facts while deadlines imply
requirements) and I just can't think of anything in the real world that
behaves that way.

More to the point, when you indent the tasks, including the finish
milestone, under the summary, the deadline then really is when the summary
needs to finish. The deadline date is an attribute of the summary task
itself and is not directly associated with a specific task within it. In
your example, if you put the deadline or FNLT constraint of 5/19 to the
summary task and not the finish milestone and then work out by hand the Late
Finish dates of the subtasks once you've indented them, you'll find
Project's calculated dates will be correct.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
 
S

Sean

Microsoft hasn't given any recommendations, they are exploring the fix to
thier "undesirable feature." If you don't use outlining it calcs correctly.
The other fix I've seen is to put a "ghost" node with a MSO after the end of
the last milestone and link it to the last FNLT. However, you have to do
this for each path through your network. On a 10,000 line file you now have
100 extra "ghost" milestones.

Don't mean for you to spend a lot of time on this, was just curious of
others encountered it and possibly had a workaround.

Thanks
 
J

JackD

It only occurs when you have a FNLT constraint so simply avoid using them. I
can't recall ever having to use one except when doing some analysis and even
then if you move it outside the summary it isn't a problem.
 
T

Tom G.

The FNLT constraint says, in effect - "If this
task hasn't already happened by xx/xx/xx date, it absolutely,
positively, WILL happen on that date regardless of anything you do"
(note "will" and not "should" - constraints imply established facts
while deadlines imply requirements) and I just can't think of
anything in the real world that behaves that way.
Click to expand...

Suppose you have scheduled a conference on xx/xx/xx date and all the
planning up to it has to happen by that date. Would that qualify? Or do
you constrain it in a different way?
 
J

Jan De Messemaeker

Hi Tom,

You schedule the conference as Must Start On and link the other tasks FS to
it.
HTH
 
S

Steve House [MVP]

That would not qualify for a constraint IMHO. It is a deadline, the time by
which you needto have the work done and the entire reason for building a
project plan is to figure out just what you have to do in order to make it
so. You leave the task unconstrained and let Project place it where it
calculates it will fall. If that's ahead of the deadline, great! If it's
not, and it often won't, you have to change some of the tasks leading up to
it so that it falls where you need it to when Project recalculates the plan.
A constraint simply declares when it will happen by "royal fiat." But real
life isn't like that and simply stating "This will happen March 15th" does
not set up the conditions that will make it actually possible. If it's
calculated to be late, you have to actually change something in the critical
path leading to that date - perhaps call in overtime on a predecessor task -
that will change the conditions driving the task's dates, you can't just
wave a magic wand and send out a memo <grin>.
 
T

Tom G.

But real
life isn't like that and simply stating "This will happen March 15th"
does not set up the conditions that will make it actually possible.
Click to expand...

SAY WHAT?? Let's assume we're planning a trade show, golf tournament or
heck, the SuperBowl. Those activities are put on calendars sometimes years
in advance. One does NOT reschedule them 1/2 way through the project. It
is a fixed event. I think I like Jan's answer better.
 
S

Steve House [MVP]

You are correct that you can't reschedule them and I never said that you
could. Don't confuse the model of reality in the project schedule from the
external objective reality of the project's requirements itself. What I said
was that the reason to do the plan was to figure out what you need to do,
how you have to organize all the preparation tasks, in order to successfully
hit that "must have by" date. Your golf tourney is scheduled for 15 Sep.
But for the tournement to happen on time a lot of preparatory things have to
also happen. If they happen on time, the tourney will too. But if they
happen late, you won't be ready to rock and roll on the required date no
matter how badly you want to be and you're going to be very very embarrased.

The reason for building the model in scheduling software is to give you a
tool to do "what if" types of planning. So I outline all the tasks the have
to come before the tourney, link them in the logic that they'll have to
follow, and assign resources that we have at our disposal. We do that and
after scheduling all the tasks that must be done before the tournment we
find that Project calculates they won't be done until 15 October. What that
is telling us is IF we assign the work according to the plan we've outlined,
we'll be late, we won't be ready for the tournement on time. My option is
not to simply use a constraint to create the ILLUSION that everything is
fine. My real option is to change the way the work is planned until we come
up with a work schedule that really and truly has us finishing all the
preparatory activities before the required date. When we modify the
schedule, Project will recalculate the finish date and tell us if our new
strategy makes things better or worse.

IMHO, too many managers think scheduling is an act of will power - if I
declare the tournement will happen on the 15th of September, that act of
determination is sufficient to make it so. I disagree. A project is
completed when a deliverable is attained, something that occurs at the end
of a long chain of physical processes. We control the date we achieve the
deliverable by controlling the performance of the component activities along
that chain. If I need to drive 500 miles and the fastest my car can go is
50 mph, it will take me 10 hours - period. My desire to get there sooner is
irrelevant, I'm limited by the physical process. If I need to be there in 5
hours, I have to find a faster mode of transport, I can't just make my
clunker go faster through an act of will power. Likewise if I have to be
ready for a tournement in 6 months and I have 12 months worth of work to do
to prepare for it, the only strategy that will work is to shorten the
preparatory tasks by adding resources or something of that nature that will
have a real physical impact on the performance of the work. I can't say
"we'll finish by xx date" as a simple policy declaration- I have to do
something proactive to make it so. Project's job is to tell me what the
outcome will be IF we do the work according to a certain trial schedule. If
it doesn't achieve the desired objective, the only thing that will fix it is
to change the schedule and see if that improves the outcome or not.
 
T

Tom G.

Your golf tourney is scheduled for 15 Sep.
But for the tournement to happen on time a lot of preparatory things
have to also happen. If they happen on time, the tourney will too.
But if they happen late, you won't be ready to rock and roll on the
required date no matter how badly you want to be and you're going to
be very very embarrased.
Click to expand...

I disagree. When you plan a real world event, you may have 100 things
you'd really like to get done by the event date. But frequently things
don't work out so you simply eliminate them.

I agree with your arguments if it comes to designing an introducing a
product (which I've done), managing a construction project or any number
of other activities. I've done full software and hardware development
schedules using MS Project and the old CA SuperProject. It's a very useful
exercise especially in terms of, as you say, trying to figure out if a
schedule is realistic.

BUT, there are still real world applications for developing a project that
has a fixed date. For example, it's pretty standard to issue a press
release 60 days before X, 30 days before X, 15 days and so on. Those are
tied to the fixed event date. Also, this kind of planning is generally not
resource constrained.

Anyway, I'd like to know how to do that better using Project as a tool.
But, maybe there are other planning tools that are more appropriate?
 
S

Steve House [MVP]

What I suggest is that Project is ideal as a "what if" planning tool so you
CAN hit your required dates AND get all the preparatory items done on time.
If you let it, it can show you what effect changing something in the plan
will have on the final completion date. Some changes will make it go later.
Other changes will bring it forward. You set up the plan so it shows all
the things that need to happen and the way they relate to each other and
then proceed to examine and adjust it by rearranging the relationships,
reassigning resources, perhaps hiring a temp or outsourcing something or
even deleting something that is "nice to have" but not essential, all the
things you can tweak and twiddle with that affect the sequencing and
durations of the tasks in your plan, until the calculated finish date
becomes equal to or earlier than the required finish date. Now you have a
plan that you can work to that with some level of confidence that if you
work accoding the the schedule you've devised you're going to be successful.
All too many project plans amount to little more than educated guesswork and
wishfull thinking. A tool like MSP takes it from that into something more
precise that can actually predict real outcomes with a reasonable level of
confidence.

You don't tell Project the schedule you think you'd like to work or even the
schedule you think you'll be able to work - you tell it what you need to do,
what the assets are you have to do it with, any requirements that the
physical process itself dictates must occur in terms of task sequencing, and
the deadlines you need to do it by, and then Project tells YOU the schedule
you'll need to work to achieve those results.

I think we get hung up on what "fixed date" means. Certainly the date on
which an even must occur in the real world might be fixed. A contract might
require something be delivered on a certain date and it's non-negotiable.
But a "fixed date" in Project really means, IMHO, something quite different.
In Project, "fixed" means that the scheduling calculation engine won't move
it in the model of the plan (even it really should be moved because the
schedule is impossible to meet). But the model is not the reality. The
idea is to use the model to figure out what you must do to hit the reality
that you must. You don't do that by creating a picture that shows the
finish sitting on the goal regardless of what comes before it, which is what
a fixed date in Project does. I want to use the plan to answer the question
"What would the effect be of moving Tom from this task to that one during
the second week of March. Would doing that make the finish come earlier or
later? It looks like we might not be finished by the required deadline ...
would calling in overtime on Task XX during the second week it May give us
some breathing room in the schedule?" In order for us to make decisions
based on those answers, we must be able to see what effect each alternative
strategy has ... and if we fix the finish with a constraint project will
never show us those results.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Critical task definitions 2
Insert tasks in Excel file indented under specific Summary tasks 6

Top