by Conrad Weisert
©2009, Information Disciplines, Inc.
This article may be circulated freely, as long as the copyright credit is included.
November 22, 2009
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.
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.
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.
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
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:
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.
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