The Relationship Diagram view (see 5-3) and the Network Diagram view (see 5-4) focus on the dependencies between tasks, helping you focus on identifying task dependencies. The Relationship Diagram view displays only task names, task ID numbers, and link lines that include designations for the type of dependency that exists between two tasks. In 5-3, the FS that appears on the link lines of the five tasks on the right stands for "finish-to-start" and means that none of the five tasks on the right can begin until the task on the left ends.

Figure 5-3. The Relationship Diagram view helps you focus on dependencies between tasks.

In addition to focusing on task dependencies, the Network Diagram view displays critical tasks in red, making them easy to identify, and provides details such as the start and finish dates and the duration for each task.

Figure 5-4. The Network Diagram view identifies critical tasks and displays basic details about each task.

You also can take advantage of Project’s Task Drivers pane to help you quickly and easily identify task predecessors and successors; the Task Drivers pane can be particularly helpful when you’ve got a lot of dependency links in your project. The Task Drivers pane identifies for the selected task the factors that, well, drive the task: the ID and name of the selected task, its start date, subtasks, predecessors, resources, and task or resource calendars associated with the task. To display the Task Drivers pane, on the Project menu, click Task Drivers. Project adds the Task Drivers pane to the left side of any task-oriented view (see 5-5).

Figure 5-5. The Task Drivers pane can help you identify task relationships.

In the Task Drivers pane, you also see predecessor information that identifies the task type of the predecessor as well as any lag time. If you’ve entered any actual information, such as the actual start date, that information also appears in the Task Drivers pane.

The task type you select when you create a task affects the way Project calculates the project schedule. In some cases, adding resources changes the way Project handles the scheduling of the task, while in other cases, adding resources doesn’t affect Project’s calculation of the schedule.

By default, when you create a task, Project creates a fixed units task. When you assign a resource to a fixed units task, you specify the assignment as a percentage, such as "100%" for full-time or "25%" for one quarter of the resource’s time. For fixed units tasks, Project doesn’t change the assignment percentage if you change the duration of the task.

In 5-6, I’ve assigned Resource 1 to work half-time on Task 1, which is a 10-day fixed units task. In 5-7, I’ve changed the duration of Task 1; notice that Project doesn’t change the half-time work assignment of Resource 1.

Figure 5-6. A fixed units task with a resource assigned to work half-time on the task.

Figure 5-7. The assignment percentage doesn’t change when you change the duration of a fixed units task.

When you use a fixed duration task, you indicate that a task will take a particular amount of time, regardless of the number of resources working on the task. When you pour a concrete slab foundation for a house, the concrete needs a specified amount of time to cure before you can proceed to frame the house. In 5-8, I’ve set up a five-day fixed duration task and assigned Resource 1 to it. In 5-9, I’ve added Resource 2 to the task; because the duration is fixed, Project doesn’t change the five-day period needed to accomplish the task.

Figure 5-8. A five-day fixed duration task with one resource assigned.

Figure 5-9. When you assign a second resource to a fixed duration task, Project adjusts the resource assignment value of the first resource but doesn’t change the task’s duration.

When you create a fixed work task, you supply a duration that represents the total amount of work needed to complete the task. When you assign a resource to that task at a particular assignment percentage level, Project assumes that the task requires that level of effort to complete in the time you specified as the duration. For example, if you create a fixed work task that takes eight days to complete, and you assign one resource to work full-time on the task, Project calculates that the task will be completed in eight days. If you initially assign one resource to the task to work half-time on an eight-day task, Project assumes that the task requires eight days for a resource working half-time to complete it. In either case, if you assign a second resource to work on the task using the same effort level as the first resource, Project reduces the amount of time needed to complete the task to half the initial amount required. The amount of work required to complete the task doesn’t change, but the duration of the task does. In 5-10, I’ve created two fixed work tasks that are each eight days long. I assigned Resource 1 to work full-time on the first task and Resource 2 to work half-time on the second task.

Figure 5-10. Two fixed work tasks.

In 5-11, I have assigned a second resource to each task; in each case, the second resource is providing the same level of effort as the first resource. Note that Project reduces the duration of both tasks to four days. If I had assigned the second resource using a different level of effort, Project would have adjusted the duration of the task accordingly without changing the amount of work required to complete the task.

Figure 5-11. The duration of a fixed work task changes when you add resources to it.

In 5-12, I have displayed the Task Usage view of this project; notice that Task 1 still requires 64 hours of work (eight days) to complete, although I’ve assigned two resources and, as shown in 5-11, the task will finish in four days. Similarly, Task 2 still requires 32 hours of work to complete (eight days at half-time or four hours per day).

Figure 5-12. The amount of work required doesn’t change when you add resources to a fixed work task, even though Project reduces the task’s duration.

An effort-driven task is one that is affected by the number of resources you assign to it. By default, all fixed work tasks are effort-driven and you can’t change that behavior. If it takes one person an hour to wash a car, this fixed work, effort-driven task could be accomplished by two people in half the time, assuming they don’t stop for a water fight.

In the preceding section, you saw how changing the duration of a fixed units task did not change the amount of effort assigned to a resource working on the task. When you create a fixed units, effort-driven task, the same rule holds true; Project doesn’t change the effort level you assign to the resources. However, Project does change the duration of the task. In 5-13, I’ve created a fixed units, effort-driven task that is four days in duration, and I’ve assigned Resource 1 to work on the task half-time.

Figure 5-13. A fixed units, effort-driven task with a resource assigned at half-time.

In 5-14, I’ve added another resource to work on the task half-time, and Project has reduced the duration of the task by half, because two people can accomplish in half the time what one person accomplishes in the originally specified duration. If I were to change the duration of that task by simply typing a new duration, Project would not change the assignment level of either resource.

Figure 5-14. Adding a resource to a fixed units, effort-driven task reduces the duration of the task without reducing the amount of work required to complete the task.

When you change the number of resources assigned to a fixed duration, effort-driven task, Project modifies the percentage of total work allocated to each resource working on the task but doesn’t change the amount of work that’s required to complete the task. In 5-15, I’ve created a four-day fixed duration, effort-driven task and assigned Resource 1 to work on the task full-time.

Figure 5-15. A four-day fixed duration, effort-driven task with one resource assigned full-time.

In 5-16, I’ve added another resource to work on the task full-time. In this case, Project doesn’t change the duration of the task, but Project reduces the amount of the assignment of each resource to 50 percent, indicating that two resources can accomplish the same amount of work by working half the time for the duration of the task that one resource can accomplish by working full-time for the duration of the task.

Figure 5-16. When you add a resource to an effort-driven, fixed duration task, Project reduces the amount of effort required from all resources assigned to the task.

By default, Project creates fixed units, effort-driven tasks. And all fixed work tasks are effort-driven by default. To create a fixed duration task that is also effort-driven, double-click the task in question to display the Task Information dialog box for that task. Then click the Advanced tab and select the Effort Driven check box (see 5-17).

Figure 5-17. Use the Task Information dialog box to create a fixed duration, effort-driven task.

Back in 3, I explained that resource calendars help you establish availability for a resource. Using a resource calendar, you can assign a resource to a task and Project won’t plan the resource to work when the resource isn’t available. In essence, a resource calendar provides a way to make exceptions to the ordinary working schedule on a resource-by-resource basis.

Task calendars work in much the same way. You can create a task calendar and assign it to a task to ensure that Project doesn’t allow the task to be scheduled during a period of non-working time or to make non-working time be working time for a particular task. Suppose, for example, that your project uses the Standard calendar, which designates Monday through Friday, 8:00 A.M. to 5:00 P.M., as working time. Further suppose that one task in your project involves performing routine maintenance on equipment. If you perform the routine maintenance during regular business hours, all work stops because the equipment isn’t available. However, if you perform the routine maintenance at night, when most people don’t work, you get the job done without impacting the work of others on your project. In this case, you’d create a calendar for the Equipment Maintenance task and set working hours on the calendar from 5:00 P.M. to 8:00 A.M.

When you create a new calendar, you can base it on one of the existing calendars: the Standard calendar, the Night Shift calendar, or the 24 Hours calendar. Or you can create a new base calendar; when you do, Project assigns the Standard calendar settings to your new calendar and you can change them. To create a new calendar, on the Tools menu, click Change Working Time to display the Change Working Time dialog box (see 5-18).

Figure 5-18. Begin the process of creating a new calendar in the Change Working Time dialog box.

Click the Create New Calendar button to display the Create New Base Calendar dialog box (see 5-19).

Figure 5-19. Use this dialog box to create a new calendar.

In the Name box, type a name for the calendar you want to create. If you want to use one of the existing base calendars as your model, select the Make A Copy Of option and click the base calendar in the list. When you click OK, Project displays the Change Working Time dialog box again, and your new calendar’s name appears in the For Calendar list.

Once you’ve set up your calendar, you need to assign it to the appropriate task in your project. Double-click the task to display the Task Information dialog box. Click the Advanced tab, and select from the Calendar list the calendar you want to assign to your task (see 5-20). Click OK, and you’re done.

Figure 5-20. Assign a calendar to a task.

In addition to using task duration, dependencies, and calendars to determine the timing of a task, Project also uses constraints. Unlike dependencies, which tie the timing of one task to the timing of another task, constraints tie the timing of a task to the start or end of your project or to a specific date. Every time you set a start date for a task, you create a Start No Earlier Than constraint, assuming that you set your project to schedule from the project start date. By default, Project honors constraints over dependencies, so if you set that start date, Project won’t let the task start until the date you select. Essentially, Project can’t adjust your schedule automatically when you use constraints. In addition, when you use constraints, you will in all probability understate or overstate the amount of time needed to complete a project. Suppose that you have two tasks linked together with a finish-to-start dependency—Task 1 and Task 2—and Task 2 needs to start after you finish Task 1. If you set a start date for Task 2 of, say, October 15, and then realize that Task 1 will be able to finish on October 10, your schedule is automatically five days longer than it needs to be. But what happens if Task 1 won’t be able to finish until October 20? Now your schedule is actually five days shorter than it needs to be.

Although you can change Project’s behavior and remove the requirement to honor constraints over dependencies, in general you’ll find that you produce better project schedules using dependencies over constraints because Project can adjust your schedule automatically when conditions change and you’ve used only dependencies. If you had simply set a finish-to-start dependency between the two tasks in the example, Project would have automatically adjusted the start date of Task 2 for you, based on the finish date of Task 1.

There are times when you need to use a constraint. But you also can minimize your use of constraints by simulating constraints using dependencies.

For example, suppose that you’re closing the local office and offering severance packages to employees who don’t relocate to the company headquarters in Houston. You need to identify the type of financial offer you will make to those who choose to leave the company. You also need to identify the type of financial offer that you’ll make to those who decide to relocate; for example, you need to decide how you want to handle moving expenses and how involved you will be in an employee’s effort to sell a local home. If you plan to offer moving and home sale benefits, you need to work out details; you might, for example, identify the mover and the real estate agency you want employees to use.

Because you understand the emotional upheaval this decision will cause, you want to be as fair as possible to your employees and give them as much time as possible to make their decisions. Essentially, you want to set up the tasks that lead up to requiring a response from your employees to end as late as possible.

Although you might be tempted to use As Late As Possible (ALAP) constraints in your schedule, you can avoid the problems associated with using constraints by minimizing them. In 5-21, I’ve set up a sample schedule that uses start-to-finish dependencies to model this "just in time" scenario; this approach avoids using ALAP constraints.

Figure 5-21. Using start-to-finish dependencies to create a "just in time" scenario.

Task 7 is the only task that uses a constraint; in this example, I used a Must Finish On constraint. But before I set that constraint, I set up Tasks 3 through 6, setting their durations, and created start-to-finish relationships between them. That approach says, essentially, that Task 4 won’t start until Task 3 finishes. Project calculated the finish date for each task based on its duration. When I set up Task 7, I used its calculated finish date as the Must Finish On constraint date.

Yes, I could have linked Tasks 3 through 6 in finish-to-start relationships and then set constraints on them to make them finish as late as possible, but I chose the alternate approach of using start-to-finish relationships because there are times when the late finish date that Project calculates for an ALAP task may actually be later than its successor tasks’ dates, and then the dependencies won’t hold true because Project honors constraints over dependencies. By using start-to-finish relationships, I achieve the same result as using the ALAP constraint, but my schedule isn’t subject to the issues that ALAP constraints can add.