Enhanced descriptions from Syndetics:

"Lean Thinking" has dominated product development and project management for over a decade. Now, however, a six-year study by MIT's International Motor Vehicle Program led by Michael Cusumano and Kentaro Nobeoka finds that, in order to dramatically improve product portfolios, Toyota and other leading companies are moving beyond single-project management on which lean thinking is based. In Thinking Beyond Lean, Cusumano and Nobeoka show that single-project management can produce isolated hit products and "fat" designs that contain few common components and many unnecessary parts and features. As a result, in this era of slowing growth and falling profits, leading companies are maximizing their investment by utilizing a groundbreaking concept the authors call "multi-project management." Drawing on a data base of 210 automobile products and detailed case studies from Toyota, Ford, GM, Chrysler, Nissan, Honda, Mazda, Renault, and Fiat, the authors demonstrate how product development teams can share engineers and key common components but retain separate designers to maintain distinctive product features. The result: multi-project management has brought these companies huge savings in development and production costs.<br> Cusumano and Nobeoka's findings will be required reading for every company that makes more than one product. Taking up where The Machine That Changed the World left off, Thinking Beyond Lean will change the way leaders do business now and in the future.

Excerpt provided by Syndetics

<opt> <anon I1="BLANK" I2="BLANK">Chapter One Introduction: Beyond "Lean" in Product Development This book is about how to manage product development more strategically and efficiently. We talk about multi-project management and the benefits this kind of thinking can bring to projects and to companies. The basic idea is to create new products that share key components but to utilize separate development teams that ensure each product will differ enough to attract different customers. If possible, projects that share components and engineering teams should overlap in time so that a firm can deliver many products quickly and utilize very new technologies. The evidence we have suggests that, if they follow these principles, firms can achieve dramatic improvements in performance -- huge savings in development costs (engineering hours) as well as remarkable growth in sales and market share. The examples and data we present are mainly from the automobile industry. The ideas, however, apply to many companies that have more than one product and want to expand the number of new products rapidly and efficiently. Managers, in our view, have a simple choice: They can manage new product development as if each project and product exists in isolation -- and possibly maximize their chances of delivering something fast and producing a "hit." Or, they can view each development project as part of a broader portfolio of projects-existing in the past, present, and future (Figure 1-1). If they follow multi-project thinking, then they can try to maximize the chances that the organization will produce a stream of new products that cover a range of market segments and make the best possible use of R&D investments. KEY QUESTIONS How to manage more than one project at a time is no simple matter, especially for companies that have many product lines, many projects to coordinate, and complex products with many components. Automobile manufacturers provide particularly excellent cases to study because of the challenges they face. They generally have numerous product lines and lots of projects ongoing simultaneously. Their products contain 30,000 or so components and usually take a million or more engineering hours per project to develop. The actual time and cost needed to create an automobile depend on how fast companies go through the different steps required. This speed, in turn, depends at least in part on how much they overlap functional activities such as concept generation (deciding what to design), product planning (determining product specifications and how a new product fits with other products), advanced engineering (coordinating the development of major components such as engines or transmissions with particular projects), product engineering (creating detailed designs for components and subsystems), process engineering (designing equipment and techniques for manufacturing), and pilot production (low-volume experimental manufacturing). A critical decision for automobile companies, or any company building a complex product with many components or subsystems, is whether or not to organize groups around functional activities or around projects that bring together people from the different functions or component areas. Most auto makers have moved toward a mixture of functional groups and projects (or clusters of projects, which we refer to as "development centers"). In doing so, all companies have debated how to balance what is optimal for the individual project versus what is optimal for the organization as a whole. In our discussions, we break down this problem into several issues, such as: Which functions should companies keep centralized to take advantage of scale and scope economies by providing engineering services and components (such as body design or engine technology) to more than one project? Which functions should companies disperse among projects in order to maximize the distinctiveness and innovativeness of the individual products? How much authority over budgets and personnel should a project manager have versus managers of functional departments? To what extent should companies seek a balance of functional with project management by grouping related projects together and then sharing some technologies as well as functions at least for clusters of similar projects? We try to provide answers to these and other questions. We base our arguments on detailed case studies and interviews with managers and engineers, as well as extensive analyses of data we have collected on automobile development projects and company performance. Before we discuss our results, however, we need to explain the background behind our concern for multi-project as opposed to single-project management in product development. LEAN PRINCIPLES AND SINGLE PROJECTS Most writings on best-practice in product development refer to single projects. This is true of Product Development Performance (1991) by Clark and Fujimoto, who first collected quantitative data from auto makers at the individual project level. This is also true of The Machine That Changed the World (1990) by Womack, Jones, and Roos, which summarized concepts that leading auto makers use to manage product development as well as manufacturing more efficiently. To characterize these "best practices," The Machine That Changed the World also used the word lean, a term coined by John Krafcik, who was a master's student at MIT in the mid-1980s. A more recent book, Lean Thinking (1996) by Womack and Jones, has extended some of these ideas about efficiency and eliminating waste to the organization of companies and operations more generally. Lean refers to a general way of thinking and specific practices that emphasize less of everything-fewer people, less time, lower costs. In product development, firms around the world in many industries now follow many of the lean concepts discussed in the books we have just cited (Table 1-1). Two especially important principles, which Clark and Fujimoto highlighted in particular, are the following: (1) overlapping different functional activities or development phases, such as concept generation, product engineering, and process engineering; and (2) using relatively independent product teams led by "heavyweight" project managers. The product teams usually bring together people from different engineering functions as well as marketing, and in this sense are cross-functional in organization. In addition, the heavyweight project managers generally have extensive control over product concepts as well as the people and budgets involved in component engineering, production preparations, and marketing. As a result, they have the ability to create distinctive new designs and then quickly move product concepts through the development process and into manufacturing. Other lean principles also contrast with the use of more traditional functional management practices in product development. In more traditional functional companies, for example, each engineering department tends to have a strong manager who hands off work to other departments, often in a sequential manner. This approach contrasts with relatively short, overlapping phases and crossfunctional teams guided by a strong project manager. There is no doubt that lean thinking has significantly improved project performance. During the 1980s, for example, many Japanese auto makers used heavyweight project managers, overlapping phases, and other techniques when they replaced and expanded their product lines nearly twice as often as U.S. and European companies. As seen in Table 1-2, the Japanese required only about two-thirds of the lead or calendar time required for the average project (about 45 months compared to 60 months or so for U.S. and European producers). They also needed approximately half the engineering effort (1.7 million compared to 3.4 million in the United States and 2.9 million in Europe). This efficient and rapid model change or expansion allowed Japanese auto makers to introduce many new features and quality improvements into their products as well as expand their sales. More important, we have learned that these practices and high R&D performance levels are not unique to Japanese firms. Table 1-2 includes data from a 1995 update of the Clark and Fujimoto survey. This indicates that auto makers around the world are adopting heavyweight or at least "middleweight" project management systems. We also can see companies moving toward comparable levels of performance in the time required for new product development (although U.S. auto makers tend to trail in product quality measures). BEYOND LEAN: MANAGING MULTIPLE PROJECTS We are not saying that heavyweight project management and other lean principles are now outdated. Tightly organized cross-functional teams are usually nimble and fast, especially if they overlap phases and give lots of authority to project managers and creative engineers. In addition, companies often can improve their chances of producing distinctive individual products by organizing autonomous product teams that focus on new designs or technologies. We are saying that, for managers, multi-project thinking usually fits reality much better than focusing on single projects, which lean practices in product development emphasize. Most companies have more than one product, and many companies have more than one new product under development at the same time. Companies may not deliberately link projects by sharing components. Nonetheless, any firm requires some sort of multi-project management if its projects compete for key engineers or financial resources, or target similar customers in the marketplace. Moreover, the evidence we have suggests that, over the long term, aiming simply for new designs or hit products in isolated projects is not enough: The best companies today view projects as part of a portfolio and make the most of their investments by introducing new technologies in as many products as possible as frequently as possible. In past years, Japanese companies such as Toyota and Honda, and then other firms such as Chrysler in the United States, decided to become leaner in product development by focusing on one project at a time and getting better products out the door faster. Their goal was to increase market share almost at any cost. Since the mid-1980s, however, growth for many auto makers has slowed or stopped, and profits have fallen dangerously low in many years. The key problem has since become how to replace products and occasionally expand product lines with innovative, high-quality models that minimize development and production costs. Not surprisingly, leading companies have already shifted their attention beyond simply the efficient management of individual projects. We can see some evidence of this in Table 1-2. In the early 1990s, Japanese firms slowed down many of their development projects. Though they still required fewer engineering hours than U.S. or European projects, compared to the 1980s, the Japanese took an extra nine months per project in this sample. Our interviews suggest that this is because they were taking more time in planning and focusing more on how to create innovative designs and avoid low-value features and unnecessary unique parts. Indeed, the data indicates that Japanese projects in the 1990s did increase their usage of common parts. This contrasts with the United States, where some companies reduced their emphasis on common parts in the early 1990s (see Table 1.2). The reverse trend now seems to be occurring, however, as U.S. companies move more toward platform sharing and what we call multi-project management. This rethinking of product development in Japan and elsewhere occurred because there is at least one drawback to an exclusive focus on single projects: Heavyweight project managers can become too heavy. At leading Japanese companies, for example, projects accumulated so much autonomy that they produced "fat" designs-too few common components and too many unnecessary features and options. As a result, however well they managed individual projects, these companies fell into the trap of optimizing product development for the good of each project rather than for the good of the firm as a whole. Six years of research have convinced us that the best way to work for the good of the firm and create a portfolio of products at low cost is to shift the company mindset and organization into a multi-project mode. This means that a firm will develop some totally new products but focus an equal amount of attention on developing common core components and quickly sharing these across multiple projects. Moreover, we have observed that companies can coordinate projects deliberately or in an ad hoc manner. The best companies, such as Toyota, follow a deliberate approach and leave little to chance. They create families of well-integrated products that share design concepts as well as key components and basic technologies. Multi-project management, as we describe it in this book, thus requires conscious, planned efforts to link a set of projects strategically, through product portfolio planning, technologically, through the design of common core components, and organizationally, through overlapping the responsibilities and work of project managers and individual engineers. STRATEGIES AND ORGANIZATIONS FOR MULTIPLE PROJECTS Once companies establish a clear strategy for linking multiple projects, they need to create an appropriate organization and management processes to make this strategy work. In this book, we do not suggest to managers what specific products to build or what components to share, or how to manage the details of engineering work. Rather, we give many examples of good practice. We also present frameworks and data analyses that should help managers form their own multi-project strategies as well as find better ways of organizing product development in their own companies. A useful start to explain our thinking is Figure 1-2, which presents our framework for project strategies. This focuses on how companies can link projects in order to share platform technologies that define the basic structure and performance of a new automobile product. The typology categorizes new projects into four types, depending on the extent of new technology or changes in a platform, how projects use the platform technology, and how fast or slow a company transfers a platform from one project to another. These four types cover all kinds of development projects and are mutually exclusive. The analysis in this book focuses on the design strategy for vehicle platforms in new cars, although the same framework can apply to major components for other products as well. Projects that develop platforms primarily from scratch we categorize as the first type, new design. This strategy is most appropriate for incorporating the latest technology or totally new designs into a product without placing many restrictions on the development team. The distinction between new design and the other three types is conceptually similar to the difference between radical and incremental innovations. Our framework, however, breaks down incremental changes into three types, depending on the strategy for leveraging technology. Our next two strategies require projects to share a platform with other projects in the firm. In the second type, concurrent technology transfer, a new project begins to borrow a platform from a base or preceding project before the base project has completed its design work. Generally, this transfer occurs within two years after the introduction of the original or base platform. Because some of the development phases overlap chronologically, engineers in the new project and the base project can discuss adjustments in the platform and other component designs. This overlap, therefore, provides opportunities for effective and efficient technology sharing. In order to make this sharing work, however, the two interdependent projects often require extensive coordination and thus some form of multi-project management. In the third type, sequential technology transfer, a project inherits a platform from a base project that has finished its design work. In other words, the second project reuses a platform design that already exists. It is "off-the-shelf." The reused platform is already relatively old compared to designs transferred while a base model is being developed, as in concurrent technology transfer. In addition, design constraints may be very high in sequential technology transfer because engineers from the two projects cannot make adjustments in the platform to suit the different products. In other words, the following project may have to force changes to accommodate elements of the core design and other components from the preceding project. This may result in too many design compromises and poor integration of product features and subsystems. Thus, sequential transfers may not be as efficient or effective as concurrent technology transfers. The last type, design modification, refers to a project that replaces an existing product but without creating a new platform or borrowing a platform from another product line. The modification project simply inherits or reuses the platform from the predecessor model in the same product line, perhaps with some minor changes. Design modification and sequential technology transfer are similar in that both inherit an existing platform from a predecessor product, although, in design modification, there is no transfer from another project. This type of project also can have no ongoing coordination with a base project. Therefore, engineers have to live with any constraints imposed by the platform of the predecessor (i.e., the current) model. We can see these four strategies at work in Figure 1-3, which maps out a decade of product histories at three auto makers. Each horizontal line represents a distinct model line, such as the Honda Accord or the Acura Integra. The circles indicate when the company introduced a model change. The dark circles indicate the introduction of a new platform. The open circles indicate a new product based on the transfer or utilization of an existing platform from another model line or the previous model in the same line. The arrows indicate the direction of the platform technology transfers. Company A (which is Chrysler) developed a new platform only once during this period, in 1980. Over the next decade, it utilized this same platform with some modifications in a series of new model lines and new generations of models. This reuse strategy was extremely economical and no doubt reflected the company's financial difficulties during these years. (It faced bankruptcy and the U.S. government bailed it out with a loan guarantee.) Given the circumstances, reusing the same platform for many years was a successful strategy. Nevertheless, one platform cannot usually meet changing market needs and technology evolution over a long time period. Indeed, by the early 1990s, this company faced another crisis due to negative customer reactions to its old products. It then encountered the daunting problem of creating new platforms for most of its existing models within a very short period of time. Company B (which is Renault) on one occasion transferred a platform from one model line to another. Usually, however, it developed new platforms each time it replaced a product or added a new product line. This approach represented an attempt to optimize the performance of each new product or product replacement. It was an expensive strategy, however, due to the costs of developing so many new platforms. No doubt this approach limited the number of new products and replacements the company introduced. Company C (which is Honda) followed a different strategy. In particular, in the later 1980s, we can see that it developed a new platform for one product line and then, in parallel projects, quickly transferred this platform to other product lines. It also developed another new platform and transferred this to a second product line. Both Company A and Company C exhibit aggressive multiproject strategies in that they frequently transferred platforms across different projects. Compared to Company A, however, Company C mixed new development (the new platforms) with incremental development (products with platforms derived from other products). Moreover, Company C transferred relatively new technologies even to projects that inherited an existing platform. Compared to Company B, we think that Company C made more effective use of its new platform investments. Using the terminology of Figure 1-2, we would say that Company B (Renault) is a good illustration of the new design strategy (Type 1). All three companies at some point created new platform designs, although they did not rely so heavily on this strategy when introducing new products or replacing existing products. Company C (Honda) presents the clearest case of concurrent technology transfer (Type 2). In the 1980s, this company developed a new platform for the Civic. The design included all-wheel double-wishbone suspension technology, which was highly innovative for cars of this class. Before completing the development of the Civic, however, Honda transferred this platform to two other independent projects (the Integra and the Concerto) that it was managing concurrently. Honda, therefore, quickly leveraged a new technology in more than one product line. Company A (Chrysler) presents the best illustration of sequential technology transfer (Type 3). In 1980, it developed an innovative front-wheel-drive platform for small cars in its K-car project, and introduced this into the Aries/Reliant model. Over the next 11 years, it reused this platform in nearly every other new car product that it introduced, transferring this platform sequentially from one project to another. Chrysler also modified at least one product without changing the platform (Type 4). If we extended the time period under analysis, we would see nearly all companies simply modifying some products without changing the platform. Not all products require frequent changes (for example, economy cars such as the Toyota Corolla and the Nissan Sentra, as well as luxury cars such as Porsche, Mercedes, and BMW models, change platforms relatively infrequently). In addition, carrying over components from one product generation to another is an important strategy for reducing costs. We demonstrate that projects and companies that rely more heavily on concurrent technology transfer perform better than companies that rely more on the other strategies we have identified. We summarize our findings in Table 1-3 and discuss the analysis in chapters 5 and 6. According to our research, auto makers that followed concurrent technology transfer more often (that is, they tended to create a second product quickly after each new platform design) would grow between 37 and 68 percent more over three years compared to firms that followed one of the other three strategies. Moreover, companies that quickly transferred platform technologies saved between 33 and 64 percent in engineering hours compared to firms following the other strategies. They also saved between 12 and 17 percent in lead time over projects that relied on new platform designs. Even companies that are excellent already can improve their performance by thinking about how to manage multiple projects. For example, Toyota, which many companies use as a benchmark for excellence in manufacturing and engineering, introduced a new organizational structure in 1992-1993 specifically to support what we would call the concurrent technology transfer strategy. It then reduced its engineering costs for new models by 30 percent as well as cut lead time by several months. These results are especially remarkable given that Toyota was already a highly efficient user as well as the originator of heavyweight project managers and other lean practices. The Toyota case also demonstrates the importance of linking product strategies and organizational strategies in product development. Figure 1-4 summarizes our framework for thinking about the range of organizational options available to managers. Of course, these are ideal organizational types that exist more as a spectrum than as a set of fixed practices. The spectrum varies, for example, by how much companies overlap or integrate phases, or how much authority they give to project managers versus functional department managers. Although it is beyond the scope of this study to treat the topic in detail, we also believe that the most complex form of multi-project management involves multiple projects at more than one firm. This multi-firm multi-project strategy occurs, for example, when two companies cooperate to develop one platform and then each partner uses this platform to create distinct products in separate projects. The cases are few but increasing among automobile companies as well as in other industries. The benefits of multi-project management also should apply to a firm that shares platforms and other technologies with another company, although coordinating this technology transfer across firms can be more difficult than within a firm. As suggested in the Honda case that we just cited, however, multi-project management can be complex to implement and requires a certain level of organizational sophistication. It requires extensive planning and physical coordination among various component technologies, project teams, and the work of individual engineers and managers. Therefore, we consider companies that succeed in multi-project management to be more advanced in strategic thinking as well as organizational capabilities compared to firms that simply manage projects one at a time or utilize traditional functional departments or even traditional matrix structures. We also recognize that, while multi-project management may be a new term, it is not a new concept. Fundamentally, it deals with the age-old problem of how to meet a variety of customer needs as efficiently as possible. This is a problem common to managers in many industries. Recent ideas in the management literature that deal with this problem include "mass customization, " which addresses how to accommodate different customer needs with products that mix standardized and customized components. Similar notions include "product families" and "platform management," as well as component "reuse" and object technologies, such as in software engineering. If a firm is particularly skilled in technology creation, moreover, multi-project management makes it possible to leverage another popular notion -- a "core competence." For example, a company can use either concurrent or sequential technology transfer to develop product platforms and then quickly diversify into related markets at minimal cost. PLAN OF THE BOOK We have organized our study into eight chapters. We begin with company discussions that lay out the basic strategic, organizational, and managerial issues. We then probe more deeply into how different strategies and organizational forms affect performance at the project level and at the company level. Chapter 2 begins by detailing recent changes at Japan's leading auto maker, Toyota. This company moved beyond lean thinking and heavyweight project managers in the early 1990s when it reorganized its product development groups around platform centers. Toyota did this specifically to facilitate a new multi-project strategy, with the excellent results we noted above. Chapter 3 then compares the strategies and structures for product development at nine leading auto makers in Japan, the United States, and Europe. All of these companies try to leverage technology across projects, although we discuss how some continue to focus mainly on single projects, while others manage multiple projects but in different ways. Chapter 4 discusses different strategies for product development and multi-project management, such as radical versus incremental innovation, and platform sharing, and then relates these ideas to our four multi-project strategy types. Chapter 5 then analyzes the impact of our four strategies on project performance, measured by lead time and engineering hours in a sample of 103 projects. This discussion highlights the cost savings possible by overlapping development work across multiple projects. Chapter 6 examines the impact of our four multi-project strategies on company performance, measured by market share and sales growth at all the world's leading auto makers, based on an analysis of 210 projects. This discussion highlights how sales and market share can grow faster if firms rapidly transfer platform technologies across different projects. This sharing enables firms to increase their productivity in new product development -- again, as long as companies ensure that individual products do not end up looking too much alike. Chapter 7 returns to the subject of organizational issues and focuses on requirements for effective multi-project management and concurrent technology transfer, such as matrix management and the need for especially good communication and knowledge transfer skills among engineers and project managers. Chapter 8 concludes with implications and lessons for managers. Copyright © 1998 by Michael A. Cusumano and Kentaro Nobeoka Excerpted from Thinking Beyond Lean: How Multi Project Management Is Transforming Produ by Michael A. Cusumano, Nobeoka Kentaro All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.</anon> </opt>

Author notes provided by Syndetics

Michael A. Cusumano is Sloan Distinguished Professor of Management at MIT's Sloan School of Management. A leading expert on the strategic management of technology, Professor Cusumano is co-author of Microsoft Secrets and the author of The Japanese Automobile Industry and Japan's Software Factories.