In Microsoft Project, Summary Tasks are Misnamed

Microsoft Project has a feature called summary tasks. In Microsoft’s world, you take a bottom-up approach to creating your schedule. You create a list of tasks, and when you realize one can be broken up into smaller activities, you create those smaller tasks and indent them (making them subtasks), and your original task becomes a summary task. Microsoft writes:

In Project, an indented task becomes a subtask of the task above it, which becomes a summary task. A summary task is made up of subtasks, and it shows their combined information.

The naming convention (“summary task”) is unfortunate because your original task isn’t a task at all — it’s more like an outline header. Complicating matters, Microsoft Project allows you to edit the data (or cells) in a summary task. You can assign a start date and a resource to it. You can assign predecessors. Do this, and your summary task is technically no longer a summary of the indented information below it.

In other words, a summary task is frequently neither. But by calling it a “task”, Microsoft inadvertently promotes a bad scheduling practice. Worse, changing the “task’s” data interferes with the correct calculation of the critical path. It’s like pouring sugar into the gas tank of a car. Not advisable for the operation of the engine. Our project schedule analyzer checks to make sure that summary tasks haven’t been used improperly, helping the critical path “engine” do its job.

Oracle Primavera, on the other hand, takes a top-down approach. Early in the creation of a schedule, you create a WBS (work breakdown structure). This is a more sensible way to build your schedule. You start with the highest level items (for example, deliverables) and then keep breaking them down until you’re ready to start creating activities. The WBS items and the activities are seen as two completely separate entities in Primavera.

I will point out that it is possible to create a schedule in Microsoft Project using a top-down approach. This is what we recommend. Change your mental model of summary tasks — they are not tasks in any way, shape, or form, and they should be left alone to report (summarize) the tasks that belong to them.

Before You Perform a Time Impact Analysis . . .

Many organizations, as they are considering the impact of a considered change to a project, perform a Time Impact Analysis (TIA).  A time impact analysis is a scheduling technique that models the change being considered and its impact (cost, time, resources) on the schedule.

Any article you read on performing a TIA stipulates as a requirement that your schedule must have a valid critical path. 

But what does “valid” mean?

In this context, “valid” means high quality.  Are the activities linked together properly?  Are constraints being used properly and only where necessary?  Are relationship types, lags, and leads being used properly?  Is there hidden trouble (e.g. negative float) that isn’t being addressed?  Does the schedule have the proper level of detail?

All of these questions help assess whether the critical path can be trusted.

As the Russian proverb made famous by President Reagan goes, trust but verify.  Large corporations are required to have a system of internal controls for their finances.  At Steelray, we believe that they are needed for project schedules as well.

Does your organization have internal controls for schedules?  Let’s talk!