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.
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.Sign up to join this community
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.
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.
I wouldn't recommend linking summary tasks in MS Project for the following reasons:
See http://www.stakeholdermap.com/ms-project/link-summary-tasks-ms-project.html for more information.