Project networks, PERT, and CPM

Project networks, PERT, and CPM

21.1 Purpose

A project network chart is a tool for graphically depicting a schedule and serves as a basis for PERT and CPM. Project networks can be used to plan, record, and document a schedule and to track actual results against the schedule.

21.2 Strengths, weaknesses, and limitations

Project networks are excellent tools for planning, tracking, and managing large projects. They are not particularly useful for small projects, however.

PERT (Program Evaluation and Review Technique) is useful in research and development projects where the times required to complete the various activities are uncertain. The critical path is the primary focus of management control, and monitoring the critical events provides an early warning if estimates are inaccurate.

CPM (Critical Path Method) is used to help solve scheduling problems when the activity times are known more precisely. Only by shortening the critical path can the project completion time be improved. Consequently, the critical path defines those activities into which additional resources might be poured to accelerate the schedule.

Creating a project network is a complex undertaking. The computations are straightforward, but non-trivial. Without appropriate software tools, maintaining or changing a project network can be difficult.

The accuracy of the project network is no better than the estimated duration of each of the activities. The lack of a relationship between an activity’s duration and the length of the arrow that represents the activity can lead to misunderstandings. Errors in computing earliest event times, latest event times, and slack times are not always apparent, so all computations should be checked carefully.

21.3 Inputs and related ideas

Before preparing a project network, the tasks or activities to be performed must be identified and each activity’s duration (the time required to complete the activity) estimated. Additionally, the sequential relationships between activities must be known. The necessary information is typically collected during the problem definition and information gathering stages of the system development life cycle (Part II).

A Gantt chart (Chapter 20) may be a better tool for scheduling a small project. The project network is the basis for crash mode scheduling (Chapter 22).

21.4 Concepts

A project network chart is a tool for graphically depicting a schedule and serves as a basis for PERT and CPM. Project networks can be used to plan, record, and document a schedule and to track actual results against the schedule.

The examples in this chapter are based on the activities listed in Table 21.1. Figure 21.1 is a project network for these activities.

Figure 21.1  A project network for an inventory system.

21.4.1 Events and activities

Each activity (a line or an arrow) in the project network begins and ends with an event (a circle or a bubble). The events are numbered (the numbers do not necessarily imply sequence), and a given activity is identified by the numbers associated with its beginning and ending events. Order hardware and software is activity 1-2. Shipment time (activity 2-5) begins with event 2 and ends with event 5. Note that events are points in time, while activities consume both time and (usually) resources.

Each activity’s duration is shown just above its arrow. Note that there is no relationship between the length of an arrow and the duration of the activity. The arrows identify dependency relationships; all activities that enter a given event must be completed before that event occurs.

21.4.2 Precedence

The project network defines event precedence. For example, to the right of Figure 21.1, event 13 must occur before activity 13-14 or activity 13-15 can begin, and event 16 does not occur until activities 13-16, 14-16, and 15-16 are all completed. Activities on parallel paths can be performed in parallel.

The path through a project network is said to diverge when a single-line path splits into multiple paths. For example, a single path (activity 12-13) enters event 13, and three paths (13-14, 13-15, and 13-16) leave event 13. Paths are said to merge when multiple input paths lead to a single output. For example, activities 3-12 and 11-12 both end at event 12, and only activity 12-13 leaves event 12.

21.4.3 Dummy activities

Some of the activities in Figure 21.1 are shown as dashed lines. These dummy activities link parallel events and consume neither time nor resources. They show dependency relationships that are not associated with activities.

21.4.4 The earliest event time

The project network defines the dependency relationships between the events. Given a clear sense of the order in which events must occur, the analyst can prepare a schedule.

The first step is to compute the earliest event time (EET) for each event. The EET is the earliest time the event can possibly begin. By convention it is zero for the first event. To compute the earliest event time for all the other events, work from left to right and follow these three rules:

1.  Select all activities that enter the event.

2.  For each entering activity, sum the activity’s duration and the EET of its initial event.

3.  Select the highest computed EET and record it in the upper right quadrant of the event circle.

An event occurs when all the activities that enter it are completed. That is why the highest computed EET is selected.

In Figure 21.1 the earliest event times are shown at the upper right quadrant of each circle. For example, consider event 2. There is only one entering activity, 1-2. Activity 1-2’s initial event is 1. Event 1’s EET is 0 and activity 1-2’s duration is 2 d, so the earliest event 2 can possibly occur is 2 d after the project begins.

Next, consider event 10. It has two entering activities (6-10 and 9-10), so two computations are needed. Event 6’s EET is 2 and activity 6-10’s duration is 1 d, so the computed EET is 3 d. Event 9’s EET is 10 and activity 9-10’s duration is 1 d, so the second EET is 11 d. The highest computed EET for event 10 is 11 d, so record 11 at the top right of the bubble that represents event 10.

21.4.5 The latest event time

The latest event time (LET) is the latest time an event can occur without impacting the project schedule. By convention, the LET of the last or terminal event is equal to its earliest event time, so 16 d is both the EET and the LET for event 16 (Figure 21.1). To compute the latest event time for all the other events, work from right to left and follow these three rules:

1.  Consider all activities that leave an event.

2.  Subtract each activity’s duration from the LET of its terminal event.

3.  Select the smallest computed LET and record it in the lower right quadrant of the event circle.

For example, consider event 13. Three activities (13-14, 13-15, and 13-16) leave event 13. Event 14 has a latest event time of 15.5 d and activity 13-14 has a duration of 1 d, so event 13’s first computed LET is 14.5 d. Event 15 has a latest event time of 15 and activity 13-15 has a duration of 0 d (it is a dummy activity), so the second candidate LET is 15 d. The computation for activity 13-16 yields 14 d. Because the smallest computed LET is 14 d, the latest event time for event 13 is 14 d.

Why pick the smallest LET? The idea is to allow enough time for the most lengthy activity or series of activities. If event 13 actually occurs at time 15.5, event 14 cannot possibly occur before day 16.5 because activity 13-14 takes 1 full day to complete. That would impact the schedule.

Next, consider event 12. Only one activity (12-13) leaves it. The LET for event 13 is 14 d and the duration of activity 12-13 is 1 d, so event 12’s LET is 13 d.

21.4.6 The critical path

Note that the earliest and latest event times are the same for several events (Figure 21.1). Those events define the critical path, which is marked by a heavy black line. If the project is to be completed on time, the critical events must begin on time and the critical activities must require no more than their estimated duration.

21.4.7 Slack time

Activities not on the critical path can (to a point) start late or exceed their estimated duration without affecting the schedule. The extra time associated with an activity, called slack or float, is computed by subtracting from the latest event time of its terminal event both the activity’s duration and the earliest event time of its initial event:

Total slack = (LET)_t – (EET)_i – duration.
(21.1)

Slack time is enclosed in parentheses and recorded below the activity arrow (Figure 21.1). Note that critical path slack times are all 0.

For example, consider activity 6-10. The LET of its terminal event (10) is 11 d, the EET of its initial event (6) is 2 d, and its duration is 1 d. Plug those numbers into the equation and you get a slack time of 8 d.

Slack represents the maximum time the activity can slip without affecting the project schedule. If an activity begins late, of course, its available slack is reduced.

21.4.8 PERT and CPM

The project network is the foundation of both PERT and CPM.

PERT gained prominence during the late 1950s when it proved invaluable in scheduling and controlling the Polaris missile program. It is particularly useful in research and development projects where the times to complete the various activities are uncertain. The critical path is the primary focus of management control, and monitoring the critical events provides an early warning if estimates are inaccurate.

Industry developed CPM (Critical Path Method) to help solve scheduling problems when the activity times are known more precisely. Only by shortening the critical path can the project completion time be improved. Consequently, the critical path defines those activities into which additional resources might be poured to accelerate the schedule. An application of the critical path method to crash mode development is illustrated in Chapter 22.

21.5 Key terms

Activity —

A task to be completed.

CPM (Critical Path Method) —

A project management technique based on a project network; the focus of CPM is project planning, with the critical path defining those activities into which additional resources might be poured to accelerate the schedule.

Critical path —

The path through a project network that links the critical events that must begin on time and the critical activities that must require no more than their estimated duration if the project is to be completed on time.

Diverge —

To split a single input path into multiple paths.

Dummy activity —

An activity that links parallel events, but consumes neither time nor resources.

Duration —

The elapsed time required to complete an activity.

Earliest event time (EET) —

The earliest time the event can possibly begin.

Event —

The beginning or end of an activity.

Latest event time (LET) —

The latest time an event can occur without impacting the project schedule.

Merge —

To combine two or more input paths into a single output path.

PERT (Program Evaluation and Review Technique) —

A project management technique based on a project network; with PERT, the critical path is the primary focus of management control and monitoring the critical events provides an early warning if estimates are inaccurate.

Project network —

A bubble chart that graphically depicts activities, their starting and completion times, and their interrelationships.

Slack —

The maximum time an activity can slip without affecting the project schedule.

21.6 Software

Such project management software products as Microsoft Project, Primavera Suretrack Project Manager, SuperProject from Computer Associates, Harvard Project Manager from Software Publishing Company, and Project Management Workbench from Applied Business Technology support project networks, PERT, CPM, and related techniques. Such charting or drawing tools as Visio and Flowcharter by Micrografx can be used to create a project network, although the project management tools are much more effective.

21.7 References

1.  Badiru, A. B. and Whitehouse, Computer Tools, Models and Techniques for Project Management, TAB Books, Blue Ridge Summit, PA, 1989.

2.  Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont, CA, 1994.

2a.  Humphrey, W. S., Managing the Software Process, Addison-Wesley, Reading, MA, 1989.

3.  PERT Coord. Group, PERT: Guide for Management Use, U.S. Government Printing Office, publication number 0-6980452, Washington, D.C., 1963.

4.  Roetzheim, W. H., Structured Computer Project Management, Prentice-Hall, Englewood Cliffs, NJ, 1988.

5.  Weinberg, G. M. and Weinberg, D., General Principles of Systems Design, Dorset House, New York, 1988.