Establishing Dependencies

Establishing Dependencies

You can't put on the roof until the walls are built. In other words, putting on the roof depends upon having built the walls. Planning requires more than a list of activities; it means knowing the order in which the activities must be carried out. That order is dictated by the dependencies.

A dependency is a relationship between two activities in which one activity cannot start or end until the other has started or ended. Dependencies exist only between work activities; they do not apply to distributed or overhead activities, or to cost components.

A dependency applies to just two activities; there are no threeway or four-way dependencies. However, any given activity may participate in more than one dependency.

When one activity is dependent upon another, the dependent activity is called the successor and the activity upon which the successor depends is called the predecessor. That is, the successor depends uponor, more properly, has a dependency onthe predecessor. Note that ''successor" and "predecessor" describe a dependency relationship, not an order in which activities are carried out. While a successor usually follows its predecessor, the two are frequently concurrent, and the successor may actually come first.

Do not describe dependencies ambiguously. The statement, "There is a dependency between design and coding" does not indicate whether design is dependent upon coding or vice versa. A clear statement of dependency is "Coding is dependent upon design" or "Coding has a dependency upon design."

There are four types of dependency between activities: finish start, finish finish, start finish, and start start. There are also two time components: lag and lead.

Finish Start Dependencies

Finishstart (F-S) dependencies are the most common: The predecessor must finish before the successor can start. With F-S dependencies, the successor always follows the predecessor.

As an example, detailed design (the predecessor) must finish before program coding (the successor) can start. Hence program coding has a finishstart dependency upon detailed design.

FinishFinish Dependencies

With a finishfinish (F-F) dependency, the predecessor must finish before the successor finishes. With F-F dependencies, the predecessor need not precede the successor, but it must finish first.

As an example, systems documentation (the successor) must reflect program coding (the predecessor); hence, although it can start any time that coding is in progress, it cannot finish until coding finishes. Hence, systems documentation has a finish-finish dependency on program coding.

StartStart Dependencies

In a startstart (S-S) dependency, the predecessor must start before the successor can start. With S-S dependencies, the successor and predecessor usually overlap.

An example is information gathering and the preparation of the data model. The information gathering (the predecessor) must start before data modeling (the successor) can start. Hence, data modeling has a start-start dependency upon information gathering.

StartFinish Dependencies

With a start-finish (S-F) dependency, the predecessor must start before the successor can finish. With S-F dependencies, the successor and predecessor may overlap, but the predecessor usually follows the successor.

This type of dependency is rare, but an example is installation of a development environment where the purchase order specifies that final acceptance will follow an evaluation period consisting of training, consulting, and live development. In this case, installation will be decomposed into two activities, setup and acceptance, both of which will have a dependency relationship with the evaluation of the environment. However, the evaluation will continue after acceptance. In this case, the predecessor (evaluation) must start before the successor (acceptance) can finish, and will therefore have a startfinish dependency on development. (Development, in turn, will have a finishstart dependency on setup.)

Exhibit 4.15 illustrates the four types of dependency and the relationships between predecessors and successors. The arrow entitled "permissible" indicates when, in relation to the predecessor, the successor may be carried out. For example, the permissible arrow for a finishstart relationship indicates that the successor can start (S) any time after the predecessor finishes, but not before.

Lag and Lead Times

Not all dependencies are immediate; you may have finished pouring the foundation, but you can't start building the walls until the concrete has set. A lag time is a period between the start or finish of a predecessor and the start or finish of the successor. Conversely, a lead time is an overlap between dependencies.

Lag and lead times are not optional slippages, they are demanded by the nature of the activities. For example, installation of equipment has a finishstart dependency upon the issuing of a purchase order, but installation (the successor) cannot start until the equipment is actually delivered. Delivery lags the issuing of the purchase order (the predecessor) by the time that the vendor needs to receive the purchase order, process it, and physically deliver the equipment. Thus, installation has a finish-start lag dependency on the issuing of the purchase order.

An example of a lead time is program coding, which is finishstart dependent upon completion of programming standards. You may decide to prepare a draft set of standards, then begin coding before the standards have been approved. If the final approvals and revisions will take two weeks, you will be able to overlap coding and standards by that amount, giving coding (the successor) a finish-start lead dependency on programming standards (the predecessor).

Lead and lag times, combined with the four types of dependency, become complex, and some will probably never occur. Exhibit 4.16 is a summary of the dependency types and time components. The table assumes that lag and lead times are stated as n days.

One important principle is that dependencies are based on activities, not resources. For example, coding is dependent upon design because coding cannot start until design is complete, not because the same person will do both. When you are defining dependencies, assume that you have unlimited resources. You will get to play with people availability later.

Dependencies complicate project plans. Indeed, one time-honored way of compressing a schedule is to remove some dependencies, increasing the overlap among activities. As a general rule, ensure that dependencies are real; that is, activity B absolutely cannot start until activity A is finished. If B "should not" start until A is finished, or if it is "a good idea" to finish A before starting B, there is no dependency. A dependency may be physical (development cannot start until workstations are installed) or methodological (coding cannot start until design has been approved), but it must always be unyieldingat least at the time of planning.

Frequently, activities are dependent, but there is an intervening dependency. For example, consider a project with the following dependencies:

Systems integration is dependent upon installation of hardware.

In this example, the tendency is not to enter the dependency because it is irrelevantthe predecessor will finish long before the successor starts. However, this is a mistake. If you do not enter the dependency and hardware installation slips by four months, you risk not noticing the impact on your project until it is too late. If you enter the dependencies, you will always be aware of the results of any significant changes in the schedule.

Precedence Diagramming

A precedence diagram is a picture of the dependency relationships. Some project managers feel that precedence diagrams are an essential planning tool, while others regard them as a waste of time. As a visual presentation of the dependencies, these diagrams are useful in conducting reviews or identifying erroneous or invalid dependencies, and they certainly make impressive wall displays of project complexity.

Volumes have been written about types of precedence diagramming. Career positions have been staked out based on such esoterica as whether an activity should be on an arrow or a node. Fortunately, the advent of project management software, which imposes a particular type of precedence diagram, has made such debates irrelevant, and precedence diagrams, in whatever format the software allows, can now be created with a few keystrokes.

What If?

Your Dependencies Are Challenged.

Dependencies are the core of the schedule. Without them, everything could be done at once, and no project would exceed the longest activity. If your dependencies are not correct, your schedule will be inaccurate. If there are too many dependencies, the schedule will be longer than necessary. If there are too few, the schedule will not be capable of being met.

Actions

Review the challenge. If it makes sense, alter your dependencies accordingly; otherwise, leave the schedule as is.

If the dependency that is being challenged is methodological, ask the challenger to commit to relieving the dependency. For example, if you are told, "We don't need to wait for approval of the design before we start coding," and the methodology says that you do, ask the challenger for a commitment to allow a deviation from the methodology for this project. If you do not receive one, stick with your original plan.