Special Demands On The Project Manager

PM Milestone Project Management Templates

PM Milestone 7000 Business Templates

Get Instant Access

At the inception of the project, the "fires" tend to be associated with resources. The technical plans to accomplish the project have been translated into a budget and schedule and forwarded up the managerial hierarchy or sent to the client for approval. In an earlier section we noted that some of the budget and schedule is pared away at each successive step up the hierarchy. Each time this happens, the budget and schedule cuts must be translated into changes in the technical plans. Test procedures may be shortened, suppliers' lead times may be cut. The required cost and schedule adjustments are made, a nip here and a tuck there. To the people affected, these may well be crises.

The PM learns by experience; the wise PM learns from the experiences of others. Every project on which the PM has worked, whether as the project manager or not, is a source of learning. The war stories and horror tales of other PMs are vicarious experiences to be integrated with direct personal experience into a body of lore that will provide early-warning signals of trouble on the way. The lore will also serve as a bank of pretested remedies for trouble already at hand.

To be useful, experience must be generalized and organized. Managing a project is much like managing a business. Business firms often develop special routines for dealing with various types of fires. Expediters, order entry clerks, purchasing agents, dispatchers, shippers, and similar individuals keep the physical work of the system moving along from order to shipment. Human resource departments help put out "people fires" just as engineering helps deal with "mechanical fires." Fire fighting, to be optimally effective, should be organized so that fires are detected and recognized as early as possible. This allows the fires to be assigned to project team members who specialize in dealing with specific types of fires. Although this procedure does not eliminate crises, it does reduce the pain of dealing with them.

As the project nears completion, obstacles tend to be clustered around two issues: first, last-minute schedule and technical changes, and second, a series of problems that have as their source the uncertainty surrounding what happens to members of the project team when the project is completed. These two types of problems are very different from one another, as well as from the problems that faced the PM earlier in the life cycle of the project. The way to deal with last-minute schedule and technical changes is "the best you can." Beyond knowing that such changes will occur and will be disruptive to the project, there is little the PM can do except be prepared to "scramble."

Coping with the uncertainty surrounding what happens at the end of a project is a different matter. The issue will be covered at greater length in Chapter 13, but it deserves mention here because it is certainly an obstacle that the PM must overcome. The key to solving such problems is communication. The PM must make open communications between the PM and team members first priority. The notion of "open communications" requires that emotions, feelings, worries, and anxieties be communicated, as well as factual messages.

Making Project Goal Trade-offs

The PM must make trade-offs between the project 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 some balance between the project time, cost, and performance goals. Conventional wisdom had it that the precise nature of the tradeoffs 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 of the goals, 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 (and perhaps performance) suffers. Research |25| has shown that these assumptions, sensible as they seem, are not true.

During the design or formation stage of the project life cycle, there is no significant difference in the importance project managers 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 eyes, 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 specified standard.

Schedule is the dominant goal during the buildup stage, being significantly more important than performance, which is in turn significantly more important than cost. Kloppenborg conjectures 125, p. 127) that this is so because scheduling commitments are made during the buildup stage. Scheduling and performance are approximately tied for primacy during the main stage of the life cycle when both are significantly more important than cost, though the importance of cost increases somewhat between the buildup and main stages. During the final stage, phaseout, performance is significantly more important than schedule, which is significantly more important than cost. Table 3-1 shows the relative importance of each objective for each stage of the project life cycle.

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 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 a 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 who have a strong problem orientation. Discipline-oriented people want to stick to the tasks for which they have been prepared and to which they have been assigned. Problem-oriented 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 responsibility for other types of trade-offs, ones rarely discussed in the literature of project management. If the PM directs more than one liable 3-1 Relative Importance of Project Objectives During Different Stages of the Project Life Cycle liable 3-1 Relative Importance of Project Objectives During Different Stages of the Project Life Cycle

Life Cycle Stage

Cost

Schedule

Performance

Formation

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment