CPM Critical Path Method

The Critical Path Method is an activity scheduling procedure. There are three elements that must be ascertained before CPM can be useful. You must know: (1) All of the activities to be scheduled before beginning, (2) How long individual activities will take, (3) Any necessary antecedents for the order of performing the events. The terminology for CPM is fairly simple. Circles with event numbers are used to identify events; lines are used to connect the circles to represent the dependencies among the events. Along the lines the time taken for the event is indicated, and within the circles the earliest start time and the latest start time are deduced. At the end of the exercise it should be possible to determine which sequence of events is critical. If events on the critical path are delayed, the completion of the project will be delayed. If events not on the critical path are delayed, the overall project will not be affected (unless the delay is great enough to establish a new critical path). The easiest way to examine the Critical Path Method is to consider an example. Let us suppose that a group is preparing to conduct a test of their partially completed project to make sure that they are on the right track. There are two streams of work that have to be completed before the test can begin. First, testing arrangements must have been completed, and second the program must be ready to test. The following material will demonstrate the typical steps to be followed in using this method. Step 1: List the activities to be considered in approximate order. In this case, the testing arrangements might consist of the following events: - questionnaire to teachers - collate information - arrange interviews - conduct interviews - schedule class trial time The programming part of the job would have these events: - complete menu structure of program - have enough modules ready to test - prepare handouts for class test And the overall test would finish with the following: - conduct program test - analyse results
Step 2: Number the events, estimate the time required for each, and determine the antecedents. In this case the scheduling branch and the programming branch must be completed before the testing branch can be started. In the chart that follows, this is indicated by showing events 5 and 8 as being antecedent to event 9. Events 1 and 6 have no antecedents, and all of the others follow in simple order:

Event #
1 2 3 4 5 6 7 8 9 10

Event Description
prepare questionnaire collate information arrange interviews conduct interviews schedule test times menu structure sufficient modules make class handouts conduct class tests analyse results

Time
3 1 2 3 2 2 5 1 2 2

Antecedents
0 1 2 3 4 0 6 7 5,8 9

Step 3: Arrange the events on a CPM diagram showing the events with numbered circles and the antecedent relationships with connecting lines. It is customary to have extra circles for the starting and ending locations on the diagram as well. On each connecting line, write the time estimate for the preceding task. Step 4: Determine the earliest times for starting the events. On the top branch, event 1 can be started immediately, but event 2 could not be started until event 1 has been finished, three days later. Similarly for the bottom branch, event 6 can be started immediately, but event 7 could not be started for two days. The tricky part is at event 9. According to the top branch, event 9 could not be started until event 5 is completed. Since event 5 cannot be started before day nine, event 9 could not be started until day eleven. According to the bottom branch, event 9 could be started one day after event 8, or eight days after the start of the project. Since both events 5 and 8 must be completed before event 9 can be started, the earliest that event 9 can be started is day eleven. The rest of the diagram is linear and easy to figure out. Step 5: Determine the latest times for starting the events. This can be done by working backwards. In each case, subtract the time required for the event from the earliest starting time of the subsequent event. In our example, the end of the project is at day fifteen. Event 10 requires two days, and hence cannot be started later than day thirteen. Similarly event 9 must be started on day eleven. At the branch in the diagram we see that event 5 must start on day nine (11 - 2), but event 8 could start on day ten (11 - 1). Step 6: Determine the critical path. If the earliest time that an event can be started is the same as the latest that it could be started, then the timing for that event is critical. Connecting the critical events determines the critical path. This is shown with doubled lines. This suggests that the group has a few days in hand for the programming part of their work, but that it is critical to produce and distribute the question as soon as possible. If the overall test is to be completed in less than 15 working days, then time savings must be found in the top branch of the diagram. Naturally if this time is reduced, the programming part becomes more critical. Also, it is typical for the time estimates for programming activities to be low, so that this branch might turn out to be more critical than originally estimated. Nevertheless, what might surprise the group is that it takes so long to prepare for something as simple as conducting a program test in their class. This insight alone justifies the use of the method. CPM diagram for this example.