Choosing a computer system for project management
This paper describes the criteria for selection of a computer software system for project management and some possible sources of such systems. It discusses common misconceptions concerning the need for project management systems and the cost of the selection process.
The initial assumption for this discussion is that the need for a computer system for project management has been established. This means, at least, that manual methods have been considered and rejected for the project at hand..
A. ‘Computer System’ as we normally use the term, really means a computer based system, including the computer programs, the computer, and those elements outside the computer which are required to make the system work. This should include the people who are a necessary part of every system. In this discussion we will confine our remarks to the computer programs themselves. The selection process must, of course, give consideration to the other system elements which influence the choice of computer programs.
If we view a project management system as a ‘management information system’ we must examine the implied assumptions frequently taken as a basis of systems designed to provide information for management. To be specific, consider the fact that:
1. It is usually assumed that managers do not have sufficient information. It is more likely that they have too much irrelevant information already, nevertheless we tend to design systems to increase the volume of information, without regard to relevancy! We should consider the elimination of irrelevant data a prime requisite of any system we select. In other words, the system should filter and condense the data so that its information value is increased for the manager who is expected to use it. Most managers already receive much more data than they can possibly read, much less absorb; therefore our system should not add to the problem of filtering out the important information from the trivial.
2. It is usually assumed that the manager needs the information he wants. This assumption implies that managers know what they need. Consider the following: For a manager to know what he needs for each type of decision he makes he must be aware of each type of decision he is supposed to make, those he actually makes, and those he is not supposed to make. Furthermore, he must have an adequate model of the first two categories. While most managers do have some conception of the types of decisions they make, they usually do not consciously consider the fact that the less we understand a given phenomenon, the more variables we require to explain it. Therefore; rather than admit, even to himself, that he does not understand something he controls, the manager will usually ‘play it safe’ with respect to information and requests every bit of available data, regardless of its information value. The problem is to recognize that we cannot specify the information required for a given type of decision until an explanatory model of the decision process has been built and tested. Since this is seldom done (or even possible), our alternative is to challenge the need for every piece of data that is requested.
3. It is usually assumed that if we provide the manager with the information he needs, then his decision making will automatically improve. This is true in many cases, but in the case of the complex decisions required in sequencing and network problems there are too many possibilities to expect experience, judgement, or intuition to provide good guesses, much less optimal solutions. It is, therefore, necessary for us to provide either decision rules or performance feedback so that the manager can learn from his mistakes.
4. It is usually assumed that if managers receive some information about operations outside their span of control, communication between them will improve and overall performance will improve because they will then co-ordinate their decisions more effectively. This is seldom true, particularly if the measures of their performance put them in conflict with each other. The result is often finger pointing, accusations, and poor overall performance. It is, therefore, necessary that we consider organizational structure and performance measurement before we let our system permit free flow of information between parts of the organization.
5. It is usually assumed that a manager does not have to understand how a system works in order to make effective use of it. As a matter of fact, we often use this argument to ‘sell’ systems to managers, so we succeed in keeping them ignorant of the ‘technical aspects’ of the systems they are using. We may agree that the manager need not be concerned with the techniques of computer programming, but the manager who does not understand the logic of the system to the degree that he knows what to expect when any change is made in the input data, runs the risk of being controlled by the system rather than controlling it himself. We must, therefore, train managers in the ‘technical aspects’ of the system. Managers who are not willing to invest some of their time in learning ‘how the system works’ are not likely to make good use of the system, and they may, in fact, make worse decisions with it than without it.
Criteria for Selection;.
In considering the choice of a system, we must consider the motivation for using a system at all. The two major functions in project management are planning and monitoring for control. The opportunity for using the computer for profit enhancement occurs only in the planning phase of project management, while the monitoring or control phase is profit protecting (or cost reducing) in nature. Both uses of a computer are defensible, but the former probably explains why the stress is usually placed upon the improvements in planning which are a natural consequence of using CPM or PERT as a project management tool. It is the selection of appropriate CPM or PERT (or similar systems such as PMS and TOPS) computer programs with which we are concerned here. Now that we have established some basic ground rules, let us examine some of the criteria to be considered in making the selection.
1. The first consideration in our selection process must be the nature of the project and the requirements it will place upon the system. A one-shot planning job will require a vastly different system from a long term construction project which we wish to monitor, while a long term construction project for a tract of residences will require a different system from a long term construction project for an oil refinery. The program characteristics influenced by the project type include:
- Whether the system is activity or event oriented.
- The number of activities it will accommodate.
- Whether the system permits a heirarchy of networks.
- Whether the system permits periodic updating with progress data and/or changes in the network.
- Whether the system permits the inclusion of cost data.
- Whether the system provides resource allocation and/or levelling.
Once the basic kind of system is decided upon, the field of search will be narrowed from hundreds of possible programs to as few as a dozen or so. (Possibly as few as three or four if we require an interactive on-line system or one which optimizes the schedule)
2. The next major consideration is the user environment. (Please note that these criteria will not usually be applie sequentially, but they are listed sequentially because It is not possible to discuss a subject meaningfully in parallel!) If a system is to be used exclusively in an engineering planning office we can assume that the intellectual level of the users will be generally higher than that of users who are primarily native construction bosses in the hinterlands of South America. This influences the type, format, and amount of input and output data we can consider reasonable.
3. We must also consider the amount, frequency, and format of the output data required. Are we concerned only with time schedules, with time and cost, do we desire or require graphic output, etc.? Even though many programs will produce similar output data, some will offer several orders of magnitude of flexibility over others. For example, we must determine whether it is important to be able to request the same data sorted by different keys. (A schedule sorted by earliest start date may serve one purpose, but the same data may be more useful for another purpose if it is sorted by slack time.) Bear in mind that most people still tend to believe numbers that appear on computer printouts simply because they are on computer printouts – we have the compound deification of the computer and the printed word, giving credence to sometimes incredible data – so extra annotation, explanatory notes, etc, are usually worth the extra effort. This factor must also be weighed in considering…
4. The input data required. The sheer volume of input data necessary to feed some programs is overwhelming. We must give serious consideration to the discipline required in preparing and controlling input data. This is one of the key factors in the useability of a system. In general, the more difficult it is to prepare data for input to a system the less acceptance and use it will receive. This is particularly true of systems which rely on field personnel for feedback data. A few systems permit free form input (as opposed to rigorous field and column restrictions imposed by most systems).
5. Once we have selected a system which is well suited to the project, we must consider the availability of the system. Is it available in time for us to use on a specific important project? Is it available in a useful form? i.e. Is the source language available to us? If so, are we free to make modifications to tailor the system to our needs? What is the computer and configuration required? Do we have a compiler for the source language? Can we get it at no cost, lease it, or buy it? Is there a tie-in between the use of the program and a processing service? How well documented is the system? These and many other questions must be answered before we can answer the basic question of whether the system is ‘available’ for our use.
6. We must also determine whether a computer which will run the program is available to us. Will it be run on an in-house computer? A service organization? At field locations? In foreign countries? Obviously a program is of little value to us if we can’t conveniently run it. Depending upon the terms under which we can acquire a desirable program, we should examine the possibility of modifying it to run on an available computer and — a consideration sometimes overlooked — whether the program will produce (or can be modified to produce) output cards or tapes which are compatible with another program or computer which may be used at another location for updates.
7. Training is an important question in selecting a system. How well documented is the system? How easy will it be to train a systems analyst (or programmer) to a level of knowledge that he knows the internal workings of the program? If we are going to use a complex system we need someone who can dig into the system to find out what happens when the output is not what was expected. The scheduler or the man who prepared the input doesn’t know or care about tricky programming techniques that may be sensitive to certain combinations of data, but we do need someone who can diagnose this kind of problem. We must also consider the problem of training the users of the system, field personnel who may be involved, computer center personnel if it is to be run on an in-house computer, sub-contractors who will be involved, and if the project involves client personnel or client management, they must be able to understand the system output. (This may be the best communication vehicle available for the client/ contractor relationship.)
8. Finally we must consider the costs involved in the selection process. There are several costs to be considered:
a. The cost to acquire or use the system. This may involve the cost to develop a system to specifications from scratch. This could be as much as several hundred thousand dollars and take a year or more to complete. Some systems are available for outright purchase, some are available on a monthly lease basis, some are available at no cost from computer manufacturers, the Federal Government, or from service organizations. Those which are available at on cost from service organizations usually are available with the condition that the service organization process the data (for a fee, of course).
b. The cost to run the programs (there may be several programs in the system). This cost may be the cost for the computer time involved, or it may be on a per activity, per node, per printed page or line of output, a combination of these, or some other basis. If the cost basis for running the program is to be for the computer time required, then we must consider the efficiency of the programs; whether parts of the system can be run without others if we want partial output, and whether restart and recovery procedures require complete re-runs from the beginning or will permit recovery from the point of error.
c. The cost of preparation of the data for the initial network run and the cost of collecting the data for the periodic input must be considered. The variations in input discussed above all influence costs.
d. Special forms may be required for either input or output. This can be a significant cost in some systems.
e. The cost of maintaining and policing the system must be considered and may be a significant factor in selection, i.e. Does the system require a separate organization to keep it going or can the line organization make it work effectively.
Sources of Computer Programs.
While we have alluded to several possible sources of computer programs, it may be worthwile to elaborate. The source we look to, once we have determined what the general specifications of the computer programs must be, will be governed somewhat by whether we have an in-house computer and whether it can, or should be used for processing the project control system. Where an in-house computer is available, the computer manufacturer should be consulted to determine whether a useable program is available at no cost. The manufacturer will usually provide assistance and training in the use of systems it provides. Some manufacturers are now charging for some programs they offer. If that is the case, their programs should be evaluated against those available from independent ’software’ houses.
If the system is to be used on a project that is partially government financed, or if the company is a government contractor, good programs may be available from the Federal Government. (In fact, the program characteristics required may be called out in the bid specification if the project is being performed for a municipal, state, or Federal Government agency.)
Many ’service bureau’ or ‘consulting’ firms have very good programs available for use by their clients. The availability of these is usually tied to a processing service, however, but they are worth investigating.
The last alternative should be the in-house development of a system from scratch. It is, of course, possible that the system requirements are such that no existing and available system is adequate. This is an unlikely possibility unless the requirement includes sophisticated graphics, extensive on-line interaction, or inflexible requirements of input, output, and scheduling techniques.
The cost of the selection process itself must be considered. In order to evaluate alternative systems properly, it is mandatory that we use our own data rather than test data supplied by the vendor of the program. It is desirable to use a completed project if we have sufficient data (perhaps a project for which a different system was used), or to generate our own test data including typical user errors in the input data.
Each report should be checked in detail and the consequences of several types of errors should be examined.
The same test cases should be used for evaluating alternative systems, whether the choice is between processing services or programs for use on an in-house computer.
The cost of the selection procedure, if it is extensive and thorough, may range from several hundred to several thousand dollars, so obviously it should be planned with care.
Finally, we must consider the question of who should be involved in the selection process. Obviously, since we are selecting computer programs, someone competent in programming must be involved; however, he would be involved for the purpose of technical evaluation only. The key person in the selection process should be the manager responsible for the project. The programs will be a tool for his management of the project. He must determine the extent to which other project people become involved in the selection. A technical team may be selected to narrow the field of choices, but the ultimate, in-depth evaluation of the final alternatives must involve the project manager extensively if he is to benefit from the system. To repeat an earlier statement: Managers who are not willing to invest some of their time in learning how the system works are not likely to make good use of the system, and they may, in fact, make worse decisions with it than without it.
There are three networking techniques commonly used as project management aids in planning and scheduling. These are CPM, PERT and PDM. While there are a virtually limitless array of bells, whistles, embellishments, gimmicks, devices and “brochure claims” associated with proprietary or modified techniques and programs, each can be placed in one of these three categories. When this is done, it becomes starkly evident, in most cases, that all the proprietarieness was added to get around, disguise or overcome a shortcoming or disadvantage indigenous to the basic technique.
Project managers are often deluged by self appointed experts touting their particular system or, more frequently, the one they’ve used and with which they feel comfortable. To the best of my knowledge there has not appeared an even modestly comprehensive tabulation or comparison of technique features, most program features resulting from being based on that technique and of the influence the project characteristics or demands can have on technique (and thus program) suitability. The attached tabulation attempts to do this for the three basic techniques and is believed to be self explanatory. Hopefully it is prepared in a form that will enable the project manager to separate chaff from wheat, decide what’s best for his current project and all this without getting tangled up in algorithms, core requirements, computerese expressions for features or results he needs, and schedulers or salesmen oratory.
One question that frequently is asked relates to the differences between PERT and CPM. The usual answer is that there were some early differences but that these have pretty much disappeared. I disagree strongly with this statement. There are some basic differences which, while they can be overcome or blurred in manual use of the technique, strongly influence the computer programs and techniques based on each technique. A perusal of the tabulation of Features of Networking Methods will reveal some major differences. I personally believe the differences result from one fundamental difference of the environments in which they were developed. CPM was developed to enable directing and scheduling the efforts of a cohesive group with a relatively common goal, not too disperse geographically, with good clean lines of communication and a relatively uniform consistent (corporate or at least project) set of procedures and methods. PERT was developed to enable the monitoring and displaying to all concerned the effects of efforts of autonomous groups with multiple (sometimes conflicting) goals converging only in general at the higher(est) levels, quite disperse geographically, with very structured (torturous) and extended lines of communication and with a very wide diversity of procedures and methods (sometimes conflicting for any one group) which had to be satisfied. These differences remain embedded in the philosophy, terminology, techniques, computer programs, applications and literature of the two techniques though time, cross-pollination and practice has blurred many of the early sharp distinctions.
* independent consultant, Houston, Texas