Summary Tasks in Microsoft Project

Summary tasks in Microsoft Project can sometimes be confusing and even misleading if one only looks at the duration of the summary task. A summary task is exactly what it says it is - a summary of the subtasks underneath it. Relating to dates and duration, the duration of a summary task is calculated from the earliest start date of all it's subtasks (which may also be summary tasks) and the latest finish date of all it's subtasks. This may seem obvious, but let's consider an example where it can be misleading.

Example 1

In this example, the hardware is composed of two subtasks: a Build task and a Test task, each of which is 7 days (1 week as we're working with a 7 day schedule) in duration. As there are no other dependencies in the schedule and they are simply linked sequentially (Finish-to-Start), the duration of the Develop Hardware task is (somewhat obviously) 14 days or 2 weeks.

Example 2

In this next example, we have introduced a software development task that the hardware testing depends on. The hardware task still has two subtasks, both 7 days in duration but (and less obviously), the duration of the Develop Hardware task is now 35 days or 7 weeks. On closer inspection, we can see that the Build task is 7 days and can start now, but then there is "dead time", waiting until the software is ready before the hardware can be tested.

So the duration is correct. The hardware can start now and it won't be completed for another 35 days (5 weeks) as it's waiting for the software. However, if one only focuses on the duration of the summary task without understanding the detail, it can cause confusion. It is easy to still think of the hardware task as being two 7 days tasks so why isn't it 7 days.

We have, on occasion, seen people manually change the duration of the summary task because it didn't come out as they expected (yes, for some peculiar reason Microsoft Project 2013 and later let's you do this). You should notdo this, as it changes the summary task from an automatically calculated task to a manual task, preventing it from adjusting as the subtasks change. fastProject prevents you from doing this.

In summary (no pun intended!), when looking at the duration of a summary task, it is important to understand the subtasks and the dependencies from other tasks in the schedule in order to understand why the duration of the summary task may not fit what you think it should be.