Yes, you can define summary tasks dependencies in Microsoft Project. It can also happen unintentionally when you promote tasks to summary tasks by indenting activities below them and fail to remove pre-existing links. However, links between summaries are generally not a good idea according to best practice guidelines. Let’s discuss.
Microsoft Project has both detail tasks and summary tasks. Detail tasks are at the lowest level in the schedule, and may have resource assignments. Summary tasks are any tasks with lower level subtasks. Microsoft Project sums the cost and effort from the detail tasks up through their associated summary tasks.
As mentioned, Microsoft Project comes with the functionality to define summary tasks dependencies. These are relationships between summary tasks or between detail tasks and summary tasks. This so called, high-level logic may be preferred by some managers because it seems to provide a top down perspective of dependencies. It may also appear more expedient to define a single summary task dependency instead of multiple dependencies on detail tasks.
Perhaps, you have multiple independent detail tasks with the same start date. One dependency on their summary task, e.g. Figure 1, will suffice to define the start of all its associated detail tasks.
Figure 1
Despite the apparent benefits of summary tasks dependencies, you should not use them in your schedule as this violates many standard best practice guidelines.
This article describes why schedulers should not insert dependencies on summary tasks.
A schedule is essentially a hierarchical breakdown of deliverables, tasks required to produce those deliverables, and task dependencies. Summary tasks are more than just a summary of detail tasks; they are your deliverables when they represent a work breakdown structure. WBS Summary tasks are therefore the product or service that your schedule produces. They are the elements in your work breakdown structure, which is a hierarchical breakdown your project’s resulting product, i.e. the deliverables.
So when you link a summary task and detail task you are defining a dependency between the deliverable and tasks required to produce that deliverable, which does not make sense. This alone is reason enough to deter one from inserting summary tasks dependencies.
There are other practical reasons though. Summary task dependencies make the effort to check if the network of dependencies is complete more difficult. With no summary tasks dependencies your inspection is limited strictly to detail tasks missing a predecessor or successor.
The critical path is also more difficult to map out when summary tasks have dependencies. (The critical path includes all tasks that drive your project’s completion date.) Your critical path may appear to stop at a detail task that has no successor, when the reality is that the path continues through a dependency on the associated summary task, e.g. Figure 2.
Figure 2
This is confusing and not good.
Summary
When organized as part of your work breakdown structure, summary tasks are typically deliverables and should generally not be confused or mixed with the tasks required to produce those deliverables.
Summary tasks should not simultaneously describe the deliverable and its dependencies. Leave the dependencies to the associated tasks. You should also keep an eye out for residual links that remain from when a task became a summary.