Task Dependencies

Developing a functional schedule requires that tasks have dependencies.  That means they have relationships to one another, they are not orphans adrift at sea.

All Tasks Should have a Dependency

The Project Management Body of Knowledge (PMBOK) states that all tasks should have a dependency.  This is because by definition, if a task is part of a project it must be related to other tasks in some way.  For example, the Eat Dinner task cannot start until Cooking is complete.

Of course, it is possible to draw a graphical schedule containing a bunch of tasks without any relationships between them, but this is a hypothetical scheduling exercise.  Professional project management requires the rapid determination of schedule impact from the many situations that occur during the project (not to mention effective project control).  Put another way, if you cannot answer the following questions you haven’t used project scheduling to its full capability:

• Which tasks are on the critical path?  (i.e. their delay will extend the overall completion date)
• If a task duration changes, what is the impact on the overall completion date?

Since projects are always changing and monkey wrenches have a pesky way of getting into the best laid plans, it is important to have a realistic and achievable schedule.  Which means the tasks should have relationships to one another.

Types of Dependencies

There are four types of dependencies, and each one has its own specific area of application.

• Finish-to-Start
• Finish-to-Finish
• Start-to-Start
• Start-to-Finish

Finish-to-Start (FS)

In this relationship, task B cannot start until task A finishes.

This is the most common scenario and in the absence of any other criteria, all tasks could have this dependency in order to produce a functioning schedule.

For example,

• “You can’t pour the concrete until the forms are built”
• “You can’t assemble the turbine until the bearings are replaced”
• “Supper cannot start until the cooking is complete”

Finish-to-Finish (FF)

In this relationship, task B cannot finish until task A finishes.

For example,

• “Fracking cannot finish until pressure testing is complete”
• “Electrical work cannot finish until drywalling is complete.”
• “Design work cannot finish until environmental studies are complete”

Start-to-Start

In this relationship, task B cannot start until task A starts.

For example,

• “Mixing of chemicals cannot start until air quality testing starts”
• “In-stream work cannot start until turbidity monitoring starts”
• “You can’t start up the machine until the pollution testing starts”

Start-to-Finish

In this relationship, task B cannot finish until task A starts.

This is a rare relationship but it happens:

• “Concrete Pouring cannot finish until Heating has started”
• “Transportation of Materials cannot finish until Overnight Security starts”
• “Inspection cannot finish until Client Review starts”

Each task should have two relationships:

1. Predecessor with an FS or SS relationship.
2. Successor with an FS or FF relationship.

Dependencies Example

In a hypothetical house building project, the dependencies would be listed on a predecessor table, like this:

	Task	Predecessors
Design
1.1	Decide on Plans
1.2	Make Changes to Plans	1.1
Structural
2.1	Excavation & Levelling	1.2
2.2	Pour Foundation	2.1
2.3	Framing	2.2
Utilities
3.1	Plumbing	2.3
3.2	Electrical	2.3
3.3	HVAC	2.3
Finishing
4.1	Drywalling	3.1, 3.2, 3.3
4.2	Painting	4.1
4.3	Finishing Carpentry	4.2
4.4	Carpet	4.3
4.5	Windows	2.3
4.6	Roofing & Siding	2.3
4.7	Landscaping & Driveway	2.3

Notice a few things:

• The utitilies (3.1, 3.2, and 3.3) can all happen simultaneously.  Each one is dependent only on the framing (2.3) being complete.
• Drywalling, (4.1) requires only that the utilities are complete, because it will cover them up.
• The last three tasks, windows, roofing, and landscaping, might be at the bottom of the list, but they are dependent only on the framing (2.3) thus they could be completed fairly early on in the overall process.  In other words, they will probably have “high float” (we will calculate this later).

Mandatory vs. Discretionary Dependencies

Until now we have dealt only with mandatory dependencies, which is when the task relationships are physically absolute, or mandated by contractual or legal requirements.  You can also define discretionary dependencies, in which the relationship is not set in stone.  Why would you want to do that?

• There is a bonus for early completion.
• The early completion of a report is preferred by management but they would accept a later “minimum completion date.”
• The project’s resources are required by another project thus early completion is important.

Using most project management software you can specify dicretionary dependencies and monitor progress against a “preferred” versus a mandatory schedule.

External vs. Internal Dependencies

Dependencies also fall under the categories of Internal vs. External.

• Internal Dependency:  A task relationship between two tasks within the same project.
• External Dependency:  A task relationship between two tasks within different projects.

External dependencies should be avoided.  Many projects require approval from regulatory agencies or other external parties, and the addition of a task, let’s say “Environmental Review” or similar places the project in the unenviable position of being dependent on a third party.  You have to put a duration on the task, but how are you to know how long it will take the third party that has little interest in your project’s completion date?

Unfortunately this is a common situation and the duration must be estimated conservatively with, hopefully, expert advice.  During the project the third party task must be monitored.  When they miss their deadline the schedule must be changed immediately (multiple times if necessary), not when they finally come around to performing the task.

Leads and Lags

Sometimes there need to be gaps between tasks.

• A lead time is the amount of time that a task can be advanced relative to its relationship with a predecessory activity.  For example, landscaping can begin 5 days before the framing is complete.  This would be an FS relationship with a lead time of 5 days.
• A lag time is the amount of time between tasks before a task can begin.  For example, framing cannot begin until the concrete foundation has cured for 10 days.  This would be represented with an FS relationships between Pour Foundation and Framing, with a lag time of 10 days.

In theory, leads and lags are the same thing except for the direction from the reference point.  A lead is simply a negative lag, and vice versa.  It’s like using the identical terms height and depth.  In Project management software, you often have to enter leads as negative lags, because lags are more common.