Over the next two years, at least a couple million people in the U.S. and Canada, and more elsewhere in the world, will be introduced to project management software. They will be introduced to a new vernacular and new concepts.
What will their experience be like? Let's think about it for a bit.
Do we really know what we mean when we use this vernacular? Consider trying a little experiment. Explain to someone who is not familiar with Modem Project Management (MPM) the difference between a PERT network, a CPM network, and a Precedence diagram. Perhaps it would be best if you stopped reading this column at this point so you will not be prejudiced by anything that follows.
As a diversion from technical jargon and as an illustration of the subtleties in the use of words in the English language, consider three similar words. They are perhaps the most misunderstood triplet in common usage—and the pet peeve of this editor. What does the following sentence really say?
“I assure you, I will ensure that it will be insured.”
Actually, it illustrates the three words very nicely—assure, ensure, and insure. Those who know more about language than this simple-minded engineer may argue the fine points of etymology. Nevertheless, until very convincing arguments are presented to persuade this editor from Missouri (stubborn as a mule) to the contrary, you can depend on the following usage of these three words in PMI publications.
Insure is the simplest. It implies pooling of risks, generally through the payment of a premium for insurance. Thus, “I will insure the project against late completion.”
Ensure means that “I will see that it is done.” Thus, “I will ensure that the project is completed on schedule.”
Assure (not to be confused with “assume,” no matter how you choose to spell it) means simply “I give you my word.” Thus, “I assure you it will be completed on schedule.” It is a commitment as serious as a contract in many parts of the world.
Clearly, if your boss writes a memo saying, “Assure me that you will ensure that it happens,” it does not mean that you should take out an insurance policy and hope you don't have to collect on a claim.
Now, back to the MPM vernacular. What's the difference between a PERT network, a CPM network, and a Precedence diagram? Does it really matter? It could! But perhaps there is a more definitive way of thinking about it.
Let's look at the roots of the three terms.
PERT (Program Evaluation and Review Technique) was originally an event-oriented diagram to which now well-known arithmetic was applied to find the set of events known as the critical path. If these events were not performed to schedule, i.e., their calculated early dates, they could delay completion of the project. By estimating three durations-optimistic, most likely, and pessimistic—for the activities represented by the arrows between events, the expected completion times and variances can be calculated for the events on the critical path and for the end event. Assuming the Central Limit Theorem applies on the critical path, this permits some inferences about the probability of completing the project on any given date. By popular usage, i.e., using a single estimate for duration and focusing on the activity, PERT-type systems were actually used as activity-oriented with a fixed duration for each activity. Thus, it is correct to refer to the network as activity-oriented in common usage and describe the network diagram as activity-on-arrow (AOA) oriented.
PMs
Thus, to be historically accurate, we should use “PERT network” to refer to an event-oriented network. If, on the other hand, we are referring to the calculations that permit the probability inferences, we really are not talking about a “network” per seas the probabilities are not dependent on the type of network but rather on the type of data and calculations that are performed.
CPM (Critical Path Method) was actually a simplification (a single time estimate) of the technique which should be called CPPSS (Critical Path Planning and Scheduling System, the title of the paper explicating the time-cost tradeoff procedure). CPPSS, and therefore CPM, was activity-oriented and, from the beginning, the network was AOA. Thus, when we refer to CPM, we are really implying the simplest procedure of using one duration estimate per activity and calculating the early and late finish and start times for each activity. (Note that academicians continue to use CPM as the name of time-cost tradeoff calculations in spite of both historical facts and popular usage.) This procedure is independent of the specific network diagram used.
Precedence diagraming was developed in the United States by Professor John Fondahl (a comparable development took place independently in France). The essential distinguishing feature of precedence diagraming is that it is activity-on-node (AON) oriented. With the momentum of the U.S. Department of Defense (DOD) and National Aeronautics and Space Administration (NASA) pushing PERT and Mauchly Associates marketing CPM, AOA became the dominant graphic convention in the U.S.
There was another feature of Fondahl's work which seems to have been tied to the graphic convention of Precedence diagramming—overlap of activities. For example, a follower of an activity could start before the predecessor was finished. Start or finish of the follower activity could be related to the start or the finish of the predecessor. Actually, the overlap calculations are not tied to the network diagram but rather to the alternative logical relations between activities in the calculation procedure, a procedure that has been used with AOA networks as well.
There is another characteristic of network diagrams that is associated with this issue, the identification convention. PERT and CPM both used event codes to identify activities, i.e., the “i-j” convention. This is applicable only to AOA networks. Precedence diagraming used AON graphic convention and thus the “i-j” notation was not applicable. An alternative identification convention was required, precedence notation. In this, the logic of the network is described by naming the activity and either its predecessor activities or successor activities. But, note that this identification convention is also applicable to AOA graphic notation and it negates one of the reasons for using “dummy” activities.
It should be stated here for clarification that, while AOA dominated U.S. usage from 1958 till sometime in the ‘80s, AON dominated in Europe from the beginning. Interestingly, AON became popular in the U.S. largely because of, or perhaps more accurately concomitantly with, the advent of personal computer programs that offered that convention. We say “interestingly” because there is nothing inherent about the PC that facilitates use of AON vs. AOA. Anyone having specific insight into this phenomena is invited to communicate with the PMNETwork.
Thus, there are three dimensions that really describe the representation of a project in a network: graphic convention (AOA vs. AON), focus orientation (activity vs. event), and identification convention (“i-j” vs. precedence). while this would normally give eight combinations, only six are valid as “i-j” identification is only applicable to AOA notation.
So what should we do?
Why not call it what it is, a Project Network! All six valid combinations of the three conventions are project networks. If more precision is appropriate, then perhaps it would be useful to preface it as an AON Project Network or AOA Project Network.
Some readers may wish to present a different point of view than that expressed here. As always, we invite letters to the editor, especially when they are aimed at clarifying issues in the project management profession.
Here's to greater precision in the use of language!
