Critical Path Question

[bamamac_1]

I was wondering if it's possible to see a Critical Path for certain tasks.
Say my project end in 2010. But I have a very important milestone in 2008.
The critical path to that very important milestone is different that the
critical path for the entire project. Is there a way I can toggle back and
forth between the different views. I want to be able to see the critical
path for my milestone in 2008. Is this possible?

Thanks in advance!

 

[Jim Aksel]

Could you break out your schedule to include only those tasks identifed to
support the milestone into a "sub-project"? If so, make that a separate file
and then turn on the critical path in that new file.

The project can be linked to the master project since it will insert as a
subject summary task.

The idea is to remove the "cloud" of all the other activities going on that
are not related to your special milestone. It would be nice if MSP had a
flag that implied "include this task in Critical Path Analysis" and then you
could set the flag for only the ones you need. For example, I have wanted to
exclude Level of Effort tasks from the Critical Path for a long time now, but
can't seem to be able to do it easily.

 

[davegb]

I was wondering if it's possible to see a Critical Path for certain tasks.
Say my project end in 2010. But I have a very important milestone in 2008.
The critical path to that very important milestone is different that the
critical path for the entire project. Is there a way I can toggle back and
forth between the different views. I want to be able to see the critical
path for my milestone in 2008. Is this possible?

Thanks in advance!

Critical Path is a project attribute, not a task attribute. Each task
does not have a Critical Path, only the project as a whole has this
characteristic. It's the path where Total Slack = 0. Since your task is
not on the CP, it has no CP.

If you want to know what tasks are precedents to the milestone, you can
google this NG and find a reference to a macro that will find them for
you.

Hope this helps in your world.

 

[Steve House]

Something to think about ... a milestone is not a target or a date. A
milestone is an event, a marker that something worth tracking has occurred
in the project. It occurs whenever it occurs. Of course you may, probably
do, have specific deadlines by which a milestone must happen, but that's
something else entirely. The milestone is the actual event being
monitored - "proposal accepted," etc - and it might end up occurring on,
before, or after the desired target date. Therefore saying "I have a
milestone in 2008" is really not a valid statement. I know it sounds like
just being picky about terminology, but phrasing it as "I have an important
milestone which must occur by XXX, 2008" can really help keep focussed on
how to build a schedule that meets the requirement. Otherwise it's far too
easy to succumb to the temptation to fix the date of the milestone to its
target with a constraint.

 

[davegb]

Something to think about ... a milestone is not a target or a date. A
milestone is an event, a marker that something worth tracking has occurred
in the project. It occurs whenever it occurs. Of course you may, probably
do, have specific deadlines by which a milestone must happen, but that's
something else entirely. The milestone is the actual event being
monitored - "proposal accepted," etc - and it might end up occurring on,
before, or after the desired target date. Therefore saying "I have a
milestone in 2008" is really not a valid statement. I know it sounds like
just being picky about terminology, but phrasing it as "I have an important
milestone which must occur by XXX, 2008" can really help keep focussed on
how to build a schedule that meets the requirement. Otherwise it's far too
easy to succumb to the temptation to fix the date of the milestone to its
target with a constraint.

I'm going to have to respectfully disagree with Steve here. We have
different concepts of milestones. I believe they can be a target and
certainly can have a date on which they must occur. If you're launching
the shuttle, there are launch windows of time in which the launch must
occur or be significantly delayed. The last day in the launch window
might be a milestone by which the launch has or has not occured,
thereby affecting what happens thereafter.

In event planning, there are usually several dates on which certain
things must occur. If the keynote speaker is scheduled to step to the
rostrum on Aug 2 at 8 am, that pretty much has to happen or you have a
fiasco. You can't call everyone planning to attend on the night before
and tell them to change their travel plans because you and your team
didn't get it right.

I imagine others have different interpretations of this term. But it's
not cast in concrete by any means.

 

[Jim Aksel]

I'm with davegb. In our world, we use IMP/IMS development defining Program
Events (PE-Milestones), Significant Activities (SA) must be completed prior
to a PE, and subodinatae to SA's are Accomplishment Criteria (AC) for each
SA. A PE occurrs when all of it's subodinate SA's and AC's are 100%
complete. The PEs are generally contractual Tier 1 Milestones that have
dates that are "Shall be on this date or you don't get paid" type contract
language. That also means they cannot occur early (or late) without contract
change authorization.

Please see Air Force publication AFMC Pamphlet 63-5 for more information.

Yes, I agree that Steve has a point supported by my position... I can't have
a PE until all it's subordinate SA/AC are completed. In that sense, the PE
(milestone) happens whenever it happens. The only issue with that is the
contract which would have performance penalties for not meeting the date. As
such, the dates become "Must Finish On" or "Must Start On." Since the
milestone is a 0 duration event, either constraint produces the same result.
Sometimes the customer is kind and allows "Finish No Later Than.."

It's all a philosophy thing, independent of our favorite tool MS Project.

 

[Steve House]

I'm simply saying the term "milestone" should refer to the event that takes
place - ie, all SA's and AC's are complete - and not the date on which it is
supposed to take place. To say "The 1st of September is a crucial milestone
in out project" without saying what it is that must take place on or before
that date doesn't make much sense. On the other hand, "we must have the
signed contracts in hand prior to the 1st of September in order to proceed
on schedule" makes perfect sense - the milestone event is "all contracts
signed" and the deadline date by which it must occur is the 1st of
September. If everyone gets a jump on it and gets right back to us, that
milestone might occur on the 20th of August, well before deadline.
Conversely, if someone drags their feet, that milestone event might not
occur until the 10th of September, 10 days too late. Regardless, the
milestone proper is the project "gate," signifigant event, or
change-of-state of having the contracts signed and ready to go. The
milestone is the important transition point between the state of "unable to
proceed because the contracts aren't signed" and the state of "able to
proceed because the required paperwork is in-hand."

 

[Jan De Messemaeker]

Hi Steve,

I know we went to all this before but since the discussion always comes up
again, I can't but repeat that I don't fully agree with you.
Remember the year 2000 conversions... 31 dec 99 was definitely a date to
remember and why not call it a milestone? why not put it on the board as "a
milestone"? Of course lots of things had to be done by then and there have
been links to it - but it was there even before the first task was planned
and the PM who would show a finish later than that would be out of job. The
option not to do some tasks or otherwise change the plan, yes, but touch the
date, never ever.

Many projects are like that... the plan simply doesn't have the right to
define its own end date: PMs don't rule the world, external constraints are
generally more compelling.

Greetings,

--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

I'm simply saying the term "milestone" should refer to the event that takes
place - ie, all SA's and AC's are complete - and not the date on which it is
supposed to take place. To say "The 1st of September is a crucial milestone
in out project" without saying what it is that must take place on or before
that date doesn't make much sense. On the other hand, "we must have the
signed contracts in hand prior to the 1st of September in order to proceed
on schedule" makes perfect sense - the milestone event is "all contracts
signed" and the deadline date by which it must occur is the 1st of
September. If everyone gets a jump on it and gets right back to us, that
milestone might occur on the 20th of August, well before deadline.
Conversely, if someone drags their feet, that milestone event might not
occur until the 10th of September, 10 days too late. Regardless, the
milestone proper is the project "gate," signifigant event, or
change-of-state of having the contracts signed and ready to go. The
milestone is the important transition point between the state of "unable to
proceed because the contracts aren't signed" and the state of "able to
proceed because the required paperwork is in-hand."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I'm with davegb. In our world, we use IMP/IMS development defining
Program
Events (PE-Milestones), Significant Activities (SA) must be completed
prior
to a PE, and subodinatae to SA's are Accomplishment Criteria (AC) for
each
SA. A PE occurrs when all of it's subodinate SA's and AC's are 100%
complete. The PEs are generally contractual Tier 1 Milestones that have
dates that are "Shall be on this date or you don't get paid" type contract
language. That also means they cannot occur early (or late) without
contract
change authorization.

Please see Air Force publication AFMC Pamphlet 63-5 for more information.

Yes, I agree that Steve has a point supported by my position... I can't
have
a PE until all it's subordinate SA/AC are completed. In that sense, the PE
(milestone) happens whenever it happens. The only issue with that is the
contract which would have performance penalties for not meeting the date.
As
such, the dates become "Must Finish On" or "Must Start On." Since the
milestone is a 0 duration event, either constraint produces the same
result.
Sometimes the customer is kind and allows "Finish No Later Than.."

It's all a philosophy thing, independent of our favorite tool MS Project.

Steve House wrote:
Something to think about ... a milestone is not a target or a date. A
milestone is an event, a marker that something worth tracking has
occurred
in the project. It occurs whenever it occurs. Of course you may,
probably
do, have specific deadlines by which a milestone must happen, but
that's
something else entirely. The milestone is the actual event being
monitored - "proposal accepted," etc - and it might end up occurring
on,
before, or after the desired target date. Therefore saying "I have a
milestone in 2008" is really not a valid statement. I know it sounds
like
just being picky about terminology, but phrasing it as "I have an
important
milestone which must occur by XXX, 2008" can really help keep focussed
on
how to build a schedule that meets the requirement. Otherwise it's far
too
easy to succumb to the temptation to fix the date of the milestone to
its
target with a constraint.

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



I'm going to have to respectfully disagree with Steve here. We have
different concepts of milestones. I believe they can be a target and
certainly can have a date on which they must occur. If you're launching
the shuttle, there are launch windows of time in which the launch must
occur or be significantly delayed. The last day in the launch window
might be a milestone by which the launch has or has not occured,
thereby affecting what happens thereafter.

In event planning, there are usually several dates on which certain
things must occur. If the keynote speaker is scheduled to step to the
rostrum on Aug 2 at 8 am, that pretty much has to happen or you have a
fiasco. You can't call everyone planning to attend on the night before
and tell them to change their travel plans because you and your team
didn't get it right.

I imagine others have different interpretations of this term. But it's
not cast in concrete by any means.



I was wondering if it's possible to see a Critical Path for certain
tasks.
Say my project end in 2010. But I have a very important milestone in
2008.
The critical path to that very important milestone is different that
the
critical path for the entire project. Is there a way I can toggle
back
and
forth between the different views. I want to be able to see the
critical
path for my milestone in 2008. Is this possible?

Thanks in advance!

 

[Steve House]

I never have said the plan or the PM has the right to define its end date.
I've said that if the purpose of entering the plan into calculating software
is to attempt to reason out what it will take, how one must organize and
staff the work, in order to finish by the required date, one needs to let
the software tell you what date you would get IF you proceeded with it
organized in the manner you have input into the computer in the current
trial iteration. You're experimenting to see what plans will work and what
plans won't work and you simply must allow Project to tell you truthfully
the results you will get from each attempt. A constraint forces it to
display that you'll finish on the desired date even if it physically
impossible for you to do so. I submit you can't just override Project's
calculated date with one of your own, your boss's, or your client's,
choosing - to actually hit the requirement they've laid down you have to
reorganize the work. Over a number of iterative trial plans you finally
zero in on one where Project's unconstrained finish date falls on or before
the required finish date - that's the plan you go with because it's the one
that meets the required objectives and that's the ONLY version out of the
perhaps many trial plans you have input and tweaked that you would ever show
the client, your boss, or the resources.

If you would running a profit and loss simulation in Excel to determine what
your product pricing should be in order to make a certain required profit,
you wouldn't force the result of the calculation profit=revenues-expenses to
always show the same value for the profit regardless of the numbers you
supply for revenue and expense, would you? Yet that's precisely what a
constraint does in Project - it forces the finish date to always show as the
same fixed date regardless of how long the tasks leading up to it take.
That obviously simply cannot be an accurate depiction of reality nor a
useful scheduling model. You rely on scanning for negative slack but I
suggest that is far less reliable than simply letting Project show you with
its calculated dates that IF you proceed as planned you WILL obtain THIS
result when what you really need is THAT result.

I'll reiterate - I've never said you can arbitrarily override the required
end date with Project's calculated end date. I've only said that the
software's job is not to document the dates you NEED - it's job is to model
the project workflow in the computer and tell you the dates you're going to
GET if you go with the plan as you have currently designed it. If the
result of that calculation doesn't meet your requirements, go back to the
drawing board and re-engineer the plan until it does. Project serves as the
reality check to insure your final working plan is firmly based on physical
reality and is not the result of wishful thinking or or just telling the
boss or client what he wants to hear. But for it to do that, you have to
remove the gag from its output and let it tell you what it's determined is
going to happen.

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

Hi Steve,

I know we went to all this before but since the discussion always comes up
again, I can't but repeat that I don't fully agree with you.
Remember the year 2000 conversions... 31 dec 99 was definitely a date to
remember and why not call it a milestone? why not put it on the board as
"a
milestone"? Of course lots of things had to be done by then and there have
been links to it - but it was there even before the first task was planned
and the PM who would show a finish later than that would be out of job.
The
option not to do some tasks or otherwise change the plan, yes, but touch
the
date, never ever.

Many projects are like that... the plan simply doesn't have the right to
define its own end date: PMs don't rule the world, external constraints
are
generally more compelling.

Greetings,

--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

I'm simply saying the term "milestone" should refer to the event that takes
place - ie, all SA's and AC's are complete - and not the date on which it is
supposed to take place. To say "The 1st of September is a crucial milestone
in out project" without saying what it is that must take place on or before
that date doesn't make much sense. On the other hand, "we must have the
signed contracts in hand prior to the 1st of September in order to
proceed
on schedule" makes perfect sense - the milestone event is "all contracts
signed" and the deadline date by which it must occur is the 1st of
September. If everyone gets a jump on it and gets right back to us, that
milestone might occur on the 20th of August, well before deadline.
Conversely, if someone drags their feet, that milestone event might not
occur until the 10th of September, 10 days too late. Regardless, the
milestone proper is the project "gate," signifigant event, or
change-of-state of having the contracts signed and ready to go. The
milestone is the important transition point between the state of "unable to
proceed because the contracts aren't signed" and the state of "able to
proceed because the required paperwork is in-hand."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

I'm with davegb. In our world, we use IMP/IMS development defining
Program
Events (PE-Milestones), Significant Activities (SA) must be completed
prior
to a PE, and subodinatae to SA's are Accomplishment Criteria (AC) for
each
SA. A PE occurrs when all of it's subodinate SA's and AC's are 100%
complete. The PEs are generally contractual Tier 1 Milestones that
have
dates that are "Shall be on this date or you don't get paid" type contract
language. That also means they cannot occur early (or late) without
contract
change authorization.

Please see Air Force publication AFMC Pamphlet 63-5 for more information.

Yes, I agree that Steve has a point supported by my position... I can't
have
a PE until all it's subordinate SA/AC are completed. In that sense, the PE
(milestone) happens whenever it happens. The only issue with that is the
contract which would have performance penalties for not meeting the date.
As
such, the dates become "Must Finish On" or "Must Start On." Since the
milestone is a 0 duration event, either constraint produces the same
result.
Sometimes the customer is kind and allows "Finish No Later Than.."

It's all a philosophy thing, independent of our favorite tool MS Project.

:


Steve House wrote:
Something to think about ... a milestone is not a target or a date. A
milestone is an event, a marker that something worth tracking has
occurred
in the project. It occurs whenever it occurs. Of course you may,
probably
do, have specific deadlines by which a milestone must happen, but
that's
something else entirely. The milestone is the actual event being
monitored - "proposal accepted," etc - and it might end up occurring
on,
before, or after the desired target date. Therefore saying "I have
a
milestone in 2008" is really not a valid statement. I know it
sounds
like
just being picky about terminology, but phrasing it as "I have an
important
milestone which must occur by XXX, 2008" can really help keep focussed
on
how to build a schedule that meets the requirement. Otherwise it's far
too
easy to succumb to the temptation to fix the date of the milestone
to
its
target with a constraint.

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



I'm going to have to respectfully disagree with Steve here. We have
different concepts of milestones. I believe they can be a target and
certainly can have a date on which they must occur. If you're
launching
the shuttle, there are launch windows of time in which the launch must
occur or be significantly delayed. The last day in the launch window
might be a milestone by which the launch has or has not occured,
thereby affecting what happens thereafter.

In event planning, there are usually several dates on which certain
things must occur. If the keynote speaker is scheduled to step to the
rostrum on Aug 2 at 8 am, that pretty much has to happen or you have a
fiasco. You can't call everyone planning to attend on the night before
and tell them to change their travel plans because you and your team
didn't get it right.

I imagine others have different interpretations of this term. But it's
not cast in concrete by any means.



I was wondering if it's possible to see a Critical Path for certain
tasks.
Say my project end in 2010. But I have a very important milestone in
2008.
The critical path to that very important milestone is different that
the
critical path for the entire project. Is there a way I can toggle
back
and
forth between the different views. I want to be able to see the
critical
path for my milestone in 2008. Is this possible?

Thanks in advance!

 

[John Sitka]

If you would running a profit and loss simulation in Excel to determine what your product pricing should be in order to make a

certain required profit, you wouldn't force the result of the calculation profit=revenues-expenses to always show the same value
for the profit regardless of the numbers you supply for revenue and expense, would you?

Awesome metaphor Steve. It's one of those extrememly obvious base principles
of scheduling. Dates are calculated, not entered, that simple. Just like extended columns
subtotals, etc. in other representations of business operations.
A milestone is best used in Project as a calculated task. Deadlines or any other of a
huge range of fixed fields can carry non calculated information.

I never have said the plan or the PM has the right to define its end date. I've said that if the purpose of entering the plan into
calculating software is to attempt to reason out what it will take, how one must organize and staff the work, in order to finish by
the required date, one needs to let the software tell you what date you would get IF you proceeded with it organized in the manner
you have input into the computer in the current trial iteration. You're experimenting to see what plans will work and what plans
won't work and you simply must allow Project to tell you truthfully the results you will get from each attempt. A constraint
forces it to display that you'll finish on the desired date even if it physically impossible for you to do so. I submit you can't
just override Project's calculated date with one of your own, your boss's, or your client's, choosing - to actually hit the
requirement they've laid down you have to reorganize the work. Over a number of iterative trial plans you finally zero in on one
where Project's unconstrained finish date falls on or before the required finish date - that's the plan you go with because it's
the one that meets the required objectives and that's the ONLY version out of the perhaps many trial plans you have input and
tweaked that you would ever show the client, your boss, or the resources.

If you would running a profit and loss simulation in Excel to determine what your product pricing should be in order to make a
certain required profit, you wouldn't force the result of the calculation profit=revenues-expenses to always show the same value
for the profit regardless of the numbers you supply for revenue and expense, would you? Yet that's precisely what a constraint
does in Project - it forces the finish date to always show as the same fixed date regardless of how long the tasks leading up to
it take. That obviously simply cannot be an accurate depiction of reality nor a useful scheduling model. You rely on scanning for
negative slack but I suggest that is far less reliable than simply letting Project show you with its calculated dates that IF you
proceed as planned you WILL obtain THIS result when what you really need is THAT result.

I'll reiterate - I've never said you can arbitrarily override the required end date with Project's calculated end date. I've only
said that the software's job is not to document the dates you NEED - it's job is to model the project workflow in the computer and
tell you the dates you're going to GET if you go with the plan as you have currently designed it. If the result of that
calculation doesn't meet your requirements, go back to the drawing board and re-engineer the plan until it does. Project serves
as the reality check to insure your final working plan is firmly based on physical reality and is not the result of wishful
thinking or or just telling the boss or client what he wants to hear. But for it to do that, you have to remove the gag from its
output and let it tell you what it's determined is going to happen.

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

Hi Steve,

I know we went to all this before but since the discussion always comes up
again, I can't but repeat that I don't fully agree with you.
Remember the year 2000 conversions... 31 dec 99 was definitely a date to
remember and why not call it a milestone? why not put it on the board as "a
milestone"? Of course lots of things had to be done by then and there have
been links to it - but it was there even before the first task was planned
and the PM who would show a finish later than that would be out of job. The
option not to do some tasks or otherwise change the plan, yes, but touch the
date, never ever.

Many projects are like that... the plan simply doesn't have the right to
define its own end date: PMs don't rule the world, external constraints are
generally more compelling.

Greetings,

--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

I'm simply saying the term "milestone" should refer to the event that takes
place - ie, all SA's and AC's are complete - and not the date on which it is
supposed to take place. To say "The 1st of September is a crucial milestone
in out project" without saying what it is that must take place on or before
that date doesn't make much sense. On the other hand, "we must have the
signed contracts in hand prior to the 1st of September in order to proceed
on schedule" makes perfect sense - the milestone event is "all contracts
signed" and the deadline date by which it must occur is the 1st of
September. If everyone gets a jump on it and gets right back to us, that
milestone might occur on the 20th of August, well before deadline.
Conversely, if someone drags their feet, that milestone event might not
occur until the 10th of September, 10 days too late. Regardless, the
milestone proper is the project "gate," signifigant event, or
change-of-state of having the contracts signed and ready to go. The
milestone is the important transition point between the state of "unable to
proceed because the contracts aren't signed" and the state of "able to
proceed because the required paperwork is in-hand."
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



I'm with davegb. In our world, we use IMP/IMS development defining
Program
Events (PE-Milestones), Significant Activities (SA) must be completed
prior
to a PE, and subodinatae to SA's are Accomplishment Criteria (AC) for
each
SA. A PE occurrs when all of it's subodinate SA's and AC's are 100%
complete. The PEs are generally contractual Tier 1 Milestones that have
dates that are "Shall be on this date or you don't get paid" type contract
language. That also means they cannot occur early (or late) without
contract
change authorization.

Please see Air Force publication AFMC Pamphlet 63-5 for more information.

Yes, I agree that Steve has a point supported by my position... I can't
have
a PE until all it's subordinate SA/AC are completed. In that sense, the PE
(milestone) happens whenever it happens. The only issue with that is the
contract which would have performance penalties for not meeting the date.
As
such, the dates become "Must Finish On" or "Must Start On." Since the
milestone is a 0 duration event, either constraint produces the same
result.
Sometimes the customer is kind and allows "Finish No Later Than.."

It's all a philosophy thing, independent of our favorite tool MS Project.

:


Steve House wrote:
Something to think about ... a milestone is not a target or a date. A
milestone is an event, a marker that something worth tracking has
occurred
in the project. It occurs whenever it occurs. Of course you may,
probably
do, have specific deadlines by which a milestone must happen, but
that's
something else entirely. The milestone is the actual event being
monitored - "proposal accepted," etc - and it might end up occurring
on,
before, or after the desired target date. Therefore saying "I have a
milestone in 2008" is really not a valid statement. I know it sounds
like
just being picky about terminology, but phrasing it as "I have an
important
milestone which must occur by XXX, 2008" can really help keep focussed
on
how to build a schedule that meets the requirement. Otherwise it's far
too
easy to succumb to the temptation to fix the date of the milestone to
its
target with a constraint.

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



I'm going to have to respectfully disagree with Steve here. We have
different concepts of milestones. I believe they can be a target and
certainly can have a date on which they must occur. If you're launching
the shuttle, there are launch windows of time in which the launch must
occur or be significantly delayed. The last day in the launch window
might be a milestone by which the launch has or has not occured,
thereby affecting what happens thereafter.

In event planning, there are usually several dates on which certain
things must occur. If the keynote speaker is scheduled to step to the
rostrum on Aug 2 at 8 am, that pretty much has to happen or you have a
fiasco. You can't call everyone planning to attend on the night before
and tell them to change their travel plans because you and your team
didn't get it right.

I imagine others have different interpretations of this term. But it's
not cast in concrete by any means.



I was wondering if it's possible to see a Critical Path for certain
tasks.
Say my project end in 2010. But I have a very important milestone in
2008.
The critical path to that very important milestone is different that
the
critical path for the entire project. Is there a way I can toggle
back
and
forth between the different views. I want to be able to see the
critical
path for my milestone in 2008. Is this possible?

Thanks in advance!