In the last chapter we described how projects are evaluated and selected for development. Before more progress can be made, a project manager (PM) must usually be appointed. This person will take responsibility for planning, implementing, and completing the project, beginning with the job of getting things started. Actually, the way to get things started is to hold a meeting, but we will delay discussion of the initial project meeting until Chapter 5 because it is the first step in the process of planning the project.
The PM can be chosen and installed as soon as the project is selected for funding or at any earlier point that seems desirable to senior management. If the PM is appointed prior to project selection or if the PM originated the project, several of the usual start-up tasks are simplified. On occasion, a PM is chosen late in the project life cycle, usually to replace another PM who is leaving the project for other work. For example, a large agricultural products firm regularly uses a senior scientist as PM until the project's technical problems are solved and the product has been tested. Then it replaces the scientist with a middle manager from the marketing side of the firm as marketing becomes the focal point of the project. (The transition is difficult and, according to firm spokespeople, the results are sometimes unsatisfactory.)
Usually, a senior manager briefs the PM on the project so that the PM can understand where it fits in the general scheme of things in the parent organization, and its priority relative to other projects in the system and to the routine work of the organization. The PM's first set of tasks is typically to prepare a preliminary budget and schedule, to help select people to serve on the project team, to get to know the client, to make sure that the proper facilities are available, to ensure that any supplies required early in the project life are available when needed, and to take care of the routine details necessary to get the project moving.
As people are added to the project, plans and schedules are refined. The details of managing the project through its entire life cycle are spelled out, even to the point of planning for project termination when the work is finally completed.
Mechanisms are developed to facilitate communication between the PM and top management, the functional areas, and the client. As plans develop still further, the PM holds meetings and briefings to ensure that all those who will affect or be affected by the project are prepared in advance for the demands they will have to meet as the project is implemented.
In this chapter we discuss the unique nature of project management and some of the ways project management differs from functional management. Our emphasis is on the role and responsibilities of the PM. We concentrate on the demands placed on the PM, particularly on those unique to project management. For example, there is considerable difference between the demands placed on the following two information system project managers. One is responsible for converting a library's card catalog to a computerized system, including CD-ROMs. The other is responsible for the organization, planning, and implementation of the federal government's information superhighway. Based on our discussions of the nature of the PM's job, we complete the chapter by considering how to identify the skills and characteristics required of this supermanager.
It is best to describe the PM's job relative to some assumptions about the nature of projects and the organization within which the project must function. We assume that the parent firm is functionally organized and is conducting several projects simultaneously with its ongoing, routine operations. We also assume a fairly large firm, a project that has some technical components, with an output to be delivered to an "arms-length" customer. Clearly, not all, and possibly even not most, projects operate under these circumstances, but these are the most demanding and we address the most difficult problems a PM might have to face. Smaller, simpler projects may not require the tools we will present here, but the PM for these projects should be aware that such tools exist. The term technical components as we apply it includes more than hardware. Any firm With a well-defined methodology of carrying out its mission has a technical component, as we use the phrase. For example, a systems analysis and functional requirements are among the technical components in most information systems projects, as is the due diligence document in a security offering.
In this chapter two conditions receive special attention. Both have a profound effect on the outcome of the project, and neither is under the complete control of the PM—though the PM can greatly influence both by dealing with the conditions early in the project life. The first of these concerns the degree to which the project has the support of top management. If that support is strong and reasonably unqualified, the project has a much better chance of success.
The second condition concerns the general orientation of the project team members. If they are highly oriented toward their individual, functional disciplines, as opposed to the project itself, project success is threatened. If, on the other hand, they tend to be oriented toward the project (that is, problem-oriented rather than discipline-oriented), the likelihood of success is much greater. The PM cannot actually control these conditions, but there is often much that can be done to influence them.
Was this article helpful?
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.