Secrets of successful multiproject managers
Multiple Project Management (MPM) has taken hold in organizations as they seek to improve management and efficiency, coordinate interrelated projects to cut cycle time (PMBOK® Guide, 2000), and transfer technology between projects to outperform the competition. MPM can take different forms but they are often implemented by groups of several concurrent projects managed by a single project manager, typically termed multiproject manager. These multiproject managers and their groups are tasked with making decisions lower in an organization hierarchy and have interrelationships with multiple functional units from which they draw resources. Essentially, they are designed as an overlay to an existing functional organization. Multiproject managers share many characteristics with single project managers, but also differ in many ways. Two examples can help illustrate the differences. First, a major piece of multiproject managers' role—linking multiple concurrent projects—doesn't exist in single-project management (SPM). Second, multiproject managers face the challenge of switchover from project to project, at times several times a day (Fricke & Shenhar, 2000). More of the differences will be discussed later in this paper.
Empirical research on management of groups of multiple projects is well behind its rate of utilization in the industry. While existing literature on single-project management and MPM is a beneficial point of departure, it has also left some important questions unanswered. In this paper, we seek to develop a framework for management of a group of multiple concurrent projects (MG/MP) by collecting and analyzing qualitative data from four multiple project managers and their managers, a total of eight respondents. Thus, the primary contribution of this grounded theory research is to investigate MG/MP—an MPM form—and develop a framework that can be used in both studying and implementing the form. An additional contribution of this paper is in contrasting MG/MP with SPM.
Several different definitions of management of multiple projects are in use today. To avoid possible confusion related to definitions, we will choose our definitions and use them consistently in this paper. We define multiple project management (MPM)—also referred to as multiproject management—as an environment in which multiple projects are managed concurrently. Some experts employ the term portfolio management for such environments (Platje, Seidel et al., 1994). In it, projects are diverse in size and importance, may be at any point in their life cycle, and rely on the same pool of resources.
Some of the projects are sufficiently large and strategic in nature to have a full-time project manager. We term such an approach single-project management (SPM)—the project manager manages a single project at a time. Often, these projects are undertaken to create a competitive advantage for the company. An example is a product platform development project. Other projects in the multiproject environment that are of smaller size and more tactical nature tend to be grouped such that one project manager (called multiproject manager) handles several concurrent projects at a time. For this approach, we use the term management of a group of multiple projects (MG/MP). Typically, projects in the group are not mutually dependent but rather grouped for the sake of efficiency and better management.
A special case of MPM is program management, where the projects in the group are mutually dependent and share a common goal (PMBOK® Guide, 2000). Although a certain number of our findings are applicable to it, program management is beyond scope of this paper.
MG/MP: The Literature Speaks
The little literature that exists on MG/MP offers two related streams of research that we will use as a starting point. The first is the literature on management of multiple projects and their context. Essentially, these issues look at interactions between the groups of multiple projects and their organizational environment. Such issues focus on the need for realistic resource allocation, formal project selection and prioritization (Adler, Mandelbaum et al., 1996)(Fricke & Shenhar. 2000). While authors suggest criteria on how to assign a project to a multiproject manager (Adler, Mandelbaum et al., 1996), no clear techniques for such an assignment are offered.
The focuses of the second stream are on the internal process and their outputs. When multiple projects are presented, the interproject interaction becomes an issue. Therefore, the interproject process needs to focus on interdependence among projects in order to maximize the objective of group success as opposed to individual project success. The idea is to manage all projects as a collection, by adjusting and linking their schedules to match available resources, and removing unnecessary variation in workloads of multiproject managers (Adler, Mandelbaum et al., 1996). This will require multiproject managers to multitask, shifting their attention from project to project, resulting in switchover time cost. In summary, the literature's two streams appear to cover three major domains—inputs, process, and outputs of MG/MP.
Exhibit 1. Summary of Case Information
Scope of the Paper
As our literature review indicates, project management writers have already looked at such critical issues in MPM as success factors, resource allocation, priority setting, resource sharing, etc. Their accounts are more of an anecdotal and less of a research nature. Even more lacking is research in MG/MP, our unit of analysis. Specifically, no research addresses the question that our exploratory study asks: “What are important issues to leading to effective MG/MP?” With answers from respondents, we seek to create a conceptual framework for effective MG/MP in the form of a process model. Its input-process-output domains would actually correspond to what we have seen as related streams of research in the existing literature on MPM. Note, though, that our focus is on product and software development.
We opted to subscribe to a multiple case study approach (Eisenhardt, 1989), often referred to as the grounded theory research. This methodology is very beneficial when there is no specifically defined theory or construct as is in our case and the small numbers of cases are available. Following the principles of theoretical sampling, we identified four companies, each holding a top position in their respective markets—a testing measurement equipment manufacturer, an LCD projector manufacturer, a construction management software developer, and dealership software developer. Each company is considered a case, meaning we had four cases (Eisenhardt, 1989). While revenues of both manufacturers were around $1B, those of two software developers were between $50M and $100M. All companies are part of high-tech industries. Exhibit 1 summarizes the information about the four cases.
We collected data through interviews ranging from 100–120 minutes. The basis for interviews was a semistructured questionnaire, seeking to get information about characteristics of the company, department, the group of multiple projects, important issues in MG/MP, or anything else they felt was important in MG/MP. The importance was perceived by the interviewers and was not validated independently. We taped and transcribed each interview. Within-case and cross-case analyses followed in combination with the review of the documentation we received from the interviewees (e.g., progress reports). All of these resulted in tabulation of qualitative data that led to the identification of important issues in MG/MP that are discussed later in this paper.
Results and Findings
Our plan is to begin by presenting a brief description of each domain, clarifying some of the issues found in our qualitative research. Part of that will be a contrasting of such issues in SPM and MG/MP environments. The purpose of this is to highlight the unique features of MG/MP. Later, we will focus on implications and conclusions.
Exhibit 2 illustrates the tree-domain process model, including inputs, process, and outputs, and issues in each domain. These issues had the highest frequencies (indicated by the number in parentheses next to the issues) of being identified as the most important one by the interviewees. We organized them into the domains per streams of current research that we discussed in the literature review. The rationale is that the three-domain model provides a systems view of MG/MP that is also familiar to many project managers using A Guide to Project Management Body of Knowledge (PMBOK® Guide), a widely respected systems model of project management.
Exhibit 2. A Process Model of Management of Groups of Multiple Projects
Five major inputs-related issues include (Exhibit 2):
1. Resource allocation
2. Project assignments
3. External linkages
4. Project objectives
5. Organizational culture
These inputs originate in the MG/MP environment and differ in some aspects from those of a SPM environment. For groups of multiple projects to operate in their environment, their multiproject managers must establish their role in relation to upper management, other external stakeholders, and the overall organization. Some examples from the interviews indicate the essence of this in relation to these issues:
Resource Allocation: “Probably the worst risk is someone is stealing my resource … They took her from me and gave me someone who has absolutely no knowledge.”
Project Assignment: “Sometimes handling 13 projects like I handle today can be effective because they are all in different phases.”
External Linkages: “I have to deal with vendors. I have to work with people who are developing my product that are not even here, coordinate them with my people.”
Project Objectives: “The typical project goals … I've never seen anything published … So, that is kind of like, we'd like to get it done by this time frame … Those goals are unpublished but they were understood.”
Organizational Culture: “Typically, the project goal is get the job done as fast as you can, and if there is a way you can cut the company cost, go for it.”
These examples reveal several important inputs-related issues in the MG/MP setting that play out differently in the SPM environment. Being larger and of a strategic nature, projects in SPM environment catch the special attention of upper management in the project selection and prioritization process. As a result, these projects are usually well resourced and are assigned to highly competent project managers. Their objectives are usually clearly defined and carefully concerted by upper management. They have a higher rating with and support from the functional departments that provide resources, establishing a single track of communication with each department. Corporate culture views the project as a strategic favorite and their project manager as a heavyweight tasked with carrying the ball to achieve results that support corporate goals.
Now, let's contrast this with the MG/MP environment. Because of their smaller size and tactical nature, these projects are often resource-strapped, causing multiproject managers to cope with delays. They are often asked to take on additional projects when they really don't have the mental and physical capacity (measured in number of work hours) to do so. In establishing linkages with a functional department, the multiproject managers need a separate communication track for each project, creating parallel tracks that further stretch their capacities. Additional risks may come from handling multiple sets of project objectives from multiple projects that are often insufficiently clear and concerted. Finally, in the eyes of corporate culture, MG/MP is an art of juggling multiple balls (projects) to get the job done, which is managing for completion, rather than for results. These differences in input-related issues between SPM and MG/MP are summarized in Exhibit 3.
The challenges in the MG/MP environment that we have described point to the need for a strong process to manage concurrent projects. Several process issues stick out in their importance for overcoming the challenges (Exhibit 3):
1. Individual project process
2. Interproject process
4. Team building
Illustrating some of the issues are the following statements of the interviewees:
Individual Project Process: “Right, we do, we have phases we go through. It is a standard model but we as a team can choose to modify it.”
Interproject process: “We don't have a formal document or process on how we combine projects. It is an informal process, but we are very aware of it because we have more opportunities than we have resources.”
Exhibit 3. Management of Groups of Multiple Projects Versus Single-Project Management
Multitasking: “You know, you don't want to load them (multiproject managers) up to the point that they can't be effective … And I think four programs for one program manager is enough … otherwise, they are changing gear too much.”
Team building: “The first thing I say when the team meets is that what I expect … We have to come up with the project name, what is our goal, and we all have to buy into that. I tend to do a lot of team building experience. I take them out because you have a bunch of people who have never worked together.”
Leadership: “They (multiple projects) probably involve you in a lot more things than you are normally exposed to because you get different personality, different dynamics on each one of the team … They are probably challenging you more.”
SPM and MG/MP have one thing in common. They both need a streamlined process to manage a project, typically consisting of project phases, activities, milestones, and deliverables. In this study's sample, a conceptually identical process for managing an individual project was used in both SPM and MG/MP. This was not the case when it came to other process issues. A comparison of other process issues in the SPM and MG/MP environments may further sharpen our understanding of the uniqueness of MG/MP.
There is a process for linking individual projects within the group of multiple projects. Often informal, it seeks to identify interdependencies between projects in terms of shared milestones, technologies, multiproject manager's time or team members' time. The intent is to increase efficiency and shorten completion times of concurrent projects. A significant issue in that process is multitasking. Multiproject managers are expected to constantly shift their attention from project to project. There is a major cost to this—switchover time cost. Specifically, it takes time to interrupt work on one project and get mentally into another project. The majority of our interviews see this time loss as a major impediment to MG/MP, and a reason to limit the number of concurrent projects assigned to a multiproject manager to two-three ones.
Because multiproject managers need to build multiple teams concurrently, their time for each team is limited. Consequently, they need to apply a condensed, fast team-building procedure. Similarly in their leadership capacity, they are expected to act in a discontinuous manner—lead one team, discontinue, and lead another team. These same process issues have different manifestations in the SPM environment. First, the interproject process is not necessary because there is only one project to manage. Multitasking relates to switchover between activities of the same project, an insignificant challenge compared to switchovers between different projects, often executed by different teams.
We define team building in SPM as diluted and continuous. Project managers can use any activity in their agenda throughout the project life—that's why we call it diluted—to hammer out their team-building message within the same project team. Similarly, they can exercise leadership continuously in their simple project team without the need to move to another project team, as is the case in the MG/MP setting. While the application of process-related issues significantly differs in the SPM and MG/MP environments summarized in Exhibit 3, such differences are smaller in the case of output issues.
Outputs are criteria for effectiveness of MG/MP that come in many forms. The most important among them are (Exhibit 2):
2. Resource productivity
3. Customer satisfaction
5. Personal growth
Short stories help visualize the emphasis on these outputs.
Time-to-Market: “Typically, we have something we call a bounding box, which basically is an outline of what our deliverables is; one of those areas is the schedule. So, we need to have a product on a certain date; time to market is very important.”
Resource Productivity: “I was allocated resources three months ago for a project … If the company changes its direction, a manager may say that your priority has been changed.”
Customer Satisfaction: “For one program, you know you're looking at that one program … As you manage multiple programs, are you putting enough focus on the customer?”
Learning: “There are some projects that we are doing mainly to gain experience in those areas …”
Personal Growth: “We always have that discussion in terms of what the person's skill level is, how they are doing, what they are doing, and also in terms of what skill we want them to develop. To assign them a project, is it going to be something that is going to get them to the next level of whatever their career goals are?”
The primary expectation of the multiproject manager is to compress time-to-market for their projects, which tend to be shorter and more time-intense than single projects. They are also called upon to manage capacity more visibly than single projects. This is a cross-link with the resource allocation discussed in the input-related issues. Being resources-strapped, multiproject managers have to manage resource capacity by balancing and sharing their own time and time of their multiple team members across multiple projects. Customer satisfaction is also an important outcome, although less so than in single projects. Simply, multiproject managers spend less time working on customer issues, pressured by the need to disperse their attention to multiple sets of customers, as opposed to single-project managers focused on one set of customers only.
SPM is typically expected to produce strategic innovation and provide new, strategic capabilities. For tactical nature of their multiple projects, multiproject managers' task is directed to learning related to tactical innovation capabilities. It appears that personal growth from managing projects is crucial to both multiproject and single-project managers. There is a difference in what both can expect. MG/MP includes various, typically unrelated projects with a variety of products and technologies, which provides benefits of growth in heterogeneous areas. Dealing with one project at a time offers single-project manager personal growth in a homogeneous area of the project. These differences between MG/PM and SPM in the area of outputs are summarized in Exhibit 3.
Despite its exploratory character and limited scope, this study points to the unique nature of MG/MP that is reflected in a specific set of traits that are different from SPM. Understanding this may help organizations design and deploy MG/MP in a way that would enhance its quality and effectiveness. Based on this study, we believe that secrets of the design and deployment are secrets of successful multiproject managers. In essence, they are about the right focus and balance of inputs, process, and output issues. Below we summarize our learning about the secrets.
To be effective, multiproject managers need a realistic resource allocation process. Such a process clearly combines several crucial elements. First, it identifies the available capacity of both the resources from functional departments and multiproject managers' time. Second, upper management should select the right number of projects for implementation—that number of projects that the capacity of available resources can match. For this, they need a flexible and ongoing project selection and prioritization process, which clearly defines each project's goals and the needed capacity of both the resources from functional departments and multiproject managers' time. A standard for how many projects a multiproject manager can manage at a time—for example, two to three projects—is vital as well. When the available and needed capacity of resources is matched in this context, the result is a set of projects that is realistically capacitated with the right resources. If a company supports these premises with a corporate culture that rewards on-the-job behaviors that promote MG/MP uniqueness, an environment conducive to effective MG/MP is in place.
The Process of MG/MP
The execution of the process for management of individual projects has proven to be a critical success factor. Connecting such processes with an interproject process is also of vital importance. While multiproject-scheduling algorithms can help in this, their impact is of limited value. Simply, development projects unfold in such a fast environment that they cannot tolerate the rigidity of multiproject scheduling. Rather, start by connecting multiple projects via points of shared functional resources, milestones, technologies, and multiproject manager's time. Then, organize work and schedules around these points, using face-to-face adjustments with functional managers and their resources (Platje, Seidel et al., 1994). Note that enforcing the low number of projects per multiproject will reduce the number of connecting points and switchovers while increasing the simplicity of the interproject process. Focusing on one project for awhile—for example, work on one project for the whole day before switching to another—will further increase the simplicity and reduce the time costs of multitasking. In addition, such an approach will make the multiteam building and multiteam leadership less demanding.
The Outputs of MG/MP
Diverse outputs are required from multiproject managers—in each of their multiple projects they are given a primary mandate to accomplish fast time-to-market. Also, they are expected to deliver desired resource productivity, customer satisfaction and learning. For multiproject managers to be successful in meeting all these requirements, upper management needs to make several things happen. First, upper management has to set the expected output levels in the form of clear project objectives that are handed down to multiproject managers as part of inputs. Second, the outputs have to be prioritized—again, the first priority is time-to-market. Third, these priorities need to be grounded in realistic resource allocation. For example, an extremely fast time-to-market won't be realistic if insufficient resources are provided. Fourth, making educated output tradeoffs is a must. As an example, practice indicates that faster projects lead to more rework and lower resource productivity. Finally, if upper management wants to deploy the MG/MP approach effectively, satisfying multiproject managers' interests in personal growth is a crucial condition to create.
Conclusions and Limitations
This exploratory study has examined MG/MP, a widespread management phenomenon, and developed a process model framed in three domains—MG/MP inputs, process, and outputs. The goal has been one of building a systems model that can be used in both practice and future research. The most original contribution from this research is in the process domain. In that domain, the major contribution is the emphasis on the unique nature of the MG/MP process compared to the SPM process. In particular, the identification and clarification of interproject process, multitasking, team building, and leadership issues represent a useful addition to the MPM-related work of other researchers (Adler, Mandelbaum et al., 1996) (Fricke & Shenhar, 2000). Also, these process issues clearly indicate the need to break out of the old paradigm that MG/MP is a little different from SPM. The difference is significant.
The strengths of this study are in its focus on a little-researched project management approach, richness of a grounded research process, and the application to a wide variety of development projects in high technology business. Potential limitations of the study are related to the fact that data were collected in four organizations. Many issues identified in our model suggest future research. Two examples may help visualize our point. First, the issue of switchover costs warrants further analysis in order to understand patterns of multitasking that would reduce such costs. Second, on a more general side, application of our model in different types of projects than development ones would constitute a meaningful research effort. Overall, since the rate of use of MG/MP has outweighed research on the topic, this situation offers opportunities for researchers.
Adler, P. S., A. Mandelbaum, et al. 1996. Getting the Most out of Your Product Development Process. Harvard Business Review (March–April), pp. 134–152.
Eisenhardt, K. 1989. Building theories from case study research. Academy of Management Review (14), pp. 532–550.
Fricke, S. E., & A. J. Shenhar. 2000. Managing Multiple Engineering Projects in a Manufacturing Support Environment. IEEE Transactions on Engineering Management, 47 (2), pp. 258–268.
Platje, A., H. Seidel, et al. 1994. Project and Portfolio planning cycle: Project-based management for multiproject challenge. International Journal of Project Management 12 (2), pp. 100–106.
Project Management Institute Standards Committee. 2000. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – 2000 Edition. Newtown Square, PA: Project Management Institute.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA