Should Summary Tasks or Detail Tasks be Predecessors?

Question

When setting up a project, what are the advantages and disadvantages to using Summary Tasks vs Detail tasks as predecessors?

If it matters, I am experimenting with MS Project 2010 as a tool.

Answer 1

Personal preference, but for me, I only group them by like kind (summary to summary, detail to detail).

Summary tasks are seen as separate work packages, ie: they summarize all of the tasks necessary to complete that particular part of the project. So if I link a Summary task to anything, it will be to another summary task (work package).

This also helps in the rollup view, as I can see how the various summaries (work packages) link together, with no linkages lost in the view.

Answer 2

I second Trevor's answer but would remove 'personal preference.' The schedule logic rests at your leaf level of the decomposition. Everything that matters to you as a PM occurs at this level; at the summary levels, things become hidden and your critical path becomes clugy. If you mix your predecessor-successor logic between levels, you will, not may, lose sight of accrued variances. They will not surface until later and you want to know these things earlier.

Answer 3

I wouldn't recommend linking summary tasks in MS Project for the following reasons:

• it can make the logic difficult to follow, and make it hard to identify the Critical Path
• it can cause logic errors which artifically extend the plan
• it can lead to unnecessary bench time.
• it can cause circular logic warnings

See http://www.stakeholdermap.com/ms-project/link-summary-tasks-ms-project.html for more information.