Schedule Computations

Normally, you would let a computer do these computations for you, so you may wonder why it is necessary to know how to do them manually. My belief is that unless you know how the computations are done, you do not fully understand the meanings of float, early and late dates, and so on. Further, you can easily fall prey to the garbage-in, garbage-out malady. So here is a brief treatment of how the calculations are done by the computer. (For most schedules, the computer has the added bonus of converting times to calendar dates, which is no easy task to do manually.)

First, consider what we want to know about the project. If it starts at some time = zero, we want to know how soon it can be finished. Naturally, in most actual work projects, we have been told when we must be finished. That is, the end date is dictated. Furthermore, the start date for the job is often constrained for some reason: resources won’t be available, specs won’t be written, or another project won’t be finished until that time. So scheduling usually means trying to fit the work between two fixed points in time. Whatever the case, we still want to know how long the project will take to complete; if it won’t fit into the required time frame, then we will have to do something to shorten the critical path.

Failure to consider resource allocation in scheduling almost always leads to a schedule that cannot be achieved.

In the simplest form, network computations are made for the network on the assumption that activity durations are exactly as specified. However, activity durations are a function of the level of resources applied to the work, and if that level is not actually available when it comes time to do the work, then the scheduled dates for the task cannot be met. It is for this reason that network computations must ultimately be made with resource limitations in mind. Another way to say this is that resource allocation is necessary to determine what kind of schedule is actually achievable! Failure to consider resources almost always leads to a schedule that cannot be met.

Initial schedule computations are made assuming that unlimited resources are available. This yields the best-case solution.

Still, the first step in network computations is to determine where the critical path is in the schedule and what kind of latitude is available for noncritical work, under ideal conditions. Naturally, the ideal situation is one in which unlimited resources are available, so the first computations made for the network are done without consideration of resource requirements. It is this method that is described in this chapter, and resource allocation methods are deferred to scheduling software manuals, as I said previously.

Network Rules

In order to compute network start and finish times, only two rules apply to all networks. These are listed following as rules 1 and 2. Other rules are sometimes applied by the scheduling software itself. These are strictly a function of the software and are not applied to all networks.

Rule 1.	Before a task can begin, all tasks preceding it must be completed.
Rule 2.	Arrows denote logical precedence.

Basic Scheduling Computations

Scheduling computations are illustrated using the network in Figure 7-1. First, let us examine the node boxes in the schedule. Each has the notation ES, LS, EF, LF, and DU. These mean:

ES	=	Early Start
LS	=	Late Start
EF	=	Early Finish
LF	=	Late Finish
DU	=	Duration (of the task)

Forward-Pass Computations

Consider a single activity in the network, such as picking up trash from the yard. It has a duration of fifteen minutes. Assuming that it starts at time = zero, it can finish as early as fifteen minutes later. Thus, we can enter 15 in the cell labeled EF.

Putting gas in the mower and weed whacker takes only five minutes. The logic of the diagram says that both of these tasks must be completed before we can begin trimming weeds, cutting the front grass, and edging the sidewalk. The cleanup task takes fifteen minutes, whereas the gas activity takes only five minutes. How soon can the following activities start? Not until the cleanup has been finished, since it is the longest of the preceding activities.

The Earliest Start for a task is the latest Late Finish of preceding tasks. That is, the longest path determines the earliest that a following task can be started.

In fact, then, the Early Finish for cleanup becomes the Early Start for the next three tasks. It is always true that the latest Early Finish for preceding tasks becomes the Early Start for subsequent tasks. That is, the longest path determines how early subsequent tasks can start.

Following this rule, we can fill in Earliest Start times for each task, as shown in Figure 7-2. This shows that the project will take a total of 165 minutes to complete, if all work is conducted exactly as shown. We have just performed what are called forward-pass computations to determine Earliest Finish times for all activities. Computer programs do exactly the same thing and additionally convert the times to calendar dates, making quick work of the computations.

RULE:	When two or more activities precede another activity, the earliest time when that activity can be started is the larger of the durations of the activities preceding it.
NOTE:	The time determined for the end or final event is the earliest finish for the project in working time. Once weekends, holidays, and other breaks in the schedule are accounted for, the end date may be considerably later than the earliest finish in working time.

Backward-Pass Computations

A backward pass is made through the network to compute the latest start and latest finish times for each activity in the network. To do that, we must decide how late the project can finish. By convention, we generally don’t want a project to end any later than its earliest possible completion. To stretch it out longer would be inefficient.

We also won’t insist (for now) that the project end earlier than the earliest possible finish calculated in the previous steps. If we want to finish earlier, we will have to redraw the network or shorten some activities (by applying more resources or working more efficiently, for example). For now, we will accept the 165-minute working time and let it be the Latest Finish for the project.

When doing backward-pass calculations, always use the smallest number for the LF of previous activities.

If Hauling Away Trash has a Late Finish of 165 minutes and has a duration of forty-five minutes, what is the latest that it could start? Clearly, if we subtract 45 from 165, we have 120 minutes, which is the Latest Start for the task. Proceeding in this manner, we get LS times for Bagging Grass and Bundling Clippings of 90 and 105 minutes, respectively. One of these two numbers must be the LF time for each of the preceding activities. Which one?

Well, assume we try 105 minutes. If we do that, it would say that Bagging Grass could start as late as 105 minutes, since as soon as preceding tasks are finished subsequent tasks can begin. But if we add 30 minutes for Bagging to the 105-minute ES time, we will finish at 135 minutes, which is later than the 120 minutes previously determined, and we will miss the 165-minute end time for the project.

When an activity has no float, it is called critical, since failure to complete work as scheduled will cause the end date to slip.

Therefore, when we are doing backward-pass calculations, the Latest Finish for a preceding task will always be the smallest of the Late Start times for the subsequent tasks. (A simpler way to say this is: always use the smallest number!)

RULE:

When two or more activities follow another, the latest time when that (preceding) activity can be achieved is the smaller of the times.

Now examine the path in Figure 7-3 that includes activities highlighted by bold lines. Each activity has the same ES/LS and EF/LF times. There is no float on this path. By convention, an activity with no float is called critical, and a total path with no float is called the critical path, which means that if any of the work on this path falls behind schedule, then the end date will slip accordingly. All of the activities that have ES/LS or EF/LF times that differ are said to have float. For example, Trim Weeds has an ES time of fifteen minutes and an LS time of sixty minutes, giving it forty-five minutes of float.

The final network is shown in Figure 7-3. Note that some tasks have the same EF and LF times, as well as the same ES and LS times. These tasks are on the critical path. In Figure 7-3, they are shown with bold outlines, to indicate exactly where the critical path lies.

The critical path activities have no latitude. They must be completed as scheduled, or the entire project will take longer than 165 minutes. Knowing where the critical path is tells a manager where his attention must be applied. The other tasks have latitude, which is called float. This does not mean that they can be ignored, but they have less chance of delaying the project if they encounter problems. The Edge Sidewalk task, for example, has an ES time of fifteen minutes and an LS time of seventy-five. The difference between the two is sixty minutes, which is the float for the task.

What good is the float? Well, we know we can start the task as late as seventy-five minutes into the job and still finish the project on time. If your son is doing this task, he can watch a sixty-minute television program during that time and still get his Edging task done on time.

Remember, too, that the times are all estimates. This means that tasks might take more or less than the scheduled time. So long as they do not take longer than the scheduled time plus the available float time, the job can be completed on time. Critical tasks, which have no float, must be managed in such a way that they take the scheduled time. This is usually done by adjusting the resources (effort) applied, either by assigning more resources or working overtime (increasing resources in either case).

This is not always possible. Applying overtime often increases errors, leading to rework, which may mean that you don’t get the job done any faster than if you had just worked a normal schedule. Furthermore, there is always a point of diminishing returns when you add bodies to a task. At some point, they just get in each other’s way, actually slowing work down rather than speeding it. Note that overtime should be kept in reserve in case of problems, so it is never a good idea to schedule a project so that overtime needs to be worked just to meet the original schedule.

It is bad practice to schedule a project so that overtime is required to meet the schedule, since if problems are encountered, it may not be possible to work more overtime to solve them.

Another point of great importance: all members of the project team should be encouraged to keep float times in reserve as insurance against bad estimates or unforeseen problems. People tend to wait until the latest possible start time to start a task; then, when problems occur, they miss the end date. If there is no float left, when the task takes longer than originally planned, it will impact the end date for the entire project, since once a task runs out of float, it becomes part of the critical path! In fact, the true meaning of the word critical is that there is no float. The task must be done on time.

Once you have used up the float on a task, it becomes part of the critical path.

Using the Network to Manage the Project

As I have indicated previously, the point of developing a CPM diagram is to use it to manage the project. If this is not done, scheduling is simply a worthless exercise. So here are some pointers that I have found helpful in managing my own jobs:

• Try to stay on schedule. It is always harder to catch up than to stay on target to begin with.

• Keep float in reserve in case of unexpected problems or bad estimates.

• Apply whatever effort is needed to keep critical tasks on schedule. If a task on the critical path can be finished ahead of schedule, do it! Then start the next task.

• Avoid the temptation to perfect everything—that’s what the next-generation product or service is all about. Note: I did not say it is okay to do the job sloppily or that you shouldn’t do your best work. I said don’t be tempted to make it perfect. By definition, you will never reach perfection.

• Estimates of task durations are made assuming the application of certain people. If someone else is actually used, you may have to adjust durations accordingly. This is especially true if the person is less skilled than the intended resource.

• This was stated in chapter 6 but is repeated because of its importance: No task should be scheduled with a duration much greater than four to six weeks. If you do, people tend to have a false sense of security and put off starting, under the assumption “I can always make up one day.” By the time they start, they often have slipped several days and find that they cannot finish as scheduled. We say that they back-end load the task by pushing all the effort toward the back end. If a task has a duration greater than six weeks, it is a good idea to subdivide it, creating an artificial break if necessary. Then review progress at that point. That will help keep it on target.

• If the people doing the work did not develop the network, explain it to them and show them the meaning of float. Don’t hide it from them. However, give them a bar chart to work to—it is much easier to read a bar chart than a network diagram. Show them that if they use up float on a given task, then the following tasks may become critical, leaving the people who must do those activities feeling really stressed.

• It is possible to shorten a task by adding resources, reducing its scope, doing sloppy (poor-quality) work, being more efficient, or changing the process by which the work is done. With the exception of doing sloppy work, all of the methods may be acceptable. A reduction in scope must be negotiated with your customer, of course.

• Scheduling is done initially on the assumption that you will have the resources you planned on having. If people are shared with other projects, or if you plan to use the same person on several tasks, you may find that you have her overloaded. Modern software generally warns you that you have overloaded your resources and may be able to help you solve the problem.