Schedule Relationships

A previous article described the steps to take to produce a work breakdown structure (WBS) and then maintain it. This article takes the process one step further by assigning precedence relationships to the activities in the WBS. Establishment of these relationships is a critical step towards creating the project schedule, and is what define the project’s critical path.

This article assumes that you are using a project management tool such as MS Project, or other tool, to create your schedule. Attempting to plan, monitor and control anything but the simplest software development project without the aid of tools would be impossible.

The breaking down of the work to be done and its entry into your Project Management tool must be complete before you start defining relationships. Ensure that you have identified the correct activities to relate. It’s worth a review of the WBS with your Subject Matter Experts (SMEs) on the software development team before proceeding to defining relationships. Each activity in the WBS should support a work package mentioned in the Statement of Work (SOW), the Project Charter, or the Scope Statement. It should be a description of work that has a start and end date that you intend to use to measure progress. It should be as granular as you need to properly oversee the work, but no more.

Types of Dependencies

There are a number of different dependencies that can be defined in your project management tool. Most of these will not be of any use to you, so won’t be covered in this article. The ones that you will find useful are defined as follows:

1. Activity A must complete before Activity B can start
2. Activity A must start before Activity B can start, or Activity B cannot finish until Activity A finishes

Type 1 is used when you define a "hard” dependency; that is a dependency describing the physical dependency of one activity on another. There aren’t that many "hard” dependencies in a software development project. The dependency of Quality Assurance (QA) testing on completed coding is one example of such a dependency. The dependency of that testing on a code walkthrough is an example of a "soft” dependency. You may choose to use type 1 to define the soft dependency described in the example, but be prepared to change the relationship to the second type if you need to compress the schedule.

Lag and Lead Times

Lag time is the amount of time that must pass before an activity can start. The best example of a lag time is the time that must be allowed for concrete to cure after it is poured. There is a hard dependency on the beginning of framing on the pouring of the building foundation but this doesn’t take into account the time required for the concrete to cure. A lead time is the amount of time that one activity can precede the other. For example, you may want to remove the hard dependency between the completion of design review and the beginning of coding, but still want to place some restrictions on how much time a developer can spend coding based on an unapproved design. Lag and lead times are usually not assigned until activities are scheduled. The exception to this rule is when you want to define type 2 activities and place a restriction on the amount of time one can lead the other.

Identifying Dependencies

The first rule in defining dependencies in your project management tool is to use this feature sparingly! Dependencies not only have to be there, they have to help you control the project or else they shouldn’t be defined. The reason I say this is because you can very easily become overwhelmed by a WBS with too many dependencies. A common symptom of over-definition is when a change to a forecast completion date for an activity not on the critical path causes the project end date to slip when it shouldn’t. Now you’ve got to trace that date through your WBS until you find the offending dependency, and then correct it.

Identify the dependency at the correct level and remember that all the children inherit parent dependencies. Also, all the child activities of a parent work package must be complete before the parent can appear as complete. This may establish default relationships you hadn’t anticipated. Let’s look at a software application using a relational database to store and retrieve data. Making completion of a login function dependent upon the completion of the database data dictionary would prevent work on the login function from starting before the last product is defined in the database. A better relationship would be between completion of the login function and completion of the userid, password, and privileges tables (a finish to finish relationship).

Look for those dependencies that are well defined and will help you manage your schedule. Good examples of these are the dependency on the Detail Design Document review on the completion of the Detail Design Document, or the code walkthrough on the completion of coding, or the completion of the build before QA testing. These are all examples of Type 1 dependencies where it isn’t possible to begin the succeeding activity until the preceding activity is complete. You can define Type 2 dependencies if you feel these will help you control your schedule. For example, defining a dependency between your design review and the start of coding. There is no harm in defining "soft” dependencies as long as you can distinguish the soft dependencies from the hard when you want to compress your schedule.

Avoid hanging multiple dependencies on any single activity or milestone. Your Gate Review, Phase Exit Review, or Business Decision Point meetings should not be dependent on every single deliverable in the phase. Likewise, all the work in the next phase should not be dependent on the meeting.

Your final project milestone, denoting the completion of the project, is one item that must have at least one preceding activity it is dependent on. Without this dependency relationship there can be no path to completion and no critical path. A change in the forecast completion date of any activity in the schedule will not bring about a change in the project completion date.