Project management, and therefore project managers, have been with us since the dawn of time. One of the earliest project managers was Noah, and the pyramids had a platoon of them. Many major programs and projects over the years have had their brilliant project leaders — but it remained for the analytical emphasis introduced by operations research to lead to better recognition of this form of organizational structure.
Within the O.R. era, the first — and one of the greatest — examples of project management was the Manhattan Project. Subsequent aerospace successes in the Polaris program, Apollo program, and many others have underscored the goals that can be attained using the project management structure as a vehicle. (Less fortunately, programs such as the C5A, and the F-11 sweptwing fighter-bomber have demonstrated that under project management, primary objectives may be met but other important facets such as cost may yield disappointing results.)
Recognition that project management exists should carry with it equivalent recognition that project managers exist — and are part of the management team. Experience indicates that the project manager has the game and the name — but not the recognition of his managerial role.
In all of its wars, the United States has benefited from the emergence of a special kind of project manager, the non-commissioned officer. In the infantry, the sergeant is the one who leads at the implementation level. For a number of reasons analogous to industry, commerce, and business, these non-com project managers (and their officer counterparts) had certain special problems.
Although their importance was implicitly recognized, the recognition has a substantial element of reluctance about it. Much of the recognition was by default, sometimes becaue the traditional infrastructure didn't care to lead patrols or search-and-destroy missions, however important.
Recognition of the non-com project manager was at its height just before and during the actual carrying on of the mission. After that, the recognition, support, and authority delegated to the mission leader gradually disintegrated, until the next mission was due.
At the non-com level, there were other problems besides recognition. Limited resources were certainly one. The mission was to be accomplished with the resources assigned, and becasue of limited authority the project manager was unable to call upon reserves unless the situation was in extremis, often too late to do any good. This limitation in resources has often had secondary advantages in the encouragement and development of tremendous ingenuity in accomplishing assigned missions.
In addition to lack of resources, the lack of authority assigned to the project manager was a constant problem. Because of limits in rank and position, he had command only of his own troops in the field, and yet often in the confusion of a mission the need arose to direct others. The typical project manager (non-com) reaction and solution was to apply leadership, often successfully. Through tact, persuasion, diplomacy, and guile, the non-commissioned project manager got his job done.
When a mission or string of missions was completed, the project manager non-com returned to the routine of the functional structure: training, drilling, polishing, cleaning, and maintaining the status quo. Routine became the order of the day, and ingenuity, aggressiveness, acts beyond authority, and other non-orderly activities were discouraged. The very things that made the project manager function in the field were discouraged and pressed downward. Routine operations are boring, and the main structure of a typical military organization was (and is) oriented toward accepting that boredom in the best don't make waves tradition.
It Can't Happen Here (Can It?)
Most management people familiar with military structure recognize strong similarities in management practices and problems between the military establishment and the civilian. However, it would be fair to question the analogy at the non-com level. Could management really be so unwilling to recognize as one of its own an individual who undertakes projects within the organization?
Unfortunately, the answer is a definite “yes.” Project managers to be successful are movers and shakers. They make things happen: on occasion they are vociferous, persistent, and insistent. There may be no other way to push a job through. Naturally, just as personalities vary, so do the methods that the individual project manager must use to get the job done.
In the S.A.M. Advanced Management Journal1 Owen Paul expressed concern about the “bonfire bonanza man,” a man who manages to get himself promoted by putting out bonfires. The concern of that article is bonafide, but to many managers any disruptive influence appears to be a bonfire bonanza man. The project manager who has stepped on some functional toes in the process of getting his project through to the mutual benefit of the organization may find himself categorized as unruly. (Complicating the situation is the possibility that a few project managers will consciously beat the drum in favor of their own importance to the detriment of the organization. Certainly, there are true bonfire bonanza men in the project manager ranks, but a much smaller percentage than those relegated to the category by managers who dislike change of any kind.)
The following comments on project management were made by Russell B. Archibald, an executive with International Telephone and Telegraph:2
“Managing projects is without question a difficult job. It is a rare organization these days that is satisfied with its performance on projects in meeting schedules and budgets, achieving desired quality of end results, and controlling the effort without too much management infighting.
“Managing projects is considerably different than managing stable organizations. The traditional concepts learned in graduate business schools don't apply very well in project management. In fact, severe conflicts usually exist between organizational or functional line management on one hand and the project management team on the other.
“Project management requires special concepts, tools, procedures, and systems. However, the project management team must be careful not to overdevelop these areas without commensurate development from a sound understanding of the tools and of the people skills needed to use them effectively.”
Use of Project Management
Project management depends upon management recognition, or it can never get underway. For various reasons, top management indicates that a project will be controlled by a project management team. In major undertakings, this is essentially a foregone conclusion. Typical mandated situations would be design and construction of a major structure such as a dam; undertaking a major study of government organization, such as the Hoover Commission; preparing and planning a large-scale military operation; or planning and carrying out major maintenance on a one-time basis. Within large organizations, project managers are assigned much smaller projects. It is in these areas that many problems occur, since the project manager is steering his assignment through many functional groups, working with managers at one or even several levels senior to his own. While the project manager may be working with contemporaries on a day-to-day basis, upon encountering any resistance the counterpart functional managers can push their concerns, grievances, and just plain gripes upward to a higher level of management with relative ease.
An organization operating functionally and on a project basis simultaneously is neatly labeled the matrix management organization. The matrix looks fine on an organization chart, but in practice it imposes many stresses and strains upon the implementing groups, both project and functional. Unfortunately, there is no easy solution. Project management exists because functional groups have shown in the past that they cannot objectively handle multiple projects simultaneously, particularly when these projects have varying priorities and demands that exceed resources.
The Major Problems
Often, the first problem the project manager has is to get the organization to recognize the need for project management. Comments from counterpart managers often follow the line of, “We've always gotten by before; why should this time be any different?” Or, “If there was a problem, certainly somebody else would have recognized it by now and used this for a solution; since they didn't, this must be the wrong solution.”
Others take the tack, “Maybe there is a problem, but since it isn't our direct responsibility, let somebody else take care of it.” This attitude opens the door to project management. And after project management has been opposed for a while, the functional people may finally confide with the project management team, “O.K., so there is a problem. But if we tell management, they always get upset about it. So go ahead, you guys tell them.”
Unfortunately for the project manager, higher management traditionally does dislike receiving bad news. In the ancient days, kings were known to kill messengers delivering bad news, and though mayhem is not common today, the wise project manager presents his bad news very carefully.
A second problem is resistance to change. Many organizations have a strong sense of uniqueness and feel that project managers cannot fully understand the problem and therefore cannot correct it. Unfortunately, many of the problems which are solved by project managers are the direct results of the trauma imposed by too much understanding of the problem. The individual manager who failed to solve the problem before may subconsciously work against the project manager's success. In other cases, the imposition of many socio-economic barriers that didn't exist before, particularly in the form of environmental concerns, poses problems that all managers find difficult to broach.
In some cases, the project manager's tools, such as network planning and computerized methods, are resisted because they represent change.
Finally, the project manager has the problem of gaining complete management support. Management may limit its implementation of project management to the assignment of the task. In some cases, the project manager is directed to improve a situation without losing any time or spending additional monies, not even spending money to save money. A related difficulty is the assignment of sufficient authority to the project manager. Either because of a static management system that can't handle the delegation of authority to the project manager, or more often plain reluctance to delegate management authority, the project manager is placed in the position of having to achieve results without the consonant authority to give orders. In this situation, perhaps another military analogy is appropriate — that of the officer-of-the-deck on a ship. This officer may be one of the most junior, but after he is qualified as OOD and is on the bridge, only the captain or executive officer can countermand an order he gives — and to do so must specifically take command back from him. If the project manager is to be used effectively, he needs this kind of authority.