INTRODUCTION
In 1957 Dupont developed CPM scheduling, and in 1958 the U.S. Navy developed PERT. The twenty or more years since then have seen an explosive growth in the use of project control systems.
- Projects have gotten larger and more complex technically and organizationally;
- Computing capabilities have increased dramatically;
- Complex, innovative project organizational forms have emerged, like multi-level matrices, while use of behavioral techniques, such as group therapy and conflict management, have become widespread.
While developments in computing capability have had a wide impact on project management, affecting the whole range of projects from city construction to multibillion dollar superprojects, it may well be the increase in the complexity of the project management task that has proved the most sigificant development. Projects tend to be larger, using more sophisticated technology, with more complex organizational forms affecting more and increasingly sensitive members of the public, and often built in more remote locations than they were twenty to twentyfive years ago.
It is in this new context of project management that this paper reviews current concepts of project control systems and their management.
THE PROJECT MANAGEMENT CHALLENGE IN THE ’80s-COMPLEXITY
Exhibit 1 lists some recent major projects. While the size of these projects is staggering, size alone is only one of the characteristics which impacts the difficulty of managing today’s projects. Others include:
- The complexity and volatility of projects and their environments.
- The extent to which technology is state of the art and involves R&D.
- The presence of external factors, such as government regulation and physical environment, constraining management.
- The extent to which size (physical, manpower, financial) exceeds a previously established threshold for the industry, technology, enterprise, etc.
Evidently only a tiny proportion of today’s projects suffer from all these factors simultaneously, but many — particularly the more important — suffer from at least one or more of them. It is much more common now than ten yeras ago to say find contractors working overseas, owners being drawn into the direct management of their projects, or government regulation significantly affecting the project.
Thus, project management in the 1980s differs from that twenty years earlier insofar as it generally demands broader and more senior management skills than it did before. The challenge of project management is now, as it was in 1957-58 to bring the project into scope, on schedule, and at minimum cost. Only in today’s environment, doing so requires expertise in handling a wide range of societal, government, labor and other issues, and more attention to strategic matters, such as government coordination, R&D management, logistics, organization design, etc., than it did previously.
SELECTING APPROPRIATE CONTROL
Control, in this more complex environment, is also tougher now than it was twenty years ago. Control techniques now generally focus on all phases of the control cycle —from initial planning to progress monitoring and review —applied to the total project process. The emphasis is less on reporting systems per se; and there is a greater appreciation of the need for different types of projects.
(a) The System as Process
In the early 1960s, U.S. Secretary of Defense Robert McNamara ordered a review of current project scheduling and and control systems. As a result, greater standardization of systems and techniques slowly emerged in the Department of Defense (Navy, Army, Marines, Air Force and Defense Supply Agency) during the decade.
Exhibit 1
Some Recently Completed Projects —
and Approximate Costs
In the late ‘60s, a new team —Melvin Laird and David Packard —took over at the Department of Defense (DOD). A primary concern of both Laird and Packard was that there should be greater decentralization of decision-making within the Department. In consequence, more attention was given to the role of the project, or program manager in the total acquisition process. DODD 5000.1 was the now historic result.1 DODD-Department of Defense Directive —5000.1 details the actions of a project manager through the total project cycle, including authorization thresholds, milestone review points, base organization and responsibilities of definition.
(b) The Appropriate Use of Sophisticated Reporting — Managing Large, Complex Projects
The systematic application of a project management process, as outlined in DODD 5000.1, undoubtedly helps management better control projects. Sophisticated reporting systems, on the other hand, have a more limited use. The greatest value of sophisticated reporting systems is in the monitoring of project performance; and it is the large, complex projects that benefit most from their data handling capacity rather than the smaller or simpler ones.
DOD, NASA and DOE (The U.S. Department of Energy) now all use the earned-value approach to project control known as C/SCSC (The Cost/Schedule Control Systems Criteria).2,3 More a system performance specification than a system per se, C/SCSC delineates 35 principal (100 plus sub-) criteria defining the system characteristics and management processes to be used on major projects or system acquisitions. But even here, in the specific area of reporting systems, two things stand out: one, the emphasis on performance specification and process rather than defining a particular system; and two, the application of the system on large projects (DOE specifies C/SCSC for projects of $50 million plus) rather than all projects.
(c) The Appropriate Use of Sophisticated Reporting — Strategic Control
Even on large projects, however, sophisticated reporting systems are not always the most appropriate means of reporting. They are more suited to periodic, strategic control than to field, tactical control.
The effective project manager will use a small number of back-of-the-envelope “key variables” for field control — inches of tunnel bored, feet of pipe laid, yards of dirt moved, meters of concrete placed. These daily tallies are quite adequate for control over workface progress and are the real drivers at the tactical level. They are, however, insufficient for comprehensive control over the total project.
Project-wide control involves measurement of periphery activity in addition to these key drivers. These may include direct measurement of progress, such as drawings approved, changes approved, equipment inspected and transported, camp capacity, permits approved, budgets committed, etc., plus support analyses such as forecast schedule completion and final cost, the safety record, staffing, weather, inventory levels, equipment downtime, etc. Clearly, the provision of this level of ’strategic review’ is considerably more complex than the simpler field control. As such, it requires more sophisticated data handling capability.
Most projects can leave this level of control to periodic review by senior management, but where the project is sufficiently complex, it may be required more frequently.4 Hence, many projects now have field operations directly linked, by land lines or satellite, to their support offices. The extreme, of course, is something like a space shot which requires on-line strategic control. In cybernetic terms, control can only be obtained if the variety of the controller matches the variety of the situation to be controlled.5
Recently, the concept of project strategic control has undergone a significant expansion, particularly for international projects. International investors today are extremely sensitive to the level of “Country Risk” a country poses (politically, economically, etc.)6 Now, however, there is a growing realization that the broader business factors associated with a project must also be appraised and monitored in detail for effective project control. As a result, both owners and investors are broadening the scope of their strategic project control to buttress their revenue-return models including such factors as start-up activities, labor (availability, training, performance), spares, marketing, servicing, etc. These are then integrated with the plant construction control system to provide a more comprehensive forward-looking control. Multilevel systems of this size and complexity are not easy to develop and install, however, and should be approached with caution. They are not too common, and apply mostly only to the very large capital expansion projects.
(d) Small computers
At the other end of the scale from such megasystems, continuing developments in small computers (mini- and micro-computers) during the last few years should have a significant impact on the way systems are used and projects are managed in the future. Miniturization is rapidly reducing the cost of computing. As a result, small computers are now being used by an increasingly large number of project managers on both the small as well as the larger projects.’ And while most of the minis currently available use relatively simple planning and control routines, more impressive mini control systems are now emerging. With this greater availability of computing power at the workface, we can anticipate a shift in the location and frequency of strategic project review. Small computers will allow more frequent review of the project’s strategic position by project and line managers. However, while there are benefits in this development, there are associated dangers. Small computers may bring with them overdelegation and the temptation to managers to overreact.
MANAGING SYSTEMS TOWARD APPROPRIATE CONTROL
The size and sophistication of project planning and control systems, then, are determined by the degree of project complexity. How does one obtain such systems?
And to what extent should project management personally be involved in the system development and implementation?
(a) Characteristics of Successful Systems
The selection (or design) of the project control system and its implementation require full management attention —but not necessarily from the project manager. Installing a control system is a (sub) project in its own right, with the (sub) project manager preferably being the head of planning and control. As such, the requirements of a successful system installation project ideally include that:
- The system requirements must be specified very early on with clear identification of different user levels (top, medium, site, etc.) where appropriate.
- The design and installation process must be planned.
- Adequate time and money must be allocated for system installation ($15,000-$50,000 for simple mini-systems; $100,000 minimum for mainframe systems for most medium/large projects; up to $1 million-plus for sophisticated systems).
- The system installation effort must have organization to support it.
- Adequate time and plans must be made for training users of the system.
- Manual procedures for obtaining and preparing data must be developed.
- The system should be installed, tested, and loaded with live data by the time major commitments are being made, if not before.
And what about the system itself? The time-honored characteristics of a good system are:
- That it provide timely data,
- which is appropriate to the users’ needs,
- and is of good quality.
- Data must be compatible and, to the extent appropriate, subsystems should be integrated.
- Costs should be reasonable.
(b) Off-The-Shelf Versus Development Systems
There are now many systems commercially available that perform most of the functions required by a typical project control system8 (engineering control, purchasing, transport, inventory management, quantities measurement, productivity, networking, accounts ledger, cost control, accounts payable, cash forecasting, etc.). For most system implementation situations, it is therefore generally more efficient to purchase off-the-shelf systems than to reinvent the wheel, albeit in most cases it is necessary to fine-tune the system to the projects’ particular needs, write manual backup procedures, or even integrate two or more off-the-shelf systems.
New system development may be worthwhile if the project needs are such that adaptation of commercially existing systems is very expensive, or if sales of the new system could offset its development costs. Large new systems may be needed on very large capital investment projects, where the project control system might be a major part of the enterprise’s MIS.
(c) Systems Implementation—A Case Study
A heavy industry plant is being constructed in the interior of Brazil. Early in the project, management recognized that it would require a sophisticated, multilevel planning and control system for the project. In particular, it recognized that the system had to be topmanagement oriented and, especially in the early years of the company, the system would have to act as the core of the company’s MIS, integrating data on all aspects of the company development —corporate planning, recruiting, finance, operations planning, startup, etc.
A planning and control department was set up with immediate responsibilities of (a) scheduling, (b) budget preparation, and (c) systems definition and implementation. Outline design of the system incorporated:
- Integrated cost and schedule systems;
- Automatic cash flow forecasting;
- Identification of three major reporting levels;
- Definition of scheduling technique (precedence) and cost reporting principles;
- Integration, through the project account code, with engineering drawings, procurement, and finance.
The manager of the planning and control department became the project manager of the system development project and a special project unit was set up to develop and install the system. While networks, budgets, and manual procedures were prepared, work on the system divided into parallel work on defining the account code and developing compiler and program software. A system induction workship was prepared.
Actual implementation of the system took longer and cost more than originally planned, for reasons that bear study since they are typical of systems installation on many large, complex projects.
- Developing the software and account code to the degree of flexibility required proved more difficult and took longer than originally envisioned.
- Personnel could not be released in sufficient numbers to test the system to schedule.
- Delays by top management in approving the budget also meant delays in loading the system with live data.
There are two drivers underlying these difficulties. First, project control systems of this level of sophistication and complexity really are technically difficult MIS projects. Integrated data base systems of this type are among the hardest software systems to build. Consequently, delays and difficulties in implementing large, complex project control systems are the rule rather than the exception.
Second, and perhaps more significant, the system implementation is just one of a number of subprojects, all of which have to be balanced and tied together toward the overall needs of the project. To achieve optimal performance of the project, some sub-optimal performance of the system implementation process may be required. Control systems are not the sine qua non of control; management is. Delaying approval of the budget and not providing additional resources, while nonoptimal for the control system implementation, was the appropriate strategy for the project as a whole.
SUMMARY
Project management today must operate in a complex, constraining, uncertain environment. As a result, the project management task is itself more difficult and complex. In this more complex environment, control is treated in its broader context of the planning and monitoring of the total project process. Project control systems are of value but require careful design or selection. In many instances, informal controls and simple systems are the most appropriate control mode; sophisticated control systems are the most beneficial in the strategic monitoring of large, technically complex projects.
Developments during the last ten to fifteen years have strikingly influenced both sophisticated and simple control systems usage. Satellites now beam data between project offices around the globe; megasystems on large capital investment projects integrate project data with other information on the enterprise to provide total venture development tracking systems. At the other end of the scale, miniturization is allowing smaller, simpler systems to become increasingly available on micro- and mini-computers. But while the likely greater use of minis should prove of considerable value to the project manager, there are potential dangers of overdelegation and overreaction in their use.
Sophisticated project control systems are difficult to install, partly because they are typically technically complex, and partly because their implementation must be phased to the needs of the project as a whole.
* * * * *
This is an extract of a paper presented to the Conference “Financial Policy and Control in Construction Projects”, the papers for which can be obtained from the C.I.C.C. Bookshop, P.O. Box 31, Welwyn AL 6 OXA, United Kingdom.