CHAPTER 7
Scheduling Activities

THE CRITICAL PATH IS THE PATH through the network diagram (see Chapter 5) that takes the longest total time. It therefore determines the earliest possible time the project can be completed. The critical path is a network analysis technique used to determine the amount of scheduling flexibility (or total float) on each of the various network paths in the project schedule and to determine the overall project duration. Activities on the critical path are not inherently more important than other activities in the project, but they are more critical to the overall project schedule, because any delay in them will delay the completion of the entire project unless other adjustments are made. The critical path allows the project manager to understand which activities have schedule flexibility and which do not.

Scheduling Activity Dates

The critical path method calculates the following dates for each activity:

Early Start: the earliest date the activity can begin

Late Start: the latest date the activity can begin and still allow the project to be completed on time

Early Finish: the earliest date the activity can end

Late Finish: the latest date the activity can end and still allow the project to be completed on time

Project management software is commonly used for critical path calculations. Once you enter the activity durations and preceding activities, the program determines the critical path and the early start, early finish, late start, and late finish dates. This saves significant time creating the original schedule and subsequent reschedules. The following sections explain how these values are calculated manually in a two-step process with a forward pass and a backward pass.

Forward Pass

A forward pass calculates the early start and early finish, which are the earliest points in time an activity can start and finish, respectively. To compute these figures, start from the left side (the project start) of a network diagram and continue to ask yourself as you proceed incrementally to the right, “What is the earliest time I can start and finish an activity?” Using Figure 7-1, follow these four steps:

1. Start the project on the beginning of day zero. Therefore, the earliest time the first activity (WP 1.1) can start is day zero.

2. Add the duration of that activity to the early start to determine the earliest time the activity can finish (WP 1.1 has a duration of five days; therefore, the early finish is the beginning of day five).

Figure 7-1 Network Diagram Solution.

3. The early start for WP 1.2, WP 1.3, and WP 1.5 is, therefore, the beginning of day five. Repeat the step 2 process for each of those work packages. Proceed from left to right.

4. Work package 1.9 must wait for WP 1.5, WP 1.7, and WP 1.8 to complete before it can start. The earliest time WP 1.9 can start is day twenty-two.

Backward Pass

Determining late start and late finish is done in exactly the opposite way as was done to determine early start and early finish. Instead of proceeding from left to right, we proceed from right to left. And instead of asking, “What is the earliest time we can start the activity?” we ask, “What is the latest time we can finish the activity without delaying the project?” Follow these five steps to conduct a backward pass:

1. Start at the end of the project. Because WP 1.9 must be complete to end the project, we ask, “What is the latest time we can finish WP 1.9 without delaying the project?” The answer is day twenty-seven—the end date of the project.

2. Because we’ve determined when the work package will end, we compute the late start by subtracting the duration. For WP 1.9: 27 – 5 = 22.

3. Continuing from right to left, work packages 1.5, 1.7, and 1.8 must finish before WP 1.9 can start. Therefore, we ask, “What is the latest time we can finish these WPs without delaying WP 1.9?” The answer is day twenty-two. Therefore, the late finish for these work packages is day twenty-two.

4. Continue the same process moving right to left for work packages 1.4, 1.2, 1.6, and 1.3.

5. WP 1.1 must complete before WP 1.2, WP 1.3, and WP 1.5 can start. The latest time that WP 1.1 can finish, therefore, is the earliest late-start time of these three work packages. Therefore, WP 1.1 must complete by day five (see WP 1.3). The late start for WP 1.1 is then computed to be day zero.

Project Float

The term float (also known as slack) refers to the amount of time an activity can slip without affecting the project end date. Mathematically, it is the difference between the early finish and late finish. For activities on the critical path, the early and late start (and early and late finish) are the same, and therefore they have zero float. Free float is the amount of time an activity can be delayed without affecting any successor.

Accelerating Project Schedules

If the schedule you develop does not allow the project to complete when desired, you may have to take action to decrease the total project duration. Compressing (accelerating) the schedule is referred to as crashing the schedule. When attempting to crash a schedule, you should consider all the available options and choose those that provide the greatest compression for the lowest cost. Concentrate on the activities on the critical path. (Remember, shortening noncritical activities will not complete the project any sooner.) Focus first on activities that occur early in the project and also those with the longest durations.

Resources

One way to crash a schedule is to change the way resources are applied to the project. The following are some options to consider:

Relieve employees of other responsibilities to allow them to devote more hours each day to the project.

Reallocate resources from noncritical activities to provide the extra help you need. After you reassign the resources, check to see if the critical path has shifted to include other activities.

Add resources to provide additional staff, overtime, additional equipment, vendor incentives to complete sooner, or the ability to outsource. Make wise choices because adding too many resources can cause problems in communication and interpersonal relations.

Reserve overtime as a contingency. Rather than scheduling overtime in the original plan, keep it as a contingency for unforeseen problems. Overtime is not as effective as regular work hours. Studies show that twelve hours of overtime by a knowledge worker increases actual output only by the equivalent of two hours of regular work. Overtime might be useful if a small increment (three to four days) will make a difference in the project, if the staff is able to see light at the end of the tunnel, and if extra money represents an incentive to them.

Activities

Another way to crash a schedule is to change the sequence of activities or reevaluate their estimates. The following are some options to consider:

Fast-track the project by changing the sequence of activities in the network diagram to allow activities to be done in parallel (at the same time) rather than in sequence (one after another) or to allow some to overlap (for example, starting to write code on a software project before the entire design is complete). Fast-tracking usually increases risk.

Reconsider the accuracy of the estimates for activities on the critical path. However, do not arbitrarily reduce the estimates to fit the time available.

Project Objectives

A third way to crash a schedule is to modify the project objectives. The following are some options to consider:

Rethink the basic strategy to determine better ways to accomplish the same objectives.

Renegotiate the project objectives. Reduce the scope, increase the budget, or increase the time.

If the schedule still won’t work, readdress the basic problem or opportunity to verify that it warrants the effort it will take to complete the project.