Types of Task Dependencies

In project management, all tasks have dependencies. If they didn’t they wouldn’t be part of the project.

That is, a task that doesn’t need to be completed in order to finish the project is not part of the project. It’s an orphan adrift at sea.

There are four types of task dependencies, and each one has its own specific reason why you would use it.

1. Finish-to-Start
2. Finish-to-Finish
3. Start-to-Start
4. 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,

• “Supper starts when the cooking is complete”
• “Concrete pouring starts after the forms are built”
• “Wind turbine assembly starts after the gear shaft is replaced”

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.

The Critical Path Method

Once all the tasks in the project have their relationships established, the critical path method can be used to determine the minimum and maximum project completion dates, as well as float times for each task.  Task floats allow the project manager to see how far ahead or behind schedule a task can be without affecting the overall completion date.

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 discretionary 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” 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 whether you meet your project’s schedule or budget?

Unfortunately this is a common situation and the budget and duration (and any other project ramifications) must be estimated conservatively with appropriate contingencies.  During the project the third party task must be actively managed.  When they miss their deadline and cause the project to change, the resulting changes must be communicated to stakeholders expeditiously.

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.

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.