Spm.docx

  • Uploaded by: Meghna Singh
  • 0
  • 0
  • April 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Spm.docx as PDF for free.

More details

  • Words: 5,261
  • Pages: 14
STANDARDIZED PROJECT MANAGEMENT This project is submitted in the partial fulfillment of academic requirements for the subject ‘Marketing Management’.

Name - Akash Saxena Reg. No. - 17A014 Batch - 2017-2022 Faculty – Mr. Viral Pandya

ABSTRACT 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. Effective implementation of SPM calls for a prudent marshaling 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 need 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.

INTRODUCTION “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 projects1.” “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. Essentially, this is a contingency approach. Many practitioners, in particular, project managers, tend to agree with the new view (Brooks 1987)2. 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) 3 . 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) projects4. 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 1

"Getting The Most Out Of Your Product Development Process". 2019. Harvard Business Review. https://hbr.org/1996/03/getting-the-most-out-of-your-product-development-process. 2 "Project Spirit-A Strategic Concept - IEEE Conference Publication". 2019. Ieeexplore.Ieee.Org. https://ieeexplore.ieee.org/document/952229. 3 Balachandra, R., and J.H. Friar. 1997. "Factors For Success In R&D Projects And New Product Innovation: A Contextual Framework". IEEE Transactions On Engineering Management 44 (3): 276-287. doi:10.1109/17.618169. 4 Basili, V.R., and D.H. Hutchens. 1983. "An Empirical Study Of A Syntactic Complexity Family". IEEE Transactions On Software Engineering SE-9 (6): 664-672. doi:10.1109/tse.1983.235431.

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 present5.” OBJECTIVES OF STUDY “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 practitioners6. 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 . 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.” “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. 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.” STANDARDISED 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. Pinto and Slevin have studied fourteen success factors in project implementation as well as across the project life cycle 7 . Balachandra and Friar identified a long list of success factors for research and development (R&D) projects 8 . Still, other researchers studied success factors in multi project management for NPD 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

5

Block, T. R., and J. D. Frame (2001). PMNetwork 15: 50–53. Brooks, F. P. J. (1987). No silver bullet: essence and accicents of software engineering. IEEE Computer 20 (4) 6 Clark, K. B. (1989, Nov/Dec). What strategy can do for technology. Harvard Business Review 67 (6): 94–99 7 Brown, S. L., and K. M. Eisenhardt. (1997). The art of contionuous change: Linking complexity theory and timepaced evolution in relentlessly shifting organizations. Anministrative Science Quarterly 42: 1–34 8 Clark, K. B., and S. C. Wheelwright. (1993). Managing New Product and Process Development Text and Cases.Freepress

(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.” Standardised project management (SPM) is defined as a methodology of managing projects that is composed of standardised practices. In our context, standardization means the degree of absence of variation in implementing such practices (Stevenson 1993) 9 . 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 conceptualised 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, an established project management standard. These SPM factors were developed through a grounded-theory research approach combined with a literature search. 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 hypothesised. 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 organised 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)10. Process can be based on structured project life cycle stages, project management activities, and milestones, for example (Clark and Wheelwright 1993) 11 . 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 organisations involved in the projects. 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.

9

Stevenson, W. J. (1993). Production/Operations Management. Boston, MA: Irwin Lynn, G. S., K. D. Abel, et al (1999). Key factors in increasing speed to market and improving new product success rate. Industrial Marketing Management 28: 319–326 11 Clark, K. B., and S. C. Wheelwright. (1993). Managing New Product and Process Development Text and Cases.Freepress 10

Project Organisation: Bringing together all company projects and organising 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 organise their projects around crossfunctional, dedicated, and accountable project teams with strong management support outperform those who do not. The present study does not take this project-level view. Rather, it examines a higher organisational level, recently termed the “enterprise” level. The idea behind the enterprise level is that interrelating all organisational projects and synchronising and aligning them with the organisation’s business strategy, through such designs as project offices or centers of excellence, will promote the accomplishment of project goals. Naturally, integration of all of an organisation’s projects and facilitation of their project management will improve PMC. Information Technology: The ability to leverage the organisation’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)12. The current trend is to use integrated information technology, called enterprise project management software (Levine 1998) 13 , 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 emphasise 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 success14, 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 goals15. 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.

12

Clark, K. B. (1989, Nov/Dec). What strategy can do for technology. Harvard Business Review 67 (6): 94–99 Levine, H. A. (1998). PMNetwork 12: 19–21 14 Shenhar, A. J. (1998). From theory to practice: Toward a typology of project-management styles. IEEE Transactions on Engineering Management 45 (1): 33–48 15 Sobek(II), D. K., J. K. Liker, et al (1998, Jul/Aug). Another look at how Toyota integrates product development. Harvard Business Review: 36–49 13

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)16. 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. 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. As a consequence, there is a strong drive in today’s organisations to define leadership style in terms of specific leadership competencies, e.g., interpersonal thinking, business, and process competencies. 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. NEW PRODUCT DEVELOPMENT PROJECTS VERSUS SOFTWARE DEVELOPMENT PROJECTS The Project Management Institute (PMI®)identifies a project as a temporary endeavour 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.

16

Hauser, J. R. (1998, December). Research, developement, and engineering metrics. Management Science 44 (12): 1670–1689

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, SWD projects are often more invisible, unvisualisable, and changeable than NPD projects (Brooks 1987)17. A comparison of several key characteristics can demonstrate issues of similarity and dissimilarity 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 technologies18 (Shenhar 1998). For example, breakthrough NPD projects that create product platforms based on a new generation of technology are characterised by a higher level of technological uncertainty than derivative NPD projects, whose purpose is to adapt the platform for a certain market niche. Similarly, an SWD project focused on maintenance, including minor upgrades, has a lower level of technological uncertainty than a breakthrough program 19 (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. • Risk involvement: Development projects are the riskiest endeavour for the modern company, 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. In both NPD and SWD projects, the risk level increases if 17

Determinants of timeliness in product development. Journal of Product Innovation Management 11: 381–396 Shenhar, A. J. (2001). One size does not fit all projects: Exploring classical contingency domains. Management Science 47 (3): 394–414 19 Raz, T. (1993). Introduction of the project management discipline in a software development organization. IBM Systems Journal 32 (2): 265–277 18

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. The complexity of the product being developed and the use of novel technology can also lead to undesirable project outcomes. 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 visualisation, product and process visibility, and changeability. • Product visualisation: Product visualisation is understood to be the degree to which one’s mind can conceptualise the product (Brooks 1987). In this context, a software product cannot be visualised: 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). • 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 either20. 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 study21. The extent of that contingency is discussed later in the findings section. FINDINGS: Level of SPM Factors 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. SWD projects have slightly higher standardization scores for information technology and project organization 22 . 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. 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 projects23. 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 direction24. 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

20

Shenhar, A. J., and D. Dvir. (1996). Toward a typological theory of project management. Research Policy 25: 607–32 Tullett, A. D. (1996). The thinking style of the managers of multiple projects: implications for problem solving when managing change. International Journal of Project Management 14 (5): 281–287 22 Zirger, B. J., and J. L. Hartley. (1996, May). The effect of acceleration techniques on product development time. IEEE Transactions on Engineering Management 43 (2): 143–152 23 Souder, W. E., and X. M. Song. (1997). Contingent product design and marketing strategies influencing new product success and failure in U.S. and Japanese electronics firms. Journal of Product Innovation Management 14: 21–34 24 Project Management Institute. (1996). A Guide to the Project Management Body of Knowledge (PMBOK® Guide).Upper Darby,PA: Project Management Institute 21

of all software firms are at the lowest level of project management maturity. 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)25. Project Management Capability 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 installed26 (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 projects27. Perhaps the reason lies in relative “youth” of software development, which is a young discipline, younger than product development 28(Kemerer 1997) The Impact of SPM on PMC 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 types29. 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.

25

Griffin, A. (1997). Measuring product development to improve the quality of the process. In The Practice of Quality Management (pp. 117–145). Kluwer Academic Publisher 26 Hoch, D. J., C. R. Roeding, et al (2000). The Secrets of Software Success.Boston, MA: Harvard Business School Press 27 Kappel, T. A., and A. H. Rubenstein. (1999, May). Creativity in design: The contribution of information technology. IEEE Transactions on Engineering Management 46: 132–143 28 Kemerer, C. F. (1997). Software Project Management: Readings and Cases.Chicago: Irwin McGraw Hill 29 Maidique, M. A., and B. J. Zirger. (1984). A study of success and failure in product innovation: The case of the U.S. electronics industry. IEEE Transactions on Engineering Management EM 31 (4): 192–201

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 30 . 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. 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.

30

Nobeoka, K., and M. A. Cusumano. (1995, November). Multiproject strategy, design transfer, and project performance: A survey of automobile development projects in the US and Japan. IEEE Transactions on Engineering Management 42 (4): 397–409

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.

More Documents from "Meghna Singh"