DEPENDENCIES AND CONSTRAINTS are two features in Microsoft Office Project 2007 most likely to drive the timing of your project; therefore both play a big role in the way your schedule reads. In this chapter, I’m going to explore a variety of topics concerning dependencies and constraints.
If you don’t use dependencies, Project assigns to every task a start date or a finish date that matches the project’s start date or finish date—the one you set up in the Project Information dialog box in the previous chapter. In such a scenario, calculating how long the project will take becomes a simple matter—the project will take as long to complete as the longest task in the project.
It’s highly unlikely, though, that all of your tasks will start and run simultaneously—this isn’t, after all, a horse race. So you should set dependencies to identify for Project the order in which tasks occur. Some tasks can run concurrently while other tasks run consecutively. Sometimes tasks can run concurrently, but you don’t have the resources to complete the tasks concurrently, so you need to set dependencies to identify which you’ll complete first. Essentially, by setting dependencies, you establish the timing logic of your project.
When you set dependencies, you link tasks. Don’t think, "computer linking" here; we’re not talking about hyperlinks. We’re talking instead about connecting two tasks in a timing relationship. Terminology alert: linking two tasks is synonymous with setting dependencies.
You might be tempted to set start dates for your tasks to identify timing for your project, but if you do, you undermine Project’s ability to adjust your project schedule when things change. And you know that conditions will change; that’s the way life is. To successfully manage your project under changing conditions, you need to be able to respond to change. If you set concrete start dates for your tasks and then run into a bump in the road, you need to adjust the start date of each affected task, effectively recalculating the schedule manually. But if you use dependencies to describe the timing of your project, you need to adjust only the task that falls behind schedule or finishes early; based on the dependencies you set, Project recalculates and adjusts the rest of the schedule.
Note
Setting start date constraints and other types of constraints can also have an unforeseen impact on your schedule by artificially inflating or understating the amount of time needed to complete the project. As a general rule of thumb, avoid setting constraints. (See "Working with Constraints" later in this chapter for more information about constraints.)
Every dependency relationship involves two tasks; one task serves as the predecessor task and the other serves as the successor task. In most cases, the predecessor task takes place before the successor task the way that the names imply, but there will be times when the timings of the two tasks overlap.
You can set one of four types of dependency relationships for each pair of tasks: finish-to-start, start-to-start, finish-to-finish, and start-to-finish. These dependencies describe the relationships between the start and finish of the predecessor and successor tasks; the first part of each type of dependency refers to the predecessor task, and the second to the successor task. So a finish-to-start dependency relates the finish of the predecessor task to the start of the successor.
Tip
Project refers to these relationships by their initials; for example, SS refers to a start-to-start relationship.
When you link tasks, Project draws arrows—also called link lines—between the tasks. As you view the figures that follow, take note of the position of the link line and the direction that the arrow points between tasks. The position of the link line provides important visual clues about the type of dependency that exists between the tasks, and the arrow’s direction provides important visual clues that help you identify the predecessor and successor tasks. For any type of relationship, the arrowhead points to the successor task.
A finish-to-start relationship is the most common type of dependency link. In this relationship, the predecessor task must finish before the successor task can start. For example, you must own and possess software before you can install it on a computer. You must get your medication from the drug store before you can take it.
Tip
The finish-to-start relationship is the only relationship that you can create by using your mouse or the Link Tasks tool or command.
In 2-1, Task 1 is the predecessor task and Task 2 is the successor task in a finish-to-start relationship. Similarly, Task 2 is the predecessor task and Task 3 is the successor task in another finish-to-start relationship. Notice that the link line starts at the finish of the predecessor task and connects to the start of the successor task.
In a start-to-start relationship, the successor can’t start until the predecessor starts. For example, suppose that you’re trimming the plants in your yard. You need to start trimming plants (Task 1) before you start picking up debris (Task 2). In 2-2, Task 1 is the predecessor task and Task 2 is the successor task in a start-to-start relationship. Notice that the link line starts at the beginning of the predecessor task and connects to the beginning of the successor task.
In the finish-to-finish dependency, the successor task can’t finish until the predecessor task finishes. For example, you have to wait until everyone finishes eating dinner (Task 1) before you can finish washing the dishes (Task 2). In 2-3, Task 1 is the predecessor task and Task 2 is the successor task in a finish-to-finish relationship. Notice that the link line starts at the finish of the predecessor task and connects to the finish of the successor task.
With the start-to-finish relationship, the successor task cannot finish until the predecessor task starts. Suppose, for example, that you’re building a house and you have Task 1, Receive Framing Materials, and Task 2, Assemble House Frame. You don’t need Task 1 to finish before beginning work on Task 2; you just need Task 1 to have started. In other words, you can always begin assembling the house frame even if all framing materials haven’t arrived, so long as you have some of the materials. You can’t finish Task 2 until Task 1 starts, so Task 1 is the predecessor task and Task 2 is the successor task. When you establish this kind of dependency, Project calculates the start date of the successor task by setting the finish date of the successor task equal to the start date of the predecessor task and then subtracting the duration of the successor task. 2-4 shows a start-to-finish relationship. Notice that the link line starts at the beginning of the predecessor task and connects to the finish of the successor task.
Figure 2-4. In the start-to-finish relationship, the successor task can’t finish until the predecessor task starts.
Note
There’s a fine line conceptually between finish-to-start relationships and start-to-finish relationships. For example, if you set up a finish-to-start relationship for the two tasks in the house-building project, you’d be saying that you couldn’t start assembling the frame until you received all the framing materials. In the start-to-finish relationship, you can’t finish assembling the frame until you start receiving the materials, but there’s the potential to do part of the assembly as you’re receiving materials—and you can make this kind of relationship visible using lead and lag time; see the section "What Are Lag and Lead Time?" later in this chapter for more information.
Setting a finish-to-start dependency is quick and easy; I like to use the Link Tasks button shown in the margin. Select the row number of the predecessor task. Then press and hold the Ctrl key while you click the row number of the successor task. When you click the Link Tasks button, Project creates a finish-to-start link. The order in which you select the tasks you want to link does matter; Project establishes the first task you select as the predecessor and the second task as the successor.
Tip
You can select as many tasks as you want to create dependency links. Project links the tasks in the order you select them.
If you prefer, you can create the links using the Predecessors column of the Gantt chart’s Entry table. 2-5 displays enough of the Entry table so that you can see the Predecessors column. To establish a link, click on the row of the successor task and, in the Predecessors column, type the row number of the predecessor task. If you want to create any relationship other than a finish-to-start relationship, also type the letters that abbreviate the relationship (such as SF for start-to-finish). In the figure, the relationship between Tasks 1 and 2 is a start-to-finish relationship, and the relationship between Tasks 3 and 4 is a finish-to-start relationship.
Some people find dialog boxes more reassuring to use. You can set a dependency on the Predecessors tab of the Task Information dialog box (see 2-6). Follow these steps:
You can use the Task Dependency dialog box to change the existing relationship between two tasks. Just double-click the link line between the two tasks to display this dialog box and make your changes.
See Also
Are you tempted to set dependencies using summary tasks? Please don’t. See the section "How Many Dependencies Are Too Many?" later in this chapter for more information.
Okay, so Project lets you define the relationship between two tasks using dependencies that relate the tasks using their start dates, finish dates, or some combination of the two dates. But how can you indicate that one task should start a short time after another task starts—not when the other task finishes or at the same time the other task starts? Essentially, how do you indicate delay time or overlap time—often called lag and lead time—between tasks?
Enter the Lag field in Project. It works in conjunction with the type of dependency you select to add delay or overlap time between tasks. To create lag or lead time, you work with the successor task and enter a positive or negative duration value in the Lag column of the Task Information dialog box or the Task Dependency dialog box. The trick is determining whether to enter a positive or a negative value to incorporate delay or overlap. With some dependency types, using a positive value adds delay, while in other cases it incorporates overlap. Let’s look at examples.
If you enter a positive value in the Lag column of a successor task that has a finish-to-start relationship with its predecessor, Project adds a delay to the start of the successor task and you see a gap between the end of the predecessor and the beginning of the successor. If you enter a negative value in the Lag column for the same type of relationship, Project adds overlap between the two tasks. In 2-7, I entered a positive value in the Lag column and incorporated lag time between Tasks 1 and 2, forcing Task 2’s start to be delayed two days after Task 1 finishes. Between Tasks 3 and 4, I entered a negative value in the Lag column and incorporated lead time that makes Tasks 3 and 4 overlap in timing, causing Task 4 to start while Task 3 is in progress.
But suppose that the relationship between the tasks is a start-to-start dependency. As you can see in 2-8, I entered a positive value in the Lag column for the first pair of tasks and a negative value in the Lag column for the second pair of tasks. A positive value in the Lag column of the successor task in a start-to-start dependency creates an overlap between the tasks, while a negative value creates a delay between the tasks.
In 2-9, the relationship between Tasks 1 and 2 and Tasks 3 and 4 is a finish-to-finish dependency. Again, I entered a positive value in the Lag column for the first pair of tasks and a negative value in the Lag column for the second pair of tasks. As you can see, a positive value in the Lag column of the successor task in a finish-to-finish relationship creates an overlap between the tasks, while a negative value creates a delay between the tasks.
I’ve repeated the experiment in 2-10, this time using a start-to-finish dependency between Tasks 1 and 2 and Tasks 3 and 4. I entered a positive value in the Lag column and incorporated overlap between Tasks 1 and 2, causing Task 2 to start while Task 1 is in progress. Between Tasks 3 and 4, I entered a negative value in the Lag column and incorporated delay time, forcing Task 3’s start to be delayed one day after Task 4 finishes.
Note
In situations where you want to build delay between two tasks, you can simply create a task that represents the delay. For example, suppose that you need two days after a conference ends to write up a report of the conference. You can add a delay between the Write Final Report task and its predecessor, the Conference task, using the Lag column of the Write Final Report task, or you can add a task between them, naming it something like Conference Wrap-Up, and give it a duration of two days. The method you choose is a matter of personal preference.
It’s quite possible to make one task the successor of many predecessors. Similarly, you can make one task the predecessor of many successor tasks. But you can get caught in the trap of over-thinking your dependencies.
Take a look at this simple example: Suppose that you need to photocopy, fold, and mail a flyer. You could create a finish-to-start dependency between the Photocopy task and the Mail task that indicates that you can’t mail the flyer before you photocopy it. But you don’t need that dependency.
If you set up a finish-to-start dependency between the Photocopy task and the Fold task, and another finish-to-start dependency between the Fold task and the Mail task, the dependency between the Photocopy and the Mail tasks is built into your schedule—you can’t mail the flyer before you photocopy it (see 2-11).
Also in the arena of avoiding too many dependencies, don’t create links between summary tasks or summary tasks and subtasks. Remember that summary tasks in Project are not productive tasks in and of themselves. Instead, they serve the purpose of providing a visual summary of the timing of the subtasks below them, along with a data summary of the cost of those subtasks.
Can you link summary tasks? That is, will Project let you link summary tasks? Project won’t stop you, but you shouldn’t. Why not? Many circular reference errors in Project ultimately are most often related to links between summary tasks and between subtasks below different summary tasks. The flow of your dependency logic can become very complex and even confusing, particularly if a summary task link conflicts with a subtask link. So, in general, avoid linking summary tasks. Just let them serve their intended purpose: to summarize.