Project management in pharmaceutical research and development

re-thinking some critical issues for the eighties

Robert Staples

Manager, R&D Management

Systems and Services

Smith Kline & French Laboratories

Philadelphia, Pennsylvania

Managers of projects and people who provide project management services in pharmaceutical research and development profit by communicating with each other. This was demonstrated clearly in the discussion which climaxed the pharmaceutical industry track of 1980 Seminar/Symposium of Project Management Institute held in Phoenix, Arizona. This writer was privileged to chair the discussion in which newer members of the profession challenged and learned from older professionals. “Junior” people shared with “Senior” people. Ideas, concepts, systems, tools and techniques were shared in a non-threatening climate outside the realm of any single corporate employer. Understanding between those who manage and those who are managed was promoted. Friendships and trust were built.

Out of the discussion four broad categories of issues surfaced:

  1. Planning and controlling R&D projects
  2. Project management as service to scientists and/or managers
  3. Organizing for project management in R&D
  4. Research — where have others succeeded or failed?

This paper amplifies these issues by presenting one manager’s observations or experiences in each of these areas.

Planning and controlling R&D projects

Anyone who has managed a project, large or small in R&D or elsewhere, has probably known the anxiety felt when primary indicators suggest that the project is “out of control.” How accurate are the indicators? What elements of the project are contributing to the loss of control? What alternatives are available to project management to restore control? What does “out of control” mean, anyway?

If we accept the proposition that “out of control” projects take longer than expected, cost more than expected or use more resources than expected, then we must have some baseline statement about our expectations. That baseline is the project plan.

Plans do not control projects, people do. Managers use plans to communicate expectations and to compare observed realities to those expectations. Analyses of deviations from plan, then, are indicators for project control. Plans are the foundation of a decision-making system.

Level of Detail

If the project plan is the baseline for project control, what is the relationship between the amount of detail in the plan and the utility of the plan as a control tool or a communications device? The first impulse is to conclude that more detailed plans make better control and communications tools. Yes and no! Highly-detailed plans are more expensive to create and update than are less-detailed ones. They are more expensive in staff time and, if automated, in data processing. Yet, if the objective of creating a project plan is to design a control tool, then more detailed plans are more comprehensive statements against which to monitor change. Additionally, more detailed plans may be constructed to facilitate communications to a wider audience. On the other side of the coin, some managers may exert control without benefit of a highly-detailed plan and communications may actually be enhanced by simplicity.

One conclusion which may be drawn is that the amount of detail appropriate for a project plan is dependent on:

  1. the intended utility of the planning process in a particular organization.
  2. the distance into the future the plan extends
  3. the mechanics of the planning systems
  4. the size of the project planning staff and budget.

Explicit activity descriptions, wide in-depth reporting systems and other special requirements may demand high levels of detail for certain sections of the plan. Short-range plans are usually more detailed than are long-range ones. In summary, determine the project planning objectives for your organization, commit to and develop a system that works for you, then use it intelligently.

Project management as service to scientists and/or managers

Project management people serve at least two masters. Information in project management reports is valuable to managers (many of whom lack a scientific background in a specific technical discipline) and to scientists (many of whom have no management training or responsibility). Value of project information is related to its relevance and credibility with respect to any current issue. Some real questions, then, are:

  1. How much should project management be involved in developing scientific study plans?
  2. Should project management people share in the responsibility for deciding data requirements, interpreting outcomes or reporting results?
  3. How far into the future should study plans be extended?

Philosophy-dependent

Appropriate responses to the questions posed above are related directly to the project management philosophy proclaimed within a specific corporate environment. For example, at one end of the spectrum a case may be built for requiring project management to get deeply involved in the “science,” to test hypotheses and suggest courses of action leading to verification and further experimentation. This case is probably most appropriate if people with project management responsibilities have credibility (through academic degrees or experience) in the scientific discipline and high esteem in an organization with high levels of trust. The further away from this position of high scientific credibility, high esteem and high trust that a project manager of staff is perceived, the higher the risk in deep involvement in planning “science.” What risk? Risk of loss of value to the corporation which could ultimately result in the loss of a specific project management function.

At the other end of the spectrum, a case may be built for structuring the project management group as coordinators, schedulers, operations researchers, information technologists, and the like. This might be a useful strategy in an organization because some scientists feel less threatened by non-scientists’ asking questions out of naivete. Questions asked from this base frequently appear less judgmental. Plans and reports produced by a project management group positioned at this end of the spectrum may be practically void of scientific data content and still be highly credible and relevant (hence valuable) to a corporation.

The truth of the matter is that any single project management group is probably positioned somewhere between those two poles. Where should it be? Wherever your corporate philosophy and objectives dictate.

Authority, responsibility, expertise and accountability

Scientists investigate; managers manage. Both seek appropriate authority commensurate with their responsibility and expertise. This concept is easily understood although not easily put into practice, especially with regard to project management people or organizations. The entire preceding discussion on philosophy-dependency is also related to the issues implied in this section:

  1. How may any corporation achieve appropriate correlation between responsibility and authority in the project management function?
  2. For what should project management people be held accountable?

Few project management people are ever satisfied that they have enough authority to carry out their perceived responsibility.

Their discomfort usually is most acute when they deal with issues and people outside their own individual orientation, be it technical, financial, business or management. Yet, the greater the success in communicating with people in a variety of functional areas, the more the project management person might feel him/herself to be the “general manager.” The closer the involvement in structuring decisions, the more power felt in guiding the future of the corporation. Hence, the perceived disparity between authority and responsibility.

One way to approach the management of projects (though admittedly impractical and untried in most traditional pharmaceutical R&D organizations) is to manage projects as if they were individual businesses. Associate rewards (salary increases, promotions, prestige symbols) with project work. Separate principal team members from their traditional line organizations, refer to them as business partners and evaluate their performance against a project charter endorsed or modified periodically with higher management. Finally, provide a mechanism to restore a project-assigned person to his/ her line function when project work requirements diminish. Theoretical? Impractical? Maybe. It is one approach, however, to recognizing responsbility for project (team) work and to providing authority needed to accomplish it.

There are, no doubt, corporations in our industry in which the authority/responsibility delineation in project management is not usually an issue. It would be interesting to study the autonomy of the project team in these organizations if, in fact, they use project teams at all.

Finally, individuals and teams should be held accountable for responsibilities for which they have authority. An R&D team’s responsibility is to develop a recommendation concerning a potential corporate asset, and to provide solid evidence for that recommendation. Accountability, therefore, should probably be related to the decision-making process which leads to the recommendation and to the quality and quantity of work done to provide data supporting the recommendation – even if the data suggest that the project should be dropped.

Self-image

This concept — how project management people see themselves — might have more to do with performance than does the job description or procedures manual. Consider this statement from two directions, who we work for and how we perform.

If project management people could position themselves strategically on the organizational chart or geographically on a specific floor or area (near laboratories or administrative/executive offices, for example), the site selected should probably be nearest to the client group most frequently served. The reality is that we cannot always position ourselves according to our own idea of where we think we could do the most good. We are most effective when we believe we are in the best position strategically, and when our management’s image of us agrees with our own self-image. It is interesting to note that half the project management groups in the 19 companies represented in the PMI discussion perceived themselves as primarily management-service oriented; the other half as primarily science-service oriented.

Organizing for R&D project management

Many of the earlier comments concerned organizational issues. It may be concluded that the most effective project management group is one located on a solid line basis to its source of power. Data cited at PMI-80 suggest that most groups are related to either the R&D executive or a vice-president responsible for development (as opposed to research). In some instances, project management groups located outside R&D provide that function as “consultants” to R&D. In a few instances, project management groups may be located within a specific technical department like preclinical, path/tox or medical. It should be located where it may do the most good, according to the objectives determined by the corporation.

The project management group itself should be only as large as need be to satisfy the job standards specified. A variety of job descriptions have been created over the past decade or more, but essentially the kind and number of staff required is related to:

1. The number and size of projects to be managed

2. The degree of automation used

3. The level of detail chosen

4. The frequency of update

5. The experience of the staff

Research — where have others succeeded or failed?

On the basis of the presentations and discussion at PMI-80, several areas for research emerged. A questionnaire is being developed to gather data from the pharmaceutical industry on a variety of R&D project management interests. Some of these are:

  1. Organization for project management
    1. Staff size
    2. Solid/dotted line relationships
    3. Team structure
    4. Placement in the total R&D framework
  2. Tools and techniques
    1. Software selection criteria
    2. Adaptation of commercially-available packages
    3. Development of systems within corporate data processing centers serving R&D
    4. Relative merits of systems to do time and/or resource processing in R&D
    5. Development of non-automated skills
  3. Project leadership
    1. Leader identification and selection
    2. Function in a matrix organization
    3. Relationship to project planning/management staff

Papers and presentations for future events concerned with R&D project management might be constructed around the following themes:

  1. Managing and communicating at the inferface of R&D -
    1. and marketing
    2. and manufacturing
    3. domestically and internationally
  2. Widening the applicability of project management skills
    1. Feedback from line managers
    2. Feedback from academia
    3. Comparative utility for ethical and over-the-counter products
  3. Recent developments in tools and techniques
    1. Dedicated mini-or micro-computer systems
    2. Database management systems
    3. Plotting and drafting techniques
  4. Managing the decision-making process
    1. Developing priority-setting systems
    2. Use of simulation
    3. Structuring milestones
  5. Experiences in team-building
    1. Effectiveness in small groups
    2. Teams: pro’s and con’s

Conclusion

This paper has given one author the opportunity to present observations and opinions about some pharmaceutical R&D project management topics which surfaced at PMI-80. In all candor, much of this paper could have been written before PMI-69 because the predominant issues concerned with the management of project-related work have been around since the concept of “project” originated. The message which persists is that projects in pharmaceutival R&D share characteristics with projects in other fields. Each project is a unique creation demanding human leadership, planning and control to make the best use of available time, money and other resources. Further, there are a wide variety of tools and techniques available to manage projects and the degree to which each is used varies from company to company. The use of specific project management tools is dependent on the philosophy and commitment of R&D and corporate managers to the belief that R&D projects are managed better with them than without them. The eternal challenge to project management people is to demonstrate the truth of this belief constantly. Finally, then, the ultimate objective of the project management staff is to select the best tools (automated or manual) available at the best price within the allocated R&D budget and to use them within the framework of an organizational setting designed to provide two-way communication in a wide array of corporate channels.

The author wishes to acklowledge the lively participation of all attendees of PMI-80, particularly those whose thought gave impetus to this paper. Among these were George Ackerman and Don Cooper (Hoffman-LaRoche Inc.), Susan Gallagher and Patrice Murphy (G. D. Searle & Co.), Bob Jackson (Lederle Labs), Ken Keisling (Johnson & Johnson Products, Inc.), Bill Lavista (Schering Corp.), Martin Malkin and Dick Rhodes (Merck), Tom McGeehan (Wyeth Labs), Gordon Ogilvie (SK&F Labs.), Patricia Patrick (Burroughs Wellcome Co.), Charles Pesterfield (Ciba-Geigy Corp.), Janet Steelman (McNeil), Chris Trautwein (Warner-Lambert), Laura Von Vlack (Upjohn Co.) and Dan Worden (Bristol-Myers).

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.