Tools for Managing Projects

Introduction

One of the major criticisms of project management literature is that too much emphasis is placed on network based techniques to the exclusion of a host of other tools that can be useful in managing projects. Attempts at finding references in current literature to many of the tools which are familiar from practical experience were fruitless in most instances except for Gantt Charts and network based techniques. Thus, it was necessary to rely heavily on personal experience to develop a taxonomy of tools for managing projects. There is no claim that the material presented in this paper is exhaustive but, rather, that it provides a framework to which other tools can be related by those experienced in their use.

Another criticism of project management literature is the inability to find guidance as to which tool, and which variant, to use under what circumstances. There has been some work in this direction but it has been done primarily with regard to network based techniques. It is not clear that networking is really the best technique for the highly conceptual and organic efforts that mark the early stages of a project, i.e., where tradeoffs are constantly being made as specifications are being developed. No evidence of specific research in this area was found in the literature.

Taxonomy of Tools

Basically the tools available to a project manager can be classified as formal and informal, and as techniques and practices. Table 1 shows a variety of techniques, most of which are familiar to managers but few of which are actually discussed in the literature of either project management or operations/production management. The list is illustrative rather than exhaustive.

Techniques

Lists

This is a general classification which includes listing of items. One basic list is a bill of materials (BOM). These exist in several forms including an engineering bill, assembly bill, and construction takeoff. The construction take-off makes clear the significance of the BOM as a technique for project management. The items included in the BOM suggest the work that must be accomplished to complete the project. For example, a door included in a construction take-off implies the framing of the opening, installation of the jamb, hanging of the door, and installation of the trim. While these activities occur in that sequence they may not be contiguous. Nevertheless, a construction estimator can estimate the total costs associated with that door from its listing in the BOM. The construction superintendent can identify the human and non-human resources required to accomplish the work, and each trade foreman involved can identify his responsibility with regard to that door.

There are numerous forms of task lists. Perhaps the simplest form is the “notes on the back of an envelope” listing things that must be accomplished. Calendars are generally marked with things to do. Construction projects are concluded by a set of activities, possibly unrelated to one another, commonly called a “punch list.” Sometimes cost and/or resources may be associated with each activity. If start and/or completion times are noted with each, it may be called a “time line.” While the activities may be unrelated as far as the list is concerned, the manager probably has some sense of relationship between them in his mind. Unfortunately, these are not always conveyed to other participants. If the project is of overwhelming importance to the organization, the participants may be sufficiently dedicated to per-form to schedule so this would not be a serious problem.

Table 1 .—Taxonomy of Techniques for Managing Projects

Worksheets also take various forms. Typically they combine a BOM with a task list in a matrix form. As each task is finished on a BOM item it is “x’ed” or colored to note progress. On some projects, such as writing a report, this may be about the most useful technique available. Its strength is the emphasis placed on work to be done. Its weaknesses include a lack of deadlines and no explicit estimates of work content.

Avariation on the worksheet is often called a “spread sheet.” It is similar except that completion dates are included in the matrix. Even so, there is no explicit estimate of work content and a very limited ability to determine the work load placed on the participants. An example of the “spread sheet” can be found in Morton [15, p. 37]. He recommends the use of such a form as an equipment list.

Budgets are a standard tool of most organizations whether or not they exist in written form. The typical administrative budget is structured by line expense items for a functional organizational entity. Seldom does it relate to the activities the organizational entity must perform. A project budget, on the other hand, is organized by the activities that must be performed or at least by the items that must be produced. A construction take-off, with costing completed, is a project budget. In a matrix organization, a single project budget may include only a portion of the budget for a functional organization entity. In a functional organization, project work is often controlled by a work order system. Often the work order accounts are aggregated at too high a level to be helpful in controlling individual activities. Partially as a result of this level of aggregation, but often as a result of sloppy practices, the work order accounts are not closed on a timely basis. As a result, foremen, who maintain their own detailed accounting records, charge things to open work orders until they have used up 100% of the estimate for that work order. In one application of a network based system associated with a work order system, work orders were closed as soon as the activity was completed. The analyst/estimator marveled at finding he had been over-estimating the work orders, a fact that was discovered only as a result of requiring prompt closing of the work orders as soon as the related activities were reported completed.

Graphics

Another technique reviewed which is not discussed in text books is the schematic diagram which may take many forms. A simple technique used on a housing development project involving some 750 units was based on a plot plan of the entire project. As an employee of the contractor during the summer of 1951, the author’s duties included updating the status chart described. Each house appeared on the plan in outline form. The outline was divided into several sections, each of which represented a major segment of work on the house such as “foundation poured,” “floor poured,” “outside walls up,” or “interior walls framed.” As the specific element of work was completed, the section representing it was marked with a distinctive color. At a glance, the entire project status could be seen, including the number of units of in-process work completed between each of the successive work crews. It is easy to visualize such an approach applied to the construction of the pyramids as well as the many floors of modern buildings such as the World Trade Center in New York or the Renaissance Center in Detroit.

The Work Breakdown Structure (WBS) is discussed in the DOD and NASA Guide: PERT COST [6, p. 28] and is defined in Glossary B of that document as follows:

“Project Work Breakdown Structure – A family tree subdivision of a project, beginning with the end objective and then subdividing these objectives into succesfully smaller work packages. The work breakdown structure establishes the framework for:

- defining the work to be accomplished;

- construction of a network plan;

- summarizing the cost and schedule status of a project for progressively higher levels of management.”

WBS’s particular advantage over the punch list or time line is the manner in which it relates detail tasks to successively higher order items or objectives. Although it does not show time relationships well, the start or completion dates can be noted with each element in the WBS. It is generally based on deliverable end items and their components except at the lowest levels. The lowest levels are “work packages” which consists of a set of activities related to cost purposes.

Lockwood [9] described the use of a WBS and an approach similar to the plot plan described above, which was used on the F-15 project in the Air Force. Top level management progress meetings were supported by a graph with pictorials of the components of the system shown by each element in the WBS. Project status on each element was shown by various colors in the WBS elements coded to represent the various phases of work completed on that element.

Several authors identify the Gantt Chart as the first formal technique for managing projects. O‘Brien states that, “Prior to (the early 1900’s), there had been no predominant scheduling techniques. Scheduling was done on an informal basis as an inherent part of other activities.” [17, p. 3] The Industrial Engineering Handbook states, “The first formal scheduling model used by management was the Gantt Chart.” [8, p. 8-57] Chase and Aquilano amplify on this by stating that the Gantt Chart “technique is interesting for historical reasons since it is one of the first recorded attempts to relate activity to time.” [3, p. 353]

The “Bar Chart” first gained prominence as the result of its application by Henry L. Gantt to the production scheduling at the Frankford Arsenal in 1917, primarily for manufacturing types of work. The chart develops an explicit relationship between work and time. Many variations have been developed including its application to project work; it is probably the single most widely used technique for graphically portraying a project plan on a time scale. Even so, the bar chart has significant deficiencies. It can be considered static in that it requires redrawing to make appreciable changes. On large projects it is necessary to draw the bar chart in a summary form. This factor often draws such comments as “It conceals more than it reveals!” or, to quote O‘Brien, “The bar chart often suffers from the morning glory complex. It blooms early in the project but is nowhere to be found later on.” [17, p. 5] A summary chart can be supplemented by detail charts, each covering only one or a few bars on the summary chart. Coordination of these various charts is often very difficult and certainly tedious.

Considerable effort is required to revise a schedule shown in this form. This problem has largely been overcome by making this a standard output from a network based system. The amount of information that can be portrayed, even on a 54” by 72” sheet of paper of a flat bed plotter, is limited. Nevertheless, its popularity continues, particularly on relatively small projects.

A modification to the Gantt Chart used small triangles to mark “milestones” on a bar and was called the Milestone Chart. One version is illustrated in the DOD and NASA Guide: PERT COST [6, p. 20]. The milestones represent easily identified points on one bar of a Gantt Chart, i.e., a major event. Thus, it was not necessary to wait until the completion of a major task to determine if it was in fact on schedule. Experts recommend that a project plan should be stated in such a way that there will be at least one and probably no more than three milestones scheduled per month. Apparently, the logic is that not having any milestones reported complete tends to make superiors uneasy, while more than three tends to confuse them.

Another adaptation of the bar chart, the man hour chart, includes resource estimates by bar (or activity). These are summed by day or week over all activities to obtain the resource requirements per time period. Based on the resource requirements obtained from the manhour chart, a useful graphic form is the histogram of resource requirements or resource profiles. It makes vivid the variations in research requirements and suggests revisions in schedule to avoid excessive changes in levels of resources.

The process chart is a standard technique for showing the relationship between the components of a BOM, with emphasis on the work required to assemble them. It is more generally used to portray job shop, progressive line, and continuous flow process operations. In such cases, operating times may be shown for each operation. Likewise, activity times may be shown on a process chart when it is used on a project.

It is only a short step from a process chart to a network design. If the chart is drawn from the present to the future it is sometimes called a “forward schedule.” It is the same as an early schedule in critical path techniques (CPT). If the chart is drawn from project completion backwards it is often known as a “project schedule.” This schedule is the same as a late schedule in CPT. The forward schedule is also similar to the Lead Time Chart in Line-of-Balance (LOB). Network diagrams are useful in developing project strategy and also in long-range planning for a firm. In both cases, relating activities technologically is much more important than relating them in time.

Network Based Techniques

The first evidence of a network related technique dates about 1900. Marsh [13] described the Har-monogram as developed in Poland by Karol Adamiecke, an engineer. He first presented it before the Society of Russian Engineers in 1903. This point raises a question as to the accuracy of the quotations regarding the Gantt Chart cited previously. Perhaps a more intensive effort would bring to light the use of other earlier techniques.

Critical Path Planning and Scheduling (CPPS) by Kelly and Walker, was presented in December 1959 at the Eastern Joint Computer Conference. Its origin, as reported by O‘Brien was:

“In 1956, the E.I. duPont de Nemours Company set up a group at its Newark, Delaware, facility to study the possible application of new management techniques to the company’s engineering functions. One of the first areas considered was the planning andscheduling of construction projects.” [17, p. 6]

Walker of the duPont Company, working with Kelly from Univax, made considerable progress in defining a model for determining optimal scheduling for maintenance or construction projects. “In 1958, Dr. Mauchly formed Mauchly Associated and was joined that year by Kelly and Walker.’” [17, p.7]. They successfully developed an algorithm for solving the trade-off between time and cost within a network formulation of a project.

Generally CPPS, or CPM as it is more widely known, has found considerable use in construction and maintenance due to the availability of relevant cost data and the considerable benefits associated with the application of the techniques in these areas. Its application in other project areas has not been as great.

At about the same time, the Navy was involved in developing the Fleet Ballistic Missile Weapons System (FBM), more commonly known as the Polaris system. The magnitude and urgency of this project led to the creation of project PERT (Program Evaluation Research Task) in the Special Projects Office, Bureau of Ordinance, U.S. Navy. According to Malcom et al,

“Project PERT was set up as a three phase program:

1. To perform an operations research study leading to the design and feasibility test of an evaluation system.

2. To make pilot application of the system in selected areas, and

3. To implement the system to applicable parts of the FBM program.” [10, p. 646]

The resulting technique continued to carry the designation of PERT with the words represented by the acronym being changed to “Program Evaluation and Review Technique.” From the words used in the name of the technique, it is apparentthat the emphasis was on evaluation and review of existing plans in assessing the ability to achieve various milestones in the project rather than the creation or optimization of plans.

“The coordination made possible by PERT is credited with advancing the Polaris program more than two years.” [14, p. 145] A more realistic statement might be that PERT gave the management of the project the confidence and insight to make decisions which permitted a reduction in time. Nevertheless, numerous accounts of successful results from the application of PERT on the FBM led to a strong push by the Department of Defense to have it applied on other projects. The acclaim and attention that PERT received led to considerable developmental work on the technique and its application by various agencies of government, contractors supplying the government, and firms servicing both of these groups.

CEIR, Inc., a consulting firm, developed a program called RAMPS (Resource Allocation and Multi-Project Scheduling) which, while very con-prehensive, required considerable skill to implement successfully. Not only were there numerous similar developments but also some extensions of the networking concept relevant to both real and imagined problems of managing projects.

Clearly, PERT as conventionally implemented has not fulfilled its claimed benefits, at least according to the literature. CPPS has not found wide acceptance, except in specific application areas. Resource leveling has found only limited acceptance in spite of the extensive literature on technique development. Little, if any, of the literature really addresses the problem of the lack of acceptance of these techniques on a rigorous basis. Rather, most of the problems described are really symptoms and give little guidance in the redesign of techniques to remove the obstacles. An exception to this case is the research by DeCoster [5], Schoderbeck [18], Hill [7], and Neel [16], all of whom trace much of the blame for limited use of PERT/COST techniques to incompatibilities with the accounting function.

Some discussion of the items listed under network based techniques is appropriate. Critical Path Technique was chosen as a unique name for versions similar to PERT and CPPS which use single time estimates and have no time-cost trade-off capabilities. It appears to be the version most commonly in use today.

Under resource management there are two types of applications – homogeneous resource and heterogeneous resource. The homogeneous resource classification includes most, if not all, of the literature in this area. Under heterogeneous resource there are two distinct types of problems. The first has been identified in this study as the “drafting room” problem, i.e., the assignment problem with a time dimension that considers technological precedence. The second is the dispatching problem found in an environment in which theprimary objective is efficient use of resources, but also recognizes the dynamics of the human resource as well as some of the uncertainties associated with non-human resources. DART (Daily Automatic Rescheduling Technique), as reported by Marchbanks [12], is closest to the latter problem. PERT/COST has clearly proven ineffective in its standardized form for several reasons. Unfortunately, the reasons provided are somewhat general and not substantiated by adequate research. Rather, they seem to be largely experiential judgements.

Relatively little has been said specifically about problems and deficiencieswith Line of Balance (LOB) or PERT/LOB. LOB has apparently received little practical use otherthan by the U.S. Navy. The Navy typically used it to diagnose problems on relatively small production contracts. Even though it has been computerized, no references were found to its application. The major problem with LOB seems to have been the effort required to collect all the data and to prepare the graphic display. Furthermore, in the manual mode, keeping the graphics current also required considerable effort. Siegel [19], in an interview, mentioned a report which discussed the problems with PERT/LOB. Efforts to obtain a copy of that report have not been successful. In the absence of the report it can only be surmised that either the implementation of the computer was not cost effective, that it was too complex for practical use, that other tools accomplished the purpose better, or that there was no need for such a tool. There are other tools available which do not have all these deficiencies. One such tool is Material Requirements Planning System which has become available in the last decade.

Historically the special relevance of LOB is the impact that its design may have had on the design of PERT. Both are event oriented.

While several references were found to the theory of Decision CPM and GERTS, relatively little has been documented about specific applications. A question is raised about the extent of application of this concept due to the conflict between lack of literature on applications versus the relatively frequent announcement of seminars on the use of the techniques. Due to the sparsity of the literature on applications or evaluation it is impossible to analyze deficiencies at this time.

Reliability Maturity Index (RMI) [11] seemed quite reasonable in concept as a means for tracking the completion of reliability related activities and of summarizing the results from reliability tests. It has not been mentioned in the literature of project management for several years nor was any literature evaluating its efficacy discovered in this search. Therefore, it is impossible to draw any conclusions on what should be done relative to RMI other than conduct research into its efficacy and its benefits and problems. It may have proved impractical and if so, should be forgotten.

Other Formal Techniques

Configuration management appears to be very necessary on military and space projects as a means for recording data on the specific components of a space vehicle, for example. It permits remote problem solving when abnormal behavior of the vehicle is encountered. As a result of such data, simulations made it possible to determine the corrective action to betaken on errant space missions. It is also important on most other hardware projects and on other types of projects including computer program specification and development.

Design cost control as used in the automotive industry is very similar to configuration management but with a stronger emphasis on the control of unit production costs and capital facility costs.

Both emphasize cost-benefit analysis, but it is suspected that on many defense-space contracts the benefits in terms of improved performance of the product carries more weight than unit cost. This situation is possibly due to the fact that the product does not have to compete in the market place for unit sales, and perhaps due to the critical aspects of reliability and performance in the operation of the product.

Informal Techniques

The literature is particularly sparse on what could be considered “informal techniques.” The only item included in this category is the “Tickler File.” This file is often maintained by the project manager’s secretary on 3” x 5” cards. The cards are filed by date of action, and cards may note “receive a report, prepare a report, or accomplish an objective.” When the date recorded for the action arrives, the cards, or notes from them, are given to the project manager for follow-up.

There are any number of techniques such as this which apparently are passed on via “on-the-job-training,” or which are re-invented as the need arises. It would seem that a deliberate search for such techniques would reveal many more which, if documented in a very brief and simple form, would aid potential project managers in gaining higher levels of skill.

Practices

Distinction between techniques and practices is arbitrary in many respects.Nevertheless, the listing of the practices in Table 2 adds to the repertoire of tools the potential project manager may find useful in managing projects. A more complete discussion should include some of the pros and cons of each plus appropriate caveats on their use.

Practices can be divided into written and verbal forms for discussion purposes. Often verbal practices should be followed by written recording of them to assure proper documentation and to minimize misunderstanding. They also serve to record commitments made by project participants.

Table 2. —Taxonomy of Practices Useful in Managing Projects

Written Practices

This is one of the oldest and still one of the most widely used techniques. Various styles and formats exist. Often standard categories of information are prescribed to try to overcome one of the major problems with this technique, i.e., the tendency for subordinates to report the good results and ignore the bad results and problems. The categories indicated in Table 2 under narrative reports suggest one approach to this, i.e., accomplishments, status, and projection of future plans. At times, headings such as “problems” and “assistance required” have been used to force subordinates to respond to these explicitly, even if to say ‘NONE’ to each of them.

Often there is a tendency to emphasize events rather than the work itself. Cost data may be inaccurate if derived from a conventional accounting system because of inadequate relating of costs to the work. This shortfall may be overcome with an effective work order system. Even then, accounting constraints on the number of active work orders often results in too high a level of aggregation of costs, and therefore has only a loose relationship with work progress.

Another problem with narrative reports is the tendency for them to be used for defensive purposes. Pleas for more resources, relief from too demanding technical requirements, etc., establish a basis for excuses at a later date in the event of failure to perform to specification.

The organization chart is a basic written document in most organizations used to show the major delegations of responsibility. These are infinite variations, of which functional and matrix charts are only very general classes, and also a variety of different ways of presenting them graphically. While there are a number of references on this subject, most references on project management provide a few examples and little else. Practical experience suggests that there is a considerable gap between literature and practice. This is unfortunate because organizational relationships are one of the most sensitive variables available to the manager in creating an effective organization.

The Linear Responsibility Chart, analyzing the delegation of responsibilities,, is mentioned in both C lei and and King [4, p. 271] and Archibald [1, p. 103] who refers to it as a “Responsibility Matrix.” The matrix shows responsibilities, by activity or in general, on the left, and positions or persons across the top. Various codes or symbols are used to indicate the degree of responsibility at each intersection. Note that such a matrix could be manipulated to have the degree of responsibility across the top with the cell entries representing the organizational entity. This matrix would be a very useful tool for the project manager to confirm that he has adequately and appropriately assigned responsibilities.

Both of the above tools are very concise and therefore convey a minimum amount of information. This fact can be overcome by publishing organization manuals. One such manual could amplify organizational responsibilities. Another could specify policy as adopted at various levels in the organization. The standardized procedures should also be documented.Furthermore, as the number of people involved becomes greater and the technology becomes more complex and/or demanding, it may also be worthwhile to develop operating instructions and technical instructions. Notice that this progression of more written documents also coincides with the concept of rationalization, i.e., the movement from an organic to mechanistic organization.

Reading a typical chapter in an operations/production management text would suggest that the network based plan is an adequate statement of a plan. It may be adequate in some instances, but the nominal information per activity plus the need for communicating objectives, general guidelines, assumptions, parameters, and other information to a large number of participants, makes it desirable to develop planning documents. Major projects require a detailed planning document. These are sometimes called bid packages for external clients or project proposals internal to an organization. Often additional detail is developed if the project is approved for execution. Tso [20] suggests a formal dissemination plan for education projects; other writers suggest a formal termination plan.

On smaller projects, the purpose of the planning document is often served by memoranda. Memoranda are a basic means of communicating understandings, directions, instructions, and, occasionally, reprimands and the like. While this is not necessarily a subject that requires lengthy discussion in a text on project management, writing such memoranda is a necessary skill of an effective project manager.

Verbal Practices

The most direct form of communications is through one-to-one discussion. Meetings with individuals can serve a host of purposes, not the least of which is establishing mutual rapport and conveying a sense of appreciation of the subordinate and his problem. The pressures on a project manager tend to make such meetings with many of the project participants low in priority. Because of the often lower intensity of supervision on project work as compared to job shop and progressive line types of work, the project manager is more dependent than the functional manager upon the subordinate’s motivation and consistency of thinking. This one-to-one meeting is valuable in achieving both of these goals. The meetings can often be informal, such as at lunch, on the golf course, or over coffee.

Staff meetings on projects are essential. They are the most immediate means of communication of a single message to the key members of the project team and sometimes to all members. The attendees at a meeting can vary depending on the need. Often a regularly scheduled staff meeting serves the general needs. Sometimes the needs are better met by an ad hoc meeting of only those affected in the solution of a specific problem. These meetings may include lower level participants as required. Occasionally, it may be desirable to have a meeting of a larger group of project participants to permit them to obtain a broader view of and greater identity with the project. This would certainly be consistent with Borcherding’s [2, p.244] recommendations for keeping project personnel informed of the overall concept and status of the project.

Staff meetings also serve as a problem solving forum, especially when the problems are not “owned” by a single participant. Discussions of potential trade-offs are essential to solve these problems. Perhaps less obvious but still very important are some motivating aspects of the staff meeting if handled properly by the project manager. For example, a few judiciously chosen questions by the project manager will encourage all participants to be very well informed in their own areas of responsibility. This point is especially reinforced when the first time a participant fails to be informed, the manager follows with a comment to all that “The staff meeting is a time to report on your homework, not to do it.” In one case this resulted in excellent performance in subsequent staff meetings. It could prove dysfunctional for some types of project participants, however.

The staff meetings also serve to motivate participants in terms of commitments. Few people who make commitments in front of their peers are likely to take it lightly, and as a result both timely and quality performance are likely to result. An approach that has proven effective in a project environment is to require participants to verbalize their plans for the next period. It is also important in that it conveys a reasonably accurate assessment to the project manager of what the participant understands he is expected to do. Without this the project manager has no assurance that the participant understood what the project manager said. Lack of understanding by the project manager of what the participant proposed is very likely to be followed by immediate questions and discussion. If the participant’s understanding is at odds with the project manager’s desires, corrective action can be taken before resources are expended. This is especially important in the project environment due to the non-repetitive nature of projects as well as the tight time and cost constraints generally applicable.

One practice which is well documented that has proven effective in meetings for certain purposes, is “brainstorming.” It is particularly useful in developing original ideas for solving difficult problems. It may also be effective in discussions leading to the development of strategic plans.

Another practice that has proven helpful, if not essential, is plant visits. The announced visit will encourage clean-up of loose ends. The unannounced visit will disclose the loose ends. The effective project manager will cultivate personal relationships with plant personnel and, as a result, discover in undirected conversation problems of which he would not be informed through formal channels. While he must be careful about giving orders outside the formal structure, often appropriate questions and involvement in problem solving will elicit cooperation that cannot be achieved otherwise. Sometimes he will discover the possible existence of a problem in another area. The reliability of information obtained in this manner should be considered suspect. Nevertheless, it can often be the basis for establishing hypotheses which the project manager can then pursue to either prove or disprove the problem’s existence. Care should also be exercised to avoid disclosure of sources to prevent possible reprisals. This can be done easily if the hypothesis testing approach is pursued in a subtle manner.

Other Practices

There are other practices which might more appropriately be called strategies and tactics. One of these which has proven generally effective was given the name “ag-pos” for agenda position. It was suggested that items which may meet with controversy or objections be placed at the end of a long agenda of a meeting scheduled in such a way that meeting participants will be anxious to adjourn by the time that item comes up and will therefore be less inclined to object or even discuss at length. There are many such practices which should be researched and documented. While some of these may seem devious, they must be viewed in light of the project manager’s primary responsibility of getting the project completed. Deliberate discussion of these would lead to a better differentiation between those which may be devious and those which are really unethical, immoral, or illegal.

Integrated Management Information and Control Systems

Finally, there have been references to “Intergrated Management Information and Control Systems” (MICS) in texts on the management of projects. Generally, such references are very optimistic about the benefits to be derived. There are at least two sides to this issue. On the one hand, the general literature in which MICS are discussed indicates a strong note of pessimism. Much of this is warranted due to the tendency of many writers to suggest that MICS may be the new panacea. A more realistic assessment recognizes that formal systems can only do a part of the job. Inherent time delays and biases limit their effectiveness. Inability to store all relevant information limits the potential considerations. They must be supplemented by informal techniques and practices which are more timely, more sensitive, and more qualitatively oriented such as meetings or plant visits.

On the other hand, there is no question that one of the serious problems associated with the management of projects is the disjointedness of the various information systems involved. Often, pieces of the systems are computerized. To relate data from one with data from another often requires extensive manual effort. Perhaps a totally integrated system, as is often envisaged in many articles, is unrealistic. Certainly some additional degree of integration does seem desirable. The findings of DeCoster [5] and others make clear that major problems in this respect have existed in the accounting systems. The author’s experience has been consistent with these findings. Thus, it seems that considerable work is warranted to gain an understanding of the possibilities, benefits, and potential problems associated with higher degrees of integration of project management information and control systems.

Conclusions

Literature on the management of projects has tended to focus on just a few techniques and practices at the exclusion of many very useful tools. The preceding discussion provides a review of a number of tools found useful in practice. The author would be interested in communicating with others having an interest in extending the lists and/or providing documentation, caveats, and descriptions of experiences associated with these tools.

¹Dr. John Mauchly was the co-inventor, with J.P. Eckert, of the firstall-electronic computer, Eniac. He was responsible for applications research at UNIVAC prior to starting his own company.