There is a premise in much of current project management literature that all projects are fundamentally similar. Consequently, they can be managed with the same set of principles and tools. To some experts, this translates into a “one-size-fits-all” form of project management for all sizes— and types—of projects.
Recent research takes a different view, arguing that projects with different characteristics and properties present different management issues; therefore, organizations should use different management strategies for the different types of projects (Pinto and Govin 1989; Balachandra and Friar 1997; Shenhar 1998; Shenhar 2001; Yap and Souder 1994; Eisenhardt and Tabrizi 1995; Brown and Eisenhardt 1997; Song, Souder et al 1997; Souder and Song 1997). Essentially, this is a contingency approach. Many practitioners, in particular, project managers, tend to agree with the new view (Brooks 1987). As an example, many of these practitioners perceive that new product development projects and software development projects are significantly different and that each poses its own set of management problems. Correspondingly, the approach to project management must take into account the specific characteristics of the two projects types.
This exploratory study sought to reconcile the two views, the one-size-fits-all approach and the contingency approach, within a research framework for assessing project managers’ perceptions of standardized project management (SPM). In particular, this study examined similarities and dissimilarities in managerial opinions regarding SPM factors and their impact on project management capability (PMC) in the two project types. Two research questions guided this study:
• What differences exist in the perceptions of project managers concerning SPM and PMC in new product development projects as compared with software development projects?
• What differences exist in the perceptions of project managers concerning the impact of SPM factors on PMC in the two types of projects?
It was expected that answers to these questions would bring together the one-size-fits-all and contingency approaches to SPM. This expectation was met by key findings in this study that both similarities and differences exist in the SPM of new product development (NPD) and software development (SWD) projects. Implementing an SPM effort, the study results suggest, requires a careful balancing of the two approaches. Where there are similarities, managers should manage certain aspects of SPM deployment with the one-size-fits-all approach. Other aspects should be managed from a contingency approach, when project type-specific circumstances are present.
Background
It has been known for some time that increasing standardization of the project management process can help improve PMC, the ability to deliver projects successfully per predetermined schedule, cost, quality, and customer satisfaction goals. Therefore, different methodologies for reaching standardization have captured the attention of both researchers and practitioners. Much of the existing body of research argues that eliminating variation in the project management process—for example, by adhering to a consistent sequence of project phases, activities, deliverables, and milestones—may significantly enhance such standardization, and hence, the PMC (Adler, Mandelbaum et al 1996). However, the use of the process as a predictor for PMC may depend on another set of factors frequently unnoticed by researchers. These factors include the type of project being studied and other SPM factors such as methods, organizational structures, performance metrics, leadership, and so on.
Exhibit 1. SPM Factors as They Relate to A Guide to the Project Management Body of Knowledge (PMBOK®Guide)
Recent research has shown that standardization of project management, and the resulting PMC, can significantly improve as standard work methods and specific organizational structures are deployed in certain types of projects (Sobek(II), Liker et al 1998; Nobeoka and Cusumano 1995). Findings like this encourage the contingency approach to project management as some SPM factors may be important in some types of projects and not in others. Since the constructs of project type and SPM are essential to our research framework, each of these constructs will be reviewed in the following sections.
Standardized Project Management
Many researchers have worked to identify success factors, specific activities that are assumed to lead to the success of a project or group of projects. Some of the recent, prominent research focuses on the product level (Cooper 1983; Maidique and Zirger 1984; Cooper and Kleinschmidt 1987). Pinto and Slevin have studied fourteen success factors in project implementation as well as across the project life cycle (Pinto and Govin 1989). Balachandra and Friar (Balachandra and Friar 1997)identified a long list of success factors for research and development (R&D) projects. Still, other researchers studied success factors in multiproject management for NPD (Eisenhardt and Tabrizi 1995; Adler, Mandelbaum et al 1996).
All of these studies focus on project success factors on the single or multiple project level. The present study differs in that it focuses on success factors in the SPM setting (hence, our term of “SPM factors”). In particular, we looked at differences in SPM factors that are needed for improving PMC in NPD and SWD projects.
Standardized project management (SPM) is defined as a methodology of managing projects that is composed of standardized practices (Toney and Powers 1997; Kerzner 2000). In our context, standardization means the degree of absence of variation in implementing such practices (Stevenson 1993). Hence, as variation decreases, standardization increases. The underlying principle of SPM is the creation of a predictable methodology with project management practices that are stable and in control. There is a corresponding expectation that the deployment of such a methodology will preclude project management practices that vary from project to project and from project manager to project manager, leading to a repeatable project management methodology and higher PMC.
These project management practices can be conceptualized as constituent elements of SPM factors, seven of which are identified for this study. These SPM factors can be cross-referenced to A Guide to Project Management Body of Knowledge (PMBOK® Guide), an established project management standard, as shown in Exhibit 1. These SPM factors were developed through a grounded-theory research approach combined with a literature search (see Methodology/Sample and Data Collection in the following). They are not specific to NPD and SWD projects; rather, they are of a general nature, spanning diverse project types. They are described below, along with a hypothetical discussion as to how they will impact SPM in NPD and SWD projects. Because of their general nature, these SPM factors may not act as we have hypothesized. One reason for this may be the differences between NPD and SWD projects that are described in the following
Project Management Process: Projects that are organized as a streamlined sequence of activities and that are intended to create added value for project customers will mean improved PMC.
Logic:Process has been considered an important factor in NPD projects (Lynn, Abel et al 1999). Process can be based on structured project life cycle stages, project management activities, and milestones, for example (Clark and Wheelwright 1993). These stages are typically composed of logically related project activities, usually culminating in the completion of a major deliverable such as a project milestone or a significant event. To structure these stages as a sequential, overlapping, or concurrent engineering process is determined by the control needs of the organizations involved in the projects (Calantone and Benedetto 2000; Yassine, Chelst et al 2000). It is believed that such a standard process can save project personnel the trouble of reinventing a new process for each individual NPD and SWD project and that it will eventually enhance PMC (Sobek(II), Liker et al 1998; Raz 1993).
Project Organization: Bringing together all company projects and organizing their management as a coordinated portfolio will increase the ability to deliver projects in tune with the project goals and thus drive PMC.
Logic:Several previous studies have found that companies that organize their projects around cross-functional, dedicated, and accountable project teams with strong management support outperform those who do not (Cooper and Kleinschmidt 1994; Zirger and Hartley 1996; Merrills 1989; Song, Thieme et al 1998). The present study does not take this project-level view. Rather, it examines a higher organizational level, recently termed the “enterprise” level (Dinsmore 1999.). The idea behind the enterprise level is that interrelating all organizational projects and synchronizing and aligning them with the organization’s business strategy, through such designs as project offices or centers of excellence, will promote the accomplishment of project goals (Gareis 1991; Block and Frame 2001). Naturally, integration of all of an organization’s projects and facilitation of their project management will improve PMC (Kerzner 2000).
Information Technology: The ability to leverage the organization’s information technology to create advantage for a project means improved PMC.
Logic: Project management information systems based upon project management software technology have been considered an important part of project success (Clark 1989). The current trend is to use integrated information technology, called enterprise project management software (Levine 1998), which links individual projects together, thus allowing management of the projects as a portfolio. By assisting in gathering, integrating, and disseminating the output of the portfolio management process, information technology makes the process accessible to management and enables support of all projects and facilitation of their goals and of PMC.
Project Management Methods: Employing good project management methods that are selected to support project delivery and that are mutually compatible will enhance the accomplishment of project goals, and consequently, PMC.
Logic: Although many project management books emphasize the contribution that methods can make to the attainment of project goals, empirical studies on this issue are scarce. Shenhar (2001) proposed that certain methods are drivers of project success, and Sobek et al (1998) found that standard project methods are crucial in providing a smooth project management process that will lead to reaching project goals. Their rationale is that methods—for example, work breakdown structure or earned value analysis—improve the quality execution of project tasks and enable the project management process, making the project goals therefore easier to achieve.
Metrics: Projects using comprehensive metrics to measure and monitor performance will have fewer problems, hence higher PMC.
Logic: Metrics are performance measures that are often cited as a key to project success (Hauser 1998; Tipping, Zeffren et al 1995) when they include all strategic areas of project health, are tiered to reflect success indicators for all management levels in a project, and are mutually compatible (e.g., the schedule and cost metrics in the earned value project management are compatible). If all these factors prevail, such metrics should help in understanding how well the project strategy works, where and why it is flawed, and how to devise actions to eliminate the flaws, bringing a project closer to its goals. Thus, designing and deploying such metrics should promote PMC.
Project Culture: In a strong project culture, team members are more satisfied, engaged, and mutually supportive. They will therefore work harder, and be more effective and more successful, which will eventually lead to increased PMC.
Logic: Organizational culture has been cited as a key success factor on the organizational level. Similarly, project management organizations strive to design an effective project culture, expressed as a set of shared behavioral norms and expectations (Cooke 1988). It is intended that personnel will identify with the norms and expectations and invest both materially and emotionally in the project (Schacht 1997; Fricke and Shenhar 2000), thus making them more engaged, committed, enthusiastic, and willing to support each other to accomplish project goals (Aronson, Lechler et al 2001).
Leadership: Projects managed by project managers with strong leadership skills are more successful and effective, thus influencing PMC.
Logic: The concept of a strong project leader as a key to project success has been a consistent topic of many studies (Cooper and Kleinschmidt 1994; Sobek(II), Liker et al 1998; Shenhar 2001). As a consequence, there is a strong drive in today’s organizations to define leadership style in terms of specific leadership competencies, e.g., interpersonal thinking, business, and process competencies (Norrgren and Schaller 1999; Tullett 1996; Dinsmore 1999; Fricke and Shenhar 2000). Along this line, Sobek et al (1998) stated that each person in a project should be equipped with the same set of standard skills to accomplish their tasks effectively in order to attain project goals, hence driving PMC.
Exhibit 2. Characteristics of NPD and SWD Projects
New Product Development Projects versus Software Development Projects
The Project Management Institute (PMI®)identifies a project as a temporary endeavor undertaken to create a unique product or service. In particular, this definition implies the following characteristics of projects (Project Management Institute 2000):
• A finite duration. This means that each project has a definite beginning and a definite end.
• A predetermined project objective. When the objectives have been met or it is apparent that the objectives cannot be met, the project is terminated.
• A unique nature. Projects undertake to accomplish something that has not been accomplished before, which makes them unique.
• A sequence of steps. Basically, each project proceeds through a set of interrelated activities.
Clearly, this definition is generic in nature, perhaps to accommodate the wide variety of project types in organizations. Under examination here are two types that occur frequently: new product development and software development projects.
The essential differences in characteristics between new product and software development projects are intuitively apparent to many project managers. However, going beyond the intuitive calls for establishing a set of characteristics that can methodically differentiate between the two types. On the most generic level, new product development projects involve designing and building new products, whereas software development projects involve the creation of the software programs. Each project type has further natural subtypes. For example, NPD projects can be classified as research or advanced development, breakthrough development, platform or generational development, and derivative development projects (Wheelwright and Clark 1992).
In addition, these two categories of project development exhibit some cross-group similarities and differences. For example, they are similar in that they both often deal with high technological uncertainty, system complexity, and risk. On the other hand, (and we recognize that this generalization may not be applicable to all cases), SWD projects are often more invisible, unvisualizable, and changeable than NPD projects (Brooks 1987).
A comparison of several key characteristics can demonstrate issues of similarity and dissimilarity (Exhibit 2).
Similarities: NPD and SWD projects face several common challenges. Some examples of those common challenges are the level of technological uncertainty, system complexity, and risk involvement.
• Technological uncertainty: This issue is closely related to the degree that the group uses novel versus mature technologies. Projects involving more novel technologies are considered to have a higher technological uncertainty than those with more mature technologies (Shenhar 1998). For example, breakthrough NPD projects that create product platforms based on a new generation of technology are characterized by a higher level of technological uncertainty than derivative NPD projects, whose purpose is to adapt the platform for a certain market niche (Wheelwright and Clark 1992). Similarly, an SWD project focused on maintenance, including minor upgrades, has a lower level of technological uncertainty than a breakthrough program (Raz 1993). Since the essence of NPD and SWD projects is innovation advantage, a large portion of these projects deal with a medium to high level of technological uncertainty.
• System complexity: This issue can be conceptualized as a combination of product characteristics, functional mission, and organizational structure (Shenhar 1998). For example, imagine a project with a single component and a single function of a limited scale that is implemented within a functional group, such as the development of a computer hard drive or development of a software translator. In contrast, a complex project would have multiple components and multiple functions and require the involvement of multiple organizations, e.g., development of a new generation of computers or a large software suite. Many NPD and SWD projects have medium to high levels of system complexity, which causes further complexities in their development process (e.g., complexity of team communication, project structure, and project schedule) and product (Brooks 1987; Shenhar 1998; Schroeder 1991; Basili ).
• Risk involvement: Development projects are the riskiest endeavor for the modern company (Cooper and Kleinschmidt 1987), and those risks may hit NPD and SWD projects from many angles. A risky situation tends to be severe when the firm has limited knowledge and experience with the product and process technologies that they intend to incorporate into the product (Gupta and Wilemon 1990; Wheelwright and Clark 1992; Raz 1993). In both NPD and SWD projects, the risk level increases if the project involves many personnel, has a high application complexity, involves a high number of technology acquisitions, and there is a lack of sufficient resources and team expertise (Jiang, Klein et al 2000; Little and Leverrick 1995; Handfield, Ragatz et al 1999). The complexity of the product being developed and the use of novel technology can also lead to undesirable project outcomes (Griffin 1997; Tatikonda and Rosenthal 2000). Generally, a significant number of NPD and SWD projects are exposed to medium to high severity of risk.
Differences: Several characteristics are good indicators of how the two project types present differing management issues, issues that need to be tackled in different ways. These issues include product visualization, product and process visibility, and changeability (Exhibit 1).
• Product visualization: Product visualization is understood to be the degree to which one’s mind can conceptualize the product (Brooks 1987). In this context, a software product cannot be visualized: we are unable to form a mental image of a software program. While we may know that it is a set of instructions, for most of us, that is as far as we can go in envisaging it. Such a low visualization level is not true of NPD projects. Even early in an NPD project, when it may not be quite clear how the product will look, prototyping techniques can help us visualize the future. Thus, product visualization in NPD projects is most often medium to high. And since the hardware product can be relatively easy to visualize, the NPD team can share the product vision more easily. On the other hand, because the software product cannot be visualized, communicating the product concepts and design among project team members creates challenges (Brooks 1987).
• Product and process visibility: To what extent one can physically see or touch a product? This issue addresses product visibility, a corollary to product visualization (McDonald 2001). To put it simply, software products are not tangible. In contrast, NPD products are can be touched; they have concrete visibility. This difference between NPD and SWD products in turn produces differences in the development process. NPD teams can visualize the product, transform it into a product prototype, project deliverables and eventually project milestones (Clark and Wheelwright 1993; Cooper and Kleinschmidt 1994; Kappel and Rubenstein 1999). In contrast, it is much more difficult for the SWD team to develop a product prototype that clearly reflects the customer’s requirements (Brooks 1987). Most of the time, these requirements and the customer’s specifications are held within the vision of the project team, rather than occurring as a tangible scope that can be quantified and estimated, as is the case with NPD projects (Findley 1998). Because of this, an SWD project manager faces challenges in transforming vision into project milestones, which will help create the visibility of the SWD process. The corresponding lack of process visibility is, therefore, also common for SWD projects (McDonald 2001).
• Changeability: Software products have a high degree of changeability, which can be described as the magnitude of the consequences of changing the product design. Traditionally, uncontrolled design changes have been perceived as a major cause of project failure because the changes may have scope, cost, and schedule ramifications that can derail the project. And, typically, the later in project life cycle that the changes occur, the graver are the consequences. The conventional wisdom, therefore, holds that design changes should be fully studied and understood before they are made. For hardware NPD projects, the level of changeability is kept low because of the high costs of change. Such change might involve changes in interfaces, tooling and fixtures, materials, the manufacturing process, etc., all resulting in the product being late to market (Brooks 1987). In contrast, if we characterize software as a pure thought-stuff (Brooks 1987), there are no tools, materials, and manufacturing process changes in SWD projects. Thus, it becomes more apparent that changing the software and making it conform to other interfaces is relatively easier. These differences in changeability in these two classes of projects may result in different needs in managing the projects.
As previously hypothesized, general SPM factors may impact PMC in NPD and SWD projects. However, the fundamental differences in the characteristics that differentiate many NPD and SWD projects—product visualization, product and process visibility, and changeability—may lead to certain differences in SPM factors, thus invalidating our hypotheses. For example, high changeability in SWD projects may render a disciplined, highly standardized project management process less effective because of frequent project changes. Since the process is often built around template project management methods, standardized methods may not be important to SWD projects either. Still, to argue convincingly that these concrete differences do exist in SPM factors related to NPD and SWD projects would be unrealistic. Rather, as our discussion has proposed and as this study indicates, the correlation between SPM factors and PMC may be contingent upon the project types under study. The extent of that contingency is discussed later in the findings section.
Exhibit 3. Descriptive Statistics of the Samples
Methodology
Sample and Data Collection
Due to the exploratory nature and the complexity of the research, we engaged in a two-phase study, combining qualitative and quantitative methods. The first phase employed the grounded-theory research approach (Eisenhardt 1989), a qualitative method, and was based on six case studies from NPD, SWD, and other project types. Using within-case and cross-case analysis, we identified a set of issues that were then grouped into seven SPM factors as extracted from the literature: project management process, organization, information technology, methods, metrics, culture, and leadership. As noted above, these SPM factors are not specific to NPD and SWD projects but are of a general nature applicable to diverse project types.
Next, a questionnaire was developed to elicit quantitative data for statistical analyses. The data set contained forty-two respondents from NPD projects and thirty-three respondents from SWD projects (see Exhibit 3). These respondents, primarily attendees of project management workshops, were project managers with at least two years of experience in managing projects. Multiple follow-up interviews were conducted after statistical analysis to add richness to the interpretation of the test results, which yielded insights into practices and substantiating our findings.
Variables
Two sets of variables in this study are PMC and SPM factors. PMC in NPD and SWD projects was measured as a set of multiple items, including the degree of accomplishment of project schedule, cost, quality, and customer satisfaction goals, which were captured on a five-point Likert scale (five being the highest extent and one being the lowest extent). The numerical level of standardization of the seven SPM factors (project management process, organization, information technology, methods, metrics, culture, and leadership in NPD and SWD projects) was also measured on a five-point Likert scale (five being the highest extent and one being the lowest extent).
The questionnaire asked respondents to think of projects that they were currently managing or had recently completed. These projects were to serve as their frame of reference in answering the questions. Note that determining SPM factors typically requires involvement of the multiple key members of an organization. Given the nature of this study, we were not in a position to follow such procedure; instead, we relied on the perceptions of project managers.
Data Analysis
To analyze the collected data, we used the following statistical analyses:
• t-test to examine the differences between levels of standardization of the seven SPM factors in NPD and SWD projects.
• t-test to examine the differences between PMC criteria (schedule, cost, quality, and customer satisfaction).
• Multiple regression to identify the most important SPM factors in both NPD and SWD projects. Pearson product-moment correlation was also used in conjunction with multiple regression analysis to explore the relationship among SPM factors and between SPM factors and each PMC criterion.
Findings
Level of SPM Factors
Exhibit 4 summarizes the level of standardization in NPD and SWD projects. Because no significant differences exist in levels of standardization in the two types of projects, it can be argued that NPD and SWD projects are similar in standardizing their project management. However, minor differences in standardization do occur. (See Exhibit 4.)
Exhibit 4. A Comparison of SPM Factors in NPD and SWD Projects
New product development (NPD) projects exhibit a higher level of standardization in five SPM factors: process, methods, metrics, culture, and leadership. Three of the five factors—methods, leadership, and metrics—rate at least 10 percent higher than their SWD counterparts (note: these differences are still not statistically significant). SWD projects have slightly higher standardization scores for information technology and project organization. The most discernible similarity is that most of the scores for both types of projects are relatively modest, falling around three on a five-point Likert scale.
Exhibit 4 also reflects the state of standardization in NPD and SWD projects. For NPD projects, the highest standardization scores were 3.79/5.00 and 3.48/5.00 for leadership and methods,respectively, while the lowest was information technology at 2.69/5.00. Tied at 3.33/5.00, culture and leadership were the highest ranked SPM factors in SWD projects. For this type of project, standardization of the project management process received the lowest score: 2.62/5.00.
It has been argued that NPD and SWD projects are similar in some aspects and different in others. Our study did not capture the impact of the differences on the level of project management standardization in the two types of projects. Rather, it found that both types of project are in a very similar state of standardization. Perhaps one reason for this is that the project management standardization concept is a relatively new phenomenon, the diffusion of which seems to be progressing slowly in both types of projects. Another possible reason surfaced in our follow-up interviews. There is a strong belief among the managers of both types of projects that they are dealing with very innovative, fast-changing technologies. As a result, they often need to change project direction. Such an approach, they argue, would be stifled by high standardization characterized by a little variation in the project management methodology. Rather, the project managers assert that low standardization with a sufficient amount of variation in methodology is a more appropriate approach to running NPD and SWD projects. This view approximates what other researchers have found. For example, Hoch et al found that 75 percent of all software firms are at the lowest level of project management maturity (Hoch, Roeding et al 2000). This is grounded in a belief that as a creative, start-up industry, software development has no need for a lot of discipline, which is what project management methodology is. Or, as another researcher found, 38.5 percent of respondents either use no project management process in NPD at all or they use an informal one (Griffin 1997).
Project Management Capability
Exhibit 5 presents t-test results of PMC in NPD and SWD projects.As is clear, significant differences exist between PMC in the two types of projects. In particular, NPD projects have a higher capability to deliver projects successfully per predetermined schedule, cost, quality, and customer satisfaction goals.
In addition to showing crucial differences in perceived PMC in the two types of projects, this finding supports the work of earlier researchers. While participants in SWD projects in our study perceived PMC as average, another study found that a large number of software projects do not finish on time, on budget, or with all features installed (Hoch, Roeding et al 2000). Also, Cooper and Kleinschmidt (1994) found that NPD project timeliness is not on a very high level. Overall, NPD projects have a higher PMC than SWD projects. Perhaps the reason lies in relative “youth” of software development, which is a young discipline, younger than product development (Kemerer 1997).
The Impact of SPM on PMC
Exhibit 6 summarizes the results of the stepwise regression analysis of the SPM factors that are significant predictors of PMC in NPD and SWD projects. While there appear to be similarities in SPM factors for the two project types, there are also indications of significant differences between the regression equations for each. The major similarity is in the perceived importance of metrics and culture. Comprehensive and integrated performance metrics and strong project performance culture were found to be highly important for PMC in both project types. The difference is that methods were perceived as critically important for PMC in NPD projects but not in SWD projects. Additionally, there was a perception that leadership had a significant impact on PMC in SWD projects and not in NPD projects.
Exhibit 5. A Comparison of Project Management Capability in NPD and SWD Projects
Exhibit 6. A Comparison of SPM Factors in NPD and SWD Projects
For NPD projects, methods, metrics, and culture were significant predictors of PMC. Ninety-one percent of the variance in PMC is explained by these three SPM factors. They were significant at p < 0.001.
The key predictors of PMC in SWD projects were metrics, culture, and leadership, having a cumulative r-square of 0.88. Again, they were significant at p < 0.001.
A major purpose of this study was to compare the perceived importance of SPM factors in NPD and SWD projects that are similar in some properties and different in others. The analysis demonstrated that some SPM factors are critical to and predict PMC in both types of projects. It further showed that importance of some factors varies across project types. These findings are consistent with perceptions of both the one-size-fits-all SPM approach and the SPM-needs contingency approach. And concerning SPM, these findings also confirm many of the similarities in and differences between NPD and SWD projects.
This study revealed that there are similarities in the SPM factors that project managers perceive to be crucial to PMC of both types of projects, such as metrics, which have a similar impact on PMC in NPD and SWD projects. In fact, in both types of projects, higher standardization of metrics is correlated with higher PMC, but the impact of the metrics is much stronger on SWD projects.
Equally important, our study found significant differences in what project managers perceived to be the SPM factors critical to PMC, such as project management methods. Our results corroborate the argument that methods have a lower impact on PMC in SWD projects. Our study showed that while they are a significant SPM factor in NPD projects, they are not a significant factor in SWD projects.
Although the study focused on the similarities and differences in SPM in the two types of projects, it also offered solid support for the identification of such factors, based as it was on case-study research combined with literature research. Four of the seven factors identified this way were confirmed by project managers as being critical. Since our Pearson correlation analysis showed that process is strongly correlated with methods and metrics in both NPD and SWD projects, we deducted that process is also a significant SPM factor. The situation is reversed for information technology and project organization. Neither was perceived by project managers in follow-up interviews as significant. When we asked these managers to help interpret their insignificance, some expressed the view that as enterprise-level factors these two factors are not well known to project managers. Others agreed that the two are relatively new and perhaps there has not been enough time for them to make an impact.
General
The most original contributions from this research are in the reconciliation of two opposing views in the project management community. To those researchers and practitioners who argue that one size of project management fits all sizes of project, this study provides support that their argument has merit in project management standardization. The study also justifies the views of those who advocate the contingency approach to project management. Inclusion of both approaches, one-size-fits-all and contingency, appears to be a useful resource for researchers and practitioners interested in pursuing project management standardization efforts.
The strengths of this study are in its focus on a relatively new project management phenomenon, its research process combining qualitative and quantitative methods, and the generality of findings across a variety of NPD and SWD projects. Potential limitations of the study relate to the fact that data were collected from a relatively small number of participants of a project management workshop. Using a large sample of respondents from various organizational levels, which would be representative of the project management population, could well provide further future validation. An additional benefit would be using a more comprehensive list of SPM factors as opposed to this study’s limited number of seven. The focus on NPD and SWD projects is also a strength. These types of projects are not only among the most demanding but are also of continuing interest to many researchers and, of course, to practitioners.
Several issues identified during the study suggest important future research. Three examples can help illustrate. First, this study did not correlate project characteristics to critical SPM factors. For example, SWD projects are characterized by low product visualization. Knowing which SPM factors are influenced by this characteristic may help understand the mechanism of standardization and improve it. Second, an important consideration is if differences exist in project management standardization across the project life-cycle stages of NPD and SWD projects. Research into this question could benefit from the model of Pinto and Govin (1989). Finally, an examination is warranted into whether there are within-type differences in project management standardization. NPD project types vary, e.g., platform, derivative, etc. Investigating SPM factors across these types may be another issue for the future research agenda.
Implications and Conclusions
Effective implementation of SPM calls for a prudent marshalling of diverse corporate resources. Two essentially opposite managerial approaches that researchers and practitioners propose may aggravate the challenges in such a process. One approach—one-size-fits-all projects—argues that all projects, regardless of type, should be managed the same way. In the other contingency approach, different project types need different managerial approaches and should discard the classical view that one approach fits all projects.
This study’s findings have three implications for project management researchers and practitioners. First, discarding the classical view of the one-size-fits-all approach to project management standardization efforts may be unnecessary. Various classes of projects such as NPD and SWD projects do differ in certain characteristics, but not all of those differences are significant enough to merit different managerial approaches. Rather, as this study indicates, one consistent managerial approach may be essential to the successful standardization of certain aspects of project management despite the differences between NPD and SWD projects. This does not mean that researchers and practitioners should prescribe a one-size-fits-all approach as the only managerial approach to either SPM implementation in the two types of projects or other diverse types of projects.
Second, one finding of this study emphasizes the need for adopting a contingency approach to SPM under certain conditions. Project type is a contingency variable, when differences in project characteristics are sufficient to merit different approaches to SPM factors in NPD and SWD projects. Consequently, this study offers the view that taking different managerial approaches to certain aspects of SPM is an important condition for their successful implementation in the two project types. This is not to suggest that researchers and practitioners should advise an across-the-board contingency approach for the management of SPM implementation in NPD and SWD projects or other diverse project types.
Third, project management standardization and the resulting PMC are to a large extent dependent on skillful balancing of the one-size-fits-all and contingent approaches. It would appear that to be successful in SPM in NPD and SWD projects, one needs to ponder carefully each management action in the view of project characteristics, before opting for either approach. Although having a list of general SPM factors like the one in this study may be useful, their strict application may not always help SPM deployment. Rather, further work on identifying contingency factors in SPM implementation in NPD and SWD projects, as well in other diverse projects, should continue.
