Train Department of Surgery clerks in
Syst. Anal, and Dept. of Surgery
operation of model.
operation of model.
The order in which tasks should be performed is as shown above because all the work must be done sequentially. There are three major jobs.
1. Build the model based on input from the users.
2. Test model on an "as if" basis and amend if necessary.
Only two units will be required for the project, a systems analysis group (housed in the Department of Administration) and a user group. Analysts and users will have to work together throughout the project. These groups each represent a different part of the parent organization.
Consideration was given to the use of an outside consultant to analyze the system and develop the model. The internal systems analysts are heavily involved in replacing an outside vendor's accounting software system with one of their own devising. They expect to be fully occupied for another six to eight months. On the other hand, some members of the Department of Surgery are worried that the hospital's own analysts will not be sensitive to the special needs of the department; they would be even less likely to tolerate and trust outsiders. Indeed, several of the sur geons are doubtful about the entire project. They are not sure that it makes any sense to set priorities on the objectives for scheduling the operating rooms because "quality of patient care is our only priority."
While the analysis group is currently engaged in a major project, it is estimated that they will be able to release an analyst to the OR scheduling project within three months. The project does not appear particularly difficult, and they feel it should not require more than two or three months to complete, given that the surgeons will consider cooperating in the analysis.
In this case, it seems best to house the project in the Department of Surgery. The project is small and involves only two departments. It is easy to move the analytic skill to the Department of Surgery, and there is nothing here that requires a separate project or matrix organization with the concomitant need for separate administration. Further, housing the project in Surgery would give that department a sense of control, which might act to allay their fears. It would, of course, be feasible to organize this endeavor as a staff project under the CEO of the hospital or the chief of the medical staff, but the psychological and political advantages of housing it in the Department of Surgery warrant the use of the functional organization.
^ 4.6 THE PROJECT TEAM
In this section we consider the makeup of the project team, bearing in mind that different projects have vastly different staff needs. (For an interesting discussion of why teams are useful, see |17|.) Then we take up some problems associated with staffing the team. Last, we deal with a few of the behavioral issues in managing this team.
Before discussing these issues, there is a seemingly unimportant item that needs mention because it is far more critical than it might seem. It is useful to have a project office, even for small projects—say, those having only a half-dozen people or so. The project office, sometimes called the war room, serves as a control center, chart room, conference room for visiting senior management and the project client, center for technical discussions, coffee shop, crisis center, and, in general, the focus of all project activity. It need not be sumptuous, but the PM's open cubicle will not suffice. (If space is tight, projects can share an office ) The war room represents the project "physically" and aids in instilling an esprit de corps in team members. If at all possible, the regular project team members should have their offices located near the project office. Certainly, the project manager's office should be nearby.
Now we continue with our discussion of the project team. To be concrete, let us use the example of an engineering project to determine how to form a project team. Assume that the size of our hypothetical project is neither particularly large nor small. In addition to the PM, the following key team members might be needed, plus an appropriate number of scientists, engineers, technicians, clerks, and the like.
• Project Engineer The project engineer is in charge of product design and development and is responsible for functional analysis, specifications, drawings, cost estimates, quality/reliability, engineering changes, and documentation.
• Manufacturing Engineer This engineer's task is the efficient production of the product or process the project engineer has designed, including responsibility for manufacturing engineering, design and production of tooling/jigs/fixtures, production scheduling, and other production tasks.
• Field Manager This person is responsible for the installation, testing and support of the product/process once it is delivered to the customer.
• Contract Administrator The administrator is in charge of all official paperwork, keeping track of customer changes, billings, questions, complaints, legal aspects, costs, and other matters related to the contract authorizing the project. Not uncommonly, the contract administrator also serves as project historian and archivist.
• Project Controller The controller keeps daily account of budgets, cost variances, labor charges, project supplies, capital equipment status, etc. The controller also makes regular reports and keeps In close touch with both the PM and the company controller. If the administrator does not serve as historian, the controller can do so.
• Support Services Manager This person is in charge of product support, subcontractors, data processing, and general management support functions.
Of these top project people, it is most important that the project engineer and the project controller report directly to the PM (see Figure 4-7). This facilitates control over two of the main goals of the project: technical performance and budget. (The project manager is usually in personal control of the schedule.) For a large project, all six project officials could work out of the project office and report directly to the PM.
To staff the project, the PM works from a forecast of personnel needs over the life cycle of the project. This is done with the aid of some special charts. First, a work breakdown structure is prepared to determine the exact nature of the tasks required to complete the project. (This chart is described in detail and illustrated in Chapter 5.) The skill requirements for these tasks are assessed and like skills are aggregated to determine work force needs. From this base, the functional departments are contacted to locate individuals who can meet these needs.
On occasion, certain tasks may be subcontracted. This option may be adopted because the appropriately skilled personnel are unavailable or cannot be located, or even because some special equipment required for the project is not available m-house. If the proper people (and equipment) are found within the organization, however, the PM usually must obtain their services from their home departments. Many firms insist on using "local" resources when they are available, in order to maintain better control over resource usage and quality. Typically, the PM will have to negotiate with both the department head and the employee, trying to "sell" the employee on the challenge and excitement of working on the project and trying to convince the department head that lending the employee to the project is in the department head's best interest.
There are some people who are more critical to the project's success than others and should report directly to the PM or to the PM's deputy (often the project engineer):
• Senior project team members who will be having a long-term relationship with the project.
• Those with whom the PM will require continuous or close communication.
• Those with rare skills necessary to project success.
Remember that the PM must depend on reason when trying to convince a department head to lend these valuable people to the project. The department head, who sees the project as a more or less glamorous source of prestige in which the department cannot share, has little natural motivation to be cooperative. Once again, it is obvious that success depends on the political skill of the PM as much as on the technical skill of the team.
Thus far, we have tacitly assumed a fairly strong matrix organization for the project in our example. In recent years, the use of weaker matrices has become more and more frequent. In many firms, when project managers are asked for the number of people who report directly to them, the answer "None!" is not uncommon. Most common of all, it seems to us, is the matrix organization with a project manager, one or two key skilled contributors who may be full-time members of the project, and a wide variety of services or capacity supplied to the project by functional groups in the parent organization. Such structures are often found in software projects that are part of larger programs being carried out by a parent firm. One or two programmers may be assigned to the project, but the work involved in integrating and testing the software, etc., is supplied to the project in the form of deliverables rather than people assigned to the project to carry out their work.
Although the project manager has to bargain for fewer individuals than in the case of stronger matrices, the PM's negotiating skills are just as critical. It is typical for the success of weak-matrix projects to be dependent on the skills of the few technical specialists who are assigned directly to the project. The ability of the PM to negotiate for skilled technicians as well as for the timely delivery of services from functional departments'is a key determinant of success.
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.