Lin Summary task (is it good practice)

[jp]

Hi,

Is it good/bad practice to link Summary Tasks?

Thanks.

-jp

 

[Dale Howard [MVP]]

jp --

I recommend that users DO NOT link summary tasks to anything, including
regular tasks, milestones, and other summary tasks. There are generally two
reasons for not linking summary tasks:

1. Summary tasks are not REAL tasks with Work and resources assigned.
Instead, they are like placeholders and are used to display the WBS in the
project. I recommend linking only regular tasks to regular tasks and to
milestones.

2. Linking summary tasks to anything else is the #1 reason for circular
reference errors in Microsoft Project. Have you ever tried to troubleshoot
a circular reference error in Microsoft Project? It's not easy and can get
really nasty in a big hurry.

Just a thought. Perhaps the others will render an opinion for you as well.

 

[Rod Gill]

I confess I find linking Summary Tasks useful, but only if a Group of tasks
need to be linked. For example all the refurbishment for a shop must be
finished before starting the next. In this case I would link the summary
tasks for each shop. As any one of a number of tasks may be the last to
finish if I didn't link the summary task I would have to link all potential
late finishers to the first task in the second shop, or to a finish
milestone. Linking the two summary tasks in this instance produces a simpler
path which I prefer.

However for people new to Project it is probably a good idea to stay clear
of linking summary tasks.

--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com

 

[jp]

Ok,

I'm hearing differences of opinion. Which make me think that ultimately
linking tasks to tasks and summary tasks to summary tasks is based on
personal preference. However, I also hear from both of you that new PM using
MS Project
should try to stay clear of using Summary Task linkages.

I think I understand circular references -- when summary tasks are linked to
their own subtasks. Please correct me if I'm wrong on this one or if I'm
omitting
to present other types of circular references not known to me. Point point
comes across kinda clear and kinda confusing. That is when you both say "New
MS Project developers should stay clear of summary task links".

Can you explain the kinds of troubles that can arise from such practices?
If you can describe one or two examples that would be great. At this time,
I'm perplexed as to how these type of linkages would create havoc in
maintaining Project.

Thanks.

-jaime

 

[Rob Schneider]

The *big* reason I *never* link Summary Tasks (or make any changes
whatsoever to the fields in Summary tasks even though Project does not
do much to stop you) is because these are not *real* tasks. Tasks are
line items that have project properties (work, duration, predecessor,
successor, a plethora of dates, etc.).

They are great when you are displaying the project in a hierarchy view.
But that's about it and outside that view you can fool yourself.

But when you start filtering, grouping, and viewing the project many
different ways, you lose the connection to the hierarchy. The idea that
a task is part of a collection under some summary task is all of the
sudden *gone*.

So, for the way I do things, this means:

: I end up with a relatively flat hierarchy. Too much hierarchy is bad
(I think it was Richard Feynman wrote about that when talking about flat
hierarchies in books ... no need for more than 2 maybe 3 for even the
biggest books).

: every task has enough information in the task name, or in affiliated
fields, e.g. WBS, to be identifiable and recognisable.

Thus when I use group views--always popular since everyone has their own
popular and unique way of looking at things--are possible.

 

[Jim Aksel]

Links on summaries ... BAD idea.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

Check out my blog for more information:
http://www.msprojectblog.com

 

[John]

Ok,

I'm hearing differences of opinion. Which make me think that ultimately
linking tasks to tasks and summary tasks to summary tasks is based on
personal preference. However, I also hear from both of you that new PM using
MS Project
should try to stay clear of using Summary Task linkages.

I think I understand circular references -- when summary tasks are linked to
their own subtasks. Please correct me if I'm wrong on this one or if I'm
omitting
to present other types of circular references not known to me. Point point
comes across kinda clear and kinda confusing. That is when you both say "New
MS Project developers should stay clear of summary task links".

Can you explain the kinds of troubles that can arise from such practices?
If you can describe one or two examples that would be great. At this time,
I'm perplexed as to how these type of linkages would create havoc in
maintaining Project.

Thanks.

-jaime

Jaime,
Fellow MVPs Dale Howard and Rod Gill are at the guru level (i.e. that's
well above the expert level). Dale doesn't recommend it and Rod says he
does link summary lines in some cases. If you feel you are at the guru
level then by all means go for it.

So what's the problem? If project plans were created and then remained
stable (i.e. no editing) then links on summary lines may be ok as long
as subtasks are not linked between summary groups. However, in most
cases project plans are dynamic and the process of maintaining those
plans requires editing that often changes the linking structure. That's
where the problem comes if summary lines are linked. Unless the plan is
small the chances of creating links that could become circular
references when other editing is performed (e.g. changes to the outline
structure).

Project is pretty good at alerting the user if a link edit will directly
result in a circular relationship. However Project cannot always detect
conditions that can result in a "backward pass" type of link that may
result when the file structure is modified to reflect the plan's
dynamics (i.e. plan tracking and maintenance).

Master projects with links between tasks in the inserted subprojects are
even more subject to circular relationships. I have seen more than one
complex master plan structure that contained one or more circular
relationships. The user may not even be aware of it although he/she may
see some strange file behavior.

The bottom line is that yes, summary line links can be used
successfully. Rod has demonstrated that. But 9 out of 10 experienced
Project users will strongly recommend against it.

John
Project MVP

 

[Reid McTaggart]

Two more reasons for anyone below guru level to NEVER link summary
tasks:

1) If you subsequently move a task to somewhere wle in your WBS, then
you have just (perhaps unwittingly) changed the logic of your schedule.

2) The critical path becomes fuzzy. If a summary task is on the
critical path, then you have to examine and mentally analyze its
subtasks to identify which one(s) are on the CP.

Ok,

I'm hearing differences of opinion. Which make me think that ultimately
linking tasks to tasks and summary tasks to summary tasks is based on
personal preference. However, I also hear from both of you that new PM using
MS Project
should try to stay clear of using Summary Task linkages.

I think I understand circular references -- when summary tasks are linked to
their own subtasks. Please correct me if I'm wrong on this one or if I'm
omitting
to present other types of circular references not known to me. Point point
comes across kinda clear and kinda confusing. That is when you both say "New
MS Project developers should stay clear of summary task links".

Can you explain the kinds of troubles that can arise from such practices?
If you can describe one or two examples that would be great. At this time,
I'm perplexed as to how these type of linkages would create havoc in
maintaining Project.

Thanks.

-jaime

Jaime,
Fellow MVPs Dale Howard and Rod Gill are at the guru level (i.e.
that's
well above the expert level). Dale doesn't recommend it and Rod says
he
does link summary lines in some cases. If you feel you are at the guru
level then by all means go for it.

So what's the problem? If project plans were created and then remained
stable (i.e. no editing) then links on summary lines may be ok as long
as subtasks are not linked between summary groups. However, in most
cases project plans are dynamic and the process of maintaining those
plans requires editing that often changes the linking structure.
That's
where the problem comes if summary lines are linked. Unless the plan
is
small the chances of creating links that could become circular
references when other editing is performed (e.g. changes to the
outline
structure).

Project is pretty good at alerting the user if a link edit will
directly
result in a circular relationship. However Project cannot always
detect
conditions that can result in a "backward pass" type of link that may
result when the file structure is modified to reflect the plan's
dynamics (i.e. plan tracking and maintenance).

Master projects with links between tasks in the inserted subprojects
are
even more subject to circular relationships. I have seen more than one
complex master plan structure that contained one or more circular
relationships. The user may not even be aware of it although he/she
may
see some strange file behavior.

The bottom line is that yes, summary line links can be used
successfully. Rod has demonstrated that. But 9 out of 10 experienced
Project users will strongly recommend against it.

John
Project MVPOffice Project Server implementation, training, integration and custom
development' (http://www.msprojectexperts.com)

 

[jp]

John,

Thank you and thank you all for your comments and suggestions.
I really appreciate it. I will more than likely fully understand some
of the answers later on as I build more MS-Project plans. At this point
I've understood the lesson -- stay away from linking summary tasks.

Again, thank you all very much for your candid answers.

-jaime

 

[John]

John,

Thank you and thank you all for your comments and suggestions.
I really appreciate it. I will more than likely fully understand some
of the answers later on as I build more MS-Project plans. At this point
I've understood the lesson -- stay away from linking summary tasks.

Again, thank you all very much for your candid answers.

-jaime

Jaime,
You're welcome and thanks for the feedback. It looks like we cleared up
your confusion.

John
Project MVP

 

[Michael.Tarnowski]

Hi,

Is it good/bad practice to link Summary Tasks?

Thanks.

-jp

Hi jp,
in my eyes Linking summary causes several problems:

Linking summary tasks is probably the number one reason project files
develop “circular reference” errors which can be very difficult to
find and correct. The main cause is links on both the summary and
between subtasks under different summaries. Other causes include out-
denting, where a linked subtask becomes a linked summary, and dragging
and dropping linked subtasks from one summary grouping to another.
Another major problem is that the logic flow of tasks becomes very
complex as summary links conflict with subtask links and from the
user's standpoint, the schedule doesn't seem to make sense or doesn't
respond to changes/updates as expected.
So, links to summary tasks at best can cause confusing logic flow and
at worst, file corruption, and thus should be avoided entirely.

Have fun
Michael

 

[L G]

Please can someone help me to resolve the issue, Iam too facing the same issue of circular reference and unable to either outdent or indent



Michael.Tarnowski wrote:

Re: Lin Summary task (is it good practice)
28-Jul-09


Hi jp
in my eyes Linking summary causes several problems

Linking summary tasks is probably the number one reason project file
develop =93circular reference=94 errors which can be very difficult t
find and correct. The main cause is links on both the summary an
between subtasks under different summaries. Other causes include out
denting, where a linked subtask becomes a linked summary, and draggin
and dropping linked subtasks from one summary grouping to another
Another major problem is that the logic flow of tasks becomes ver
complex as summary links conflict with subtask links and from th
user's standpoint, the schedule doesn't seem to make sense or doesn'
respond to changes/updates as expected
So, links to summary tasks at best can cause confusing logic flow an
at worst, file corruption, and thus should be avoided entirely

Have fu
Michael

EggHeadCafe - Software Developer Portal of Choice
SQL Server 2005 CTE (Common Table Expression)
http://www.eggheadcafe.com/tutorial...cf-b15d65b91c9c/sql-server-2005-cte-comm.aspx

 

[John]

Please can someone help me to resolve the issue, Iam too facing the same
issue of circular reference and unable to either outdent or indent

LG,
I assume you are still able to at least open the file. If so, apply the
built-in filter for "Summary Tasks" and look at the Predecessor and
Successor fields. There should be nothing in either field. If there is,
delete the predecessor and/or successor from the summary line. Yes, that
will change your project's logic, but it is necessary to get things back
to normal.

If the Predecessor and Successor fields on all summary lines are clear
then the circular relationship is more subtle. There is no quick and
simple way to find it. There are two basic approaches I can think of.

One is to painstakingly go through all the link logic in the file and
trace the paths. I've used this method in the past and believe it or
not, the "culprit" will eventually show up.

The second approach involves VBA. Although I don't have the exact macro
to do this I do have one that works in a similar manner with master
files that contain circular relationships. Basically it stores all link
information in a couple of spare fields. The existing Predecessor and
Successor fields are then cleared and the stored information is used to
re-create the link structure. When the algorithm hits the link that
would cause a circular relationship, the code faults thus telling the
user where the problem is.

Good luck.

John
Project MVP

 

[GirlGeek]

While trying to convince my clients NOT to put any predecessors or successors
on Summary Tasks, I did a search and found this discussion. Here's what I
usually suggest to people:

If there's a PREDECESSOR on a Summary task, it means that section can't
start until the Predecessor task is done. Figure out which Detail Task within
that section is the real Successor... the one that has to wait until the Pred
is done. Is it the first task in the section? If so, put the Predecessor on
that first task, remove from the Summary task. Is the Predecessor a pred for
ALL tasks in the section? Put on all.

Are the links between the Detail tasks in the section represented fully? If
not, add the right predecessors/successors to them.

If there's a SUCCESSOR on a Summary task, it means that Successor should not
get started until ALL the tasks in that section are done. So add a Milestone
at the end of the section to say that the section is completed (e.g.
"<Summary Task Name> Completed)". Put the Successor on the Milestone line
instead. Make sure all Detail tasks in the section flow through to the
milestone, whether one to the next to next, or each one having the Milestone
task ID in their Successor column.

Apologies to those of you who may think this explanation is obvious.

- Aviva

 

[John]

While trying to convince my clients NOT to put any predecessors or successors
on Summary Tasks, I did a search and found this discussion. Here's what I
usually suggest to people:

If there's a PREDECESSOR on a Summary task, it means that section can't
start until the Predecessor task is done. Figure out which Detail Task within
that section is the real Successor... the one that has to wait until the Pred
is done. Is it the first task in the section? If so, put the Predecessor on
that first task, remove from the Summary task. Is the Predecessor a pred for
ALL tasks in the section? Put on all.

Are the links between the Detail tasks in the section represented fully? If
not, add the right predecessors/successors to them.

If there's a SUCCESSOR on a Summary task, it means that Successor should not
get started until ALL the tasks in that section are done. So add a Milestone
at the end of the section to say that the section is completed (e.g.
"<Summary Task Name> Completed)". Put the Successor on the Milestone line
instead. Make sure all Detail tasks in the section flow through to the
milestone, whether one to the next to next, or each one having the Milestone
task ID in their Successor column.

Apologies to those of you who may think this explanation is obvious.

- Aviva

Aviva,
No apology is needed. You're expanded explanation is right on track and
it never hurts to restate a good practice - obvious or not.

John
Project MVP