Steve
Tue Mar 01 08:09:42 CST 2005
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
"Sean" <Sean@discussions.microsoft.com> wrote in message
news:3AE2FAA1-12AE-421C-8B5E-D223D2605338@microsoft.com...
> 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.
>
>
> "Steve House [MVP]" wrote:
>
>> 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
>>
>>
>>
>> "Sean" <Sean@discussions.microsoft.com> wrote in message
>> news:2112CCC3-04E6-4438-8ABE-81E853992169@microsoft.com...
>> > 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
>> >
>> >
>> >
>> >
>> > "Steve House [MVP]" wrote:
>> >
>> >> 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.
>> >> --
>> >> Steve House [MVP]
>> >> MS Project Trainer & Consultant
>> >> Visit
http://www.mvps.org/project/faqs.htm for the FAQs
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> "Sean" <Sean@discussions.microsoft.com> wrote in message
>> >> news:8D16920B-D1B6-47F2-B279-B190C3F654F4@microsoft.com...
>> >> > 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
>> >> >
>> >>
>> >>
>>
>>