Although critical path scheduling (CPM/PERT) was developed in the late 1950s and has been taught in seminars and university courses since then, it is used by few and understood by even fewer. Yet it is an extremely powerful and adaptable — but simple — tool.
The reasons for CPM/PERT’s limited use seem to be a failure to appreciate its simplicity and a misconception that computers and scheduling specialists are necessary for its use. Project managers have either attempted to plan and control their jobs with bar charts or have surrendered their basic role of planning, scheduling and controlling progress to a machine and a technician. Subsequent failure of computerized schedules to reflect the thinking of those doing the work often results in schedules that are not or cannot be followed. In addition, many managers are unable to cope with the reams of data that the computer spews forth. The end result is that most projects are still being planned with bar charts — if at all.
There is a method of CMP/PERT scheduling that is simpler, easier and just as powerful as computerization. It is the time-scale arrow diagram — a method used successfully by this firm for years on all types of projects. It’s been taught to hundreds of people who have found it vastly superior to computer printout on most jobs. The following discussion presents a brief overview of CPM/PERT, then explains how and when to use the time-scale arrow diagram method of CPM scheduling.
CPM (Critical Path Method) and PERT (Program Evaluation and Review Technique) were both developed in the late 1950s on very large computers for massive projects. PERT, developed for research and development projects, focused on major events (called milestones) and used probabilities to calculate the most likely time between milestones. CPM, oriented toward construction, focused on those activities required to accomplish a project by using one estimate of activity duration instead of the three used in PERT.
Although there has been a mind-boggling proliferation of CPM and PERT variations, the two techniques have become quite similar. CPM users have adapted the use of the milestone to highlight the beginning or end of a major phase of work. And now PERT users seldom use three estimates of activity duration because one is plenty of work and not many have the time or patience to estimate two more durations when the results are scarcely better.
Today, few civil engineers or contractors use PERT, and those who do should recognize that the techniques are essentially the same. Therefore, the following discussion focuses on CPM.
There are three basic steps in preparing a CPM schedule: 1) planning (or diagramming), 2) estimating of activity durations, and 3) scheduling (or computing).
First, one must plan the job, usually by laying out the activities in sequence on a piece of paper. This is the network diagram; it defines the activities and their relationship. The two types of network diagrams are the arrow diagram and the precedence diagram. Either of these, or some variation, must be prepared even if the schedule is eventually computerized.
Second, one must assign time durations to each activity. This step is almost as difficult as the first step and also must be done manually.
Third, only when the diagram is prepared and durations assigned, can one compute the critical path, early start (ES), late start (LS), early finish (EF), late finish (LF), float, and total project duration. This is the easiest step as it requires only simple mathematics — addition and subtraction. It can be done by computer.
There are four methods of computing the critical path. Two are computerized (i-j node and precedence) and two are non-computerized (manual computation directly on the network and time-scale computation with the network diagram).
i-j Node Computing
CPM was originally developed using the i-j node method. In this method, each activity is identified to the computer by its beginning (i) node number and its ending (j) node number. These two numbers (i-j) uniquely define each activity and the relationship between them. For example, if activity B follows activity A (as in Fig. 2) then the j (ending) node number of activity A is the i (beginning) node number of activity B (as in Fig. 1).
lt is nearly impossible to determine accurately the complex relationships between activities of a major project from just a table of activity descriptions and their i-j nodes (such as Fig. 1). Consequently, activities first are laid out on a network diagram that graphically shows the relationship between them. This is called arrow diagramming, as an arrow represents the activity (with no time-scale) and a circle (or node) at each end contains the i-node number and j-node number. A relationship between two activities that cannot be shown by directly connecting the arrows is indicated by a dotted-line arrow, called a dummy arrow (Fig. 2).
The precedence method is a new approach to CPM scheduling; it assigns one number to the activity itself and simply lists all preceding activities, making it much easier to update and revise than the i-j node method (see Figs. 3 and 4).
Precedence diagramming uses a box instead of an arrow to represent an activity. A solid line goes from the back of the preceding activity to the front of the following one to show relationships, making the precedence diagram much easier to draw and revise than the arrow diagram (see Fig. 4).
Although the precedence diagram appears to be quite different than the arrow diagram, they are really quite similar (as shown in Figs. 5-8).
One of the first non-computer scheduling methods was developed by Prof. John Fondahl of Stanford University in 1963.Non-computer methods are easy to use, requiring only a network diagram and basic skills in addition and subtraction to compute the ES, LS, EF, LF, float, and total project duration.
It has been found to often be cheaper and faster to manually calculate the critical path than to input data into a computer, make the run, debug it, and rerun. Incidentally, if one doesn’t computerize, there is no need for the nodes (circles) and i-j numbers except to highlight a milestone. This will significantly speed drafting (the typical activity arrow and notation is shown in Fig. 9).
The ease of manual CPM schedule computation can be illustrated with the example network (seen in Fig. 10).
The first step is to start activity A at the beginning of work day 1 (Fig. 11), which is the ES for activity A. If activity A starts the beginning of work day 1 and takes 5 working days, its EF will be 1 + 5 = 6 (the beginning of work day 6, which is the same as the end of work day 5; see Fig. 12). If the earliest that activity A can finish is (the beginning of) work day 6, then the earliest that activities B and D can start is (the beginning of) day 6 (ESB = ESD = EFA = 6); see Fig. 13.
Since activity B can start the 6th day and takes 6 days, the earliest it can finish is the 12th day (EFB = ESB + duration = 6 + 6 = 12). Also, activity D can start the 6th day and takes 8 days so it can’t finish before the 14th day (EFD = ESD + duration = 6 + 8 = 14); see Fig. 14.
To compute the Early Start for activity C, one must consider what activities have to finish before C can begin and what is the earliest that they will finish. From Fig. 15, it is apparent that activities B and D both must be finished before C can start — and that the earliest that they will be finished is day 14 (ESC = latest EF of B or D = 14). Therefore the ES for C (and also E) is 14.
The computations continue:
1) EFC = ESC + duration = 14 + 5 = 19
2) EFE = ESE + duration = 14 + 2 = 16
3) ESF = latest of EFC or EFE = 19
4) EPF = ESF + duration = 19 + 4 = 23 (see Fig. 16).
This completes the “forward pass,” which gives the early start, early finish, and total project duration. The next step is the “backward pass,” which gives the late start, late finish and float. To begin the backward pass, set the late finish of the last activity equal to the early finish (LFF = EFF = 23). The earliest the project can finish is (the beginning of) the 23rd day. The latest the project can end is also (the beginning of) the 23rd day. If activity F takes 4 days, then the latest it can start and not delay the project is the 19th day (LSF = LFF – duration = 23 – 4 = 19) (see Fig. 17).
If day 19 is the latest activity F can start and not delay the project, then day 19 is also the latest that activities C and E can finish and not delay activity F (and thus the project). Therefore, the late finish of both activities C and E is day 19 (see Fig. 18).
From here, it is simple subtraction to determine that:
1) LSC = LFC – duration = 19 – 5 = 14
2) LSE = LFE – duration = 19 – 2 = 17
3) LFB = LSC = 14
4) LSB = LFB – duration = 14 – 6 = 8
5) LFD = earliest of LSC & LS = LSE = 14
6) LSD = LFD – duration = 14 – 8 = 6
7) LFA = earliest of LSB & LSD = LSD + 6
8) LSA = LFA – duration = 6 – 5 = 1
This completes the “backward pass” and gives the late finish and late start of each activity (see Fig. 19).
Computation of Float
Float is the number of days between either the early start and late start or the early finish and late finish (float = LS – ES = LF – EF). Activities with an early start equal to the late start have zero float and are therefore critical. Note that activity A is critical (LSA – ESA = 1 – 1 = 0 = LFA – EFA) as is activity D (LSD ESD = 6 – 6 = 0), activity C (LSC – ESC = 14 – 14 = 0), and activity F (LFE – EFE = 23 – 23 = 0). However, activity B has 2 days float (LSB – ESB = 8 – 6 = 2 = LFB – EFB = 14 – 12 = 2), and activity E has 3 days float (LSE – ESE = 17 – 14 = 3).
Conversion to Calendar Date
The final step is to convert the computed work days for ES, LS, EF, & LF to calendar dates. This can be accomplished by providing a simple conversion table on the network diagram or even developing a table with the calendar dates. Conversion to calendar date is tedious, but for only one project it is probably cheaper and faster than to: 1) learn how to use a particular computer program, 2) key punch the date, 3) make the computer run, and 4) debug the data so that it runs correctly.
Time-scale Arrow Diagrams
Fortunately, there is another non-computer alternative to the time-scale arrow diagram. The initial step is to draw the first activity to scale. As seen from Fig. 20, activity A begins on work day 1 and ends (the beginning of) work day 6.
Next step is to draw the activities directly following activity A (see Fig. 21). The natural tendency is to draw activity C starting day 12, directly after the finish of activity B. However, activity C is also dependent upon activity D and therefore can’t start before day 14. Therefore, activity C has a two-day float arrow from activity B and a vertical relationship (dummy) arrow from activity D
(see Fig. 22).
Activity E starts immediately after activity D is completed, then continues as a float arrow until the end of C. Activity F follows C & E and takes 4 days.
A quick review of this network diagram will reveal that Activity B has 2 days float; activity E has 3 days float; and activity path A, D, C, F have zero float and is therefore critical. In addition, one can quickly determine early start and early finish days (ESF = 19, EFE = 16, ESB = 6, etc.).
Comparison with Bar Chart
It’s interesting to compare the time-scale arrow diagram with the bar chart (Fig. 24). Both are easy to read and understand. The time-scale arrow diagram takes less space, shows the relationship between activities, and shows float.
It has been found that the time-scale arrow diagram is but slightly more difficult to prepare than the bar chart and can be just as simple. Yet it has many advantages over the bar chart.
But the bar chart is still a good technique for projects without a critical path. For example, a process machine shutdown is often more dependent upon resources than upon a certain sequence of activities. In such cases, either a bar chart or a modified time-scale arrow diagram may be used.
Alleged criticisms of the time-scale arrow diagram are:
1) too hard to draw
2) too difficult to update
3) too long a drawing
4) too little information
None of these criticisms have been found to be true.
First of all, one should remember that the vast majority of work in CPM scheduling is in gathering and evaluating information — not drafting the network. Secondly, a network diagram always has to be drawn in order to schedule a project; it also frequently is erased and redrawn before it is satisfactory. Although time-scale diagrams are more work to draft and change than non time-scale diagrams, the extra effort is negligible. Besides, drafting techniques developed by Pinnell Engineering more than compensate for the additional work. In fact, they make time-scaling easier than normal methods of non time-scale networking.
One time-saving technique is to eliminate the i-j nodes (they aren’t needed unless the schedule is computerized with the i-j method). The amount of work required to draw the circles is much greater than normally realized. Also, the circles clutter up the diagram, making it difficult to read. Instead of circles to mark the beginning and end of activities one need only use arrowheads to give a sense of flow.
Another time-saving technique is to draft the network on fade-out grid paper (a translucent grid paper with light blue lines at 1-in. or 25-mm intervals). A blueline preprint drops out the grid lines, leaving only items drafted onto the network. The grid lines greatly facilitate drafting the network because:
1) horizontal lines are easily drawn
2) activities are easily and evenly spaced 1-in. apart, with subnetworks separated by 2-in. (50 mm) for clarity, and overlooked activities inserted at 1/2-in. spacing
3) lettering is fast because the small grid lines provide an adequate guide
4) time-scaling is simplified – if a scale of 1-in. per week is used, then 1 working day = two 1/10-in. grid lines on a 10 x 10 grid, or if a scale of 1-in. per month is used, then 1 week equals approximately two 1/8-in. grid lines
5) drawing of consistently sloped angle portions of activity arrows is facilitated as one can easily lay out a 1:10 or 1:8 slope.
Difficult to Update
One of the most frequent criticisms of the time-scale arrow diagram is that it is too time consuming to update when work falls behind or gets ahead of schedule.
First, there is no more need to redraw a time-scale arrow diagram. An out-of-date time-scale arrow diagram is at least as valid as the non time-scale arrow diagram. Second, the preferred method of showing deviation from plans is not to redraft the network (obscuring the original plans and deviations) but, rather, to show a vertical status line. This starts at the revision date, drops vertically to the first activity, jogs horizontally to the percent complete of that activity arrow, and continues to the bottom of the page (see Fig. 25 for an example of an update line).
As can be seen in Fig. 25, “Pour Concrete” is 4 days behind, “Excavate Footings” is on-schedule, and “Mechanical & Electrical Work” is one week ahead. This provides an excellent guide for the project manager as to what needs expediting. Naturally, if the project gets too far ahead or behind schedule – or if there are major logic changes – redrafting is necessary in order to maintain the usefulness of time-scale.
A classic example is the computer-generated, time-scale arrow diagram that starts over the project engineer’s desk, runs across the wall, around the corner into the next office, and clear down to the other end of the job trailer.
One need not do this. The smallest necessary scale is usually 1-in. per week. This allows one working day equal 2/10-in. (10 x 10 grid paper) and is enough to draw a very short arrow with an arrowhead for those infrequent activities that require only one day. If some activities take less than a day, they can be combined with others. If there isn’t room to put the description directly over the activity, then it can be put up out of the way with a leader (see Fig. 26). Sometimes, of course, one inch per week doesn’t give enough room (as in a paper machine shutdown). In these cases, overall project duration is usually quite small and the scale can be expanded.
At 1-in. per week, a one-year project becomes rather unwieldy (52-in. plus 2-in. margins or 1320-mm plus 50-mm), and a two-year project becomes impossible. One solution is to stack one half of the schedule over the other on the same sheet of paper. Using a 30-in. (762-mm) wide sheet with ½-in. margins top and bottom – plus 2-in. between the halves – 14-in. (355-mm) widths are available for each half. Since some activities will be separated by ½-in. and a few by 2-in., there is room for about 20 concurrent activities at the same time (which is adequate for most projects). If a schedule is stacked, plenty of room must be left between halves so that the two are already delineated.
Another solution is match lines and two or more sheets. Although this may be required in some cases, it is obviously not as desirable as viewing the entire schedule in one piece.
Yet another solution is to break the scale, drafting the first part at 1-in. per week and the rest at another scale or not-to-scale. This often works well, as it is best to avoid too much detail too far into the future because: 1) one seldom has sufficient time, and 2) plans will probably change by the time one gets closer to doing the work.
The final solution is to use a different scale. One inch per two weeks works very well and even one inch per month does well for many projects. This is about as far as one need go, as a 4-ft. (1.2 m) drawing can then cover about four years.
Too Little Information
The time-scale arrow diagram does have some limitations, however. Assume an average vertical spacing of 1 in., an average activity length of 1½ weeks at in./week, and 25% of the space unused due to the organization of the network. A large drawing (36 in. x 60 in. or 1524 mm x 914 mm) can have up to 1000 activities and a medium-sized drawing (30 in. x 36 in. or 762 mm x 914 mm) can have up to 500 activities.
For projects up to $30 million, Pinnell Engineering has seldom exceeded 300 activities on anyone network. It is best to have additional detail in subnetwork schedules tied to the master schedule but prepared and maintained by the organization responsible for that portion of the project. Not only does this reduce the information required, it places the scheduling responsibility where it belongs.
This firm does not, in fact, recommend having over 500 activities on a network (at anyone time) as managers cannot and should not grapple with such detail. However, as the project progresses, completed activities are dropped off and new activities added so that the total number of activities may be several thousand over the life of the project.
Advantages of Time-Scale Arrow Diagram
Rather than being inferior to computer scheduling, timescale arrow diagramming actually has several distinct advantages; these are:
- greater flexibility
- quicker and clearer communication and visualization
- faster and cheaper preparation
- more power
Good graphics (time-scale arrow diagram) implies relationships between two concurrent activities or shows an approximate relationship between activities that computer printout could never do. Many work activities (e.g., Mechanical embedded in concrete), take only a short time to accomplish, must occur sometime concurrent with another activity (e.g., form for concrete), yet cannot (and need not) be precisely defined as to exactly when they will occur (see Fig. 27).
Other activities must be completed at some uncertain time prior to completion of another activity (e.g., rebar footings before completing form footings in Fig. 27). The computer requires precise relationships and cannot show generalities.
In addition, the time-scale arrow diagram can show assumptions: questions about durations, relationships or activity descriptions, and alternatives that are impossible to show with computer printout. All that is needed is a brief note on the diagram informing readers as to what assumptions have been made, questioning what the relationship should be, or a different type of line (say a dot-dash) to show an alternative path from a decision point or a differing outcome event.
The human eye and brain can grasp the fundamental organization, repetitive patterns, critical path, float, and a sense of the overall criticality and complexity of the entire project and subnetworks from a brief review of a well-prepared time-scale arrow diagram. A similar understanding gleaned from computer printout would take hours of dedicated concentration and elude all but the most determined.
Time-scaling takes longer to draft initially, but once the network is drafted, there is no delay or cost to keypunch data, make the computer run, or wait for printout and debug the data. It also costs much less to update. If a status line is used to show current status instead of redrafting, the cost of monthly or weekly revisions can be negligible compared to computer runs.
Finally, the time-scale arrow diagram can permit concurrent consideration of resource availability, space limitations, weather effects, and related activities. If the scheduler rough drafts the schedule in time-scale instead of converting later, all these factors can be considered initially instead of first going through the laborious, expensive and inaccurate process of computer rescheduling, resource leveling, and least-cost expediting. In fact, no existing or contemplated computer system can begin to compete with the sophistication, power, and accuracy of an experienced manager with such a practical tool to aid him in visualizing and analyzing a project.
In summary, CPM and PERT are seldom used or understood in spite of over 20 years availability. In fact, many are strongly opposed to it, having had reams of computer printout and unreasonably detailed, poorly planned CPM schedules forced upon them.
Computer printout alone is not adequate for scheduling. Computer scheduling without an understanding of the basics is largely responsible for CPM’s limited use; it is similar to finding one’s way from a list of streets and intersections instead of from a map.
Computer-generated, time-scale network diagrams, at least the ones seen by this firm, are not yet satisfactory due to the poor quality of graphics. They do, however, hold promise for the future.
Precedence scheduling, although recently quite popular, also is not the answer. If a computer is used, precedence computing is far superior to i-j node computing. In addition, precedence diagramming does have some advantages over arrow diagramming, especially when “roughing out” a very complex network (because it is easy to modify relationships). It doesn’t, however, lend itself to time-scaling, and always must be eventually converted to time-scale arrow diagram.
The most important step to increase the use of CPM scheduling is for everyone to understand it, and to use more judgment when applying it. Whether one uses i-j node or precedence computer computing; non time-scale or time-scale arrow diagramming; precedence diagramming or other methods isn’t as important as properly understanding and using the method selected. The profession must first learn and apply the basics before attempting sophisticated computer technology.