One size does not fit all--true for projects, true for frameworks
Aaron J. Shenhar, Stevens Institute of Technology
Dov Dvir, Ben-Gurion University
Thomas Lechler, Stevens Institute of Technology
Michael Poli, Stevens Institute of Technology
One of the common myths and misconceptions about projects is that all projects are the same and you can use similar tools for all your project activities. We call this the project is a project is a project syndrome, and it often leads to project failure and delays when companies are using improper project management techniques for some of their project efforts. While all projects have a goal, a budget, and a time-frame, there is more to project management than just a few common elements. In reality, projects differ in numerous ways, and one size does not fit all! Yet, at present, only a few organizations know explicitly how to classify their project efforts and how to select the best approach to a specific project, and there is still no standard framework for distinction among projects and for selecting the right approach to the right project.
This paper summarizes over ten years of studies on the differences among projects and among project management techniques. Over the years we have studied more than 600 projects and conducted over 1,000 interviews with project managers, line managers, team members, executives, project clients, and users. We have come to realize that project success depends, not just on the traditional critical success factors, but also, greatly, on the proper project management style and on adapting the right technique to the right project. We have seen many projects fail because managers assumed that their current project would be the same as the previous one.
Our research shows that in well-managed projects, project managers as well as top management are aware of project differences and use specific techniques and styles to manage different kinds of projects. However, our research also found that in most cases, companies and managers don’t have a specific framework with which they distinguish among their project efforts. We realized it is time to develop a universal, context-free, and simple-to-use framework that will help managers and organizations start a project by assessing the project type and selecting an appropriate management style. The purpose of this paper is to provide propose such a framework and suggest guidelines on how to use it.
However, in our work we realized that one framework does not fit all either, and that one would need different project classification systems for various organizational needs. This paper therefore includes a collection of frameworks for project classification—some have been published in the past, and others are new, and just emerging. We will start with some theoretical discussion, followed by the needs of different stakeholders for classifications. The main part of the paper will describe the various frameworks, and we will conclude by discussing who and how would use them.
Initial Theoretical and Practical Perspectives
From a theoretical perspective, one of the major barriers to understanding the nature of projects has been the little theoretical distinction made between the project type and its strategic and managerial problems, and the lack of specificity of constructs applied in project management studies. Although innovation studies have often used a traditional distinction between incremental and radical innovation, the project management literature has been slow in adopting similar approaches. Furthermore, while correlates of structural and environmental attributes have been well studied when the organization is the unit of analysis, they have been much less investigated in the project context. As mentioned above, the project management literature has often ignored the importance of project contingencies, assuming that all projects share a universal set of managerial characteristics. Yet, projects can be seen as “temporary organizations within organizations,” and may exhibit variations in structure when compared to their mother organizations. Indeed, numerous scholars have recently expressed disappointment in the universal, “one-size-fits-all” idea, and recommended a more contingent approach to the study of projects. As argued, by utilizing traditional concepts in a new domain, new insights will most likely emerge in this evolving and dynamic field. Our study attempts, as well, to address this theoretical gap.
Who are the stakeholders that would benefit from a framework for project classification? It seems that different people would use such a framework for different purposes. For example, among other things, top management— CEOs, executives, and business leaders—would look at decisions about portfolio management, aggregated returns, financial and business risk, and setting priorities. The marketing function, in contrast, would look for the impact of different projects on their marketing efforts, market research, and their ability to determine customer needs and product requirements. Similarly, the engineering manager would need a framework for distinguishing among difficulty and complexity of technical tasks, for assignment of technical experts, and for resources allocation. Finally, project managers would use a framework to determine their project structure, processes, and tools. They would also use it to distinguish among their design, testing, and verification efforts, and for the selection of team members and assignments of tasks.
What framework would each one of them use and how, and would one framework suffice for all needs? As we show later, they would need more than one system, and they would use it in different ways. We turn now to describing the various frameworks and the specific project types in each framework.
The Frameworks: How to Distinguish among Projects
Strategic Goal Classification
This framework relates to the strategic business goal of the project. Different projects are initiated with different business perspectives and expectations. Some have longer-term business goals than others, and some are just for the short run. Some projects are for building infrastructure and capability for the future and others are just exploratory in nature. We identified five different types of projects according to this categorization.
These projects are extensions of existing products. They constitute improvements, line extensions, derivatives, cost reduction, upgrading, or feature enhancement. They are typically short term, and their goal is to gain as much as possible from an existing product. They are considered as “cash cows,” which are aimed at extending the life of a product in the market. They would represent slight modifications or upgrades that are done “in between” major introductions of new products or new generations. Examples are in-between years in automobile models, or stripped down models with less features and lower cost than the original product.
These are prime efforts that are made to create or sustain strategic positions in markets and businesses. Typically, strategic projects are initiated with a long-term perspective in mind. Their goal is to create a significant competitive advantage in the market, and to establish leadership positions. Some see them as vehicles to create the basis of competition in their fields, others just see them as necessary steps for sustainable survival and organizational endurance. In both cases, such projects are the backbone of organizations; they enjoy management attention and priorities, and their success or failure has a great impact on the organization’s future. Examples are major automobile models introduction (PT Cruiser), new aircrafts such as Boeing 777, and such.
These “get-hold” projects are made to solve a specific problem that is needed in future endeavors. They do not produce a specific product, but produce a solution, which will be applied to future projects. They typically have a narrow focus, and involve getting hold of a new technology that is needed for future products, creating a new capability in manufacturing, creating a new feature that would be added to several products, an effort of cost reduction that would be utilized in several future products, and so on. Such projects are relatively short term, narrow in focus, and need moderate attention, to just “solve the problem.”
These projects are made to “keep the lights on.” While they, as well, do not produce any product that would be sold in the market, they are necessary for organizational survival. For example, such projects involve major maintenance efforts, new equipment procurement and installation, reengineering, reorganization, or new software acquisition and implementation, such as ERP systems. Such projects may have low priority or slow time frames, they are essential to organizational sustainability, and may consume extensive amount of critical resources.
This category includes all projects, which are initiated for purposes of learning. They do not involve a clear product with a clear customer in mind. Rather, they are the company’s “investment in the future.” In these projects the company explores new ideas, creates new knowledge, or just “pushes the envelope.” Typically, such projects receive low priorities, and they often need to be separated. Otherwise, they are in danger of termination in face of quick, and more urgent needs.
Exhibit 1.The UCP Model
The UCP Model
In search for a universal, context-free framework for all project types, our research identified three dimensions to distinguish among projects: uncertainty, complexity, and pace. Together, we call them the UCP model, and they form a context-free framework for selecting the proper management style (see Exhibit 1).
Different projects present, at the outset, different levels of uncertainty. Clearly, when a project is completed, everything is well known—the end result, the cost, the time, and the final specifications. Yet, as we have seen, uncertainty at project initiation is one of the major characteristics of any project. It determines, among other things, the length and timing of front-end activities, how well and how fast can one define and finalize product requirements and design, the degree of detail and extent of planning accuracy, and the level of contingency resources (time buffer and budget slack). Project execution can therefore be seen as an ongoing process, which is aimed at uncertainty reduction. Failing to assess project uncertainty may result in excessive resources and unexpected delays.
Uncertainties could be divided into external or internal, and classified into several levels as we show later. External uncertainty will have an effect on accuracy and predictability of customer requirements, and on how to treat market research results, while internal uncertainty determines the process of product design, testing, and finalizing the specifications.
Complexity is the second dimension for distinction among projects. Management should realize that complexity and uncertainty is not the same thing. Imagine building a high-rise office tower in a major city. For this kind of project, even low levels of uncertainty may involve a highly complex collection of tasks. Project complexity is generally determined by project size, number and variety of elements, and interconnection among elements, and it may come from product complexity, but also from the level of organizational interaction.
When it comes to managing different levels of complexity, the “one-size-does-not-fit-all” rule will affect project organizational structure, the hierarchical level of the project manager, the formality with which the project is managed, the extent of subcontracting and outsourcing, and the degree and tightness of project control.
The third dimension of the UCP model involves the speed and criticality of time goals. Obviously, no project is free of limitations, and time is one of the major constraints. However, as we found, the available time given for project completion and the degree of urgency, is an important factor for distinction among projects. The same goal with different timeframes may require different project structures and different management attention.
The highest-paced projects are the most critical in terms of time of product introduction. The higher the pace, the closer is project monitoring, the more autonomous is the project team, and the higher is management involvement.
The Sources of Project Risk
Obviously, no project is risk free, but various projects have different levels of risk. The three dimensions for project distinction create, together, a risk assessment and management frame-work. The most risky projects are those of highest uncertainty, highest complexity, and highest pace. How can organizations apply this concept as a practical tool for better understanding of the nature of projects and for adapting the proper management style? In the following sections we operationalize project classification along the three dimensions to describe typical project management styles and integrate different risk levels. The categories we use emerged in our studies as the most common types of project styles. Since, in general, most projects do share things in common, we will focus, for each category, on the unique features of project management characteristics—what is different and what should management be aware of.
External uncertainty represents factors that are beyond the immediate control of management or project team. The major source of external uncertainty is the market, where three levels of uncertainty can be identified—derivative, platform, and breakthrough. Other sources, however, may involve political, economical, or environmental issues. Market uncertainty is associated with accuracy and confidence in which one can define the end product—the “what” needs to be done. To define market uncertainty management should assess: how new is the product to the market and how well do customers or users know about it. Different market uncertainties require different techniques for market assessment, market research, market feedback, and thus product definition. It will affect the involvement of marketing in product development and the cross-functional interaction between marketing other departments such as engineering. When Sony considered introducing its first Walkman®, the product presented a new concept to the market. Market research proved inconclusive and the decision to launch was based on managerial intuition. The first prototype was tested as soon as possible in the market and product introduction was then followed by fast market response, which was relayed back to engineers for immediate product modifications and development of derivatives. And similarly famous 3M Post-it® notes did not get much appraisal from marketing predictions. Only after initial market testing did the product create its reputation to become the greatest success in the history of office supply products.
Wheelwright and Clark used three major new product categories to manage the company’s product portfolio and to create an aggregate project plan. These categories represent different levels of external uncertainty and determine management behavior regarding marketing of new products and their impact on project management:
These projects include cost reduction, product improvement, and additions to existing lines. Previous products are well established in the marketplace and market data is readily available. The “what to do” question is relatively easy to answer. Predictions about product cost, as well as other product requirements can be fairly accurate and there is no need for market experimentation. Product requirements must therefore be fixed as early as possible, most likely at project launch, and design should adhere to these requirements to ensure fast execution for a timely completion of the project.
These projects exhibit new generations in existing product lines. They create a new family of products to form the basis for numerous derivatives. Such products replace previous products in a well-established market sector. Although some platforms may involve completely new technologies, product usage by customers can be predicted fairly well. New combat aircraft designs or new automobile models of are typical platform examples. Market uncertainty is obviously higher than in derivatives. For these projects companies should perform extensive market research, study data of previous generations, and make careful planning of product price. The final setting of product requirements will therefore take much more time and it should be planned well into the project execution period. However, there is a trade-off; It should not be delayed too long to ensure timely product introduction and reasonable profitability.
Introducing the first Post-it notes or the first Walkman were just two examples of breakthrough projects; so were the first personal computer, the first microwave oven, or the first Internet browser. Breakthrough products may use new or mature technologies, but in each case the market does not know anything about the new product, nor do customers know how to use it until they see it. Market studies are therefore, to a great extent, ineffective and product definition must be based on guessing, intuition, and market trial and error. Requirements must remain flexible until first market introduction is possible and until customer feedback is available. Fast prototyping is necessary and is much more critical than extensive market research. Since no one can predict market actual response or customer preferences, changes in initial product specifications are inevitable, and while clear product definition is perceived to be critical to any project, management of breakthrough projects must realize that product definition will most likely change in time after initial market trials and feedback from early users.
Technological Uncertainty (Internal)
The major source for internal uncertainty is technological uncertainty. (Other types may involve team experience, or tight budget constraints.) Higher technological uncertainty at the time of project initiation requires longer development phases, more design cycles, more testing, and later design freeze. In general, we associated such uncertainty with the degree of using new (to the company) versus mature or well-known technology within the product or process produced. In our studies we found four distinct levels of technological uncertainty, which matched four different project management styles.
Type A—Low-Tech Projects
Low-tech projects are those projects that rely on existing and well-established technologies. The most typical examples of such projects are construction, road building, or “build to print” cases, where a contractor is required to rebuild an existing product. Projects in this category require no development work; their architecture, design, and resource planning are all carried out prior to the project’s implementation phase. Such preliminary work typically results in detailed plans, specifications, drawings, and material lists. In such projects, the product is entirely shaped, and the design frozen, prior to the project’s formal approval and the inception of the implementation phase. Management style in such projects must be firm, since profit margins are typically slim given the low level of uncertainty. Project managers should therefore stick to the initial plan, with a no nonsense, no changes, and get the job done attitude.
Type B—Medium-Tech Projects
Medium-tech projects use mainly existing or base technologies, yet incorporate some new technology or a new feature that did not exist in previous products. Examples include improvements and modifications of existing products (derivatives), but also new generations of products in industries where technology is relatively stable, such as major appliances, automobile, or heavy equipment. Although most of the technologies used in this kind of projects are not new, the project, never the less, will involve development work and testing activity. In general, however, some changes would be added to the initial design, but they should be confined to a limited period, and the design should be frozen quite early, typically after two cycles. While still firm, management style could be more flexible since some changes and adjustment in design are needed. No changes and improvements should be allowed, however, once the design was frozen (with an exception of safety or hazardous reasons). The policy and attitude could be “limit changes to minimum and freeze as early as possible, but not too early.”
In an attempt to save time, some companies are using “collapsing” methods, or overlapping of project phases. Typically it involves starting manufacturing activities or ordering production parts even before product development is completed. This will work best in Type A or B projects, but should be exercised cautiously in higher levels of technological uncertainty as we show later.
Type C—High-Tech Projects
High-tech projects are typical to situations in which most of the technologies employed are new, but nevertheless, exist when the project is initiated. Such technologies had been developed prior to project inception and a Type C project probably represents the first effort to integrate them into one product. Most defense development projects belong to this category, but also new generations of computers and other products in the high-tech industry. Incorporating new technologies for the first time typically leads to products that did not exist in the past, and as we found, execution and management of high-tech projects is entirely different than of medium-tech and low-tech type. They are characterized by long periods of design, development, testing, and redesign. Projects of this nature require at least three design cycles. Design freeze must be scheduled therefore to a much later phase, normally during the second or even the third quarter of the project execution period. And management style must be much more flexible in these projects since numerous designs must be tested and will lead to changes and improvements during much longer periods.
Type D—Super High-Tech Projects
These projects are clearly distinguished from type C. These projects are based on new technologies that do not exist at project initiation. While the mission is clear, the solution is not. This type of project is relatively rare, and is usually carried out by only a few, probably large, organizations or government agencies. One of the most famous examples of this type was the Apollo Moon-landing program. At project inception, it had a well-defined mission and timetable, but no available technology was at hand, and nobody really knew how to get to the moon.
Unlike previous, lower uncertainty type projects, a great deal of the effort in this type is devoted to the development of completely new technologies, and to testing and selecting among various alternatives. As our studies found, projects in this category use similar techniques to resolve the issue of unknown technologies. They institute an intermediate program to build a small-scaled prototype on which new technologies are built and tested. Type D projects thus require extensive development periods, very late design-freeze points, and intensive management of ideas and change until the final configuration is selected.
Management style must be extremely flexible, yet cautious. The attitude in these risky projects must be: “look for trouble; it’s there; if you don’t see it, you have not looked enough.” And since things change so fast, extensive communication is essential among project teams and team members. The formal system of reporting could simply not accommodate the degree of new information that is created, and the formal documentation is normally slow and normally too late to record the latest changes. Needless to say that collapsing project phases is even more difficult and later phases cannot start until previous project phases have been completed and approved.
System Scope—Project Complexity
In our study of different project complexities we observed three typical management styles. They are distinguished by the way the project is organized, its subelements are coordinated, and the extent of formal versus informal interaction and documentation. Higher complexity will require more advanced and far-reaching organizations, increased formality in managing and coordinating project activities, and more documentation.
As we found, a simple way to define and distinguish among different levels of complexity is to use a hierarchical framework of systems. We call it system scope, and in most cases, a lower scope level may be seen as a subsystem of the next higher level. Project management practices can be “compressed” to the following typical three levels.
Level 1—Assembly Projects
Assembly projects involve creating a collection of elements, components, and modules combined into a single unit or entity that is performing a single function. Compared to the higher levels, assembly projects are relatively simple. They may produce a stand-alone product such as a CD player, an overhead projector, or a coffee machine; or create a subsystem of a larger system such as a computer hard drive or a radar receiver. They may also involve restructuring a functional organization or building a stand-alone service.
Assembly projects are typically carried out by a single organizational function or a small cross-functional team, often within one organization and with a low level of formality or bureaucracy. The number of project activities or subtasks is normally in the range of tens, and as we learned, the planning of budget and schedule in this type of project is simple, requires only basic tools of project management, and is often done manually. Interaction, communication, and much of the decision-making is, to a large extent, informal and is carried out among people who know each other well and meet each other almost daily. Documentation and reporting is minimal and is often carried out only after the main activities are performed and finalized. As a result, administrative staff within the project team is minimal with most of the administrative work done by the technical performing staff.
Level 2—System Projects
Systems involve a complex collection of interactive elements and subsystems, jointly dedicated to a wide range of functions to meet a specific operational need. System projects may produce aircraft, cars, computers, or buildings, but may also involve reengineering efforts of entire businesses. System projects are typically led by a main contractor or program office, and the total effort is divided among numerous subcontractors—some in house and some external. The program office is responsible for the final integrated result and for meeting overall performance, quality, time, and budget goals. Such projects are managed in a more formal way than assemblies with extensive documentation and contracting between main and subcontractors.
One of the major problems encountered in system projects is total system optimization and system integration (particularly at the medium, high, and super-high levels of uncertainty). In system projects, the successful execution of separate subunits and the optimization of each one of them is one thing, while integrating them into a one working and optimal result is another. Problems of interface, interference, energy dissipation, and even lack of space usually require a long process of assembly, testing, and trade-off. Experienced system providers will make sure their schedule includes a long period of system integration with several cycles until the entire system is optimized.
Since most system projects extend beyond organizational borders and require substantial outsourcing and contracting, they usually employ special administrative staff as part of the project team. Such staff people will handle the planning, budget management, contracting, and controlling issues, and free the technical staff to do the work of design, building, and testing. System project tools are also more complicated than those used on assembly projects. The number of project activities is in the range of hundreds and may be up to a few thousands. While there are many existing project management tools and applications, system projects and their corporations often find it necessary to develop their own tools and documents to meet their specific requirements.
Level 3—Array Projects
Arrays deal with large, widely dispersed collections of systems (sometimes called “super systems”) that function together to achieve a common purpose such as city public transportation systems, national air defense systems, or interstate telecommunication infrastructures. Arrays are clearly large-scale projects, yet, in most cases, they do not involve building the super system from scratch. Rather, such projects often involve gradual growth, addition, or modification to an existing infrastructure. Notable array projects of recent years were the upgrading of the New York Subway system in the early 1990s, the preparation of the city of Atlanta to the Olympic games of 1996, and building the English Channel Tunnel.
Array projects require the administration of many separate programs, each one devoted to a different component or system. Projects are typically organized in the form of a central “umbrella organization”which is set-up as a separate entity or company, and is formally (and legally) coordinating the efforts of numerous subprojects in other organizations. The actual technical work is executed, however, within the suborganization. Success in such projects depends, to a large extent, on the proper bureaucratic system set up to manage and coordinate the program. The focus is on extensive documentation, contracting, and tight financial controls. The dispersed nature of the end product and the extent of subcontracting, makes it necessary to manage these programs in a highly formal way, and to put a lot of effort into the legal aspects of the various contracts. Ordinary tools of planning and control are even less relevant here, and management must often develop its own system of contract coordination and program control. Yet one issue is probably less critical here—system integration. Since most elements are add-ons to the entire system and many projects involve infrastructure building, add-ons do not normally cause the same level of interference as in tightly built systems. The Internet, for example, was originally built in the 1960s as a network connecting academic and government labs. It gradually evolved to the global phenomena of the World Wide Web, extending national borders and early visions. No single project could probably have planed it all in advance and integrate it at one time.
Project Pace—How Critical is Your Timeframe?
Criticality of meeting time goals and consequences of failing to do so is associated with project pace. While in reality, project delays are more common than not, on this scale projects will differ by how much time is available and what happens if the time goal is not met. We identified three different types of pace—regular, fast/competitive, and critical/blitz.
Such projects are typically carried out by organizations to achieve long-term or infrastructure goals. They include public building works, road building, organization improvements such as reengineering, and technology build-up efforts. Although they are scheduled for completion on a certain date, missing the deadline is in fact being tolerated, since time is not critical to immediate organizational success. Unless specifically prioritized, such projects are managed in a relatively casual format and may often be delayed or pushed aside by more urgent critical assignments. While hard to admit, such projects exist, and are inseparable part of the spectrum of project management landscapes.
A famous example of this type of project was building the Sydney Opera House in Australia. When commissioned, the original schedule assumed six years of construction. With no real pressure and city political changes, the building was finally completed in 1990, after almost sixteen years of stops and starts. Today, it is one of the best tourist attractions in Australia and no tourist will come to Sydney without visiting at the Opera House. The lesson is clear: with no external or enforced pressure, such projects will always take longer than planned. Similarly, reengineering efforts are normally not affected by direct market pressures of meeting the deadline of time-to-market introduction. Unless real pressure comes from the top, other priorities are sometimes winning. In fact, many reengineering projects have gone nowhere for the lack of time pressure and commitment.
These are the most common projects carried out by industrial and profit driven organizations. They are typically conceived to address market opportunities, create a strategic positioning, or form new business lines. Time to market is directly associated with competitiveness, and although missing the deadline may not be fatal, it could hurt profits and competitive positioning.
Fast/competitive projects must be managed strategically. Project managers should focus on meeting schedule, but also achieving profit goals and addressing market needs. Managing the time frame should be one of the main concerns, and top management must support and closely monitor these projects at their major milestones, yet also be alert if something goes wrong in between milestones.
These are the most urgent, most time-critical projects. Meeting schedule is critical to success and project delay means project failure. Such projects are often initiated during a crisis situation or as a result of an unexpected event. Examples may be industrial projects set up to leapfrog a surprising move by competition, or military projects that address a timely problem during wartime. September 11 created numerous projects of this kind. Similarly, although the problem was expected years in advance, many Y2K projects became critical as December 1999 approached.
Yet to succeed, such projects must be managed completely different. The workflow in these projects is very tight. It is performed almost around the clock, with non-stop interaction and continuous decision-making. There is normally no time for detailed documentation or report writing. So is the rest of the bureaucracy—limited to minimum.
Project managers in critical/blitz projects must possess high autonomy, where project organization could be nothing less than a pure project structure and all team members reporting directly in the chain of command to the project leader (sometimes this form is called “skunk works”). And top management must be there all the time—to support and continuously monitor project progress. Without such commitment of all parties, blitz projects could not be launched successfully. Yet don’t forget, a single organization cannot embark on too many of those projects. One or two, at most, can be carried out at the same time since critical/blitz projects are hurting the rest of the organization: drawing important resources from other fast/competitive projects and alienating excellent project managers who do not enjoy the extent of commitment and priority of the blitz project.
Using the Different Frameworks
Who would use these frameworks and how would they be used? As our research shows, each one can be used in a different way, and by different stakeholders. The following exhibit summarizes the different models and their use.
In this paper we have shown how an organization can identify differences among projects and how to classify projects according to different dimensions and frameworks. The results accumulated over a period of a decade of research, some of it was published in the reference papers. However, in conclusion one should remember two points. First, the research is not over. With time, one should expect that additional and better frameworks would emerge. That is particularly true in the current age of global wireless and Internet world, or the emergence of biotechnology as the next possible revolution after the information revolution of today. Second, while these frameworks are quite universal and may serve many needs, any organization wishing to implement a framework for project classification, should look at its own situation, and adapt some of these frameworks, while maybe developing its own way for project classification, which will better fit its structure, strategy, and culture.
This research has benefited from the support, advice, and ideas of many individuals and organizations. The National Science Foundation provided support for the study of commercial competitive projects. In addition, various levels of support were granted by the Institute for Business Research at the School of Business at Tel-Aviv University, the Center for the Development of Technological Leadership at the University of Minnesota, and the Center for Technology Management Research and the Alliance for Technology Management at Stevens Institute of Technology. Finally, the Ministry of Defense in Israel provided resources and important access for the study of defense development projects.
Exhibit 2. Summary of Frameworks for Project Classification
Initial drafts had benefited from ideas by Alex Laufer, Zeev Bonen, Michael Doubey, Dov Eden, Simcha Ronen, Avi Nir-Grossfeld, Boaz Ronen, Shlomo Globerson, and Peter Koen. Ofer Levy helped in the development of the success dimensions framework. Many other students have also contributed to this study, among them, Michael Peled, Shlomo Klein, Scott Fricke, Z Hougui, A Lagerwaard, Paula Richards, Brian Cohn, and Brian Nofzinger. Max Wideman was a thought provoking partner in developing the work breakdown structure risk assessment framework. Finally, several members of the Project Management Institute (PMI®) group on project classification organized by Greg Githens and Brian Cohn suggested helpful and insightful comments on previous portions of this work. To all of them I am deeply indebted.
D. Dvir, S. Lipovetsky, A. J. Shenhar, and A. Tishler. (1998). In search of project classification: A non-universal approach to project success factors. Research Policy 27: 915–935.
Shenhar, A. J. (1991, December). Project management style and technological uncertainty: From low- to high-tech. Project Management Journal 22 (4): 11–14, 47.
———. (1992, March). Project management style and the space shuttle program: A retrospective look. Project Management Journal 23 (1): 32–37.
———. (1993). From low- to high-tech project management. R&D Management 23 (3): 199–214.
———. (1998). From theory to practice: Toward a typology of project management styles. IEEE Transactions on Engineering Management 41 (1): 33–48.
———. (2001, March). One size does not fit all projects: Exploring classical contingency domains. Management Science 47 (3): 394–414.
———. (2001).Contingent management in temporary organizations: The comparative analysis of projects. Journal of High Technology Management Research 12: 230–271.
Shenhar, A. J., D. Dvir, and Y. Shulman. (1995). A two dimensional taxonomy of products and innovations. Journal of Engineering and Technology Management 12: 175–200.
Shenhar, A. J., and D. Dvir. (1996). Toward a typological theory of project management. Research Policy 25: 607–632.
Shenhar, A. J., and Z. Bonen. (1997, March). A new taxonomy of systems: Toward an adaptive systems engineering framework. IEEE Transactions on Systems, Man, and Cybernetics 27 (2): 137–145.
Proceedings of PMI Research Conference 2002