A Brief History of Scheduling
Until around 1958, the only tool for scheduling projects was the bar chart (see Figure 6-1). Because Henry Gantt developed a complete notational system for showing progress with bar charts, they are often called Gantt charts. They are simple to construct and read and remain the best tool to use for communicating to team members what they need to do within given time frames. Arrow diagrams tend to be too complicated for some teams. Nevertheless, it is often helpful to show an arrow diagram to the people doing the work so that they understand interdependencies and why it is important that they complete certain tasks on time.
Figure 6-1. Bar chart.
Bar charts do have one serious drawback—it is very difficult to determine the impact of a slip on one task on the rest of the project (e.g., if Task A in Figure 6-1 gets behind, it is hard to tell how this will affect the rest of the work). The reason is that the bar chart (in its original format) did not show the interdependencies of the work. (Contemporary software does show links between bars, making them easier to read. The actual name for these bar charts is “time-line critical path schedules.”)
To overcome this problem, two methods of scheduling were developed in the late 1950s and early 1960s, both of which use arrow diagrams to capture the sequential and parallel relationships among project activities. One of these methods, developed by Du Pont, is called Critical Path Method (CPM), and the other, developed by the U.S. Navy and the Booze, Allen, and Hamilton consulting group, is called Program Evaluation and Review Technique (PERT). Although it has become customary to call all arrow diagrams PERT networks, strictly speaking the PERT method makes use of probability techniques, whereas CPM does not. In other words, with PERT it is possible to calculate the probability that an activity will be completed by a certain time, whereas that is not possible with CPM.
CPM: Critical Path Method PERT: Program Evaluation and Review Technique
Network Diagrams
To show the sequence in which work is performed, diagrams like those in Figure 6-2 are used. In these diagrams Task A is done before B, while Task C is done in parallel with them.
Figure 6-2. Arrow diagrams.
The network in the bottom half of Figure 6-2 uses activity-on-arrow notation, in which the arrow represents the work being done and the circle represents an event. An event is binary; that is, it has either occurred or it has not. An activity, on the other hand, can be partially complete. Note that this is a special use of the word event. We speak of a football game as an event, even though it spans time. In scheduling terminology, however, an event is a specific point in time where something has just started or has just been finished.
The network in the top half of Figure 6-2 uses activity-on-node notation, which shows the work as a box or node, and the arrows show the sequence in which the work is performed. Events are not shown in activity-on-node networks unless they are milestones—points in the project at which major portions of the work are completed.
Why two forms of diagrams? Probably a tyranny to confuse the uninitiated. Actually, it simply happens that the schemes were developed by different practitioners.
Is one better than the other? No. They both get the same results in figuring out when work is supposed to be completed. Both forms are still used, although activity-on-node is used a bit more than the other, simply because much of today’s personal computer software is programmed to use node notation.
The critical path is the longest path through a project network. Because it has no slack, all activities on the critical path must be completed as scheduled, or the end date will begin to slip—one day for each day a critical activity is delayed.
What is the benefit of using either CPM or PERT? The main advantage is that you can tell whether it is possible to meet an important project completion date, and you can also tell exactly when various tasks must be finished in order to meet that deadline. Furthermore, you can tell which tasks have some leeway and which do not. In fact, both CPM and PERT determine the critical path, which is defined as the longest series of activities (that can’t be done in parallel) and which therefore governs how early the project can be completed.
The Reason for Scheduling
Naturally, the primary reason for scheduling a project is to ensure that the deadline can be met. Most projects have a deadline imposed. Furthermore, since the critical path method helps identify which activities will determine the end date, it also helps guide how the project should be managed.
However, it is easy to get carried away with scheduling and spend all of your time updating, revising, and so on. The scheduling software in use today should be viewed as a tool, and managers should not become slaves to the tool.
It is also very easy to create schedules that look good on paper but don’t work in practice. The main reason is usually that resources are not available to do the work when it comes due. In fact, unless resource allocation is handled properly, schedules are next to useless. Fortunately, today’s scheduling software handles resource allocation fairly well, but we leave discussion of the methods used to the software manuals. In this book, we simply examine how networks are used to show us where we need to manage.
One company found that when it stopped having people work on multiple projects, workers’ productivity doubled!
I am often told that scope and priorities change so often in a given organization that it doesn’t make sense to spend time finding critical paths. There are two points worth considering here. One is that if scope is changing often in a project, not enough time is being spent doing up-front definition and planning. Scope changes most often occur because something is forgotten. Better attention to what is being done in the beginning usually reduces scope creep.
Second, if priorities are changing often, management does not have its act together. Generally, the organization is trying to tackle too much work for the number of resources available. We all have “wish lists” of things we want to do personally, but we have to put some of them on hold until time and/or money become available. The same is true of organizations. Experience shows that when you have individuals working on many projects, productivity suffers. One company found, as an example, that when it stopped having people work on multiple projects, employees’ productivity doubled! That obviously is highly significant.
What does CPM have to do with this? Knowing where the critical path is in a project allows you to determine the impact on the project of a scope or priority change. You know which activities will be impacted most heavily and what might need to be done to regain lost time. In addition, managers can make informed decisions when you can tell them the impact of changes to the project. Thus, CPM can be an invaluable tool, when used properly.
| Definitions of Network Terms | |
|---|---|
| ACTIVITY | An activity always consumes time and may also consume resources. Examples include paperwork, labor, negotiations, machinery operations, and lead times for purchased parts or equipment. |
| CRITICAL | A critical activity or event is one that must be achieved by a certain time, having no latitude (slack or float) whatsoever. |
| CRITICAL PATH | The critical path is the longest path through a network and determines the earliest completion of project work. |
| EVENTS | Beginning and ending points of activities are known as events. An event is a specific point in time. Events are commonly denoted graphically by a circle and may carry identity nomenclature (e.g., words, numbers, alphanumeric codes). |
| MILESTONE | This is an event that represents a point in a project of special significance. Usually it is the completion of a major phase of the work. Project reviews are often conducted at milestones. |
| NETWORK | Networks are called arrow diagrams. They provide a graphical representation of a project plan showing the relationships of the activities. |
Constructing an Arrow Diagram
As was pointed out in chapter 5, a Work Breakdown Structure (WBS) should be developed before work on the project is scheduled. Also, we saw that a WBS can contain from two to twenty levels. To illustrate how a schedule is constructed from a WBS, we consider a simple job of maintaining the yard around a home. The WBS is shown in Figure 6-3.
Don’t schedule in more detail than you can manage.
In the case of this WBS, it is appropriate to schedule the tasks at the lowest level. However, this is not always true. Sometimes work will be broken down to level 6 but only those activities up to level 5 will be entered into the schedule. The reason is that you may not be able to keep level 6 tasks on schedule. That is, you can’t manage that tightly. So you schedule at a level that you can manage. This follows the general rule that you should never plan (or schedule) in more detail than you can manage. Some projects, such as overhauling a large power generator, are scheduled in increments of hours. Others are scheduled in days, while some big construction jobs are scheduled to the nearest month.
While planning in too much detail is undesirable, if you plan in too little detail, you might as well not bother. As a practical example, a manager told me that his staff wanted to create schedules showing tasks with twenty-six-week durations. He protested that the staff would never complete such schedules on time. They would back-end load them, he argued.
A good rule of thumb to follow is that no task should have a duration much greater than four to six weeks. For knowledge work, durations should be in the range of one to three weeks, because knowledge work is harder to track than tangible work.
What he meant was that there is a lot of security in a twenty-six-week task. When the start date comes, if the person doing the task is busy, she might say, “I can always make up a day on a twenty-six-week activity. I’ll get started tomorrow.” This continues until she realizes she has delayed too long. Then there is a big flurry of activity as she tries to finish on time. All the work has been pushed out to the end of the twenty-six-week time frame.
A good rule of thumb to follow is that no task should have a duration much greater than four to six weeks. A twenty-six-week task can probably be broken down into five or six subtasks. Such a plan will generally keep people from back-end loading.
There are two ways you can develop a schedule. One is to begin at the end and work backward until you arrive at the beginning. The second method is to start at the beginning and work toward the end. Usually, it is easiest to start at the beginning.
The first step is to decide what can be done first. Sometimes several tasks can start at the same time. In that case, you simply draw them side-by-side and start working from there. Note the progression in the diagram in Figure 6-4. It sometimes takes several iterations before the sequencing can be worked out completely.
This small project might be thought of as having three phases: preparation, execution, and cleanup. There are three preparation tasks: pick up trash, put gas in equipment, and get out hedge clipper. The cleanup tasks include bagging grass, bundling clippings, and hauling trash to the dump.
Schedules should be developed according to what is logically possible, and resource allocation should be done later. This will yield the optimum schedule.
In doing this schedule diagram, I have followed a rule of scheduling, which is to diagram what is logically possible, then deal with resource limitations. For a yard project, if I have no one helping me, then there really can be no parallel paths. On the other hand, if I can enlist help from the family or neighborhood youth, then parallel paths are possible, so this rule says go ahead and schedule as if it were possible to get help. This is especially important to remember in a work setting, or you will never get a schedule put together. You will be worrying about who will be available to do the work and end up in analysis paralysis.
Another rule is to keep all times in the same increments. Don’t mix hours and minutes—schedule everything in minutes, then convert to hours and minutes as a last step. For this schedule, I have simply kept everything in minutes.
I suggest that you draw your network on paper and check it for logical consistency before entering anything into a computer scheduling program. If the network has logical errors, the computer will just give you a garbage-in, garbage-out result, but it will look impressive, having come from a computer.
Another rule is to keep all times in the same increments.
It is also important to remember that there is usually no single solution to a network problem. That is, someone else might draw the arrow diagram a bit differently than you have done. There may be parts of the diagram that have to be done in a certain order, but often there is flexibility. For example, you can’t deliver papers until you have printed them, so if the diagram showed that sequence, it would be wrong. The conclusion is that there is no single right solution, but a diagram can be said to be wrong if it violates logic.
It is hard to tell whether a network is absolutely correct, but it can be said to be wrong if logic is violated.
The network for the yard project could get a lot more complicated. You could have edge front sidewalk and edge back sidewalk. You could talk about trimming around trees in both front and back, and so on. But there is no need to make it too complicated. We don’t usually try to capture exactly how we will do the work, just the gist of it.
The next step is to figure out how long it will take to do the job. Time estimates for each task are made by using history—remembering how long each activity has taken in the past. Remember, though, that the estimate is valid only for the individual who is going to do the task. If my daughter, who is sixteen, does the lawn mowing using a push mower, it will probably take less time than for my son, who is only twelve. In the following chapter, we see how to find the critical path through the network, so we can know how long it will take.
Key Points to Remember
|