managing multiple engineering projects in a manufacturing support environment

258 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 47, NO. 2, MAY 2000

Managing Multiple Engineering Projects in aManufacturing Support Environment

Scott E. Fricke and Aaron J. Shenhar

Abstract—Business trends today require front-line managersto integrate multiproject concepts with those of traditional single-project management since very rarely can one find major organiza-tions managing just one project. A typical situation entails a limitedpool of resources which is applied to the management of severalprojects, with people moving back and forth among different as-signments in different projects. Yet, few studies on project manage-ment have started to explore the issue of how to manage an organ-ization with multiple inter- or intradepartmental projects. Using acase study method, our exploratory research investigates the spe-cific problems associated with the management of multiple engi-neering projects in a manufacturing support environment, withthe intent to identify common factors of success. Knowing the fac-tors of success is but the first step toward improving multi-projectmanagement. Our findings provide insight into how the most im-portant multiple-project success factors in this environment differfrom factors of success in traditional single-project management,and are consistent with other emerging research in product devel-opment environments. The differences center on resource alloca-tion and flexibility. Some factors, such as ownership, staff expe-rience, and communication, take on additional dimensions whenconsidered in a multiple- versus a single-project environment. Yetother factors, such as division and assignment of resources, priori-tization, and customized management style, which have little rele-vance in relation to single projects, are shown to play a major rolein the success of multiproject management.

Index Terms—Engineering projects, multiple projects, resourcemanagement.

I. INTRODUCTION

COMPANIES today find themselves in a highly competi-tive environment of rapidly changing operational require-

ments. Many are losing their competitive ability to balance oper-ational processes against harsh business realities, including theneed to manage increasing product complexities, shorter timeto market, newer technologies, and threats of global competi-tion. Given these changes, businesses are trying to improve theirworkload processes with the use of effective project manage-ment techniques. While managing a single project was nevera typical situation in most organizations, these trends requirefront-line managers to focus more and more on the aggregatesuccess of multiple projects, in addition to traditional, single-project management performance. Indeed, few, if any, actualprojects are carried out in complete isolation.

Manuscript received August 5, 1996; revised July 1998. Review of this man-uscript was arranged by Department Editor J. K. Liker.

S. E. Fricke is with Seagate Technology, Bloomington, MN 55437 USA.A. J. Shenhar is with the Wesley J. Howe School of Technology Management,

Stevens Institute of Technology, Hoboken, NJ 07030 USA.Publisher Item Identifier S 0018-9391(00)03357-2.

A typical organization would normally undertake severalproject commitments at the same time while utilizing the samepool of resources. Paradoxically, however, most of the currentliterature onproject managementis still focused on the studyof a single project in isolation, assuming limited interactionsamong projects. Kapur [29], for example, mentions interactionsbetween projects as only one potential means of project failurein a long list of reasons. Even influential and best sellingpublications such as Archibald [6], Frame [25], Love [35],Wheelwright and Clark [63], and Meredith and Mantel [40]devote at most only one chapter to project interactions oraggregate project management. Recent research, however, isstarting to explore the specific problems and success factorsassociated with multiple-project management (e.g., Brown andEisenhardt [14], Adleret al. [2], Griffin and Page [27], andGriffin [28]).

A great portion of the current literature on projects dealswith product development, where the objective is to developand build a new product to meet customer needs according toa certain set of specifications (e.g., [28]). Yet, in addition toproduct development, typical industrial organizations includethe manufacturing function as well, and there, project manage-ment means something else. In this setting, projects are usuallyset up to determine the cause of some defect in the productbeing produced or to determine if some cost-reduction changein the process can be made without downgrading the product'squality and performance [20]. Such projects are typicallyconducted within one department that is supporting the man-ufacturing processes, in contrast to the product developmentcase of interfunctional projects.

Missing from the literature are studies dedicated to under-standing how a first-tier manager in such a manufacturing en-vironment can coordinate a department which undertakes nu-merous projects at the same time and maximize its total deliv-erables. Few are also the reports on common factors and tech-niques that contribute to success or failure in a multiple-projectenvironment. Shifting the attention from an individual projectexecuted across multiple departments to multiple projects exe-cuted in an individual department may provide a new perspec-tive on reasons for project success and failure.

The purpose of this exploratory study is to investigate the spe-cific problems associated with the management of multiple en-gineering projects in a manufacturing support environment, withthe intent to identify common success factors. Lacking an estab-lished theoretical framework and as is common in early stagesof investigation, we chose a case-study method and the method-ology of building theory from case-study research [22]. Whilelimited in scope and focusing on a specific environment, this

0018–9391/00$10.00 © 2000 IEEE

FRICKE AND SHENHAR: MANAGING MULTIPLE ENGINEERING PROJECTS 259

study identified some success factors that were not discussed inthe critical factor literature on single projects.

The next sections include a presentation of the theoreticalbackground and the associated relevant questions, followed bya description of the research method. The findings and successfactors are included in Section IV. Section V is dedicated to im-plications and a discussion on how companies could improvetheir management of multiple projects. We conclude with ideasfor possible directions for further research.

II. BACKGROUND

We define “multiple projects” as a setting in which more thanone project is carried out at the same time. The projects varyin size, importance, required skills, and urgency, are in var-ious stages of completion, and are using the same pool of re-sources. According to this definition, multiple projects exist inalmost every organization in which functional divisions under-take a number of duties through a project format. The “man-ufacturing support environment” is a portion of an organiza-tion whose main activity is related to manufacturing. The mainsource of projects in this environment is presumed to be man-ufacturing engineering or other manufacturing support activity.“Success factors” is used to indicate the specific activities thathave been identified as leading to the success of a project or agroup of projects.

After more than three decades of research, single-project suc-cess factors are well documented [8]. According to the clas-sical proposition organizations must develop a set of strategicstrength areas which are key to the environment and industry inwhich they operate [5], [4], [52]. Notable studies at the productlevel are Project SAPPHO [54], Newprod [16], the Stanfordinnovation study [38], and the more recent studies of Cooperand Kleinschmidt [17]. Success factors at the business unit levelwere studied by MacMillanet al. [37] and by Dviret al. [21].An early study at the project level was conducted by Rubin-steinet al. [55], who found that individuals, rather than orga-nizations, make an R&D project successful. Slevin and Pinto[59] have developed a research framework that identified the fol-lowing major factors contributing to the success of project im-plementation: clearly defined goals, top management support,a competent project manager, competent project team mem-bers, sufficient resources, adequate communication channels,control mechanisms, feedback capabilities, and responsivenessto client’s needs. Using this framework on 52 large projects inthe United States, they found that the most important factorsare those related to satisfying the client’s needs [50]. Pinto andSlevin [51] have also studied success factors across the projectlife cycle; Pinto and Mantel [49] have studied the major causesof project failure, and Might and Fischer [41] investigated struc-tural factors affecting project success. In a recent comprehensivesurvey of previous research, Balachandra and Friar [8] demon-strated that the list of project success factors is indeed verylong and divergent. They suggested, therefore, that future re-search should adapt a contingency framework, focusing on thespecific factors associated with different environments and dif-ferent types of projects. Indeed, different environments were ad-dresses by Pinto and Covin [48], who compared success factors

of construction and R&D projects; and by Tishleret al. [62],who studied success factors in a defense development environ-ment. Success factors and the best practices in new productdevelopment were recently widely addressed by Cooper andKleinschmidt [18], Griffin and Page [27], and Griffin [28].

When more than one project is involved, there is the potentialfor interproject interaction, which may lead to delay. Mur-mann [43], for example, studied 14 projects in eight Germanmechanical engineering companies, and found that projectdelays were as high as 150% with a mean of 41%. Otherstudies (e.g., Mansfield [39] and Norris [44]) noted averagetime deviations of 70% and 140%, respectively. Murmann [43],Brockhoff [13], and Fenneberg [24] noted that delays in smallprojects were generally higher than in the larger ones, attributedmainly to higher priorities of the large projects. Murmann [43]suggested attention to interdependence, recognizing resourceutility, establishing a formal project selection process, andkeeping an activity database.

Two recent studies in a multiple-project environment shouldbe mentioned: Adleret al. [2] used a process model structureadapted to this environment. Focusing mainly on productdevelopment projects, they suggested managing the devel-opment organization as an integrated process, use similarityamong tasks, and share staff and equipment across similarprojects. And Brown and Eisenhardt [14] studied successfulmultiple-product innovation in comparison to nonsuccessfulones. They focused on the importance of limited (but not toochaotic) structures, priority setting, extensive communication,and design freedom. They also emphasized probing the future,and linking the present to the future through time-pacedtransition processes.

The major objective in an environment of multiple, com-peting projects is to maximize overall departmental successrather than the success of any individual project. Because ofthe usually narrow focus and accountability for a singularproject, individual project managers instinctively tend tochoose courses of action that are beneficial to their assignedprojects [12]. A very strong project manager may thus besuccessful in his or her project(s), but the organization maysuffer from delays produced in other projects [6]. The lack ofattention to interdependence leads to what Cyert and March[19] term local rationality. They argue that although individualproject problems may be solved rationally, the individualsolutions may be inconsistent and less than optimal for thefirm (department) as a whole. Thus, companies need to devotemore attention to managing the collection and mix of projects.In particular, they should focus on how resources are allocatedbetween projects [63], [2], [14]. This calls for management toexplicitly understand and use techniques that, in some cases,may help one project succeed at the expense of another. Love[35] suggests that the key to managing multiple projects is toadjust the schedules to suit the available resources, and Adleret al. [2] recommend that organizations take on fewer projectsat a time, relieve bottlenecks, eliminate unnecessary variationin workloads, and eliminate distractions and delays.

These arguments resulted in some practical suggestionsdealing with resource utility. For example, Kapur [29] sug-gested that, for a full-time assignment, the organization should


realize more than 120% (six days/week) of dedicated laborbecause of the intensity with which that resource is enabled towork. A half-time assignment would result in less than 40%( two days/week) of dedicated labor per project' because ofthe switchover time required to align a persons thinking fromone project to another. Alternatively, a loss factor is suggestedof 0% for full-time assignment, 10% for three-quarter-timeassignment, 15% for half-time assignment, and 20% forone-quarter time assignment. Although these numbers are notbacked by hard data, it is interesting to note them as a “rule ofthumb” suggested by a practitioner consulting firm.

Another common suggestion to manage resources withindepartments is the establishment of a formal project selectionprocess or a central capacity planner [56], a “director ofprojects” [45], an “integrator” [23] who is one person whoresolves resource conflicts. This was echoed by other sourceswhich suggest prioritizing by ranking competing projectattributes to decide which projects are most important to theorganization, the use of review boards at “stage gates” alongthe different project phases [16]. Once projects are selectedand prioritized, a decision must be made regarding how manywill be undertaken at one time. A study by Knolmayer [31]confirms that the more projects carried out simultaneously, thelonger the average duration of the individual project, and thehigher the coordination expenditures.

A major issue relevant to allocating resources to differentprojects and prioritization among them involves project clas-sification. If projects could be grouped into categories, thismight make prioritization simpler, and enable instituting orga-nizational policies for project selection and approval. Differentproject typologies have been mentioned in the literature. Forexample, Blake [11] suggested a normative distinction betweenminor change (alpha) projects and major change (beta) projects;Wheelwright and Clark [63] mapped development projectsaccording to the degree of change achieved by their outcomewithin the companys product portfolio. Their typology includedderivative, platform, breakthrough, and R&D projects. Adleret al. [2] have classified projects into support, administration,new products, and line extensions. Cashet al. [15], Ahituvand Neumann [3], Pearson [47], and Steele [60] mentionedadditional frameworks. Finally, Shenhar and Dvir [57] have re-cently suggested a “typological theory of project management.”Using a combination of quantitative and qualitative methodsand two databases, their two-dimensional typology classifiesprojects according to four levels of technological uncertainty(low-tech, medium-tech, high-tech, and super-high-tech, or A,B, C, D, respectively) and three levels of system complexity(or scope) based on a hierarchy of systems and subsystems(assembly, system, and array projects).

The questions addressed in this study are: “What are thespecific problems associated with the management of multipleprojects in a manufacturing support environment, and what arethe most important factors for success and failure?” To answerthese questions, and since we deal with a unique environment,we will first explore more basic questions: “What do multipleprojects look like in a manufacturing support environment,and what characterizes such environment in general?” In otherwords, how different is this environment from a common

product development engineering organization? Realizing thelimitations, scope, and early stage of the study, a great deal ofattention was also devoted to identifying and indicating newdirections for further research on this timely and relevant topic.

III. M ETHODOLOGY AND DATA

A. General

Our main research technique was qualitative [42], subscribingspecifically to the process of building theory from case-study re-search [22]. This process is particularly useful when there is nospecifically defined theory or construct, a small number of casesis involved, and there is a need for within-case and cross-caseanalysis combined with the role of existing literature [26], [61],[22], [30]. Data collection was multifaceted [30], and includedin-depth semistructured interviews, observations, and structuredqualitative questionnaires. To strengthen our research validity,and as is often required by qualitative studies [30], investigatorsinteracted with their subjects on their own turf, namely, at thedepartment site.

B. Data Sources

Research sources involved five manufacturing engineeringand support departments from four separate manufacturingcompanies: a control and navigation device manufacturer, ahigh-tech filter manufacturer, a medical device manufacturer,and a manufacturer of hard disk drive components. Thenumber of cases was within the typical range for this kind ofresearch—four to six cases [22]. All companies were mediumto large size (at least $100M in revenues) and functioningin high-technology industries. Since high technology oftenimplies a need for quick project execution, it was hoped thatcharacteristics unique to this environment would be exagger-ated, and thus easier to identify.

Effort was made to identify managers for interview based ontype of responsibility and years of experience. The target was tofind managers specifically responsible for manufacturing engi-neering and support with at least ten years of field experience.Telephone contacts were made prior to a site visit to confirma targeted manager’s conformance to these criteria. Although,in the instance of case 2, the manager was currently associatedwith product and application development rather than with man-ufacturing support, this case was included nevertheless becausehis previous experience was as required, and the organization it-self met the required criteria. The case provided an insignificantvariance from the other cases against which to test conclusionson multiproject success factors.

C. Data Collection

Most data were qualitative, collected by interviewing expe-rienced technical managers in the field. Each of the intervie-wees was presented a list of open questions involving the na-ture of the company and the department, the characteristics ofprojects in the department, and techniques they have used whichthey have found to contribute to project success or failure. Wenote, however, that success or failure was perceived by the in-terviewees, not measured independently. Interviewees were also


asked to discuss things that were on their minds, not neces-sarily addressed by the structured questions. A detailed list ofinterview questions is given in Appendix I. Although this listwas compiled from previous literature on single-project man-agement as well as recent literature on multiproject manage-ment, it was made clear during the interview that all questionsare focused on the success of multiple, and not single projects.In fact, some of the “free-mind” ideas have departed consider-ably from the original questions, leading to additional insightsand further, more deep discussions.

Interviews lasted from 1 to 2 h, and included a tour of themanufacturing line during part of the interview. After prelimi-nary data analysis, some interviewees were contacted again viatelephone, and two cases were revisited to verify and add de-tail to points of particular interest, thus contributing to an itera-tive process. Notes were taken during interviews, and they werepromptly summarized in writing after the interviews accordingto a common format (Appendix II).

D. Data Analysis

Notes from the interviews were structured into informationabout the company, the interviewee, the department, projectcharacteristics, and project success and failure factors that theinterviewee found to be significant in daily operations. Thefree-form project success/failure factors from all case studieswere then carefully reviewed and generalized into the eightcategories, or major success factors.

The case-by-case outlines were then consolidated into com-prehensive tables. The tables, and the more detailed outlines, al-lowed identification of within-case and cross-case patterns [22].Within-case patterns were identified by the exercise of rewritingand categorizing the notes into the standard outline form, andfollow-up questions and conversations with the interviewees.Comparing categories and dimensions between cases, then se-lecting pairs of cases, and listing similarities and differencesbetween each pair identified cross-case patterns. Iterative tab-ulation of the data and searching evidence for “why” behindrelationships led to the identification of the most common mul-tiple-project success factors, their implications, and the resultantrecommendations.

E. Case Descriptions

The manager at the control and navigation device manufac-turer (company A, case 1) led a department of seven engineersand two technicians. His department was responsible formanufacturing support and continuous process improvementof a high-tech navigation device. Company A was the onlymajor manufacturer of these devices; thus, many of the man-ufacturing processes were unique to this particular companyand product. Engineers from this group were typically assignedresponsibility by device or process manufacturing area. Themanufacturing line at this company was highly automated andtightly controlled.

At company B (case 2), the high-tech filter manufacturer, themanager was responsible at the time of interview for a depart-ment performing new product development. However, he hadjust recently moved from a group responsible for developing

applications for new products, and thus could give an interestingperspective on the workings of the two environments. His cur-rent group consisted of five engineers and technicians respon-sible for the development of basic product concepts that thencould be passed to the application development groups. The ap-plication development group with which the interviewee waspreviously involved consisted of 12 engineers and techniciansresponsible for developing applications for new products, butalso supporting outside customers and transferring new appli-cations to manufacturing.

The medical device manufacturer (company C, case 3) hadthe interesting distinction of being not only a high-tech manu-facturer, but also highly regulated. The manufacturing line wasmuch less automated than in the other companies studied. Theinterviewee in this company had a unique position that requiredextensive interface with both development and manufacturingengineering departments. The development department hadroughly 12 engineers developing and designing new products,with some additional responsibilities for ongoing productsupport. The manufacturing engineering department also had12 engineers doing line support and sustaining engineering.

Interviews at the hard drive component manufacturer wereutilized to check consistency of results within and across de-partments within the same company. Two engineering managerswere interviewed from one department (case 4), and a thirdwas interviewed from another department with a completely dif-ferent organizational association (case 5). The departments had17 and 31 people, respectively, thus qualifying as the largest de-partments studied. All were responsible for sustaining the en-gineering of a manufacturing line, as well as the developmentand incremental improvement of processes, line cost reductions,and control.

Table I summarizes the five case-study environments: depart-ment sizes and objectives, number of consecutive projects,typical project size and duration, and the mix of project clas-sifications according to the Shenhar and Dvir typology [57].

IV. FINDINGS

A. The Multiple-Project Environment

The departments in our case studies ranged from 9 to 31people, with an average of 15 engineers and technicians. Mostspecified an approximate ratio of 3 to 1 in favor of engineers,with the exception of the department with 31 people, whoseratio was approximately 5 to 2 in favor of technicians. Whilesome groups directly supported a manufacturing line, others hadmixed objectives, including product development as well. Yetall departments were required to undertake process developmentand process optimization responsibilities in support to the man-ufacturing process.

Typical project goals in this environment involved problemsolving, machine building, process development, quality im-provements, or cost reductions in the form of labor reductions,yield improvements, capital avoidance, and reduction of burdenand overhead costs. The majority of projects undertaken wereof a small nature—one to six people per project—and lastedfrom one to six months. The department head typically filledthe top management role, one member of the department staff


TABLE ISUMMARY OF CASE INFORMATION

filled the project manager role, and the project team was com-posed mainly of members of the same department. Commonly,two to three staff members were assigned to a project, whileone was serving as the “lead manager.” Additional resourceswere obtained from corporate support services such as labs,tooling, quality, test, or design. Rarely, however, were depart-ments such as Marketing, Sales, Accounting, or Finance in-volved in these types of projects. This, obviously, is in contrastto common, large, cross-functional projects that are well docu-mented in the literature.

Utilizing resources effectively was normally perceivedas a major problem in this environment, and all managersinterviewed felt that they were short staffed. Many engineersin the departments studied were responsible for leading two orthree projects at one time. In addition, they were expected toparticipate in one or two smaller or less critical projects. Manywere also responsible for ongoing “sustaining engineering”duties on different pieces of equipment or in a particular area ofexpertise on the manufacturing floor. Most managers agreed,however, that two to three “major” projects at one time wasan effective maximization of an engineers productivity. Inthis way, engineers were not left with idle time when theyreached slow points on a project, nor were they overburdenedwith too many competing responsibilities. Most projects wereplanned with specific timelines and major milestones. Costs,however, were mainly supported by overhead resources, andwere normally treated indirectly and in less precise order thanschedules and attainment of the final goals. Projects weremonitored through weekly reports combined with one-on-oneor one-on-team meetings.

Two major sources for project initiation were observed. Onewas from the engineers and technicians, which mainly involvedideas for cost reductions, and were sold up the managementchain. The other source of project initiation was top down,coming from upper management, based on strategic initiativesor reactive undertakings in response to customer complaints.Most projects in this environment were justified on the basis ofthe cost of capital equipment since financial return was moreoften than not difficult to quantify. Some interviewees notedthe existence of an “emotional project” [40], one which isdictated by management, while hardly justified through rationalcalculations. It was noted that these “emotional” projects wereoften responsible for disrupting budgets and forecasts sincethey were usually unanticipated.

While the study was conducted in the high-tech industry,unlike new product development, the majority of projects in themanufacturing support environment were low and medium techin nature, based mainly on existing technologies [57]. Low-tech“projects” in this environment took the form of sustainingtasks such as maintaining machine uptime, yields, training,and certification. Case 3 was an exception with medium- andhigh-tech projects, and no low-tech projects at all. In this par-ticular organization, a separate group had been assigned to dealwith the low-tech types. Examples of medium-tech projectsincluded the development of new processes, the installationof new equipment, and problem resolution. There were alsoa smaller number of projects identified as high tech. Suchprojects were mainly exploratory, and typically involved thedevelopment of new technologies.


TABLE IISUMMARY OF CRITICAL SUCCESSFACTORSACROSSCASES

B. Multiple-Project Success Factors

Table II summarizes key variables that were mentioned ascritical factors contributing to project success in a manufac-turing support environment, although, because of the smallsample size, the list of factors may not be inclusive and theremay be other, more refined factors not found in our study.The patterns we identified, however, showed considerableconsistency among cases. It is interesting to note that noneof the interviewees mentioned technical issues as a majorfactor affecting either the success or failure of a project.And other factors commonly mentioned in the single-projectsetting were notably missing (e.g., client acceptance andtroubleshooting [50]).

One could easily recognize a number of factors that were pre-viously identified and documented in the project managementliterature on single-project assignments. Clear goals, top man-agement support, ownership, experienced staff, and communi-cation fall into this category [8], [50], [40]. As noted in ourinterviews, clear goals, top management support, and owner-ship were even perceived as “must have” factors—to the extentthat, without them, failure was guaranteed. However, given thepurpose of this study, the factors of most interest are those thathave little relevance to project success when carried out in iso-lation. Such factors generally have not been addressed in detailin the existing literature on project management. The factors wefound belonging to this list are the division and assignment of re-sources among projects, prioritization, and flexible customiza-tion of management to the specific project type [2], [14]. Yet,other factors, such as ownership, experienced staff, and commu-nication, which are frequently mentioned in the single-projectmanagement literature, take on a different form and meaningwhen applied to nonisolated projects [14]. The following dis-cussion addresses in detail the context of these nontraditional ormodified success factors.

The most relevant factors with respect to multiprojectmanagement were the division and assignment of resourcesamong projects, prioritization, and flexible customization.However, their presence or absence was clearly affected by

other factors, and by interaction among factors. Managersbelieved that dividing and dedicating resources to sustainingor development tasks was a key to long-term project successin multiple-project environments. However, the importanceof dividing and assigning resources was mentioned togetherwith the need for flexible customization, as well as havingan experienced, cross-trained staff whose members couldundertake assignments on short notice, and could easily switchfrom task to task. For example, in case 5, 12 of the 31 staffmembers were assigned to sustaining engineering tasks (lowtech), seven to process optimization (medium tech), six to newprocess development projects (medium to high tech), and therest to process control and metrology projects. What clearlycontributed to success in this department was the fact that staffwas cross trained in each other’s areas of expertise, and theycould easily move between projects. Almost all other casesdemonstrated this point as well: as noted, the greatest restriction(or barrier) to success was a group’s lack of cross training,and the ensuing inability to shift resources and project leadersamong projects. If technical resources are well cross trained ondifferent types of work and are flexible enough, more projectscan run smoothly in parallel (rather than sequentially), and totalwork productivity is higher. One should note the differencebetween the need to have an experienced staff focusing on asingle project, and a similar, but slightly different need to beable to move staff from one project to the next in a multiprojectenvironment where the priorities and needs of the organizationmay change on a weekly or even daily basis.

Similarly, the most common factors in both single- and mul-tiple-project environments, clear goals and top managementsupport, have also demonstrated interaction with other factors.Clear goals are clearly critical to success in all cases. Goals,however, can be interpreted in different ways, and by differentstakeholders. In a multiple-project manufacturing environmentwhen there is typically no identified external customer andmany projects are done for internal purposes, project goalsare determined by department management. Management,however, may see these goals in a different light when prioritiesare shifted or new assignments are undertaken. Similarly, top


management support, which is so important to the stability andsuccess of single projects, may be affected strongly by shiftingpriorities and other changes which are so characteristic of amultiple-project environment.

Prioritization, in fact, appears to be one of the most impor-tant factors. It is inextricably linked to the availability of re-sources. In a department with many small-size projects withvarying ranges of importance, project priorities can shift on al-most a daily basis. A major challenge in this environment iskeeping resources focused on the top-priority project withouthurting the less important ongoing smaller projects. A commoncomplaint expressed by at least two thirds of the managers wasthat staff resources are continually distracted with side projectswhich are not necessarily critical to departmental or organiza-tional success. Although this is potentially similar to what hap-pens between subprojects or activities in a single project, the dif-ference is that a single project has one goal, one priority, and onemanager who could integrate it all, while multiple projects varyin goals and priorities, and have different managers. The chal-lenge is therefore greater when there is a need to decide whichproject is more important and deserves the focus of existing andlimited resources.

The prioritization problem demonstrates another deviationfrom the single-project case. As we found, resources in amultiproject environment are often not recognized as part ofa common pool. They are frequently viewed as individualresources dedicated to individual projects. Therefore, the man-agers’ ability to prioritize projects and assign resources was aneven stronger key factor influencing total success. The mostcommonly attempted remedy is to bring together functionalmanagers to set priorities on their common resources. Whilesome prioritization systems appeared to succeed, others failed,often because of a lack of a single responsible decision maker.If a clear decision maker could be assumed, he or she couldrecognize the need for, and then make, critical prioritizationdecisions.

As mentioned, the problem of allocating resources andsetting priorities among different projects is associated withthe need to customize management to the specific project,namely, to adapt management style to the individual projecttype. Thus, there is clearly a need to classify projects usingsome typology for distinction among projects. For lack of astandard classification schema, we often observed managers inmultiproject environments using implicit, rather than explicitproject classification templates, or find their “own” way ofdistinguishing among projects, and thus treating them differ-ently. For example, some managers mentioned that “simpler”projects (coined by us during interviews as “low-tech”) mightnot need milestone chart tracking, while other, “more compli-cated” (i.e., medium- to high-tech) projects require extremelydetailed methods for tracking both schedules and costs. Theability to recognize these differences between project types andadjust the management style accordingly was reported to be asignificant factor of overall project success in multiple-projectenvironments. While this factor was not mentioned as fre-quently as some of the other success factors, to some successfulmanagers, this ability seemed a “second nature,” and doing itwas straightforward without too much elaboration. This mayexplain why some did not mention it initially in their list of

critical factors. In later discussion and in the “open-minded”stage, however, it was acknowledged in many different ways.As one manager put it: “Well, not all projects are the same, andwe must learn to treat them differently.”

Ownership means the full acceptance of responsibility bythe project leader and project team for the success or failureof a project. Although it is commonly a factor of success in asingle-project environment, it was found to be increasingly im-portant in a multiproject environment where an individual orteam is assigned to more than one project at the same time. Untilownership is clearly accepted, a project can languish forever atthe bottom of the “to-do” list. Although ownership can be emo-tional, namely, some people may make a specific task their “petproject,” it is also strongly influenced by the actions of manage-ment. In addition to prioritization, we found that managementcan play a major role in matching individuals to projects, andmake sure team members accept ownership on a personal level(“this baby is yours, pal”).

Communication was found to take on an enhanced role in themultiproject environment. In addition to communication withina project team, proper, frequent communication up and downthe management chain and between project teams was clearlyseen as critical to success in the multiproject environment.Information streaming among projects related to milestones,dates of completion, resource needs, and people’s availability(or lack of it). Good communication did not necessarily meanlarge volumes or frequent communications. To the contrary,enacting trust-building systems that relied on short interactionsand immediate-action items increased project success rates.Such norms actually reduced the volume of reported material,and limited communication to those with the authority andability to decide and help. In one example, a team of functionalmanagers would meet with internal “customers” for a summarycommunication of their project’s status. This practice hasgreatly reduced the time spent on repetition of ideas, requests,and explanations, and therefore improved communicationeffectiveness. In sum, communication in a multiproject envi-ronment is a double-loop process: it must happen, as usual,within the project, but also across and above individual projectarenas. This phenomenon was found relevant to multiple- aswell as single-project environments [36], [14].

Finally, at least six management skills were found useful inthis environment. They were leadership, motivation, planning,decision making, coaching, and communication. Although theseskills are not unique for a multiproject setting, their existencewas clearly mentioned as contributing to achieving the list ofcritical success factors in this environment. Because of the smallsample and similarities among some skills, we grouped theminto four categories, as shown in Table III. The table indicatesthe linkage that was found in our study among these skills andsuccess factors. As can be seen, taking care of multiple-projectsuccess factors depends, in most cases, on a mixture of skills.

V. IMPLICATIONS

A. General

Although limited in scope, sample size, and specific environ-ment, this exploratory study provides some important insights


TABLE IIIMANAGEMENT SKILL DEVELOPMENT AND SUCCESSFACTORS

into and implications of management and organizations at large,even at this early stage of investigation. It indicates the unique-ness of the multiproject environment, and suggests the existenceof specific problems associated with managing such projects ina manufacturing support setting. Focusing on the uniqueness ofthe environment and eventually understanding its specific suc-cess factors may improve project management effectiveness inthis less studied environment. As many managers emphasized,it is important to develop the right setting, attitude, tools, andparticular skills in these departments. In the following discus-sion, we integrate the major lessons that emerged, and sug-gest some ideas for management consideration in a multipro-ject environment.

B. The Process of Project Selection

Although project selection issues have been well investi-gated, particularly in an R&D context (e.g., Bardet al. [9] andPearson [46]), they pose specific problems in a multiprojectmanufacturing environment. The normal process of projectselection suggests doing a yearly review of the business projectportfolio, followed by midyear updates and ongoing periodicalreviews. Decision making is based on the company businessstrategies, using some form of criteria or ranking methods (e.g.,Bard et al. [9]). Since only a few of the projects in the multi-project manufacturing support environment can be attributed tomajor organizational strategies, and many are locally initiatedsmall tasks, a yearly process of project assessment and selectionmay have only a limited value. It may help management seethe big picture, but it is hardly sufficient. It seems that projectselection should be conducted almost as a routine activity[14]. While a periodical monthly process may be appropriate,managers should leave room for taking up assignments at anytime, and not waiting for the monthly reviews. For this process,an organization should develop its own criteria and policies tohelp decision makers in making their selections. Such criteriamay be based on company policies and strategy, and use someform of project classification and determined priorities.

Project selection often involves setting a target value to limitthe number of projects which the department will undertake atone time (see Adleret al. [2]). To do this, it may be useful totake into consideration the apparent de facto standard of two tothree projects per person found in the field and the “loss factor”rule of thumb proposed by Kapur [29].

C. Project Classification, Priorities, and Policies

As we found, most managers use some explicit or implicitform of distinguishing among projects. Obviously, not allprojects are the same, and they differ in importance, size,difficulty, and time frame. Implementing an explicit andformal construct for project classification may help the or-ganization in setting its priorities according to its needs andstrategy, and may contribute to the process of project selection,customizing management to the specific project, and com-municating management vision and goals to team members.The classification may be based on the type and meaning ofthe project (e.g., support, improvement, new product [2]),the technological uncertainty of the project (e.g., low tech,medium tech, etc. [57]), or on some format that fits the specificorganizational tasks and character. It would be helpful if thetypology is well communicated and accepted by managementand team members. Once the framework has been established,management could state its priorities and policies related toproject types. In this way, specific project selection becomeseasier, and it may reduce some of the conflict and argumentsregarding resources and priorities. In this way also, when a newassignment comes on, it is easier to assess its importance incomparison to existing and running projects.

D. Allocating Resources and Managing the “Mix”

Once projects have been selected, it is management’sresponsibility to see that the mixture of projects is managedwell, that important projects get the right resources, and that notask is randomly left behind for lack of interest, resources, orother nonrelevant reasons. The process of allocating resources


in a manufacturing environment is an ongoing process aswell. Although resources could be shifted constantly, someform of stability should be maintained. Management shouldconsider protecting certain tasks from too much change, andmake sure that the important projects sustain some nucleus ofpeople to carry them through. Ownership is critical as well.Management should make sure every project or task has anowner who takes the responsibility, is accountable for gettingthe job done, and will fight for this project. Similarly, the rightpeople should manage the right project, and the appropriateproject management style should be employed for the specifictype of project.

E. Developing Management Skills

Leadership in the multiproject manufacturing support depart-ment obviously requires setting clear goals. Leaders must alsoprovide support, establish ownership, and know how to motivatetheir staff. Leadership in this environment also means matchingthe right person and style to the project, while understanding theconcepts of project classification and adaptation. Finally, effec-tive leaders know how to communicate their goals, explain theirpolicies, and make sure that all members are informed.

Planning and decision making in this environment requiredeveloping methods for allocating resources and prioritization.And, as before, managers should learn how to use project clas-sification in their planning processes. Different projects mayneed different approaches to planning, risk management, andresource utilization.

Coaching poses another unique challenge in this environ-ment. While developing technical skills of staff membersis important in all settings, the multiproject environment isparticularly susceptible to flexibility. Building an experiencedstaff in this environment means training and cross trainingpeople to conduct a myriad of assignments, and being ready toswitch among jobs on short notice.

Finally, communication skills in this environment requireadditional attention as well. If assignments are changedconstantly, management should make sure that prioritization,ownership, and resources are being reassigned as neededand communicated on an ongoing basis. Communicationinvolves formal means such as reports and documents, buta great deal of communication is informal, based on dailyongoing interactions.

VI. CONCLUSION

Even at this early stage of study, our research suggeststhat project management in multiple-project environments isunique, and has different and additional factors of success thanthose found in traditional research on single-project manage-ment. While previously known factors such as clear goals,management support, ownership, staff experience, and com-munication are also key to project success in a multiple-projectenvironment, some of them, such as ownership, staff ex-perience, and communication, seem to take on additionaldimensions in the multiple-project environment. Other factorssuch as the division and assignment of resources, prioritization,

and flexible customization of management style generally havenot been discussed in relation to single projects in isolation.A clear understanding of basic similarities and differencesbetween projects is important, and may help managers in thisenvironment to divide, assign, and manage resources moreefficiently. It also may help management when adapting ordeveloping specific tools, processes, and documentation forthis environment. And understanding common classificationsfor projects in this type of environment may prove useful to“manage the mix.”

Although exploratory and limited in scope, this study may beseen as part of a new stream of research on this timely topic,and may offer some ideas for further investigations on mul-tiple-project management. First, because of the small samplesize, many of the conclusions are only preliminary. Further re-search may add justification and focus on the full list of multi-project success factors. Multiple projects are common in mostorganizations, and their study in the future should focus on allorganizational functions. It is very likely that such research willshed light on new success factors not identified in the currentstudy. Of special interest for additional research are also the con-tributions of a cross-trained workforce, and the types of commu-nications that are most effective in a multiple-project environ-ment. An interesting topic for potential further study is also thevery significant trend in increasing productivity through dedica-tion of resources by project type in multiproject environments.Finally, what is the proper classification schema for a multipleproject environment? What is the best way to distinguish amongprojects in manufacturing support versus engineering develop-ment departments may be the subject of another timely study.

APPENDIX IINTERVIEW QUESTIONS

Environment

Describe your area and the duties/responsibilities of yourgroup.

How many people are in your group?How many projects does your group typically undertake atone time?How is achievement measured in your area?

Typical Project Characteristics

Describe projects in terms of number of people involved,functional or cross functional, duration, cost, typical activitiesrequired, high/low tech, etc.

How many people are involved in a project typical of yourdepartment, and how long does such a project typicallytake? (Is there such a thing as a typical project?) Do youfeel that this is a good number people or amount of time?Why?What percent of time are your people split betweenmedium/high-tech projects (i.e., new development) andlow-tech projects (i.e., current systems support roles)?What should this ratio be? How do you think this idealratio can be achieved?


Project Success/Failure Factors

What determines a project’s success or failure?

How many projects can one person successfully lead/par-ticipate in at one time?Is it typical to find a point in a project’s life where theleadership role needs to change in order for the project tobe successful? How is this change handled?How would you rank the following success dimensions:meeting design goals, benefits to customer, benefits to thedeveloping organization? Why?How would you rank the following success dimensions:cost, schedule, performance?Does your senior management provide you with a strategicdirection?

APPENDIX IISTANDARD FORMAT OUTLINE FOR INTERVIEW NOTES

CompanyProductsGeneral company info

IntervieweePositionYears in field

Department General InfoStaff sizeDepartmental duties/objectives/charterProjects/person

Project CharacteristicsPeople/projectDurationIntra- or interdepartmentalTypical project objectivesPlanning, tracking, costsSource of project initiationClassification distribution (A/B/C/D)

Success/Failure Factors (from experience)

REFERENCES

[1] Abdel-Hamid, Sengupta, and Hardebeck, “The effect of reward struc-tures on allocating shared staff resources among interdependent softwareprojects: An experimental investigation,”IEEE Trans. Eng. Manag., vol.41, no. 2, pp. 115–125, 1994.

[2] P. S. Adler, A. Mandelbaum, V. Nguen, and E. Schwerer, “Getting themost out of your product development process,”Harvard Bus. Rev., pp.134–152, Mar.–Apr. 1996.

[3] N. Ahituv and S. Neumann, “A flexible approach to information systemdevelopment,”MIS Quart., pp. 69–78, June 1984.

[4] K. R. Andrews,The Concept of Corporate Strategy. Homewood, IL:Irwin, 1971.

[5] I. H. Ansoff, Corporate Strategy an Analytical Approach to BusinessPolicy for Growth and Expansion. New York: McGraw-Hill, 1965.

[6] R. D. Archibald,Managing High-Technology Programs and Projects,2nd ed. New York: Wiley, 1992.

[7] A. O. Awani, Data Processing Project Management. Princeton, NJ:Petrocelli, 1986.

[8] R. Balachandra and J. H. Friar, “Factors for success in R&D projects andnew product innovation: A contextual framework,”IEEE Trans. Eng.Manag., vol. 44, no. 3, pp. 276–287, 1997.

[9] J. F. Bard, R. Balachandra, and P. E. Kaufman,IEEE Trans. Eng.Manag., vol. 35, no. 3, pp. 139–146, 1988.

[10] R. Barlog and D. Ginn, “Reduce project-cycle time,”Chem. Eng., pp.133–135, July 1994.

[11] S. B. Blake, Managing for Responsive Research and Develop-ment. San Francisco, CA: Freeman, 1978.

[12] R. G. Boznak, “Master business planning: The art of controlling projectmanagement in a multi-project environment,” inProject Manage. Instit.Sem./Symp., Milwaukee, WI, Oct. 1987, pp. 143–158.

[13] K. Brockhoff and C. Urban, “Zeitmanagement in Forschung und En-twicklung,” Z. Betriebswirtschaftliche Forschung zfbf., pp. 1–42, 1988.Special Publ. 23-88.

[14] S. L. Brown and K. M. Eisenhardt, “The art of continuous change:Linking complexity theory and time-paced evolution in relentlesslyshifting organization,”Admin. Sci. Quart., vol. 42, pp. 1–34, 1997.

[15] J. I. Cash Jr., W. F. McFarlan, and J. L. McKenney,Corporate Informa-tion Systems Management. Homewood, IL: Irwin, 1988.

[16] R. G. Cooper, “A process model for industrial new product develop-ment,” IEEE Trans. Eng. Manag., vol. EM-30, pp. 2–11, Feb. 1983.

[17] R. G. Cooper and E. J. Kleinschmidt, “Success factors in product inno-vation,” Indust. Marketing Manage., vol. 16, no. 3, pp. 215–224, 1987.

[18] , “Uncovering the keys to new product success,”Eng. Manage. Rev.,pp. 5–18, Winter 1993.

[19] R. M. Cyert and J. G. March,A Behavioral Theory of theFirm. Englewood Cliffs, NJ: Prentice-Hall, 1963.

[20] W. J. Diamond,Practical Experimental Designs. Belmont, CA: Life-time Learning, 1981.

[21] D. Dvir, E. Segev, and A. J. Shenhar, “'Technologys varying impact onthe success of strategic business units within the miles and snow ty-pology,” Strat. Manage. J., vol. 14, 1993.

[22] K. M. Eisenhardt, “Building theories from case study research,”Acad.Manage. Rev., vol. 14, no. 4, pp. 532–550, 1989.

[23] J. Felch, “How to manage concurrent engineering,”Mach. Des., pp.56–57, Feb. 1994.

[24] G. Fenneberg, Kosten- und Terminabweichungenuim Entwicklungs-bereich, Darmstadt, Germany, 1979.

[25] J. D. Frame,The New Project Management. San Francisco, CA:Jossey-Bass, 1994.

[26] B. G. Glaser and A. L. Strauss,The Discovery of Grounded Theory:Strategies for Qualitative Research. Chicago, IL: Aldine, 1967.

[27] A Griffin and A. L. Page, “PDMA success measurement project: Rec-ommended measures for product development success and failure,”J.Prod. Innovation Manage., vol. 13, pp. 478–496, 1996.

[28] A. Griffin, “PDMA research on new product development practices:Updating trends and benchmarking best practices,”J. Prod. InnovationManage., vol. 14, pp. 429–458, 1997.

[29] Kapur International, Inc.,Project Management Seminar Hand-book. San Ramon, CA: Center for Project Management, 1993.

[30] J. Kirk and M. L. Miller, Reliability and Validity in Qualitative Re-search. Beverly Hills, CA: Sage, 1986, vol. 1. Sage Univ. Ser. on Qual-itative Res. Methods.

[31] G. Knolmayer, “Das brookshe gesetz,”WiSt, vol. 9, pp. 453–457, 1987.[32] R. Leifer and W. J. Burke, “Organizational activity analysis: A method-

ology for analyzing and improving technical organizations,”IEEETrans. Eng. Manag., vol. 41, no. 3, pp. 234–244, 1994.

[33] C. Y. Lin and R. R. Levary, “Computer-aided software developmentprocess design,”IEEE Trans. Software Eng., vol. 15, pp. 1025–1037,1989.

[34] S. Lipovetsky, A. Tishler, D. Dvir, and A. Shenhar, “The relative im-portance of project success dimensions,” Israel Inst. Bus. Res., WorkingPaper 26/95, Sept. 1996.

[35] S. F. Love,Achieving Problem Free Project Management. New York:Wiley, 1989.

[36] G. Lynn, “Organizational team learning for really new product develop-ment,” Marketing Sci. Inst., Boston, MA, 97-113, July 1997.

[37] I. C. MacMillan, I. C. MacMillan, D. C. Hambrick, and D. L. Day, “Theproduct portfolio and profitability—A PIMS-based analysis of indus-trial-product business,”Acad. Manage. J., vol. 25, no. 4, pp. 773–755,1982.

[38] M. A. Maidique and B. J. Zirger, “A study of success and failure inproduct innovation: The case of the U.S. electronics industry,”IEEETrans. Eng. Manage., vol. EM-31, pp. 192–203, 1984.

[39] E. Mansfieldet al., Research and Innovation in the Modern Corpora-tion New York, 1971.

[40] J. R. Meredith and S. J. Mantel,Project Management—A ManagerialApproach, 3rd ed. New York: Wiley, 1995.

[41] R. J. Might and W. A. Fischer, “The role of structural factors in deter-mining project management success,”IEEE Trans. Eng. Manag., vol.EM-32, no. 2, pp. 71–77, 1985.

[42] M. B. Miles and M. A. Huberman,Qualitative Data Analysis. BeverlyHills, CA: Sage, 1984.


[43] P. A. Murmann, “Expected development time reduction in the Germanmechanical engineering industry,”J. Prod. Innovation Manage., vol. 11,pp. 236–252, 1994.

[44] K. P. Norris, “The accuracy of project cost and estimates in industrialR&D,” R&D Manage., vol. 2, pp. 25–36, 1971.

[45] J. H. Payne, “Management of multiple simultaneous projects,”Int. J.Project Manage., vol. 13, no. 3, pp. 163–168, 1995.

[46] A. W. Pearson, “Project selection in an organizational context,”IEEETrans. Eng. Manage., vol. EM-21, no. 4, pp. 152–158, 1974.

[47] , “Innovation strategy,”Technovation, vol. 10, no. 3, pp. 185–192,1990.

[48] J. K. Pinto and J. G. Covin, “Critical factors in project implementation:A comparison of construction and R&D projects,”Technovation, vol. 9,pp. 49–62, 1989.

[49] J. K. Pinto and S. J. Mantel, “The causes of project failure,”IEEE Trans.Eng. Manag., vol. 37, no. 4, pp. 269–276, 1990.

[50] J. K. Pinto and D. S. Slevin, “Critical factors in successful project im-plementation,”IEEE Trans. Eng. Manag., vol. EM-34, no. 1, pp. 22–27,1987.

[51] , “Project success: Definitions and measurement techniques,”Project Manage. J., vol. 19, no. 3, pp. 67–73, 1988.

[52] M. E. Porter,Competitive Strategy. New York: Free Press, 1980.[53] T. Reeder, “Take a flexible approach,”Indust. Eng., pp. 29–35, Mar.

1995.[54] R. Rothwell, C. Freeman, A. Horsley, V. T. P. Jervis, A. B. Robertson,

and J. Townsend, “SAPPHO updated—Project SAPPHO phase 2,”Res.Policy, vol. 3, pp. 258–291, 1974.

[55] A. M. Rubinstein, A. K. Chakrabarti, R. D. O’Keefe, W. E. Sounder,and H. C. Young, “Factors influencing success at the project level,”Res.Manage., vol. 16, pp. 15–20, 1979.

[56] M. Scheinberg and J. Stretton, “Multiproject planning: Tuning portfolioindices,”Int. J. Project Manage., vol. 12, no. 2, pp. 107–114, 1994.

[57] A. J. Shenhar and D. Dvir, “Toward a typological theory of project man-agement,”Res. Policy, vol. 25, pp. 607–632, 1996.

[58] A. J. Shenhar, D. Dvir, and O. Levy, “Mapping the dimensions of projectsuccess,”Project Manage. J., pp. 5–13, June 1997.

[59] D. P. Slevin and J. K. Pinto, “The project implementation profile: Newtool for project managers,”Project Manage. J., vol. 18, pp. 57–71, 1986.

[60] L. W. Steele,Innovation in Big Business. New York: Elsevier, 1975.[61] A. L. Strauss,Qualitative Analysis for Social Scientists. Cambridge,

U.K.: Cambridge Univ. Press, 1987.

[62] A. Tishler, D. Dvir, A. Shenhar, and S. Lipovetsky, “Identifying criticalsuccess factors in defense development projects: A multivariate anal-ysis,” Technol. Forecasting Social Change, vol. 51, no. 2, pp. 151–171,1996.

[63] S. C. Wheelwright and K. B. Clark,Revolutionizing Product Develop-ment. New York: Pergamon, 1992.

[64] G. Whitney, “Organizational analysis: Its application to performance im-provement,”Nat. Productivity Rev., pp. 168–176, Spring 1987.

Scott E. Fricke received the bachelors degree in ma-terials science and engineering from NorthwesternUniversity and the masters degree in management oftechnology from the University of Minnesota.

He is an Engineering Manager at Seagate Tech-nology, Inc., Bloomington, MN.

Aaron J. Shenhar has received five academic degrees in various fields of en-gineering and management from Stanford University and the Technion, IsraelInstitute of Technology.

He is the Institute Professor of Management at Stevens Institute of Tech-nology. Previously, he was at the University of Minnesota and Tel-Aviv Uni-versity. He accumulated more than 20 years of technical and management ex-perience as an Executive in the defense industry in Israel. In his present aca-demic career, he is focused on teaching and research in the areas of technologyand innovation management, project management, product development, andthe management of professional people. He is a recognized Speaker and Con-sultant in leading high-technology organizations such as 3M, Honeywell, CrayResearch, Trane, and Martin-Lockheed.

For his cumulative contribution to engineering and technology management,Dr. Shenhar was chosen “Engineering Manager of the Year” by the EngineeringManagement Society of IEEE.

managing multiple engineering projects in a manufacturing support environment

Documents