As is the case with any manager, most of the PM’s time is spent communicating with the many groups interested in the project. Running a project requires constant selling, reselling, and explaining the project to outsiders, top management, functional departments, clients, and a number of other such parties -at-interest to the project, as well as to members of the project team itself.

The PM is the projects’ liaison with the outside world, but the manager must also be available for problem solving in the lab, for crises in the field, for threatening or cajoling subcontractors and for reducing interpersonal conflict between project team members. And all these demands may occur within the span of one day, a typical day, cynics would say.

To some extent, every manager must deal with these special demands, but for a PM such demands are far more frequent and critical. As if this were not enough, there are also certain fundamental issues that the manager must understand and deal with so that the demands noted can be handled successfully.

First, the PM must know why the project exists; that is, the PM must fully understand the projects intent. The PM must have a clear definition of how success or failure is to be determined. When making trade-offs, it is easy to get off the track and strive to meet goals that were really never intended by top management.

Second, any PM with extensive experience has managed projects that failed. As is true in every area of business we know, competent managers are rarely ruined by a single failure, but repeated failure is usually interpreted as a sign of incompetence. On occasion a PM is asked to take over an ongoing project that appears to be heading for failure. Whether or not the PM will be able to decline such a doubtful honour depends on a great many things unique to each situation, such as the PM’s relationship with the program manager, the degree of organizational desperation about the project, the PM’s seniority and track record in dealing with projects like the one in question, and other matters, not excluding the PM’s ability to be engaged elsewhere when the “opportunity” arises.

Managing successful projects is difficult enough that the PM is, in general, well advised not to volunteer for undertakings with a high probability of failure.

Third, it is critical to have the support of top management. If support is weak, the future of the project is clouded with uncertainty. If the support is not broadly based in top management, some areas in the firm may not be willing to help the project manager when help is needed.

Suppose, for example, that the marketing vice-president is not fully is support of the basic project concept. Even after all the engineering and manufacturing work has been completed, sales may not go all out to push the product. In such a case, only the chief executive officer can force the issue, and it is very risky for a PM to seek the CEO’s assistance to override a lukewarm vice-president. If the VP acquiesces and the product fails, the project manager looks like a fool. If the CEO does not force the issue, the VP has won and the project manager may be out of a job. As noted earlier, political sensitivity and acumen are mandatory attributes for the project manager. The job description for a PM should include the “construction and maintenance of alliances with the leaders of functional areas”.

Fourth, the PM should build and maintain a solid information network. It is critical to know what is happening both inside the project and outside it. The PM must be aware of customer complaints and department head criticism, who is favourably inclined toward the project, when vendors are planning to change prices, or if a strike is looming in a supplier industry. Inadequate information can blind the PM to incipient crises just as excessive information can desensitize the PM to early warnings of trouble.

Finally, the PM must be flexible in as many ways, with as many people, and about as many activities as possible throughout the entire life of the project. The PM’s primary mode of operation is to trade off resources and criteria accomplishment against one another.

Every decision the PM makes limits the scope of future decisions, but failure to decide can stop the project in its tracks. Even here, we have a trade-off. In the end, regardless of the pressures, the PM needs the support of the non-involved middle and upper management.

The project Manger makes trade-offs between the projects goals of cost, time, and performance. The PM must also make trade-offs between project progress and process, that is, between the technical and managerial functions. The first set of trade-offs is required by the need to preserve some4 balance between the project time, cost and performance goals. Conventional wisdom had it that the precise nature of the trade-offs varied depending on the stage of the project life cycle. At the beginning of the life cycle, when the project is being planned, performance was felt to be the most important goal, with cost and schedule sacrificed to the technical requirements of the project. Following the design phase, the project builds momentum, grows, and operates at peak levels. Because it accumulates costs at the maximum rate during this period, cost was felt to take precedence over performance and schedule. Finally, as the project nears completion, schedule becomes the high priority goal, and cost suffers.

During the design or information stage of the project life cycle, this is no significant difference in the importance project manager’s place on the three goals. It appears that the logic of this finding is based on the assumption that the project must be designed in such a way that it meets all the goals set by the client. If compromises must be made, each of the objectives is vulnerable. At times, however, a higher level of technical performance may be possible that, in the client’s eye, merits some softening of the cost or schedule goals. For example, a computer software project required that an information system be able to answer queries within 3 seconds 95 percent of the time. The firm designed such a system by ensuring that it would respond within 1.5 seconds 50 percent of the time. By meeting this additional standard, more stringent than that imposed by the client, it was able to meet the specific standard.

Schedule is the dominant goal during the build-up stage, being significantly more important that performance, which is in turn significantly more important than cost. Scheduling and performance are approximately tied for primacy during the main stage of the life cycle when both are significantly more important than cos, though the importance of cost increases somewhat between the build-up and main stages. During the final stage, phase-out performance is significantly more important than schedule, which is significantly more important than cost.

The second set of trade-offs concern sacrificing smoothness of running the project team for technical progress. Near the end of the project it may be necessary to insist that various team members work on aspects of the project it may be necessary to insist that various team members work on aspects of the project for which they are not well trained or which they do not enjoy, such as copying or collating the final report. The PM can get fairly good reading on team morale by paying attention to the response to such requests. This is, of course another reason why the PM should select team members which have a strong problem orientation. Discipline-orientated people want to stick to the tasks for which they have been prepared and to which they have been assigned. Problem-orientated people have little hesitation in helping to do whatever is necessary to bring the project in on time, to ‘spec”, and within budget.

The PM also has t responsibility for other types of trade-offs, ones rarely discussed in the literature of project management. If the PM directs more than one project, he or she must make trade-offs between the several projects. It is advisable, for when a project manager is directing two or more projects, care should be taken to ensure that the life cycles of the projects are sufficiently different that the projects will not demand the same constrained resources at the same time, thereby avoiding forced choices between projects.

 

In addition to the trade-offs between the goals of a project, and between projects, the PM will also be involved in making choices that require balancing the goals of the project with the goals of the firm. Such choices are common. Indeed, the necessity for such choices is inherent in the nature of the project management. The PM’s enthusiasm about a project, a prime requirement for successful project management. Can easily lead him or her to overstate the benefits of a project, to understate the probable costs of the project completion, to ignore technical difficulties in achieving the required level of performance, and to make trade-offs decisions that are clearly biased in favour of the project and antithetical to the goals of the parent organisation. Similarly, this enthusiasm can lead the PM to take risks not justified by the likely outcomes.

Finally, the PM must make trade-off decisions between the project, the firm, and his or own career goal’s. Depending on the PM’s attitudes toward risk, career considerations might lead the PM to take inappropriate risks or avoid appropriate ones.