Extra options undermine manageability. . .

Prerequisite confusion

by Conrad Weisert

©2009, Information Disciplines, Inc.
This article may be circulated freely, as long as the copyright credit is included.
November 22, 2009


Background

I just read another book on project management that explains predecessor-successor relationships among tasks in the project plan. On a project plan a given task Tj may be designated as prerequisite (or predecessor) to another task Tk. Indeed such relationships are fundamental to a task network.1

But that's not all, according to some sources. A prerequisite relationship, they claim, can be specified in any of four ways:
finish to start Tk may not start until Tj ends.
start to start Tk may not start until Tj is underway.
start to finish Tk cannot be completed until Tj is underway.
finish to finish Tk cannot be completed until Tj has been completed.

There may be projects for which those distinctions are useful, but the projects I.T. people undertake are rarely among them. Only one of the four contributes to our ability to manage work assignments and to monitor project status accurately.

Tasks and task deliverables

The unit of work in a project plan, usually assigned to a single member of the project team, is a task. A task specification consists of a general description of the work to be done, estimates of duration and resources required, and these two essential items:

The most common reason for specifying a prerequisite task is that this task needs the task deliverables that the earlier task produced. Obviously, this is the finish to start relationship in the above table. That's what we mean whenever we say that one task is prerequisite to (or predecessor of) another task.

But what if only part of an earlier task has to be done first?

Advocates of greater complexity sometimes put forth an example in which task executions need to be overlapped. We can start moving the furniture into the new building as soon as some of the walls have been painted, so paint walls is a start-to-start predecessor of move furniture.

Nonsense! Would you tell the movers to start unloading the truck if you were told that the paint was dry in half the new offices?

Overlapping tasks are a symptom of insufficient granularity in the project plan. That is, the tasks are too big and there are too few of them.

For very simple activities a highly competent experienced project manager may be able to keep track of the details in his or her head, but for a complicated project with a high penalty for failure, the risk is too great. One might also trust an experienced project team member who is assigned to both Tj and Tk to figure out appropriate short cuts. But otherwise, a prerequisite-successor relationship always means finish-to-start.

Spawning subtasks2

In the course of carrying out a task T one may identify one or more subordinate tasks needed to support T. If one of those subordinate tasks is large enough to be assigned and tracked separately, it is then entered into the project plan.

This commonly occurs in developing modular software. Suppose a programmer assigned to develop module B identifies a non-trivial submodule C that B will use. Once the interface between the two modules is rigorously specified, work can proceed in parallel on the two modules. It may be tempting to specify a finish-to-finish precedence between one module and the other, depending on whether the programmers are following

  1. a top-down approach in which B, uses a temporary dummy stub in place of C
  2. a bottom up approach in which C, is called by a temporary driver program.

The problem with either finish-to-finish approach is that a project may get mired in a morass of task status reports claiming 90% completion while waiting for subtasks. It's then very hard for the project manager to aggregate the individual statuses and estimates of remaining work into a credible target date for the project.

A better approach, if the project really needs to maximize parallel effort, is to combine top-down and bottom-up development by specifying three tasks on the project plan:

  1. T1: develop B with a dummy stub
  2. T2: develop C with a test driver
  3. T3: integration test B and C (and possibly other modules) together (prerequisites T1 & T2)
Then the project manager will always know the status exactly.

But if either module is simple enough to develop in a few hours, it's still simpler just to make either T1 or T2 a prerequisite (finish-to-start) to the other.

Finally, some old-fashioned progammers will note that we could have avoided the question by specifying separate tasks for

But modern development environments make it more natural, more reliable, and more efficient to consider those as just integrated development. Experienced professionals know how meaningless it is to report that a program has been fully coded but not yet tested. In the course of unit testing, the programmer may make massive changes to the code, even redoing it entirely.

Taking a risk

There's no reason why a project team member, in the interest of compressing the schedule, can't start working on a task before some prerequisite task has been completed. But it is then understood that we're taking a risk hoping that when the prerequisite task produces its deliverables there will be no surprises. Such risk taking is common among experienced and responsible professionals, and is even encouraged by the so-called agile methodologies.

In the worst case, the premature effort will have to be redone, and the time charged to the task may exceed original estimates.


1—also called a "work breakdown structure" (WBS) in the project-management community.
2—I'm indebted to my colleague Joseph O'Brien who pointed out the need for this example.

Return to Management articles
IDI home page.

Last modified 4 December 2009