DCMA DECM 06A208a

Summaries with Logic

“A book is simply the container of an idea like a bottle; what is inside the book is what matters.”

- Angela Carter

In this check, DCMA is looking for a practice that you should never use in a scheduling tool – summary tasks with logic. To explain summary tasks, we first need to understand the work breakdown structure.

What is a work breakdown structure?

One of the first steps in creating a schedule is to break down the project’s work into a hierarchy known as a work breakdown structure (WBS). The hierarchy looks like the roots of a tree (or a tree flipped upside down). You begin by organizing the project’s work into sections and breaking down those sections repeatedly until you get to the actual activities or tasks that do not need further division.

In a tree structure, when you divide a section into smaller parts, the section is said to be the parent of the parts. The parts are said to be the children. Of course, you may subdivide the children into even smaller parts, which makes them both parents and children. The parts that have no children represent the actual work in the schedule. The parents are just placeholders used to contain their children.

Let’s use the book example from the initial quote. A book is a container of sections or chapters. Chapters contain paragraphs, and paragraphs contain sentences. It is the sentences that have a sequence. Chapters and paragraphs are essentially containers for the real content (the sentences).

What is a summary task?

In a schedule, the parent is not actual work – it’s a container for the work. The information attached to it (start date, finish date, duration, etc.) is summarized from its children. For example, a parent’s earliest start date is calculated by finding the earliest start date of its children.

In Microsoft Project, these parents are called summary tasks. In Primavera, they’re called WBS summary activities. Both names are unfortunate because they are not tasks or activities. Instead, they summarize their children’s information. If you think of them as tasks/activities, it’s easy to treat them that way and make a severe mistake.

The mistake

The mistake you can make is to assign a start date, a finish date, a predecessor, a successor, or a resource to the summary task. Instead of letting the scheduling tool calculate that information, you are hardcoding it instead.

Why is this a mistake?

Because summary tasks aren’t tasks, but instead summarize the information from their children. You are interfering with the laws of nature (scheduling nature) when you hardcode that information. In this case, let’s look at adding logic (predecessors or successors).

Let’s refer to children who have no children and have a duration greater than zero as effort tasks. Effort tasks represent the real work in a schedule. Effort tasks should have dependency relationships with other effort tasks. The scheduling tool calculates start and finish dates by following each chain in the network of effort tasks and their relationships.

But what happens when you attach relationships to summary tasks? Let’s revisit our book example.

Suppose I recorded a storyteller telling a long and detailed story, and I transcribed the recording as a book. I submitted it to my publisher, and she came back and said that I need to break it into chapters because, well, books have chapters.

So, I look at logical places in the text where a chapter can close, and a new one can begin. Now I have my chapters. We know the following is true: the storyteller decided that the first sentence of Chapter 3 should immediately follow the last sentence of Chapter 2. The storyteller didn’t know anything about chapters. They made the sequence relationship between the two sentences of each chapter. They made a classic finish-to-start relationship.

Now suppose that I add finish-to-start relationships between the chapters as well, and I make a mistake and say that Chapter 3 can start immediately after Chapter 1 finishes. The typesetter sees two conflicting pieces of information. The first sentence of chapter 3 can begin when the last sentence of chapter 2 finishes. But it can also begin immediately after chapter 1 finishes. We have a problem!

In the same way that a book is sequences of sentences, the true sequence of a schedule is in its work and not in its containers. When you add logic to the containers (and the children within them), you are making it very possible to interfere with the proper calculation of the critical path. This is why we (and DCMA) look at summary tasks – to make sure that they are not interfering with the correct calculation of the critical path.

Food for thought

It’s certainly possible to add relationships to summaries in a way that doesn’t disrupt a correct critical path calculation. If you *only* linked summary tasks at the same level in the tree, you could still get the same project finish date. But just because you *can* do something doesn’t mean you *should*.

Next steps

In each case where a summary task has logic, remove the links and replace them with links between non-summary tasks. Understand the true dependency that exists in the real world before adding those links.

14 Point Analyzer