M
MikeH
Is there a tech or other doc on "dangling tasks" (no successor) and their impact on crit path calc?
J
JackD
If you have project set to show "multiple critical paths" (tools
menu/options/calculation tab) then any chain that is dangling will show up
as critical. If not, then only the longest chain will show as critical.
-Jack
menu/options/calculation tab) then any chain that is dangling will show up
as critical. If not, then only the longest chain will show as critical.
-Jack
impact on crit path calc?MikeH said:
S
Steve House
FYI, In my opinion you should never have any dangling tasks at all. At
the very least a task still would have the project finish milestone as a
successor since the project isn't finished until ALL the tasks within it
are done and thus the last task in every chain is a predessor to the
finish milestone..
--
Steve House
MS Project MVP
Visit http://www.mvps.org/project/faqs.htm for the FAQs
the very least a task still would have the project finish milestone as a
successor since the project isn't finished until ALL the tasks within it
are done and thus the last task in every chain is a predessor to the
finish milestone..
--
Steve House
MS Project MVP
Visit http://www.mvps.org/project/faqs.htm for the FAQs
their impact on crit path calc?MikeH said:
J
JackD
I concur. No reason not to do this.
-Jack
-Jack
Steve House said:
M
MikeH
Thanks for your responses to which I concur. What I am looking for is some documented authority on this. I don't find the term "dangling tasks" or "impact on MSP 2002 critical path calculation of no successors for a detail task" in Microsoft's documentation. My observation is that MSP cannot calculate a critical path when there are detail tasks without successors. I mean a cp that is a "path" not just a single task that meets the definition of a critical task. Is the answer that MSP calculates a cp on the network that has links to a single end point, and leaves the no successor link tasks as simply stand alone non-critical tasks?
B
Brian K - Project MVP
MikeH said:
You can change the setting for the option called "Calculate Multiple
Critical Paths" on the Calculation tab of the Tools | Options dialog.
This will basically show any task whose finish date is equal to the
project finish as being critical.
I think that is what you are looking for, right?
--
___
Brian K
Project MVP
http://www.projectified.com
Project Server Consultant
http://www.quantumpm.com
M
MikeH
No. I understand the concept of multiple cp as discussed in the "MSP 2002 FAQ Standard and Professional." My question is related to the completeness of an MSP plan and its quality. My plans are straight forward 100 to 200 task IT development plans for a single project each. The question is whether there is a Microsoft or other published authority (text, paper, other) that states "all detail tasks should be connected to a single end point" and "...the reason for this in MSP plans is that without this condition, the MSP generated cp will be sub-optimal for critical path analysis." So far I have not found such a document.
B
Brian K - Project MVP
MikeH said:
There is no such document for several reasons, not the least of which
is that it is not a fact that the CP that project produces is sub
optimal. It is your opinion and that is certainly valid but it is that,
an opinion.
--
___
Brian K
Project MVP
http://www.projectified.com
Project Server Consultant
http://www.quantumpm.com
S
Steve House
I haven't seen such a document but it seems to me that the idea that all
task sequences should converge on a single end point is implicit in the
defintion of a project as a "time limted undertaking resulting in the
creation of a unique result." If there are multiple ending points, it
implies that there are multiple, non-related deliverables in the result.
But that isn't a single project, rather that describes is a cluster of
different projects. Such a thing might occur when using MSP to display a
consolidation view, say, a single Gantt chart to illustrate all the projects
underway in the IT department this year and the "display multiple critical
paths" would then allow you to view each project's own critical path. But
if we are looking at the network diagram of a single project, the end of the
project occurs when and not until *all* the tasks required to produce that
result have been completed. If the finish milestone indicates the point
when everything is done, the deliverables created, and the project team can
disband and go have a beer, it logically follows that the finish milestone
would have as its predecessor(s) the last activity in all task sequences
through the project and the single critical path then is the particular
sequence of tasks that determines what that date will be.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
of an MSP plan and its quality. My plans are straight forward 100 to 200
task IT development plans for a single project each. The question is
whether there is a Microsoft or other published authority (text, paper,
other) that states "all detail tasks should be connected to a single end
point" and "...the reason for this in MSP plans is that without this
condition, the MSP generated cp will be sub-optimal for critical path
analysis." So far I have not found such a document.
task sequences should converge on a single end point is implicit in the
defintion of a project as a "time limted undertaking resulting in the
creation of a unique result." If there are multiple ending points, it
implies that there are multiple, non-related deliverables in the result.
But that isn't a single project, rather that describes is a cluster of
different projects. Such a thing might occur when using MSP to display a
consolidation view, say, a single Gantt chart to illustrate all the projects
underway in the IT department this year and the "display multiple critical
paths" would then allow you to view each project's own critical path. But
if we are looking at the network diagram of a single project, the end of the
project occurs when and not until *all* the tasks required to produce that
result have been completed. If the finish milestone indicates the point
when everything is done, the deliverables created, and the project team can
disband and go have a beer, it logically follows that the finish milestone
would have as its predecessor(s) the last activity in all task sequences
through the project and the single critical path then is the particular
sequence of tasks that determines what that date will be.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
FAQ Standard and Professional." My question is related to the completenessMikeH said:
of an MSP plan and its quality. My plans are straight forward 100 to 200
task IT development plans for a single project each. The question is
whether there is a Microsoft or other published authority (text, paper,
other) that states "all detail tasks should be connected to a single end
point" and "...the reason for this in MSP plans is that without this
condition, the MSP generated cp will be sub-optimal for critical path
analysis." So far I have not found such a document.
M
MikeH
Brian, your right, but Steve's hit the nail on the head. A real home run in my view. Excuse the mixed metaphors. Thanks to all for your responses.
B
Brian K - Project MVP
MikeH said:
I agree. I like his answer better but I will throw some gas on the fire
by saying I disagree that having multiple tasks that end on the finish
date does NOT imply that they were unrelated. There could be several
different things all going along at the same time. When all of them are
done the project is done. They can all happen at the same time and you
have enough resources to have them working at the same time. This does
not mean they are unrelated. Sure you can link them all to a common
"Finished" milestone but this is just artificial. They are all still
actually on the CP since they all finish on the project finish date.
--
___
Brian K
Project MVP
http://www.projectified.com
Project Server Consultant
http://www.quantumpm.com
S
Steve House
But then, the finish milestone itself is also artificial <grin>. Milestones
are arbitrary markers that describe a particularly "interesting" state
transition point. We must lay down the foundation before we erect the
framing. The "Foundation Ready" milestone is a marker of the change of
state from the "foundation in progress" condition to the "foundation in
place" condition and we mark it off with as a milestone because the
achievement of the "foundation ready" state condition is an important
measure of progress while "third rebar from the left has been inserted into
south wall" is probably not important enough to monitor as a trigger event.
Imagine two parallel chains starting at the same time, one lasting 100 days,
the other 120 days. We put the finish milestone and the end of the 120 day
chain but do NOT link the 100 day chain's last task to it. Hitting the
finish milestone indicates the project is done and if we can work that
schedule as is we're fine. But if the 100 day chain has some problems and
gets delayed, by say 30 days, now we'll show the finish milestone (at the
end of the 120 day chain) as hit even though we still have 10 days of work
left to do in the parallel chain and the project really isn't done yet after
all. What should happen is the marker of "everything done, finished,
finito, everyone go home" event should have been pushed out by 10 days
beyond where it originally was found. That will only happen if all parallel
chains converge at or before the finish milestone.
are arbitrary markers that describe a particularly "interesting" state
transition point. We must lay down the foundation before we erect the
framing. The "Foundation Ready" milestone is a marker of the change of
state from the "foundation in progress" condition to the "foundation in
place" condition and we mark it off with as a milestone because the
achievement of the "foundation ready" state condition is an important
measure of progress while "third rebar from the left has been inserted into
south wall" is probably not important enough to monitor as a trigger event.
Imagine two parallel chains starting at the same time, one lasting 100 days,
the other 120 days. We put the finish milestone and the end of the 120 day
chain but do NOT link the 100 day chain's last task to it. Hitting the
finish milestone indicates the project is done and if we can work that
schedule as is we're fine. But if the 100 day chain has some problems and
gets delayed, by say 30 days, now we'll show the finish milestone (at the
end of the 120 day chain) as hit even though we still have 10 days of work
left to do in the parallel chain and the project really isn't done yet after
all. What should happen is the marker of "everything done, finished,
finito, everyone go home" event should have been pushed out by 10 days
beyond where it originally was found. That will only happen if all parallel
chains converge at or before the finish milestone.
B
Brian K - Project MVP
Steve said:
That is what I meant. That milestone is artificial. In my mind I watch
the "foundation in progress" task. When it is done then the foundation
is done. I dont need to link that task to some made up milestone that
means the same thing. The right-most end of the foundation in progress
task IS the milestone.
Say I have 15 tasks in parallel that can all be done at the same time
that make up the foundation. I can have them all link to the first task
in the next phase OR I can have them all link to a fake milestone and
then link that fake milestone to the fist task in the next phase.
Having a milestone just to have it seems like a waste of time. Now if
there are a ton of tasks in parallel and they all link to several tasks
each in the next phase then having a milestone makes sense to save the
complexity of the links between phases but I have never understood the
milestone mania that seems to have most of PM world in it's grip! LOL
--
___
Brian K
Project MVP
http://www.projectified.com
Project Server Consultant
http://www.quantumpm.com
S
Steve House
I agree - I think of milestones as marking key points in the project where a
major deliverable is complete, a contractor payment is due, a key go/no-go
decision has to be made, that sort of thing. They're there for convenience
rather than necessity. For the most I think of them as being there because
outlining the key deliverables is the first step in creating the WBS, then
the work packages are filled in between them as the deliverables get
decomposed into their component parts.
major deliverable is complete, a contractor payment is due, a key go/no-go
decision has to be made, that sort of thing. They're there for convenience
rather than necessity. For the most I think of them as being there because
outlining the key deliverables is the first step in creating the WBS, then
the work packages are filled in between them as the deliverables get
decomposed into their component parts.
J
Jan De Messemaeker
Hello,
My 2cts worth.
Milestones are only a reporting thing.
As a PM you know that when certain tasks are done, the "foundation is ready"
When you report to a financial manager or a customer they may not know that.
What you want to know is "When is the foundation ready"?
So it is convenient to link it to the appropriate tasks in your plan because
it facilitates reporting.
But agree, for the PM him/herself they are nearly useless.
Greetings,
My 2cts worth.
Milestones are only a reporting thing.
As a PM you know that when certain tasks are done, the "foundation is ready"
When you report to a financial manager or a customer they may not know that.
What you want to know is "When is the foundation ready"?
So it is convenient to link it to the appropriate tasks in your plan because
it facilitates reporting.
But agree, for the PM him/herself they are nearly useless.
Greetings,