Lets talk about linking summary tasks first.
While the concept sounds like it could make developing the schedule easier, applying predecessor/successor relationships to summary tasks is not recommended for the following reasons.
1. It can create dependency logic that is difficult to follow
2. It may produce logic errors and create circular relationships
3. It will result in inefficient use of resources
1) Dependency Logic that is Difficult to Follow
Within your schedule, there will be direct task to task relationships such as Task C following Task B. However there will also be indirect relationships at the summary task level. For example, Summary1 is a predecessor of Summary2 which means that no tasks within Summary2 can start until ALL tasks in Summary1 complete. When debugging a schedule constructed in this manner, tasks may show no predecessor and/or successor which means that in order to determine why a task is scheduling where it is, you now need to start following indirect relationships.
2) Logic Errors and Circular Relationships
Assume we have a schedule where Summary1 contains tasks A-C and Summary2 contains tasks G-K and Summary1 is a predecessor of Summary2. Because there are no direct dependency relationships between task A-C with any task G-K it’s easy to see how a PM can easily add task relationships between a task in Summary1 with a task in Summary2 that could violate the relationship of Summary1 being a predecessor of Summary2. Attempting to create such a task relationship will generate an error and because of the summary level indirect relationships, complicates the debugging process.
3) Inefficient use of Resources
This is one of the biggest issues. Assume Joe is assigned to Task A in the Summmary1 group and he is also assigned to Task G in the Summary2 group. When scheduled, Joe can start Task A today, but Task B will not be scheduled until ALL of Summary1 tasks are completed, which could mean Joe now has a gap of days/weeks where he is assigned no work.